6 ms·

Seems to be some suggestions now that apps were continuing to crash even after commenting out the FB implementation because FB is managing to do remote API call

by fooey 6y ago

Seems to be some suggestions now that apps were continuing to crash even after commenting out the FB implementation because FB is managing to do remote API calls just because the framework is linked. https://github.com/facebook/facebook-ios-sdk/issues/1373#issuecomment-624944045 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?

saagarjha 6y ago
(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.)
- favorited 6y ago
  Even better: don't override +load or use static constructors!
  - saagarjha 6y ago
    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…)
    - favorited 6y ago
      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.
- vvG94KbDUtRa 6y ago
  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
  - saagarjha 6y ago
    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.)
  - jfkebwjsbx 6y ago
    Running code before main has nothing to do with performance.
    - unilynx 6y ago
      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
  - munchbunny 6y ago
    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.
- kccqzy 6y ago
  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 https://en.cppreference.com/w/cpp/language/constinit It basically asks the compiler to enforce that constructor calls can only do trivial things.
- rohansuri 6y ago
  (non C++ developer here) What is the +load being referred?
  - zerocrates 6y ago
    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/nsobject/1418815-load?language=objc https://developer.apple.com/documentation/objectivec/nsobjec...
- red_admiral 6y ago
  For the iOS developers reading along: please ban this behaviour in a future version?
  - ynx 6y ago
    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.
    - red_admiral 6y ago
      Not 'ban static constructors', sorry if I wasn't clear. Ban network I/O before main() has started.
bitcrazy 6y ago
The Facebook SDK does make some calls on init. https://developers.facebook.com/docs/app-events/gdpr-compliance/ 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...
- gtufano 6y ago
  I would be shocked...
- mschuster91 6y ago
  > 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.
  - tpxl 6y ago
    This is not a violation by Facebook, this is a violation by the app developer.
    - mschuster91 6y ago
      Technically yes, but it is as much also FB's fault for providing an SDK that cannot be used without violating the GDPR.
      - pilif 6y ago
        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)
0x0 6y ago
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.
- steerablesafe 6y ago
  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?
- marcus_holmes 6y ago
  Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?
  - 0x0 6y ago
    An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.
  - microcolonel 6y ago
    That's only if you don't review the changes, and trace the entry points at least.
- ChrisMarshallNY 6y ago
red_admiral 6y ago
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.
- dgoldstein0 6y ago
  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.

by fooey 6y ago

saagarjha 6y ago

(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.)

favorited 6y ago
Even better: don't override +load or use static constructors!
- saagarjha 6y ago
  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…)
  - favorited 6y ago
    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.
vvG94KbDUtRa 6y ago
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
- saagarjha 6y ago
  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.)
- jfkebwjsbx 6y ago
  Running code before main has nothing to do with performance.
  - unilynx 6y ago
    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
- munchbunny 6y ago
  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.
kccqzy 6y ago
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 https://en.cppreference.com/w/cpp/language/constinit It basically asks the compiler to enforce that constructor calls can only do trivial things.
rohansuri 6y ago
(non C++ developer here) What is the +load being referred?
- zerocrates 6y ago
  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/nsobject/1418815-load?language=objc https://developer.apple.com/documentation/objectivec/nsobjec...
red_admiral 6y ago
For the iOS developers reading along: please ban this behaviour in a future version?
- ynx 6y ago
  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.
  - red_admiral 6y ago
    Not 'ban static constructors', sorry if I wasn't clear. Ban network I/O before main() has started.

bitcrazy 6y ago

The Facebook SDK does make some calls on init. https://developers.facebook.com/docs/app-events/gdpr-compliance/ 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...

gtufano 6y ago
I would be shocked...
mschuster91 6y ago
> 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.
- tpxl 6y ago
  This is not a violation by Facebook, this is a violation by the app developer.
  - mschuster91 6y ago
    Technically yes, but it is as much also FB's fault for providing an SDK that cannot be used without violating the GDPR.
    - pilif 6y ago
      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)

0x0 6y ago

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.

steerablesafe 6y ago
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?
marcus_holmes 6y ago
Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?
- 0x0 6y ago
  An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.
- microcolonel 6y ago
  That's only if you don't review the changes, and trace the entry points at least.
ChrisMarshallNY 6y ago

red_admiral 6y ago

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.

dgoldstein0 6y ago
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.