Facebook iOS SDK Remotely Crashing Spotify, TikTok, Pinterest, Winno and More(github.com)
github.com
Facebook iOS SDK Remotely Crashing Spotify, TikTok, Pinterest, Winno and More
https://github.com/facebook/facebook-ios-sdk/issues/1374
375 comments
I'm shocked but perhaps not surprised at many of the comments in that thread. These people are app developers who voluntarily link in huge multimegabyte binary-only third party sdks, and then act surprised that the code they are linking is prone to crashing? It should be obvious that any bug in such an SDK might bring down any app, even on launch and even if your own code never makes an explicit call to the SDK.
Third party SDKs have free reign in your apps. They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.
It gives the SDK developers a foothold inside each app's sandbox/keychain/developer-specific app ID. It must be a gold mine for correlating and tracking users across apps and websites, breaking down the intended barrier between different apple developer team IDs and app containers.
Last time I checked one of these binary SDKs along the likes of FB, Gmaps, etc just running strings on the binary framework lib was enough to send chills down any developer's spine.
Third party SDKs have free reign in your apps. They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.
It gives the SDK developers a foothold inside each app's sandbox/keychain/developer-specific app ID. It must be a gold mine for correlating and tracking users across apps and websites, breaking down the intended barrier between different apple developer team IDs and app containers.
Last time I checked one of these binary SDKs along the likes of FB, Gmaps, etc just running strings on the binary framework lib was enough to send chills down any developer's spine.
We are now in a “dependency-oriented programming environment” (D.O.P.E) world.
One the one hand, it’s easy to sniff at the use of dependencies, when we have these kinds of disasters, but on the other hand, dependencies give us the ability to do truly great stuff.
For example, I program Apple devices (not just iOS). I wrote my first Apple code in 1986, so I have some “prior art.” I’ve “seen it all.”
I remember the days of MPW and MacApp, which spent most of its life in beta (Photoshop was initially based on MacApp 1.0b9, when it was first released).
Writing a full GUI experience was hard. It could take weeks to get a fairly basic app up and going.
Nowadays, with the various flavors of the Cocoa Application Framework, I can have a fairly full-featured app up in just a couple of hours.
Cocoa (and its implementation SDKs, like UIKit) is a dependency.
That said, I like to avoid dependencies wherever possible, relying on real “core” dependencies, like OS infrastructure.
It’s just that I can’t justify building my own power plant, when I can simply pay for a hookup from the pole.
There’s a good reason for the current DOPE.
Many corporations are using DOPE to “embrace and extend,” to an extent that makes Microsoft’s antics in the oughties look like child’s play.
When we use an SDK as the basis of our apps, we are giving them a huge amount of trust. They have access to everything our app can reach, which is often a lot. It also means that we may not have anyone on staff that actually knows what’s going on, under the hood, as we rely on the dependency to do most of the heavy lifting.
Apple’s App Store approval process is a pain, but this is the kind of thing they try to avoid. There’s just no way they can account for everything, and some corporations are getting very good at the whole “camel’s nose” thing.
I think that the “Wild West” nature of DOPE will shake itself out, sooner or later, with a few solid, trusted SDKs rising from the ashes.
There’s just gonna be a lot of collateral damage, on the way.
One of the worst things, is to build on a dependency, then have it collapse (or corrupt) down the road. That can be devastating.
BTW: I use the acronym “DOPE” for a reason.
The spice must flow...
One the one hand, it’s easy to sniff at the use of dependencies, when we have these kinds of disasters, but on the other hand, dependencies give us the ability to do truly great stuff.
For example, I program Apple devices (not just iOS). I wrote my first Apple code in 1986, so I have some “prior art.” I’ve “seen it all.”
I remember the days of MPW and MacApp, which spent most of its life in beta (Photoshop was initially based on MacApp 1.0b9, when it was first released).
Writing a full GUI experience was hard. It could take weeks to get a fairly basic app up and going.
Nowadays, with the various flavors of the Cocoa Application Framework, I can have a fairly full-featured app up in just a couple of hours.
Cocoa (and its implementation SDKs, like UIKit) is a dependency.
That said, I like to avoid dependencies wherever possible, relying on real “core” dependencies, like OS infrastructure.
It’s just that I can’t justify building my own power plant, when I can simply pay for a hookup from the pole.
There’s a good reason for the current DOPE.
Many corporations are using DOPE to “embrace and extend,” to an extent that makes Microsoft’s antics in the oughties look like child’s play.
When we use an SDK as the basis of our apps, we are giving them a huge amount of trust. They have access to everything our app can reach, which is often a lot. It also means that we may not have anyone on staff that actually knows what’s going on, under the hood, as we rely on the dependency to do most of the heavy lifting.
Apple’s App Store approval process is a pain, but this is the kind of thing they try to avoid. There’s just no way they can account for everything, and some corporations are getting very good at the whole “camel’s nose” thing.
I think that the “Wild West” nature of DOPE will shake itself out, sooner or later, with a few solid, trusted SDKs rising from the ashes.
There’s just gonna be a lot of collateral damage, on the way.
One of the worst things, is to build on a dependency, then have it collapse (or corrupt) down the road. That can be devastating.
BTW: I use the acronym “DOPE” for a reason.
The spice must flow...
For Java you can actually control a lot of this through a security manager: https://stackoverflow.com/questions/5401281/preventing-syste...
And I think you can even control the loading through a custom class loader.
It's a bit of work but it should give you decent oversight over the dependencies you really don't trust but have to use.
And I think you can even control the loading through a custom class loader.
It's a bit of work but it should give you decent oversight over the dependencies you really don't trust but have to use.
You can hack things through reflection. You can use Gradle directives to specifically exclude certain dependencies of your dependencies. You can use ProGuard to strip out the parts of libraries you don't need.
A side note: on Android, class loaders are definitely of no use for this purpose. Android runtime uses its custom bytecode language and file format that packs the entire classpath of your app into one .dex file. You can't load separate classes from these, only the entire thing all at once.
(yes there's multidex for large apps but the way classes are split between files is rather random in my experience)
A side note: on Android, class loaders are definitely of no use for this purpose. Android runtime uses its custom bytecode language and file format that packs the entire classpath of your app into one .dex file. You can't load separate classes from these, only the entire thing all at once.
(yes there's multidex for large apps but the way classes are split between files is rather random in my experience)
Also arguing about phoning home in a constructor versus some init() function misses the point. Why would you dynamically link to an SDK that you don't initialize?
> They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.
Unrelated to Facebook, but some malicious SDK already doing it. For example, Igexin(https://blog.lookout.com/igexin-malicious-sdk), and it's not the only one.
Be careful when importing anything.
Unrelated to Facebook, but some malicious SDK already doing it. For example, Igexin(https://blog.lookout.com/igexin-malicious-sdk), and it's not the only one.
Be careful when importing anything.
Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?
An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.
That's only if you don't review the changes, and trace the entry points at least.
Turns out if you're linking in code (or even calling out to it, but that's another level of effort) you should probably have the source, or have a person on your team who can do basic RE.
(For the iOS engineers reading along: please don't put network calls in +load, or __attribute__((constructor)), or a C++ static variable, or whatever other clever way you think you can get code execution before main.)
For the iOS developers reading along: please ban this behaviour in a future version?
This is akin to banning any application that calls 'malloc' and 'free'.
To do ban static constructors they'd have to literally ban anything that links the C++ runtime, which is almost literally everything on your system.
Not possible.
To do ban static constructors they'd have to literally ban anything that links the C++ runtime, which is almost literally everything on your system.
Not possible.
Not 'ban static constructors', sorry if I wasn't clear. Ban network I/O before main() has started.
Not just network calls, but also the file system, or basically anything nontrivial.
C++ static variables can now be annotated with constinit to resolve issues like this: https://en.cppreference.com/w/cpp/language/constinit It basically asks the compiler to enforce that constructor calls can only do trivial things.
C++ static variables can now be annotated with constinit to resolve issues like this: https://en.cppreference.com/w/cpp/language/constinit It basically asks the compiler to enforce that constructor calls can only do trivial things.
Even better: don't override +load or use static constructors!
Eh, I wouldn't go that far; they do have their uses. But for a SDK author, it pays to be excessively cautious when putting things on the application startup path. (Something which the Facebook is well aware of, as the dyld session is always full of their company's engineers, and the architecture of their app shows that put effort into meeting launch deadlines…)
Every bad thing has its uses. If an SDK author wants to be a responsible participant in the app's startup path, it will defer its own setup to the app.
`__attribute__((constructor))` is most obviously a hack – like any great hack, it is useful enough to be implemented everywhere, but it will never be standardized because everyone acknowledges that it sucks. I used to use it! But it is extremely limited in its usefulness, and there are always better solutions to the problem.
`__attribute__((constructor))` is most obviously a hack – like any great hack, it is useful enough to be implemented everywhere, but it will never be standardized because everyone acknowledges that it sucks. I used to use it! But it is extremely limited in its usefulness, and there are always better solutions to the problem.
(non C++ developer here) What is the +load being referred?
It's Objective-C being referred to here: the "+" prefix indicates a class method.
Any class can implement +load and the runtime will call the method upon loading the class (note, this doesn't require using it at all).
https://developer.apple.com/documentation/objectivec/nsobjec...
Any class can implement +load and the runtime will call the method upon loading the class (note, this doesn't require using it at all).
https://developer.apple.com/documentation/objectivec/nsobjec...
Spoken like someone who has never tried to optimize startup time. If network is your blocker, you need to do it as soon as possible
Putting more code in a constructor is almost never advised. I would expect that whatever connection the Facebook SDK is making is not a blocker for application launch. (If you have more insight on why this code must unconditionally run this early, I would be glad to hear it.)
Running code before main has nothing to do with performance.
It surely does, performance is more about just raw CPU. Prefetching data (even a DNS query) reduces the latency the user perceives.
The web similarly added the various <link rel=preload, dns-prefetch> tags, so things can be connected and fetched before the JS/CSS code is ready
The web similarly added the various <link rel=preload, dns-prefetch> tags, so things can be connected and fetched before the JS/CSS code is ready
The gain from trying to eke out a millisecond by executing network or filesystem I/O code before main() is extremely marginal compared to the can of worms opened by doing that.
The next evolution of "every app in a sandbox" must surely be custom sandboxes for individual libraries within apps. The main app could selectively delegate permissions of its own (like network, camera) to the libraries, for example after obtaining user consent.
I don't quite see how this would evolve?
Some logical consequences of this outage:
* Apple may ask, "what is this SDK doing and why can't it be done with IPC"?
* Other app developers may start thinking harder about the risks of SDKs and ask "why do I need this and how can I not take the reliability / security risks of code I haven't reviewed"?
* an unlikely, but not impossible outcome, is that people start looking at letting processes drop capabilities, maybe even forking SDK code into it's own subprocesses. But... why not just make the SDK ship as a separate process as part of a different app at that point? Linux I know has tons of capabilities available, yet security engineers often complain about tons of apps just not even trying to use them. So I'm skeptical anything major will change here.
But there's probably never going to be anything to guarantee that developers don't submit 3rd party code as part of their apps, effectively pretended it's their own. And as long as Apple can't tell SDK code from your original code, how can they do anything about it?
I suppose they could look at popular SDKs and make some sort of bytecode signatures of them, but that mostly just serves to figure out which apps use which SDKs, which might be useful for review or malware detection, but it's unlikely to have the fidelity to actually enforce stronger error boundaries or security boundaries.
Some logical consequences of this outage:
* Apple may ask, "what is this SDK doing and why can't it be done with IPC"?
* Other app developers may start thinking harder about the risks of SDKs and ask "why do I need this and how can I not take the reliability / security risks of code I haven't reviewed"?
* an unlikely, but not impossible outcome, is that people start looking at letting processes drop capabilities, maybe even forking SDK code into it's own subprocesses. But... why not just make the SDK ship as a separate process as part of a different app at that point? Linux I know has tons of capabilities available, yet security engineers often complain about tons of apps just not even trying to use them. So I'm skeptical anything major will change here.
But there's probably never going to be anything to guarantee that developers don't submit 3rd party code as part of their apps, effectively pretended it's their own. And as long as Apple can't tell SDK code from your original code, how can they do anything about it?
I suppose they could look at popular SDKs and make some sort of bytecode signatures of them, but that mostly just serves to figure out which apps use which SDKs, which might be useful for review or malware detection, but it's unlikely to have the fidelity to actually enforce stronger error boundaries or security boundaries.
The Facebook SDK does make some calls on init.
https://developers.facebook.com/docs/app-events/gdpr-complia...
From them: "The Facebook SDK automatically initializes when the app is opened. When the SDK is initializing, it fetches app settings from Facebook. If you want to block all network requests to Facebook, you can disable automatic initialization." If you want to turn it off, you're supposed to set in your app's plist <key>FacebookAutoInitEnabled</key><false/>.
If people are claiming that the SDK is still fetching despite adding that key, that could be breaking some compliance and consent laws...
https://developers.facebook.com/docs/app-events/gdpr-complia...
From them: "The Facebook SDK automatically initializes when the app is opened. When the SDK is initializing, it fetches app settings from Facebook. If you want to block all network requests to Facebook, you can disable automatic initialization." If you want to turn it off, you're supposed to set in your app's plist <key>FacebookAutoInitEnabled</key><false/>.
If people are claiming that the SDK is still fetching despite adding that key, that could be breaking some compliance and consent laws...
I would be shocked...
> If people are claiming that the SDK is still fetching despite adding that key, that could be breaking some compliance and consent laws...
It is still a violation of GDPR as I as the user never have the chance to consent (or not consent!) to any data transfer to Facebook. But as no one seems to be willing to go after FB... sigh.
It is still a violation of GDPR as I as the user never have the chance to consent (or not consent!) to any data transfer to Facebook. But as no one seems to be willing to go after FB... sigh.
This is not a violation by Facebook, this is a violation by the app developer.
Technically yes, but it is as much also FB's fault for providing an SDK that cannot be used without violating the GDPR.
but that's the point: It can be. Just add that key to the plist file and the SDK won't initialize and won't do any requests by default.
This is absolutely on the app developers. Not knowing what an SDK you linked does or doesn't do doesn't absolve you from GDPR (or any law for that matter)
This is absolutely on the app developers. Not knowing what an SDK you linked does or doesn't do doesn't absolve you from GDPR (or any law for that matter)
Is it a violation of GDPR if the data is anonymized?
Who is auditing if the data is anonymized?
It is, as FB will automatically get at least the IP address, date and time which is seen as PII under GDPR.
All of this because app developers can't be bothered to add one line of code...
This isn't on app developers.
This is on FB for not being forthcoming and stating very clearly that the SDK is doing that in their docs.
Is it documented somewhere? Sure, probably.
But if your SDK is doing something _very unusual_ and goes against platform conventions and best practices, and 99,9% of the people integrating the SDK _have no idea_ about it, it's your fault for not explaining what and why you're doing it.
This is on FB for not being forthcoming and stating very clearly that the SDK is doing that in their docs.
Is it documented somewhere? Sure, probably.
But if your SDK is doing something _very unusual_ and goes against platform conventions and best practices, and 99,9% of the people integrating the SDK _have no idea_ about it, it's your fault for not explaining what and why you're doing it.
For those wondering why the Facebook SDK is so widely used in popular mobile apps: Facebook Login is actually in the minority of reasons to add the Facebook SDK to your mobile app. The vast majority of apps will add the Facebook SDK because it contains Facebook App Ads; a library that "completes the circle" in terms of finding out how effectively the ads you ran on Facebook were at getting people to download, install and run your mobile app. So really the Facebook SDK is there to collect data of that advertisement being effective and provides both Facebook and the mobile app developer with knowledge of how their ad spend went.
Is that "spyware"? Some would call it merely wanting to know if your marketing budget was wisely spent - I suppose a lot depends on what data it collects on people.
More info: https://developers.facebook.com/docs/app-ads
Is that "spyware"? Some would call it merely wanting to know if your marketing budget was wisely spent - I suppose a lot depends on what data it collects on people.
More info: https://developers.facebook.com/docs/app-ads
Thankfully we removed FB several years ago when I found it sending data to FB servers that we did not authorize, we support our own logins for our own customers and there was no reason to use it (not sure the history before I got here). Sadly we do use Google Maps and got bit for weeks when that fiasco happened recently. I wish we could just use Apple Maps for iOS but somehow we have some marketing deal or something with Google.
It’s spyware when the user is unaware of it and their usage data is used without their consent.
If the parties consent to it, it’s fine. When it’s hidden and nonconsensual is where the problem arises.
If the parties consent to it, it’s fine. When it’s hidden and nonconsensual is where the problem arises.
Can’t you just use a simple tracking pixel?
>Is that "spyware"?
Yes, absolutely.
It uses energy and bandwidth I paid for to surreptitiously transmit my information for use which will solely benefit Facebook and the software developer.
Yes, absolutely.
It uses energy and bandwidth I paid for to surreptitiously transmit my information for use which will solely benefit Facebook and the software developer.
If it benefits the software developer and this is what allows their business to work, then that benefits you. If it didn't then you wouldn't have the app.
That definition is rather too broad. It makes basically everything spyware which dilutes the word too much to be useful.
Nowadays, lots of things are spyware. It's important that we acknowledge this fact. Back when the Internet had a more technical userbase, the shady nonsense software tries to pull nowadays would not have flown at all. Those people would be outraged, and they'd absolutely agree that things like Facebook, Spotify, and Windows 10 meet the definition of spyware.
But slowly, the Internet population grew to include the masses, and it turns out most people don't care whatsoever about what their software is doing or how it works so long as it gets the job done, whether that's communicating with relatives, playing music, or providing a platform for other applications.
But slowly, the Internet population grew to include the masses, and it turns out most people don't care whatsoever about what their software is doing or how it works so long as it gets the job done, whether that's communicating with relatives, playing music, or providing a platform for other applications.
This is what happens to every charged label.
1. People realize the label is powerful.
2. They begin applying the label to as many things they don't like as they can get away with.
3. This changes the definition of the label, causing it to become some blanket umbrella term.
4. The label loses its power, because it now describes many lukewarm behaviors instead of just the worst offenses.
For example, it's popular nowadays to say "everyone is racist." Well, if everyone is racist, is being labeled a racist really that bad? Not compared to what it used to imply about you.
1. People realize the label is powerful.
2. They begin applying the label to as many things they don't like as they can get away with.
3. This changes the definition of the label, causing it to become some blanket umbrella term.
4. The label loses its power, because it now describes many lukewarm behaviors instead of just the worst offenses.
For example, it's popular nowadays to say "everyone is racist." Well, if everyone is racist, is being labeled a racist really that bad? Not compared to what it used to imply about you.
>That definition is rather too broad. It makes basically everything spyware which dilutes the word too much to be useful.
I don't agree. I was very specific in stating that the practice of consuming a user's resources to transmit their information, without their explicit consent, nor an indication of the activity, for the sole benefit of Facebook and the software developer, can absolutely be considered spyware.
I don't agree. I was very specific in stating that the practice of consuming a user's resources to transmit their information, without their explicit consent, nor an indication of the activity, for the sole benefit of Facebook and the software developer, can absolutely be considered spyware.
And you since you installed the app for some purpose.
If the software developer didn't get anything off you they wouldn't make the software available to you in the first place.
If the software developer would charge a reasonable price directly to the user, they wouldn't have to use intrusive and unreliable libraries like Facebook SDK.
And yet FOSS exists.
And paid software (such as Spotify) still does shady stuff like reporting to Facebook that I'm a user of their app and the schedule on which I use it.
And paid software (such as Spotify) still does shady stuff like reporting to Facebook that I'm a user of their app and the schedule on which I use it.
I'd rather pay for the app directly actually.
Fuck, I've been paying for Spotify as an act of charity?
Spotify is actually using Facebook for login, though, so they don't necessarily use App Ads. The original commenter only said that it's the reason most (but not all) apps use the SDK.
Ah. I'm thankful for the opportunity, err... requirement to trade my privacy for others to have one fewer password to deal with. And of course for Facebook to have more personal data to munch on.
I'm not really sure what the problem is here. You are perfectly free to not use Spotify, or any other app that chooses to utilize Facebook login or other components of the Facebook SDK. Spotify made their choice to use the SDK for whatever gains they get out of it, and as a customer you can choose to not use their service or app if you disagree with that.
There's even comments in this HN thread that point you on how to do it on Android if you're so inclined.
There's even comments in this HN thread that point you on how to do it on Android if you're so inclined.
This is really just a variant of the "and yet you participate in society, hmmm" argument.
At some point users are allowed to complain about shady behaviour done by huge corporations with resources they use to try to thrust their way into everyones lives.
At some point users are allowed to complain about shady behaviour done by huge corporations with resources they use to try to thrust their way into everyones lives.
And at some point, companies are allowed to make their own decisions about how they want to instrument and monetize their products. This general complaint about not liking a component of someone else's software doesn't resonate with me at all. Not that you're wrong, but we just have different values.
I sometimes will load a website that uses React when really it's just a static content site. It just gets tiring, and doesn't add to the conversation, when every discussion about an article that could be HTML devolves into that. I get that other people feel that way, and in many ways I share their values... But it becomes its own sideshow and hijacks the otherwise interesting conversations, without adding anything new.
I sometimes will load a website that uses React when really it's just a static content site. It just gets tiring, and doesn't add to the conversation, when every discussion about an article that could be HTML devolves into that. I get that other people feel that way, and in many ways I share their values... But it becomes its own sideshow and hijacks the otherwise interesting conversations, without adding anything new.
<< I get that other people feel that way, and in many ways I share their values... But it becomes its own sideshow and hijacks the otherwise interesting conversations, without adding anything new. >>
With sincere respect, I don't understand this argument, in general, whenever it comes up. Whenever I find a discussion unhelpful or tedious, I move on or mute it. Often, I've been in an interesting online discussion, and someone pipes up with the wish for everyone to stop talking about this topic because it's not interesting, when they have the tools available to not follow the discussion.
Can you explain? Honest question.
With sincere respect, I don't understand this argument, in general, whenever it comes up. Whenever I find a discussion unhelpful or tedious, I move on or mute it. Often, I've been in an interesting online discussion, and someone pipes up with the wish for everyone to stop talking about this topic because it's not interesting, when they have the tools available to not follow the discussion.
Can you explain? Honest question.
At the risk of getting downvotes for being snarky, it essentially boils down to the "Stop it, you're having fun wrong!" nerd stereotype.
>> And at some point, companies are allowed to make their own decisions about how they want to instrument and monetize their products.
No, they are only allowed to monetize according to laws and regulations. There is nothing magic about software making it right to disregard laws or not having respect for customers. It feels like some think software should be where to world was at the start of the industrial revolution, where companies could do what they wanted and there was no laws stopping them from dumping acid in the river.
Edit: fixed spelling
No, they are only allowed to monetize according to laws and regulations. There is nothing magic about software making it right to disregard laws or not having respect for customers. It feels like some think software should be where to world was at the start of the industrial revolution, where companies could do what they wanted and there was no laws stopping them from dumping acid in the river.
Edit: fixed spelling
Obviously companies can choose how they want monetize, that doesn't mean you are obligated to defend then when what they're doing is scummy it immoral.
Why deflect criticism.by saying "well you don't have to use their app now do you?"
When a person does something immoral rarely do people defend them by saying "well you don't have to engage with them now do you?
Why not debate the morality or legitimacy of the act in question rather than deflect try to deflect the criticisms?
Why deflect criticism.by saying "well you don't have to use their app now do you?"
When a person does something immoral rarely do people defend them by saying "well you don't have to engage with them now do you?
Why not debate the morality or legitimacy of the act in question rather than deflect try to deflect the criticisms?
Does React report your personal data to Facebook?
As with all things Facebook, the truth is that they're opaque as mud about what they do with data.
I'd give more credence to "the market is making an informed choice" hypothesis if consumers were, in fact, informed.
I'd give more credence to "the market is making an informed choice" hypothesis if consumers were, in fact, informed.
Spotify made their choice to use the SDK for whatever gains they get out of it, and as a customer you can choose to not use their service or app if you disagree with that.
Wrong. At least for EU citizens.
If Spotify are collecting data in this way (and not only using the SDK for Facebook Login), they are in violation of the GDPR. There must be clear unambiguous consent to collect the data in the form of an affirmative action of the user and it must be possible to use the app without giving consent, because the Facebook data collection is not essential for the app to operate.
If they do share data with Facebook, Spotify should be scared, since they are definitely large enough to be on the radar of the EU or national bodies.
Moreover, outside the EU it would be dumb for Spotify to say "just don't install the app if you don't agree". The 10 Euro per month that premium users pay is worth more than some Facebook tracking.
(IANAL)
Wrong. At least for EU citizens.
If Spotify are collecting data in this way (and not only using the SDK for Facebook Login), they are in violation of the GDPR. There must be clear unambiguous consent to collect the data in the form of an affirmative action of the user and it must be possible to use the app without giving consent, because the Facebook data collection is not essential for the app to operate.
If they do share data with Facebook, Spotify should be scared, since they are definitely large enough to be on the radar of the EU or national bodies.
Moreover, outside the EU it would be dumb for Spotify to say "just don't install the app if you don't agree". The 10 Euro per month that premium users pay is worth more than some Facebook tracking.
(IANAL)
> If Spotify are collecting data in this way (and not only using the SDK for Facebook Login), they are in violation of the GDPR.
It's kinda worse. They "only" open the gate wide and any of your data they can see is there for Facebook to take. It can feast on any data it can grab with the same permissions the main app has. Like a fucking virus from MS-DOS times infecting binaries, but this time developers are doing it quite voluntarily.
It's kinda worse. They "only" open the gate wide and any of your data they can see is there for Facebook to take. It can feast on any data it can grab with the same permissions the main app has. Like a fucking virus from MS-DOS times infecting binaries, but this time developers are doing it quite voluntarily.
There should be more visibility on where a user's data is going. User's should be informed, similar to malware sites, they should be informed "this website is sending your data to the following companies" etc.
Facebook Login can be implemented with plain oAuth without sending any data to Facebook until the user actually uses the FB Login feature.
Regardless of which SDK features they use the SDK calls out to Facebook with the device's fingerprint and a persistent UUID every time the app is launched or brought back into foreground.
Regardless of which SDK features they use the SDK calls out to Facebook with the device's fingerprint and a persistent UUID every time the app is launched or brought back into foreground.
Would 100% suggest going the basic OAuth route with FB, and not relying on their SDKs whenever possible. Been bit by Friday-afternoon-PST deployments that wreak havoc until work starts Monday too many times :/
Did anyone make any replacement login-only libraries for Facebook?
It's not exactly what you want, but just yesterday I made AccountsJS work with Facebook OAuth.[1]
I was glad today when watching this newsline, to have avoided the facebook SDK.
I think OAuth is usually better because every major provider has some version of it and so you basically can implement them all the same or at least in a really similar fashion.
1. http://www.accountsjs.com/
I was glad today when watching this newsline, to have avoided the facebook SDK.
I think OAuth is usually better because every major provider has some version of it and so you basically can implement them all the same or at least in a really similar fashion.
1. http://www.accountsjs.com/
Maybe they could try the novel method of charging money instead of buying ads to get users to show ads to.
For the average user out there, the fact is, most people only care about privacy when there's a breach/outage/scandal of some kind. Otherwise, the average person is not going to have "zomg fb is spyware" on their mind.
If apps start charging money, there would be a significant drop in the # of average user installs. Then the app would only make money off of privacy focused users, which is comparatively small.
If apps start charging money, there would be a significant drop in the # of average user installs. Then the app would only make money off of privacy focused users, which is comparatively small.
>For the average user out there, the fact is, most people only care about privacy when there's a breach/outage/scandal of some kind. Otherwise, the average person is not going to have "zomg fb is spyware" on their mind.
Because they don't know.
Like every industry, there are practices involved to which the layman is oblivious. It is important to remind ourselves that the reason the majority of users aren't vocalizing their concerns with these unsavory practices isn't because they don't care but because they don't know.
Because they don't know.
Like every industry, there are practices involved to which the layman is oblivious. It is important to remind ourselves that the reason the majority of users aren't vocalizing their concerns with these unsavory practices isn't because they don't care but because they don't know.
The 'not knowing' part happens when the outrage is then transferred to any app which does integrate the FB SDK (like zoom). We as developers have sortof taken for granted that the FB/Google/etc SDKs can do no evil. Maybe that attitude should change, because public opinion certainly has.
>The 'not knowing' part happens when the outrage is then transferred to any app which does integrate the FB SDK (like zoom).
Sorry, I'm lost here. Can you elaborate?
>We as developers have sortof taken for granted that the FB/Google/etc SDKs can do no evil. Maybe that attitude should change, because public opinion certainly has.
Previously, you mentioned
>If apps start charging money, there would be a significant drop in the # of average user installs. Then the app would only make money off of privacy focused users, which is comparatively small.
I don't have any reason to believe sales would lessen if a formerly "free" application began charging. The difference, however, I have no idea. You mention "significant" which is, of course, relative.
It isn't difficult to see the incentive at work in this scenario:
a) I could charge a nominal fee for use of my software, foregoing the unsavory practices discussed in this thread, and make X amount of money.
b) I could sell my user out and potentially make more than X amount of money. How much more? I don't know, but more.
Is that what it comes down to?
Sorry, I'm lost here. Can you elaborate?
>We as developers have sortof taken for granted that the FB/Google/etc SDKs can do no evil. Maybe that attitude should change, because public opinion certainly has.
Previously, you mentioned
>If apps start charging money, there would be a significant drop in the # of average user installs. Then the app would only make money off of privacy focused users, which is comparatively small.
I don't have any reason to believe sales would lessen if a formerly "free" application began charging. The difference, however, I have no idea. You mention "significant" which is, of course, relative.
It isn't difficult to see the incentive at work in this scenario:
a) I could charge a nominal fee for use of my software, foregoing the unsavory practices discussed in this thread, and make X amount of money.
b) I could sell my user out and potentially make more than X amount of money. How much more? I don't know, but more.
Is that what it comes down to?
That makes sense if you're talking about ads in the app, but that wasn't the discussion. The discussion is about the marketing folks running ads on Facebook for the app and wanting to know how effective those ads were.
Apps that are based on a subscription model also advertise for their apps, the two issues are orthogonal.
>If the software developer didn't get anything off you they wouldn't make the software available to you in the first place.
A lot of software these days don't offer a way for casual users (read: not enterprise/small business) to pay for it. It's "free" or nothing.
A lot of software these days don't offer a way for casual users (read: not enterprise/small business) to pay for it. It's "free" or nothing.
> will solely benefit Facebook and the software developer.
I mostly agree. But, in some(most) also the user by encouraging the developer to release updates and launch new features.
I mostly agree. But, in some(most) also the user by encouraging the developer to release updates and launch new features.
release forced updates and launch no new features, but "general bug fixes and performance enhancements."
I’ve got tons of apps in my App Store’s update queue, some that I haven’t updated for a couple months and they still work perfectly. Uber is one that comes to mind. They keep changing the UI while I keep using the same version from ages ago. I don’t bother updating anymore, it’s just noise.
What about security?
I do update banking and critical apps (say, VPN clients, PDF reader), though.
In the consumer app cases, either I'm hitting somebody's backend with wrong data, which fails and so I update the app, or more frequently, those whiny apps with almost daily updates are just a WebView shell to some website.
Otherwise, what a hacked iOS sandboxed app can do? If there's an exploit to escape the sandbox, like in the WhatsApp case, we have a way larger issue and I wouldn't expect a random hacker to waste such an exploit that could be better targeted at Jeff Bezos or so.
Other exploits are for system apps (Mail, Safari, etc) and are handled by OS updates.
In the consumer app cases, either I'm hitting somebody's backend with wrong data, which fails and so I update the app, or more frequently, those whiny apps with almost daily updates are just a WebView shell to some website.
Otherwise, what a hacked iOS sandboxed app can do? If there's an exploit to escape the sandbox, like in the WhatsApp case, we have a way larger issue and I wouldn't expect a random hacker to waste such an exploit that could be better targeted at Jeff Bezos or so.
Other exploits are for system apps (Mail, Safari, etc) and are handled by OS updates.
> Is that "spyware"?
>> Yes, absolutely.
Much much worse: https://news.ycombinator.com/item?id=19595478
>> Yes, absolutely.
Much much worse: https://news.ycombinator.com/item?id=19595478
It's difficult to argue about whether it's "surreptitious." It's certainly no secret. I think this is why you need organizations (perhaps government or otherwise) to establish standards for what is and isn't acceptable, so we don't have to quibble over words like "surreptitiously."
> It's certainly no secret.
There is no easy way to tell whether an app shares data with third-parties without setting up an MITM proxy or a packet capture. As far as the majority of users are concerned it is a secret.
There is no easy way to tell whether an app shares data with third-parties without setting up an MITM proxy or a packet capture. As far as the majority of users are concerned it is a secret.
>It's difficult to argue about whether it's "surreptitious." It's certainly no secret. I think this is why you need organizations (perhaps government or otherwise) to establish standards for what is and isn't acceptable, so we don't have to quibble over words like "surreptitiously."
It is a secret, though. Outside of you, me, and a few other folks like ourselves, users of this software have no idea what's going on behind the curtains. There is no overt disclosure to the user explaining the myriad communication exchange, occurring on a nearly constant basis, between their device and some remote server(s); much less giving the user a say in the matter.
Stating the use of the word "surreptitious" (to act in a clandestine manner; exactly how these communications are executed) amounts to a mere quibble is disingenuous.
It is a secret, though. Outside of you, me, and a few other folks like ourselves, users of this software have no idea what's going on behind the curtains. There is no overt disclosure to the user explaining the myriad communication exchange, occurring on a nearly constant basis, between their device and some remote server(s); much less giving the user a say in the matter.
Stating the use of the word "surreptitious" (to act in a clandestine manner; exactly how these communications are executed) amounts to a mere quibble is disingenuous.
I cannot easily see what information goes through an ASP form submitted with a ViewState parameter (where the page state is encoded in a blob buried in a JS var or HTML comment). Is that also surreptitious?
>I cannot easily see what information goes through an ASP form submitted with a ViewState parameter (where the page state is encoded in a blob buried in a JS var or HTML comment). Is that also surreptitious?
I can't say I completely understand the scenario, but if you're talking about a user filling out a form, then submitting that form, then no. That would be expected behavior.
Data may be encoded in any number of encodings depending on need. Encoded data isn't always human readable; especially so during secure transmission. It's not so much the inability for a human to read the encoded data as it is the data being consisting of only what is necessary to perform the action expected by the user; those expectations, of course, set via whichever means the user is interacting with the software.
Please correct me if I've misunderstood.
I can't say I completely understand the scenario, but if you're talking about a user filling out a form, then submitting that form, then no. That would be expected behavior.
Data may be encoded in any number of encodings depending on need. Encoded data isn't always human readable; especially so during secure transmission. It's not so much the inability for a human to read the encoded data as it is the data being consisting of only what is necessary to perform the action expected by the user; those expectations, of course, set via whichever means the user is interacting with the software.
Please correct me if I've misunderstood.
> That would be expected behavior.
That's exactly my point. "Surreptitious" is being used to mean "I think it's bad, and I think it's not expected." The "bad" part is obviously subjective, but even if we agree on that, the latter is where you really need standards bodies to agree on what is acceptable technology practices. To me, ad tracking is definitely expected (regardless of whether I think it's bad). I suspect it's also expected by nearly all HN participants, and ubiquitous ad tracking is even in the mainstream public consciousness outside of tech circles.
That's exactly my point. "Surreptitious" is being used to mean "I think it's bad, and I think it's not expected." The "bad" part is obviously subjective, but even if we agree on that, the latter is where you really need standards bodies to agree on what is acceptable technology practices. To me, ad tracking is definitely expected (regardless of whether I think it's bad). I suspect it's also expected by nearly all HN participants, and ubiquitous ad tracking is even in the mainstream public consciousness outside of tech circles.
Having a government full of technical lot illiterate politicians regulating digital advertisement - what could possibly go wrong.
Then that's the fault of companies who fucked up self-regulation so badly that the government has to step in. If they had behaved, this wouldn't be necessary.
I am not sure whether there could be anything worse than the current situation of a free-for-all with customers' data.
There absolutely could, if the new legislation were easy enough to circumvent for large companies but expensive to implement for everyone else, giving big players an even bigger advantage as far as data goes.
Maybe the government having access to all of your data....
>Having a government full of technical lot illiterate politicians regulating digital advertisement - what could possibly go wrong.
I'm not sure that argument works.
If we expand a bit, It wouldn't be difficult to find that governments are mostly comprised of <industry> illiterate politicians. There is no need for a government to be comprised of digital advertisement industry specialists in order to pass meaningful industry regulation.
I'm not sure that argument works.
If we expand a bit, It wouldn't be difficult to find that governments are mostly comprised of <industry> illiterate politicians. There is no need for a government to be comprised of digital advertisement industry specialists in order to pass meaningful industry regulation.
Those who don’t learn from history....
https://en.wikipedia.org/wiki/Communications_Decency_Act
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...
And a few where we dodged a billet.
https://en.wikipedia.org/wiki/Stop_Online_Piracy_Act
https://en.wikipedia.org/wiki/Pirate_Act
https://en.wikipedia.org/wiki/Communications_Decency_Act
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...
And a few where we dodged a billet.
https://en.wikipedia.org/wiki/Stop_Online_Piracy_Act
https://en.wikipedia.org/wiki/Pirate_Act
You're trying to convince me that the system isn't perfect. Listen, I've long since agreed with you.
I commented on your initial response because it was overly dismissive and implied the only way forward is to first wait until we have a government stocked with domain experts who only act only on policy within their domain. It dismisses the fact that it is unlikely that the politicians introducing regulation were solely responsible for its construction.
Yes, there is corruption in government and yes ignorance is painfully obvious in some legislation, but to dismiss the idea of enacting regulation because the politician(s) signing it into law may not be experts in the field the regulation addresses, isn't at all practical.
I'd further argue that it is incumbent upon those working in industry to ensure the creation of regulation is conducted transparently and includes representatives from the industry to contribute the necessary knowledge and expertise required to formulate the law(s) such that society benefits from the protection and commerce suffers no undue burden.
I commented on your initial response because it was overly dismissive and implied the only way forward is to first wait until we have a government stocked with domain experts who only act only on policy within their domain. It dismisses the fact that it is unlikely that the politicians introducing regulation were solely responsible for its construction.
Yes, there is corruption in government and yes ignorance is painfully obvious in some legislation, but to dismiss the idea of enacting regulation because the politician(s) signing it into law may not be experts in the field the regulation addresses, isn't at all practical.
I'd further argue that it is incumbent upon those working in industry to ensure the creation of regulation is conducted transparently and includes representatives from the industry to contribute the necessary knowledge and expertise required to formulate the law(s) such that society benefits from the protection and commerce suffers no undue burden.
Given the choice between a corrupt company and a corrupt politician, the corrupt politician can do far more damage. It’s far easier for me to choose which companies I use than choose which government that I am under.
The government can do and has done far more damage than big tech.
The government can do and has done far more damage than big tech.
History has much scarier lessons about governments abusing detailed lists of population preferences.
Devil's advocate: you could always not run those apps. Although for non-technical users it would be challenging to determine if the apps were transmitting that info, it's possible for technical users to detect it (assuming the info goes to an obviously-facebook url and isn't piped through e.g. spotify)
Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case
Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case
>Devil's advocate: you could always not run those apps. Although for non-technical users it would be challenging to determine if the apps were transmitting that info, it's possible for technical users to detect it (assuming the info goes to an obviously-facebook url and isn't piped through e.g. spotify)
But therein lies the rub: the overwhelming majority of users of software are not like you and me and have no idea what's going on behind the curtains.
>Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case
I hear this argument a lot and I empathize with the idea that having such information can aid in the development process. However, the argument asserting that some data may be useful to the developer so the developer is thus entitled to it, doesn't wash.
Regardless of the ubiquity of this behavior in today's software development industry, the fact remains that this process consumes the user's resources without their knowing or say in the matter and it's not OK.
But therein lies the rub: the overwhelming majority of users of software are not like you and me and have no idea what's going on behind the curtains.
>Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case
I hear this argument a lot and I empathize with the idea that having such information can aid in the development process. However, the argument asserting that some data may be useful to the developer so the developer is thus entitled to it, doesn't wash.
Regardless of the ubiquity of this behavior in today's software development industry, the fact remains that this process consumes the user's resources without their knowing or say in the matter and it's not OK.
The resources are trivial. If you don't like it you don't have to use the app that you chose to install.
>The resources are trivial.
Some of them aren't, though. The Facebook SDK isn't a trivial resource. It also depends a lot on the specific device the software is being loaded on to. It may be trivial to a newer device or one with upgraded hardware, but perhaps not so with baseline hardware or devices several years old.
>If you don't like it you don't have to use the app that you chose to install.
This argument may work with someone working in the software industry, but falls flat the moment the implied obligation is place on the unsuspecting.
Some of them aren't, though. The Facebook SDK isn't a trivial resource. It also depends a lot on the specific device the software is being loaded on to. It may be trivial to a newer device or one with upgraded hardware, but perhaps not so with baseline hardware or devices several years old.
>If you don't like it you don't have to use the app that you chose to install.
This argument may work with someone working in the software industry, but falls flat the moment the implied obligation is place on the unsuspecting.
You've very quickly sidestepped the primary point of the parent - many users would not know if it was even being loaded.
> The resources are trivial.
I think I as a user should get to decide that.
I think I as a user should get to decide that.
My bank has the Facebook sdk in there app. At the time they where the only bank willing to open an account for an under 18, international student. I queried them about opting out, they told me to opt out on Facebook's end. Not sure how I would avoid banking.
What is this fresh hell? If you buy a spatula on Amazon, would you accept "client-side analytics" on what you cook because "it's basically the only way to monitor it?" Or would you say that your spatula usage is nobody's business?
I love and happily pay for Spotify, but it is eye-opening that they send any data to Facebook. Well, shit.
I love and happily pay for Spotify, but it is eye-opening that they send any data to Facebook. Well, shit.
> Additionally I don't think there is anything wrong with client-side analytics in general since it's basically the only way to monitor performance/usage in production. And this type of thing is hard to discern from the more benign case
I think in these situations it often helps if we would find this behaviour acceptable in the real world. For example we see advertisment in airport toilets or malls or whatever. As someone pointed out, the company advertising does have an interest in finding out if the ad is effective. So would people find it acceptable if someone was following the from the advertisement and writing down which stores they go to, what they buy? I acknowledge that there is significant effort to develop technology (e.g. using ultrasound) to do this, but the efforts to do this covertly are IMO a good indication that people would not accept it if it was done in the open.
I think in these situations it often helps if we would find this behaviour acceptable in the real world. For example we see advertisment in airport toilets or malls or whatever. As someone pointed out, the company advertising does have an interest in finding out if the ad is effective. So would people find it acceptable if someone was following the from the advertisement and writing down which stores they go to, what they buy? I acknowledge that there is significant effort to develop technology (e.g. using ultrasound) to do this, but the efforts to do this covertly are IMO a good indication that people would not accept it if it was done in the open.
Offline shops already track you via bluetooth and wifi
https://falkvinge.net/2017/04/15/schiphol-airport-tracking-e...
https://falkvinge.net/2017/04/15/schiphol-airport-tracking-e...
That's what I acknowledged with the ultrasound tracking (I was not aware of the tracking at Schiphol). But it just reenforces my point, if they would do it openly people would strongly object. Privacy invasion using technology is so abstract that it doesn't really relate to reality for many people (even very smart people).
I feel like I'm in the minority here -- but I don't understand the problem.
Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this. You always have the choice to not install the app (if you don't want to).
This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.
Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this. You always have the choice to not install the app (if you don't want to).
This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.
>Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this.
As you mention, this is something the software developer want, not necessarily the user.
>You always have the choice to not install the app (if you don't want to).
This argument may have some teeth if directed toward a user in our industry. Depending on the scope of the particular software in question, the majority of users is likely to be those outside the software industry; the layman. The argument falls flat when the other person doesn't have the necessary understanding to be able to perform thoughtful analysis.
>This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.
That may be one reason this practice is in-use. I don't see how it makes the difference: the software developer continues these practices with no consideration of their user, much less the user's consent or indication anything is going on at all. It's all about what the software developer wants, not the user and that's not OK.
As you mention, this is something the software developer want, not necessarily the user.
>You always have the choice to not install the app (if you don't want to).
This argument may have some teeth if directed toward a user in our industry. Depending on the scope of the particular software in question, the majority of users is likely to be those outside the software industry; the layman. The argument falls flat when the other person doesn't have the necessary understanding to be able to perform thoughtful analysis.
>This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.
That may be one reason this practice is in-use. I don't see how it makes the difference: the software developer continues these practices with no consideration of their user, much less the user's consent or indication anything is going on at all. It's all about what the software developer wants, not the user and that's not OK.
> It's all about what the software developer wants, not the user and that's not OK.
I work in Software Development. Most of the time, the user doesn't know what he or she wants. They might feel that something is just not right, but don't know why, or cannot express why, because they don't know. Or don't care: I used to send out surveys, and the response rate was usually around 300 out of 50.000 confirmed users. That's... not much. At least for me, if I need to make major decisions.
My main takeaway with metrics is that I'm fine to give metrics to the vendor, as long as it's only me and the vendor, and as long as I know what it's used for. Also, it depends a lot on what is tracked.
Starting and closing the app, ways the user took to get to a certain point - I'm fine with that. But dare you transmitting my file names over to your server. Or any data I enter. That's none of your business.
I work in Software Development. Most of the time, the user doesn't know what he or she wants. They might feel that something is just not right, but don't know why, or cannot express why, because they don't know. Or don't care: I used to send out surveys, and the response rate was usually around 300 out of 50.000 confirmed users. That's... not much. At least for me, if I need to make major decisions.
My main takeaway with metrics is that I'm fine to give metrics to the vendor, as long as it's only me and the vendor, and as long as I know what it's used for. Also, it depends a lot on what is tracked.
Starting and closing the app, ways the user took to get to a certain point - I'm fine with that. But dare you transmitting my file names over to your server. Or any data I enter. That's none of your business.
You wanting more data does not give you license to assume consent for using a device you do not own to spy on a user. Even if a majority would have consented, assuming consent means that you are now co-opting some number of devices which do not belong to you to do things the owners of those devices do not want to happen.
It’s extremely unethical, and should be illegal.
It’s extremely unethical, and should be illegal.
Well - the user is using the device with a part that I created. If the user doesn't want to participate in enhancing the product, we need to go the old school way of enhancing products: Research. We need to conduct studies, do testing with test persons, etc.
This can be done, sure. But then your off-the-shelf app won't be available for 99 cents or for free, but cost more like 19.99 USD.
Might help streamlining the market, so I‘m open for that.
Might help streamlining the market, so I‘m open for that.
This very same argument would apply to, say, "5% of the price of my dinner goes towards healthcare for the waitstaff. That's something the company wants, not something I want."
There are much better argument for it being spyware, e.g., that it spies. It's not a very strong argument that a thing is bad simply because it helps the provider of the thing.
There are much better argument for it being spyware, e.g., that it spies. It's not a very strong argument that a thing is bad simply because it helps the provider of the thing.
It is not the same argument. Money is fungible, you know exactly what you are paying and the cost to you, how the money is used is not usually your problem [1]. In this case you have no idea how much and with what you are paying. The app could be exfiltrating all kind of information and you have no way of knowing.
[1] although people might have issues with unethical or illegal uses.
[1] although people might have issues with unethical or illegal uses.
>This very same argument would apply to, say, "5% of the price of my dinner goes towards healthcare for the waitstaff. That's something the company wants, not something I want."
I'm not sure I follow. If you're paying the same amount in either scenario, how are you adversely affected when a portion of your bill is allocated to a healthcare account?
>There are much better argument for it being spyware, e.g., that it spies. It's not a very strong argument that a thing is bad simply because it helps the provider of the thing.
I'm lost here, as well. Your argument is that I haven't made any arguments stronger than "that it spies"? I agree that stating only "that it spies" would be lacking critical thought and analysis, but my arguments have been more specific. The whole "it spies" assertion, generally speaking, is the basis for the more detailed responses I've submitted to this discussion.
I'm not sure I follow. If you're paying the same amount in either scenario, how are you adversely affected when a portion of your bill is allocated to a healthcare account?
>There are much better argument for it being spyware, e.g., that it spies. It's not a very strong argument that a thing is bad simply because it helps the provider of the thing.
I'm lost here, as well. Your argument is that I haven't made any arguments stronger than "that it spies"? I agree that stating only "that it spies" would be lacking critical thought and analysis, but my arguments have been more specific. The whole "it spies" assertion, generally speaking, is the basis for the more detailed responses I've submitted to this discussion.
I certainly don't want 5% of the price of my dinner going to healthcare costs. Don't tell me that's something that actually happens where you live?
Do you expect 100% of the cost of your meal to be the raw ingredients? Surely in (almost?) every single retail or service transaction, part of what you are paying is going towards operational costs, taxes, and yes... employee health insurance.
Is your objection the 5% or that it's going to healthcare costs?
I think the objection is that for most of western civilisation, healthcare costs are paid for by taxes not employers
OK, but those taxes are paid by someone (usually business taxes). I am strongly in favor of government-funded healthcare but the number of countries where the government can be funded by, like, drilling oil is very small, so I think my argument stands - some portion of the money I spend on dinner is going not towards things that directly produce my dinner but things that someone else thinks is worthwhile. Even if I agree with it, it's not my decision.
Structuring something in the interests of what benefits them won't necessarily align with what benefits you, since the actual structure of the relationship matters, as brief regard to my flippant comment on your analogy. It isn't about what % of dinner goes to healthcare - it's (and I was assuming some hideous employer-pays healthcare system) rather about the system which is built to align incentives and benefits in certain ways. That is, I stand to lose in many situations if healthcare is provided directly by the payments of my customers, or whatever.
Likewise, with privacy, it isn't just that 'it spies', it's that what it purports to aid me in is likely coincidental. Just like a targeted advertisement actually really benefiting me is effectively irrelevant to the advertiser - it's just nice if our incentives happen to align, for one brief moment. :-)
It isn't so nice when they don't.
It isn't so nice when they don't.
User benefits from effective marketing. If software dev knows who their audience is better it means product will reach the correct customers more efficiently. It is win for everybody.
Marketing platform and the product being marketed benefit from effective marketing.
That the user was “sold” to is not inherently positive. Not all products are good. Not all users can afford products they’re buying. Not all users necessarily understand they’re paying in ways they’re unaware of.
Straying away from social media in this example, cigarettes and alcohol feel like good candidates here.
That the user was “sold” to is not inherently positive. Not all products are good. Not all users can afford products they’re buying. Not all users necessarily understand they’re paying in ways they’re unaware of.
Straying away from social media in this example, cigarettes and alcohol feel like good candidates here.
It has to say something about the effectiveness of your marketing if the only way you even observe it having an effect is by installing spyware on every users system.
Nobody said it was the only way, but better measurement means optimizing ad spend to better target users and lower prices.
If companies genuinely believed that they'd advertise loudly that they were using the ad platform. The fact that they do it surreptitiously speaks volumes.
What’s wrong are two things: lack of transparency and lack of choice. They could just ask where people got the app, and offer them a choice not to disclose, but they choose to not offer the user that choice and to not transparently communicate the choice has been withheld.
That’s user-hostile.
The problem with saying “just don’t install the app” is that you have to be informed first, and that even then you have no real choice. If you want to take part in digital social networks you must surrender control and privacy. If your data is a valuable commodity you should be able to decide who gets what, just like you decide with your money. But you can’t, not really.
That’s user-hostile.
The problem with saying “just don’t install the app” is that you have to be informed first, and that even then you have no real choice. If you want to take part in digital social networks you must surrender control and privacy. If your data is a valuable commodity you should be able to decide who gets what, just like you decide with your money. But you can’t, not really.
It is not clear to users which apps use the Facebook SDK, so they can’t avoid them even if they wanted to. And so many do include it that it’s hard to find alternative apps…
> You always have the choice to not install the app
You also have the choice to consider the practice questionable, unethical, a systemic problem once it becomes widespread; to highlight it in public posts and forums, to protest how widespread it has become, to believe that it should be illegal in the context of consumer and privacy protections, to lobby for making it illegal, etc.
You also have the choice to consider the practice questionable, unethical, a systemic problem once it becomes widespread; to highlight it in public posts and forums, to protest how widespread it has become, to believe that it should be illegal in the context of consumer and privacy protections, to lobby for making it illegal, etc.
> You always have the choice to not install the app (if you don't want to).
Before this article came out was this information available to the users to help them in making this decision.
No, it was not! Hence the problem.
Before this article came out was this information available to the users to help them in making this decision.
No, it was not! Hence the problem.
I think it's pretty clear that if you're not paying for the application, then you're the product not the customer. Even the most ignorant users have probably got that message by now.
If the app is paid-for, it's less forgivable to be using this kind of spyware.
If the app is paid-for, it's less forgivable to be using this kind of spyware.
Usually when you say “win-win”, one of the wins is for each side.
The user has not explicitly allowed this information to be collected, yet the software developer wants to. That I think is the definition of spyware.
If I were to project this pattern 10 steps further, a software developer may want to know the gender and emotional state of the user installing their software using the front camera. That would also be a spyware, but it's on the higher end of the spyware spectrum.
If I were to project this pattern 10 steps further, a software developer may want to know the gender and emotional state of the user installing their software using the front camera. That would also be a spyware, but it's on the higher end of the spyware spectrum.
>The FB SDK helps with this. You always have the choice to not install the app (if you don't want to).
up until now I wasn't even aware of the facebook sdk or that say, spotify is sharing my data with facebook even if I don't use their login option so it's pretty hard to make a informed decision.
Is this even legal under GDPR?
up until now I wasn't even aware of the facebook sdk or that say, spotify is sharing my data with facebook even if I don't use their login option so it's pretty hard to make a informed decision.
Is this even legal under GDPR?
To the best of my knowledge, no. Even if we assume advertising attribution falls under legitimate interest (which isn’t certain), it would still only allow them to call out to Facebook once after install to report whether the app was installed from an ad. As of right now the Facebook SDK calls out every single time the app is opened or brought back in foreground.
> Is this even legal under GDPR?
I guess you could always complain about it to your country's data protection watchdog and then we'll all find out?
I guess you could always complain about it to your country's data protection watchdog and then we'll all find out?
“It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”
- Upton Sinclair (https://en.wikipedia.org/wiki/Upton_Sinclair)
- Upton Sinclair (https://en.wikipedia.org/wiki/Upton_Sinclair)
It's probably time to retire Upton to the Internet Hall of Fame next to Betteridge.
> Software developers want to know whether their existing marketing methods are effective.
so what?
so what?
The problem is that it happens silently and without consent of the owner of the hardware.
It’s win-win for facebook and the app developer. It’s only lose for the actual user.
It’s win-win for facebook and the app developer. It’s only lose for the actual user.
There are other ways to target / close the circle. App developers can share emails of new installs with facebook for cross match and more options. Would this feel better?
>There are other ways to target / close the circle. App developers can share emails of new installs with facebook for cross match and more options. Would this feel better?
Of course not because it describes the same behavior.
Of course not because it describes the same behavior.
I can see a difference between paid and free-to-play apps.
If I pay for the service, I can expect that the service is taking nothing more from me than the payments I make. Our contract is explicit.
If it's a free-as-in-beer service, then the user must realize that the business which is offering the service expects to get something for its purposes from the user, such as user's eyeballs and user's computing resources.
If I pay for the service, I can expect that the service is taking nothing more from me than the payments I make. Our contract is explicit.
If it's a free-as-in-beer service, then the user must realize that the business which is offering the service expects to get something for its purposes from the user, such as user's eyeballs and user's computing resources.
So do you argue then that looking at highway banner ads caused you to deplete your glucose stores in your cells derived from the food you paid for?
> Is that "spyware"?
No You know its being used then you install the app. You have a choice. Either don't use Spotify and go to some shitty open source music app or give your data.
> Yes, absolutely.
I support you in your courageous fight against nuance.
I support you in your courageous fight against nuance.
Do you feel the same about Google Analytics? Its data collection is very similar.
Why on Earth is it the advertiser's perspective that decides what is spyware. This is a consumer rights issue. As a user, I don't care what the intentions of the spying are.
If you squint then the Venn diagram of "spyware" and "knowing if your marketing budget was wisely spent" is a circle.
No need to squint, just cross your eyes ever-so-slightly
I'm not interested in arguing definitions. I look at what apps on my phone do, and delete anything that wants to talk to the surveillance shops.
It is that simple - I don't trust or use FB, and of course that includes third party FB feeders.
It is that simple - I don't trust or use FB, and of course that includes third party FB feeders.
Genuinely curious here, which apps have you kept and use daily? The number of monetized apps that don't talk to Google/FB (or other install trackers) is likely in a very small minority.
I am in the same position though I am not justifying this spying by any means. I have probably a handful of third-party apps and rely on built-ins as much as possible (Apple Maps, calendar, mail, etc) and use most third-party services through the browser with AdGuard to block spyware.
How do you monitor this?
There are several ways to do it. At home I run mitm-proxy and sometimes squid.
For on-phone use, so you can grab cellular data, Charles:
https://www.charlesproxy.com/documentation/ios/
For on-phone use, so you can grab cellular data, Charles:
https://www.charlesproxy.com/documentation/ios/
Network blocking like PiHole can block it, but on Android, I also use Blokada, which traps and logs outbound requests to domains on the block list. I also sometimes use ClassyShark3xodus to scan apks for trackers.
https://f-droid.org/en/packages/com.oF2pks.classyshark3xodus...
Also Netguard, pay 6 euro or greater 1 time donation and monitor all outbound requests, among other things
That is definitely not the case for the ~10 relevant apps I have worked on.
> Is that "spyware"?
This seems like much less of a damning claim than openly supporting an ad network.
This seems like much less of a damning claim than openly supporting an ad network.
This is also not GDPR compliant, not that anyone actually bothers to enforce the law.
If we respect the GDPR then data sharing for Facebook Login should only happen once the user presses the Facebook login button (as at that point the data sharing becomes essential to provide the functionality).
As far as ad/marketing attribution it should be opt-in as that is not an essential requirement to provide the service (and even less so for paid apps).
In both cases the SDK breaches the GDPR as it calls out every time it's loaded and upon first launch it will "register" itself with Facebook by submitting device information (make/model, carrier name, locale, timezone, etc) and obtain a unique ID which is then used in subsequent requests, providing Facebook with a trail of your whereabouts and usage patterns based on IP addresses you connect from (which they can then correlate with any other information they have).
If we respect the GDPR then data sharing for Facebook Login should only happen once the user presses the Facebook login button (as at that point the data sharing becomes essential to provide the functionality).
As far as ad/marketing attribution it should be opt-in as that is not an essential requirement to provide the service (and even less so for paid apps).
In both cases the SDK breaches the GDPR as it calls out every time it's loaded and upon first launch it will "register" itself with Facebook by submitting device information (make/model, carrier name, locale, timezone, etc) and obtain a unique ID which is then used in subsequent requests, providing Facebook with a trail of your whereabouts and usage patterns based on IP addresses you connect from (which they can then correlate with any other information they have).
Re: Ad/marketing attribution, that's not necessary correct. If the data point that gets sent back to Facebook is a GUID type string that matches the GUID that got generated when you first clicked the Facebook ad for the app and doesn't include data about you specifically, I believe that's fine. I don't myself have up-to-date information what data Facebook receives via its SDK but I suspect it is GPDR compliant through such methods.
GPDR specifically allows for anonymized/aggregated data on app usage or marketing feedback: https://gdpr.eu/eu-gdpr-personal-data/
GPDR specifically allows for anonymized/aggregated data on app usage or marketing feedback: https://gdpr.eu/eu-gdpr-personal-data/
> matches the GUID that got generated when you first clicked the Facebook ad
Knowing Facebook, that GUID would surely be bound to the user, still leaking to Facebook that the user is now using the app.
An ad campaign ID (same for all ads of this format in this campaign) sent to the app developer (which can then aggregate them on their side and send the daily aggregated data to Facebook) would be better.
Knowing Facebook, that GUID would surely be bound to the user, still leaking to Facebook that the user is now using the app.
An ad campaign ID (same for all ads of this format in this campaign) sent to the app developer (which can then aggregate them on their side and send the daily aggregated data to Facebook) would be better.
In the eyes of the law, how is storing and sending the guid later different from storing and sending a cookie?
Edit: the GPDR link specifically says identifier numbers are personal information, and I don’t see a carve out for allowing targeted marketing campaigns to use them to measure/improve targeting performance.
Wrong link, maybe?
Edit: the GPDR link specifically says identifier numbers are personal information, and I don’t see a carve out for allowing targeted marketing campaigns to use them to measure/improve targeting performance.
Wrong link, maybe?
Sorry, use of the term GUID confused things - I meant that if an identifier string is generated when you click on the ad, and the purpose is to simply see if that identifier completes the app install and first use - that's not against GPDR. (In my head GUID means "unique identifier string".) Storing the GUID tells you nothing other than some device clicked on an ad and some device did or did not complete the app install.
Don't mind me. I'm just going to come into your house and record what commercials you are watching. I'm not spyware I'm just _merely_ wanting to know about my marketing budget.
Analogy may not be perfect but it takes serious mental gymnastics to fail to see this as spyware, in my opinion.
Analogy may not be perfect but it takes serious mental gymnastics to fail to see this as spyware, in my opinion.
It wouldn't be surprising if some Smart TVs are already doing this.
Yes, Vizio already got caught and sued over this behavior.
> Starting in 2014, Vizio made TVs that automatically tracked what consumers were watching and transmitted that data back to its servers. Vizio even retrofitted older models by installing its tracking software remotely. All of this, the FTC and AG allege, was done without clearly telling consumers or getting their consent.
> What did Vizio know about what was going on in the privacy of consumers’ homes? On a second-by-second basis, Vizio collected a selection of pixels on the screen that it matched to a database of TV, movie, and commercial content. What’s more, Vizio identified viewing data from cable or broadband service providers, set-top boxes, streaming devices, DVD players, and over-the-air broadcasts. Add it all up and Vizio captured as many as 100 billion data points each day from millions of TVs.
> Vizio then turned that mountain of data into cash by selling consumers’ viewing histories to advertisers and others.
https://www.theverge.com/2017/2/7/14527360/vizio-smart-tv-tr...
https://www.ftc.gov/news-events/blogs/business-blog/2017/02/...
> Starting in 2014, Vizio made TVs that automatically tracked what consumers were watching and transmitted that data back to its servers. Vizio even retrofitted older models by installing its tracking software remotely. All of this, the FTC and AG allege, was done without clearly telling consumers or getting their consent.
> What did Vizio know about what was going on in the privacy of consumers’ homes? On a second-by-second basis, Vizio collected a selection of pixels on the screen that it matched to a database of TV, movie, and commercial content. What’s more, Vizio identified viewing data from cable or broadband service providers, set-top boxes, streaming devices, DVD players, and over-the-air broadcasts. Add it all up and Vizio captured as many as 100 billion data points each day from millions of TVs.
> Vizio then turned that mountain of data into cash by selling consumers’ viewing histories to advertisers and others.
https://www.theverge.com/2017/2/7/14527360/vizio-smart-tv-tr...
https://www.ftc.gov/news-events/blogs/business-blog/2017/02/...
We are already living in the world of 1984.
"TV watches you", except this isn't Soviet Russia.
"TV watches you", except this isn't Soviet Russia.
In many ways; yes.
In the most of the important ways; no.
You can still fight back effectively. Don't go gentle into that good night.
In the most of the important ways; no.
You can still fight back effectively. Don't go gentle into that good night.
Some of them even connect to any available open wifi without being configured to do so, so even keeping them from phoning home
is difficult/impossible if your neighbor is careless.
https://samba.tv/
"We use anonymized data to provide a positive advertising experience, enable ad-supported TV networks to keep their shows free, and partner with TV manufacturers which reduces the price of TVs for you."
"We use anonymized data to provide a positive advertising experience, enable ad-supported TV networks to keep their shows free, and partner with TV manufacturers which reduces the price of TVs for you."
Didn't Samsung literally get caught uploading screenshots of content played on their TVs to some server? Maybe it was some other company?
These days, unless you take drastic measures to defend yourself from spyware embedded in consumer technology or forgo it all together, it seems that you'll be subject to this kind of surreptitious abuse as a matter of course.
These days, unless you take drastic measures to defend yourself from spyware embedded in consumer technology or forgo it all together, it seems that you'll be subject to this kind of surreptitious abuse as a matter of course.
Worse than that, audio recordings from people's living rooms:
"Please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party through your use of Voice Recognition."
"Please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party through your use of Voice Recognition."
> that information will be among the data captured and transmitted to a third party through your use of Voice Recognition
Could also mean they're using AWS Transcribe (or similar) instead of rolling their own speech to text engine.
But that's only the most optimistic interpretation.
Could also mean they're using AWS Transcribe (or similar) instead of rolling their own speech to text engine.
But that's only the most optimistic interpretation.
Don’t forget that you’re picking which houses to invade based on gender, age, etc.
Totally not creepy.
Totally not creepy.
Isn't that how the TRP is calculated. IIRC agencies install devices in random houses to find which program is being watched.
One important distinction that often gets lost in these conversations is the difference between "linking" and "de-anonymization". In general, the bigger players in the analytics space are extremely careful about avoiding any risk of de-anonymization both contractually and in process. Salted hashes and minimum base sizes to report out are the norm. Some funkier approaches seem to be in R&D. There are of course bad players in the fringes but the big players have largely cleaned up their act.
How does the Facebook SDK in a 3rd party app correlate that you're the same user if you don't log into the app with FB? Is there some universal device identifier all your apps have access to?
There was a static universal device identifier until iOS 6. Even today, while Apple has implemented many sensible restrictions on tracking, there's still a ton of information that can be used for device fingerprinting freely available to all apps. This blog post [0] pegs the amount of useful information at around 56 bits.
[0]: https://nshipster.com/device-identifiers/#fingerprinting-in-...
[0]: https://nshipster.com/device-identifiers/#fingerprinting-in-...
The IP addresses (both WiFi and mobile), device make/model, carrier and locale can be combined into a fairly unique fingerprint, narrowing it down even more over time since the SDK phones home every time the app is opened.
There's an "advertising id" that's assigned to your phone, accessible by apps you install. This ID can be reset by the user, but only if they are aware of it.
That isn't even as useful as `identifierForVendor`.
Do you know how common it is to use the Facebook SDK for app analytics even from outside the Facebook ads ecosystem? I can’t remember exactly where I got this from but I was under the impression that it was pretty widely used for general analytics in the same way that loads of sites use Google Analytics without being in their ads ecosystem.
Many apps on my Android device routinely send requests to edge-star-.facebook.com even when I don't use facebook login. Are these ad related requests?
That’s most likely the Facebook SDK we’re talking about. The SDK phones home regularly regardless of whether it’s features are actually being used.
You can get NetGuard on Android and see how often and what is called (facebook.com, graph.facebook.com, other vendors, platforms, IPs, etc). You can choose to block what is not needed. Kind of uBlockOrigin for Android. Sometimes stuff breaks.
And a lot of stuff is not related to FB Login.
Facebook launched Facebook Off Activity a while ago https://news.ycombinator.com/item?id=22178917
You can go to your profile, and check which third parties, or advertisers uploaded contact data of you, download backup data to see in json files which apps what sent about you ("App activated", "Made some purchase").
And a lot of stuff is not related to FB Login.
Facebook launched Facebook Off Activity a while ago https://news.ycombinator.com/item?id=22178917
You can go to your profile, and check which third parties, or advertisers uploaded contact data of you, download backup data to see in json files which apps what sent about you ("App activated", "Made some purchase").
Why is facebook spyware part of Spotify. I signed up to Spotify via email not facebook login.
i mean, they offer FB sign in in the app, so the FB SDK is bundled with the app binary. looks like the mere presence of the library is causing crashes. someone on a related GH thread noted they commented out the code invoking the FB SDK but the issue remained.
Yeah these SDKs are siphoning off data without authorization like your location, songs you listen to and who knows what else (eg other processes or apps running on your phone). Eg the latest iOS exploit allows any app to get access to all SMS data.
Tech companies of today trample upon individual privacy openly. Amazing!
i'm by a longshot no facebook fan but... are you sure the SDK can actually siphon out what songs you listen or your location from the app it's sandboxed in (which, BTW, is in its own sandbox from an iOS system POV, and also has its own set of permissions)?
I am an iOS developer and most likely the problem is related to configuration and basic analytics, not "siphoning" app data.
Offending code :
if (restrictiveParams[eventName][@"is_deprecated_event"]) {
So, the iOS library does not check for nil, and whatever the server is returning does not have the expected content. Lame.
Offending code :
if (restrictiveParams[eventName][@"is_deprecated_event"]) {
[deprecatedEventSet addObject:eventName];
So, the iOS library does not check for nil, and whatever the server is returning does not have the expected content. Lame.
Looks like that would've probably been caught if it were written in Swift.
if (restrictiveParams[eventName] as! [String: Any])["test"] != nil
Well the reason FB/Foursquare/Google etc add these to 3rd party apps is so they can get data. Example if you visit a website which has a Facebook like button, your browser fetches the js files/which maybe even makes an API call to let FB know your IP (and hence location). All this data is fed to the giant system that feeds you ads.
Adding their SDK to other apps/sites (even if there is no user facing need) is a common strategy used by most big companies to get data. In return the app that puts in the SDK gets $ from the company.
Of the companies you named, Foursquare's business model explicitly revolves around paying apps for user location data and selling it.
I doubt (and at least from my experience around SV, haven't seen) that FB/Google are paying apps to include their SDKs.
I doubt (and at least from my experience around SV, haven't seen) that FB/Google are paying apps to include their SDKs.
You have no idea what you're talking about. Apps use the Facebook library because a good portion of end-users want to be able to login with a Facebook button --or Google, or whatever that doesn't require them to create a user/password account. It's just that simple.
I have been witness to such business partnerships to embed SDKs to siphon telemetry/other data. The world is not as simple as you think...
well, this would be extremely believable
If you only need login, then you can have the same functionality without the Facebook SDK or Google SDK by using OAuth.
I think he's talking in general. I worked at Spotify for a while and I can tell you the only reason they have the FB SDK bundled is to provide login.
They dont use FB for any tracking or attribution at all, for that they have other frameworks. They are aware of the FB SDK misbehaving in some cases and do take steps to prevent it.
you are assuming that the Spotify app is not simply handing that data over.
I would not be surprised if there is a financial agreement in place.
Yes, requiring the SDK to implement Facebook Login is the decision that's being criticized. Facebook encourages SDK usage obviously for the data collection it enables, but even they provide an OAuth-only login flow that doesn't require the SDK at all: https://developers.facebook.com/docs/facebook-login/manually...
Then if this can be fixed by a server side change as suggested below, that's worrisome, since it suggests it is communicating with FB even if you don't invoke it.
the real question though is if the library is not even imported into the main app and just left hanging around, linked, would it still crash? i'd be curious to know
Apparently yes: https://news.ycombinator.com/item?id=23097887
Correct, as the code is run as the dynamic linker pulls in the library (which is usually at application startup).
They had some big partnership deal about 8 years ago which involved some low level integration. It also gave Spotify access to more Facebook user information than what was originally authorized, like letting Spotify read users' FB messages.
I remember being grandfathered into not having it and Spotify would ask me every time I logged in to integrate my FB account.
I remember being grandfathered into not having it and Spotify would ask me every time I logged in to integrate my FB account.
Would you expect a separate app for people who login using Facebook and people who login without?
It’s part of most apps you use on your phone - Facebook is great for app download campaigns and adding the SDK means end to end visibility on marketing. So “everyone” is using it.
In an abstract sense this is similar to how Facebook (ab)used the like button on 3rd party sites to track anyone using that site. Only it’s much worse because with an app SDK they have access to much more sensitive data.
In an abstract sense this is similar to how Facebook (ab)used the like button on 3rd party sites to track anyone using that site. Only it’s much worse because with an app SDK they have access to much more sensitive data.
Spotify is a web app, that is wrapped into clients on different platforms. The app is constantly pinging googletagservices.com, edgesuite.net, fbcdn.net, fbsbx.com, google.com, googlesyndication.com and doubleclick.net, however you are using the app. It doesn't matter if you only listen to one, unshared, downloaded playlist. Constant tracking.
[deleted]
[deleted]
Facebook chose to make Facebook Login spyware, and Spotify didn't think anyone would mind when they did, because who cares about tracking? and/or wasn't aware, because who could realize this from the unclear Facebook docs? (Either is possible!)
That was a very pre-2019 decision, and now that Facebook just set the world on fire, we're probably going to see a lot fewer Login with Facebook.
That was a very pre-2019 decision, and now that Facebook just set the world on fire, we're probably going to see a lot fewer Login with Facebook.
The ironic thing is that you can actually implement Facebook login in a privacy-respectful manner by using standard oAuth where Facebook is only contacted when the user decides to log in with it (which is mostly fine as they have an account anyway and thus consent to Facebook tracking).
It's likely that apps that load the SDK are using other features of it, such as Facebook Analytics (which is similar to Google Analytics), not just login with Facebook.
We found a couple workarounds while Facebook was busy fixing this.
1. Airplane mode 2. Block facebook.com as adult content under Settings | Screen Time | Content Restrictions | Web Content | Limit Adult Websites | Add a site. 3. Block facebook.com at your router.
Option 2 could be helpful if you want to block it for privacy reasons.
1. Airplane mode 2. Block facebook.com as adult content under Settings | Screen Time | Content Restrictions | Web Content | Limit Adult Websites | Add a site. 3. Block facebook.com at your router.
Option 2 could be helpful if you want to block it for privacy reasons.
I added YouTube.com under the restricted sites (not specifically as an adult site, just restricted) and it did stop my kids from going there directly, but they figured out that they can Shazam a song, use its “show song on Youtube” feature to get a fully functioning YouTube page and start working from there.
They can’t even read yet.
I am at the same time very proud at the l33t hacking skills and upset at their disregard for rules. But mostly proud.
I will check if “adult” blocking works better.
They can’t even read yet.
I am at the same time very proud at the l33t hacking skills and upset at their disregard for rules. But mostly proud.
I will check if “adult” blocking works better.
Does the adult filter work in apps? If so this seems like a lovely workaround for the lack of firewall.
It worked to fix this, so I’m assuming so.
I tried adding spotify.com as a limited adult website and I can still use the Spotify app normally. So either I'm missing something or it can't be used as a firewall.
You might be using their magical p2p network.
I tried with various app and I can’t break any of them. I’d be really interested in a firewall for iOS
The adult filter probably works like a DNS bkackhole and simply bans those websites from getting resolved.
Perhaps this outage will raise awarenesses more broadly as to the prevalence of "non essential" third party SDKs like these, and the risk that their failure can significantly impact on the wider ecosystem.
I can't imagine Apple will be all too pleased by this. Perhaps time for them to look at clamping down on SDKs that make remote network requests? (Given they have their own private sign in system now as well, they might even have a secondary incentive)
I can't imagine Apple will be all too pleased by this. Perhaps time for them to look at clamping down on SDKs that make remote network requests? (Given they have their own private sign in system now as well, they might even have a secondary incentive)
From June 30th, 2020:
"Apps that authenticate or set up user accounts must support Sign in with Apple if required by guideline 4.8 of the App Store Review Guidelines."
"Apps that authenticate or set up user accounts must support Sign in with Apple if required by guideline 4.8 of the App Store Review Guidelines."
Not likely. FB has made it too easy, and developers are lazy. For the marketing/sales/PR types of the company that made the app, the info the SDK returns is exactly the type of information they want/need. At the end of the day, the "morality" of a developer will always come second to the sales/marketing/PR people. After all, you're just a developer, and there's a line a mile long of people waiting to replace you.
Yes, please.
Firebase should be next, requiring you to include a whole bunch of Firebase lib crap just to use Crashlytics.
Firebase should be next, requiring you to include a whole bunch of Firebase lib crap just to use Crashlytics.
At the very least, this might spawn some discussion around being able to remotely enable/disable SDKs, from a server that you control. Last week it was Google Maps, today Facebook SDK...
I block all Facebook domains with the NextDNS iOS app — didn't seem to be affected by this. Blocking spyware has its perks.
Same here and I’ve always been a bit skeptical about how well it actually works but I’m pleasantly surprised by the results of this impromptu test!
Ditto!
NextDNS automatically blocks subdomains.
More info here: https://qz.com/1234502/how-to-block-facebook-all-the-urls-yo...
facebook.com
fbcdn.com
fbcdn.net
fbsbx.com
fb.com
instagram.com
NextDNS automatically blocks subdomains.
More info here: https://qz.com/1234502/how-to-block-facebook-all-the-urls-yo...
I wish there were an easy way to deploy rpi to people I know much in the same way it's easy to tell them to install uBlock Origin
Also: Tinder, Venmo, GrubHub (think of the botched deliveries heh), and more. An ongoing list here: https://twitter.com/aburninghilll/status/1258169688959352832
Also see: https://github.com/facebook/facebook-ios-sdk/issues/1373
Also see: https://github.com/facebook/facebook-ios-sdk/issues/1373
We have a few thousand apps on the App Store and got bit by this today.
The SDK is very useful for a smooth login experience if the user has the Facebook app installed, because your app can offer Facebook as a login option, then just pop the user over to the Facebook app, they can tap “okay” (or whatever), and jump back to your app.
That said, we’re going to rip this thing out of our apps ASAP. No framework should be calling network code in “+load”. The convenience for the user (and the dirty tracking Facebook apparently does) is just not worth the trade-off of handing our app’s stability over to Facebook.
The SDK is very useful for a smooth login experience if the user has the Facebook app installed, because your app can offer Facebook as a login option, then just pop the user over to the Facebook app, they can tap “okay” (or whatever), and jump back to your app.
That said, we’re going to rip this thing out of our apps ASAP. No framework should be calling network code in “+load”. The convenience for the user (and the dirty tracking Facebook apparently does) is just not worth the trade-off of handing our app’s stability over to Facebook.
How can one developer have thousands of apps? It sounds just like a giant scattergun for malware. There are not 1000 distinct useful ways to use an iPhone.
A consulting company or a company that makes "white label" apps like for restaurants or stores.
Can we agree that each restaurant having a separate app is one of the dumbest outcomes imaginable?
I think individual businesses (I am talking about the neighbourhood grocery stores and restaurants) ought to move to their own websites, their own apps (at least branding if there are template apps) as much as they can. I believe we have had enough of centralisation and consolidation which aren't problematic only when they are about a messaging service or a social network.
Yes, this should have been solved by the web, but you can't push notifications to it or rely on local storage (thanks to Apple). Also, generally people' don't even want to know what an URL is.
That's not how it actually is. Apple actually rejects those type of template apps. The restaurants use an ad-hoc way of installing the apps. So those apps are only available to the restaurant for example.
No, Apple accepts white label applications. Their requirement is that if you're going to release a white label application, then it should be released under the customer's own individual Apple developer account rather than having them all under one developer account.
Sure, unless you’re one of those restaurants that wants their own app.
>Can we agree that each restaurant having a separate app is one of the dumbest outcomes imaginable?
Nope, can't agree there. Every outlet/brand should have it's own app in my book.
Nope, can't agree there. Every outlet/brand should have it's own app in my book.
For what purpose? Why not just a good website?
Why do I need some integrated solution when its probably just a shim around their website anyway?
That sounds awful tbqh, download a binary for every website that I have little control over.
They probably do contract app development, with 1000s of clients
>There are not 1000 distinct useful ways to use an iPhone.
This comment reflects badly on your imagination. There are 00s of uses for a concrete brick -- let alone a single device with a plethora of distinct functions.
This comment reflects badly on your imagination. There are 00s of uses for a concrete brick -- let alone a single device with a plethora of distinct functions.
[deleted]
I hope that this incident and the Zoom incident will motivate app developers to remove the Facebook SDK when possible.
In most cases, it's not really up to the app developers.
From the crash log, it looks like the server response it's getting back is missing a field that the SDK wants. Facebook should be able to fix this on their end?
Edit: from the issue it looks like they've done something, but people are still reporting crashes…
Edit: from the issue it looks like they've done something, but people are still reporting crashes…
it will probably take time to propagate (edit: though i didn't expect this much time, still crashing!)
The description is definitely weird. Any server change change should never crash an app, which should have proper validation for all data that it receives.
Thereby the mitigation "to update something on the server that takes time to propagate" also sounds wrong more like a rollback/mitigation than a fix of the actual issue.
Thereby the mitigation "to update something on the server that takes time to propagate" also sounds wrong more like a rollback/mitigation than a fix of the actual issue.
This comment made my day LOL
https://github.com/facebook/facebook-ios-sdk/issues/1374#iss...
I really think the use of remote, undocumented and unknown code just needs to end. Including the SDK which can make changes invisibly should never be an acceptable practice.
And it's why I am weary of installing apps in general. Tip: use f-droid, check privacy exodus and stick to the browser where possible, where you can have much greater control, and not be spied on by FB.
And it's why I am weary of installing apps in general. Tip: use f-droid, check privacy exodus and stick to the browser where possible, where you can have much greater control, and not be spied on by FB.
Hi everyone,
Please use the oauth-only version for login and strip the facebook SDK garbage from your apps. It seems it's not worth the trouble.
Please use the oauth-only version for login and strip the facebook SDK garbage from your apps. It seems it's not worth the trouble.
The Facebook SDK is a single point of failure it seems.
If you must integrate Facebook, it is better to use OAuth + API and then control every call, only necessary ones needed i.e. login, friends, maybe game leaderboards, profile photo, etc.
Not sure why people are still putting the Facebook SDK in their apps, it is basically malware and tracking for authoritarian ends [1][2].
Engineers are supposed to be anti-authoritarians.
Engineers are supposed to be into decentralization and distributed systems, and not have single points of failure like libs with hard crashes that inject network calls that don't fail gracefully before your app can even launch.
[1] https://www.nytimes.com/2017/11/05/world/yuri-milner-faceboo...
[2] https://www.theguardian.com/news/2017/nov/05/russia-funded-f...
If you must integrate Facebook, it is better to use OAuth + API and then control every call, only necessary ones needed i.e. login, friends, maybe game leaderboards, profile photo, etc.
Not sure why people are still putting the Facebook SDK in their apps, it is basically malware and tracking for authoritarian ends [1][2].
Engineers are supposed to be anti-authoritarians.
Engineers are supposed to be into decentralization and distributed systems, and not have single points of failure like libs with hard crashes that inject network calls that don't fail gracefully before your app can even launch.
[1] https://www.nytimes.com/2017/11/05/world/yuri-milner-faceboo...
[2] https://www.theguardian.com/news/2017/nov/05/russia-funded-f...
> Engineers are supposed to be anti-authoritarians
Strongly disagree on this. Exact opposite maybe but I don't want to generalize. Modern authoritarian tactics are pretty much impossible without engineering.
Strongly disagree on this. Exact opposite maybe but I don't want to generalize. Modern authoritarian tactics are pretty much impossible without engineering.
Wait, are you saying that (software) engineers should _actually_ be authoritarian? And you suggest this is because otherwise "authoritarian tactics" wouldn't work?
No, I did not say that. I am not even talking about what they should or shouldn't be. There's no set rule which says engineers are supposed to be pro-authoritarians or anti-authoritarians.
I was disagreeing with what the parent said: "Engineers are supposed to be anti-authoritarians."
I take that to mean that the person thinks engineers are anti-authoritarians - which is simply false and not what happens in real life. Engineers are often enablers of authoritarians.
And this is a bad thing but just fact of life. Humans are flawed and greedy for power. There are higher chances of someone with power to abuse it (engineer in this example but could apply to others too).
I was disagreeing with what the parent said: "Engineers are supposed to be anti-authoritarians."
I take that to mean that the person thinks engineers are anti-authoritarians - which is simply false and not what happens in real life. Engineers are often enablers of authoritarians.
And this is a bad thing but just fact of life. Humans are flawed and greedy for power. There are higher chances of someone with power to abuse it (engineer in this example but could apply to others too).
Ah, right. Your wording of "Exact opposite maybe" made me think you were suggesting that.
I agree that what engineers _should_ be is different from engineers _actually_ are, and that today you see how software is definitely enabling authoritarian rule. I wish it wasn't so, and I guess that's what OP wanted to communicate.
I agree that what engineers _should_ be is different from engineers _actually_ are, and that today you see how software is definitely enabling authoritarian rule. I wish it wasn't so, and I guess that's what OP wanted to communicate.
Is there a comprehensive list of applications that have the FB SDK in them so that I can decide to not install those?
Does Apple use FB SDK in their apps? I think not, but can someone confirm?
Does Apple use FB SDK in their apps? I think not, but can someone confirm?
Same thing happened with Google Maps SDK just a few weeks ago.
https://www.reddit.com/r/androiddev/comments/g6t8fu/google_m...
https://www.reddit.com/r/androiddev/comments/g6t8fu/google_m...
> This is insane, half of the apps on my phone aren't launching!
> Please move slower and break fewer things. Thank you.
> Please move slower and break fewer things. Thank you.
Maybe this will motivate product owners, developers, marketers, to start thinking before implementing a dozen of SDKs in a mobile app (or website). It's understandable when you need some analytics/crash reporting, but it becomes a privacy and ethics question when a lot of data is wandering around, and even better, crashes your app. And the users will blame you, they don't even know how many SDKs are there and what they are doing.
> And the users will blame you
Rightfully so. If you add an SDK to you app, it's your fault if the SDK causes your app to crash.
Rightfully so. If you add an SDK to you app, it's your fault if the SDK causes your app to crash.
A similar thing happened with Google Maps recently: https://twitter.com/GergelyOrosz/status/1253608276660551680
Not sure what the lesson is, other than that you can’t trust third party code, even if it’s written by the worlds largest companies!
Not sure what the lesson is, other than that you can’t trust third party code, even if it’s written by the worlds largest companies!
Waze, a company owned by Google was also broken and force crashing over and over again for a few hours.
Whenever I hear of some Facebook offering all I think of is when you dance with the devil, you shouldn't be surprised when you get burned.
Whenever I hear of some Facebook offering all I think of is when you dance with the devil, you shouldn't be surprised when you get burned.
Wow. At almost exactly the time that report was filed ... about 30-40 Minutes, my spotify ios app started crashing. I was listening to a song on my desktop, and wanted to share it on my instagram so I went to the app to do it. everytime I opened up the app it would crash immediately, I restarted my phone, tried it again, and it was fine for about 5 seconds and then crash ... crash ... crash ...
I filed a report with Spotify and by the time they got back to me, the problem had gone away ... I thought it was very odd, until I read this post ...
I guess now I know what happened.
I filed a report with Spotify and by the time they got back to me, the problem had gone away ... I thought it was very odd, until I read this post ...
I guess now I know what happened.
This is one of several reasons why I refuse to install apps unless I absolutely must. You have no way of knowing what kind of spyware is bundled with them, and there's no way to block it (like you can in a proper browser with uBlock Origin).
Looks like it's back to normal (ish) now. I'm curious as to what kind of testing they have that this wasn't caught by a test suite though--login integration seems like an incredibly important thing to not break.
Is there a list somewhere of all the apps importing the spyware Facebook SDK?
For all the privacy stuff that Apple does on Safari, it does absolutely nothing against the tracking issues in the mobile app ecosystem.
The unspoken rule is because apps make money for Apple and websites don't.
The unspoken rule is because apps make money for Apple and websites don't.
Ouch. Not knowing how the iOS apps are written, two questions come to mind:
1) Why wasn’t the SDK written to tolerate bad data and fail gracefully?
2) Could clients integrating the SDK be written to tolerate failures like this?
1) Why wasn’t the SDK written to tolerate bad data and fail gracefully?
2) Could clients integrating the SDK be written to tolerate failures like this?
I had to remove the SDK a few months ago due to it causing crashes. If I remember correctly they injected some code into didSelectRowAtIndexPath for table / collection views...Looks like its fixed now but I definitely won't be adding it back, https://github.com/facebook/facebook-ios-sdk/issues/1318
How to gain market share? Release a breaking server-side update and "forget" to inform other vendors in time so that their apps crash, while yours do not.
Zoom dodged this bullet.
And got so much flak for it. How much "zomg you're spying on me" press are the other 50% of the iOS ecosystem going to receive for doing the same thing Zoom did, going on a decade.
Just because others are doing it doesn't make it okay.
You beat me by a couple of minutes.
Dear Facebook: Please move slower and break fewer things.
Thank you very much.
[deleted]
This is a good resource to see who is being impacted[1].
[1] - https://downdetector.com
[1] - https://downdetector.com
This is a nice demonstration of why exceptions, in particular untyped exceptions, are a major liability.
I had no idea why my app was suddenly crashing multiple times all of a sudden. God fucking damnit.
Hm my whatsapp crashed midcall today, wonder if they use the Facebook SDK or something else
Given that whatsapp is owned by facebook, that seems very likely.
that's exactly why I was wondering if they use something else, a better internal shared library for accessing facebook services
Move fast and break other things
18 minutes ago:
> Server side change is already reverted. The crash will vanish.
> Server side change is already reverted. The crash will vanish.
> Still crashing 30 minutes after your revert. Are you sure you reverted the right thing?
Ah that is what is happening!!! Thanks HN. :)
Guess Joma was right: https://www.youtube.com/watch?v=rR4n-0KYeKQ
At least they moved fast.
This is surely a competition violation, wordly blocking competing products from operating.
guess we're back to "move fast and break things"
Move slowly with unstable infra.
[deleted]
But all of the engineers passed LeetCode, how could this be?
Questions went stale
Facebook engineering generally is super competent. Leet code or not, such slip ups are bound to happen from time to time. True test of competence would be these mistakes don't repeat and that they learn from it, which I'm pretty sure they would.
Exactly. OP makes it harder on everyone expecting engineers to be flawless just because they've gone through a very selective hiring process. Programming is hard.
Lets skip the hyperbole, appeals to authority and platitudes. This crash is from handwritten API response wrapping code that lacks checks. This is string-based programming. This is utter shit.
Ok, I'm sure you've written perfect code your entire career and have never made a single mistake, however simple, and however early in your career. Right?
If you want to criticize something, criticize the testing that let this change through, not the developer who made it. We were all young and inexperienced once, we've all had bad days, and we've all written crap code. This is only unique because it affected a lot of people.
If you want to criticize something, criticize the testing that let this change through, not the developer who made it. We were all young and inexperienced once, we've all had bad days, and we've all written crap code. This is only unique because it affected a lot of people.
Without staking my flag on either side of this argument, it's a bit silly to say "the only reason this stands out is because it affected so many people" as if that's a reasonable counter-argument.
The large amount of people affected reinforces your parent comment's argument. Something that has the potential to affect an immense amount of people should be treated with a relative amount of care. Writing crap code and pushing carelessly would be a far more significant failure of judgement if that code were in the Facebook SDK than if it were in Johnny's Hello World App.
It's also worth noting the difference between writing code with a minor change in behavior that when pushed to production causes an unexpected domino-effect of obfuscated cascading failures across multiple different services that eventually impacts an immense amount of people, vs. directly writing code that crashes on the client side and impacts an immense amount of people. This is the latter.
The large amount of people affected reinforces your parent comment's argument. Something that has the potential to affect an immense amount of people should be treated with a relative amount of care. Writing crap code and pushing carelessly would be a far more significant failure of judgement if that code were in the Facebook SDK than if it were in Johnny's Hello World App.
It's also worth noting the difference between writing code with a minor change in behavior that when pushed to production causes an unexpected domino-effect of obfuscated cascading failures across multiple different services that eventually impacts an immense amount of people, vs. directly writing code that crashes on the client side and impacts an immense amount of people. This is the latter.
> criticize the testing
Criticise the process that let it through.
Why was the testing not sufficient? Was it even tested at all? Maybe a developer just "pushed it straight to master"? Why/how can they do that (hypothetically)
Criticise the process that let it through.
Why was the testing not sufficient? Was it even tested at all? Maybe a developer just "pushed it straight to master"? Why/how can they do that (hypothetically)
[deleted]
That’s not a slip up on their end, it’s a feature to enable them to collect stuff even if you don’t use their code.
So you're saying we can be confident they won't break democracy again?
What does that have to do with engineering talent?
It has everything to do with it. Software engineers should take care to consider the risks and potential downsides to the shady products they build with that talent that aren't just downtime or tech debt but the larger impact to society itself. Silicon Valley prioritizes technical talent while completely disregarding strength and quality of character.
> True test of competence would be these mistakes don't repeat and that they learn from it
It's not that they aren't smart or don't learn but that FB's performance review process rewards optimizing for growth over reliability/sustainability.
e: you can downvote me but I lived it so you won't change my mind :)
It's not that they aren't smart or don't learn but that FB's performance review process rewards optimizing for growth over reliability/sustainability.
e: you can downvote me but I lived it so you won't change my mind :)
> “ True test of competence would be these mistakes don't repeat and that they learn from it, which I'm pretty sure they would.”
Which begs the question why test engineers with leetcode trivia bullshit. You are yourself emphasizing why their interview process (and they are just one of many offenders) is so bananas inappropriate.
Which begs the question why test engineers with leetcode trivia bullshit. You are yourself emphasizing why their interview process (and they are just one of many offenders) is so bananas inappropriate.
One single bug is why their process is bananas inappropriate? I really hope all of your code is perfect every single time to be acting so high and mighty.
This isn't exactly the first time Facebook has been called out for poor engineering practices:
https://www.darkcoding.net/software/facebooks-code-quality-p...
https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap...
https://www.darkcoding.net/software/facebooks-code-quality-p...
https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap...
So what? They're an enormous engineering company with many millions of lines of code. Bugs are expected.
Those criticisms aren't about mere bugs, but a bloated over-engineered iOS apps with far too many classes (18k back in 2015) [0]. The Android app was also previously notorious for patching Dalvik at runtime to deal with the huge number of Java methods [1].
Granted, perhaps things have gotten better in the last five years.
It's certainly possible for an enormous engineering company to have poor code quality or poor engineering practices, despite having a high interviewing standard. And a criticism of Facebook need not be a criticism of all companies that interview by Leetcode, for instance no one here is criticizing Google, Amazon, or Apple, and all have better reputations for code quality.
[0] https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_...
[1] https://www.facebook.com/notes/facebook-engineering/under-th...
Granted, perhaps things have gotten better in the last five years.
It's certainly possible for an enormous engineering company to have poor code quality or poor engineering practices, despite having a high interviewing standard. And a criticism of Facebook need not be a criticism of all companies that interview by Leetcode, for instance no one here is criticizing Google, Amazon, or Apple, and all have better reputations for code quality.
[0] https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_...
[1] https://www.facebook.com/notes/facebook-engineering/under-th...
I think I’ve done things like what Facebook did, when I was writing one-off security exploit scripts. Someone needs to stop that team.
This is so shortsighted it’s painful.
You’re describing the attitude Facebook takes towards candidates, not the attitude I take towards anything.
Candidates should be saying to Facebook, “ I really hope all of your code is perfect every single time to be acting so high and mighty” and absolutely making a huge deal out of a case like this when it isn’t.
You’re describing the attitude Facebook takes towards candidates, not the attitude I take towards anything.
Candidates should be saying to Facebook, “ I really hope all of your code is perfect every single time to be acting so high and mighty” and absolutely making a huge deal out of a case like this when it isn’t.
pb7(1)
If only they knew how to balance a binary search tree.
vmception(2)
LeetCode easy
But Apple advertising says we have privacy!
good
Unpopular opinion: bugs happen. Be bold.
What's "be bold" supposed to mean?
Break every application that links your SDK, of course.
git force push, and damn the torpedoes
remove the headphone jack of course
This should not be the case for a library developer. If you accept the consequences for your app, that's fine, but you shouldn't be expected to accept the consequences of a library developer being careless.
That's true. But other apps crashing due to it is much worse. Facebook would be bold if theu opens address the issue.
I’m calling it “lefb-pad”
10 to 1 it is going to be about SDKs generated from php with its bizzaire associate arrays.
https://github.com/facebook/facebook-ios-sdk/issues/1373#iss...
> It does not matter. Their libraries are dynamic, and they abuse +load functions for classes with some business logic calls. So, +load will be called anyway on the application launch when dyld loads all linked frameworks.
and
> I really don't understand why it is still crashing when we turn it off? Could you please explain, why there is a remote connection even we comment out the implementation? Linking binary framework just enough to break things down, why? What do you do in background? Sending or receiving some data even it's not been initialized?