Facebook iOS SDK Remotely Crashing Spotify, TikTok, Pinterest, Winno and More
github.com
github.com
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?
`__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.
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
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.
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...
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.
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...
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 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 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.
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.
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...
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.
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)
It is not any arbitrary sdk, it is fb, probably one of the essential sdk nowadays.
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.
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.
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
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.
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.
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.
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.
There's even comments in this HN thread that point you on how to do it on Android if you're so inclined.
I'd give more credence to "the market is making an informed choice" hypothesis if consumers were, in fact, informed.
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.
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.
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.
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
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?
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)
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.
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.
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.
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.
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.
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?
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.
There would be no reason to put advertising in the app the user has already paid for.
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 mostly agree. But, in some(most) also the user by encouraging the developer to release updates and launch new features.
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.
>> Yes, absolutely.
Much much worse: https://news.ycombinator.com/item?id=19595478
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.
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.
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.
The government can do and has done far more damage than big tech.
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 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 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'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.
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
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.
I think I as a user should get to decide that.
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.
I love and happily pay for Spotify, but it is eye-opening that they send any data to Facebook. Well, shit.
In fact I would say that the incident we are discussing here shows that adding the sdk adds a failure mode.
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.
https://falkvinge.net/2017/04/15/schiphol-airport-tracking-e...
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.
- Upton Sinclair (https://en.wikipedia.org/wiki/Upton_Sinclair)
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?
I guess you could always complain about it to your country's data protection watchdog and then we'll all find out?
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.
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.
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 isn't so nice when they don't.
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.
[1] although people might have issues with unethical or illegal uses.
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.
It’s extremely unethical, and should be illegal.
Might help streamlining the market, so I‘m open for that.
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.
If the app is paid-for, it's less forgivable to be using this kind of spyware.
Apparently you don't think actually knowing if the app includes the SDK is relevant, this is victim blaming of the highest tier.
so what?
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.
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.
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.
It’s win-win for facebook and the app developer. It’s only lose for the actual user.
Of course not because it describes the same behavior.
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.
I support you in your courageous fight against nuance.
It is that simple - I don't trust or use FB, and of course that includes third party FB feeders.
For on-phone use, so you can grab cellular data, Charles:
This seems like much less of a damning claim than openly supporting an ad network.
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).
GPDR specifically allows for anonymized/aggregated data on app usage or marketing feedback: https://gdpr.eu/eu-gdpr-personal-data/
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.
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?
Analogy may not be perfect but it takes serious mental gymnastics to fail to see this as spyware, in my opinion.
"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."
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.
"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."
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.
"TV watches you", except this isn't Soviet Russia.
In the most of the important ways; no.
You can still fight back effectively. Don't go gentle into that good night.
> 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/...
Totally not creepy.
[0]: https://nshipster.com/device-identifiers/#fingerprinting-in-...
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").
If the parties consent to it, it’s fine. When it’s hidden and nonconsensual is where the problem arises.
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.
if (restrictiveParams[eventName] as! [String: Any])["test"] != nil
I doubt (and at least from my experience around SV, haven't seen) that FB/Google are paying apps to include their SDKs.
I remember being grandfathered into not having it and Spotify would ask me every time I logged in to integrate my FB account.
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.
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.
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.
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.
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)
Firebase should be next, requiring you to include a whole bunch of Firebase lib crap just to use Crashlytics.
"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."
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...
Also see: https://github.com/facebook/facebook-ios-sdk/issues/1373
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.
Nope, can't agree there. Every outlet/brand should have it's own app in my book.
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.
Edit: from the issue it looks like they've done something, but people are still reporting crashes…
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.
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.
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.
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...
Strongly disagree on this. Exact opposite maybe but I don't want to generalize. Modern authoritarian tactics are pretty much impossible without engineering.
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 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.
Does Apple use FB SDK in their apps? I think not, but can someone confirm?
https://www.reddit.com/r/androiddev/comments/g6t8fu/google_m...
> Please move slower and break fewer things. Thank you.
Rightfully so. If you add an SDK to you app, it's your fault if the SDK causes your app to crash.
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!
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.
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.
The unspoken rule is because apps make money for Apple and websites don't.
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] - https://downdetector.com
> Server side change is already reverted. The crash will vanish.
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.
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.
https://www.darkcoding.net/software/facebooks-code-quality-p...
https://blog.timac.org/2017/0410-analysis-of-the-facebook-ap...
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...
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 :)
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.
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)
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.