3 ms·

What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up

by DenisM 10y ago

What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up when discussing in-browser crypto and could never get a satisfactory answer.

remy_ 10y ago
Because the binary is served from a marketplace that works with an app that you trust and that will verify the package signature. Or, the web browser does not behave like a package manager.
- aurelianito 10y ago
  So it would need a browser plug-in instead of just a web page? That seems fair enough. Extra kudos if they manage to use a standard plug-in for several websites. Maybe we can even get some kind of standard for this.
eganist 10y ago
For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications). Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate disruption via code injection i.e. XSS. That said, we're all conveniently ignoring the fact that all of this assumes that the devices themselves haven't been owned. If you think you're a target of entities capable of getting into a fully patched phone, you've got bigger problems.
- DenisM 10y ago
  So this is "whomever is signing the app gets compromised" vs "whomever is hosting js gets compromised". Right? Facebook could afford a security team just as capable as Apples security team, and make sure the js server remains secure. And if they can't, their own signing procedure can get compromised before the app is uploaded to Apple for review. I'm still not seeing the difference. Anyone?

3 ms·

What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up

by DenisM 10y ago

remy_ 10y ago
Because the binary is served from a marketplace that works with an app that you trust and that will verify the package signature. Or, the web browser does not behave like a package manager.
- aurelianito 10y ago
  So it would need a browser plug-in instead of just a web page? That seems fair enough. Extra kudos if they manage to use a standard plug-in for several websites. Maybe we can even get some kind of standard for this.
eganist 10y ago
For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications). Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate disruption via code injection i.e. XSS. That said, we're all conveniently ignoring the fact that all of this assumes that the devices themselves haven't been owned. If you think you're a target of entities capable of getting into a fully patched phone, you've got bigger problems.
- DenisM 10y ago
  So this is "whomever is signing the app gets compromised" vs "whomever is hosting js gets compromised". Right? Facebook could afford a security team just as capable as Apples security team, and make sure the js server remains secure. And if they can't, their own signing procedure can get compromised before the app is uploaded to Apple for review. I'm still not seeing the difference. Anyone?