5 ms·

> We are at a point where auto-updates are more risky than the security flaw itself - especially since iOS has a pretty good sandbox, especially since its impos

by g_p 6y ago

> We are at a point where auto-updates are more risky than the security flaw itself - especially since iOS has a pretty good sandbox, especially since its impossible for one app to access the data of another. Additionally, the App usually connects to a pretty limited set of servers, and is not publicly reachable. So the attack vector is pretty small. I'd have to say that most apps now connect to a rather large number of hosts/servers, and it's getting increasingly untenable to not offer users proper control of this. I get that Apple wants to be "friendly computers", but looking at my firewall logs I'm seeing: - third party audience segmenting - third party analytics - third party static content being fetched - third party ad networks - first or third party generic cloud server connections I think the attack vector on apps is quite significant if you consider the app itself to have been built to monetize data - there's no outbound traffic filtering to check the system isn't leeching user data and/or device identifiers (the latter getting better and hopefully Apple will require consent soon for the ID for advertisers). It's trivial to make an app that leeches a user's contacts regularly to a server, then does anything the developer feels like to build a social graph. See clubhouse. I fear the biggest issue for most users' privacy are the "legitimate" apps they use simply not being built with incentives aligned with their interests, and having access to phone home to any server with anything they can access.

Silhouette 6y ago
hopefully Apple will require consent soon for the ID for advertisers Just think through the implications of that phrase for a moment, though. Your own device comes with a built-in mechanism specifically designed for advertisers to track you. Why was that ever a good idea in the first place?
- sjwright 6y ago
  Such mechanisms have already existed and never needed OS-level sanction. It’s pretty clear that Apple is employing the strategy of “embrace, extend, extinguish” against tracking and privacy compromising dark patterns. In other words, force developers to use a special API, then give consumers the ability to block it. The current stoush with Facebook is only the most formidable hurdle Apple has encountered so far.
  - Silhouette 6y ago
    That is the usual argument, but I don't see how it stands up to scrutiny. Either there are alternative ways to track a user of an Apple device without IDFA or there are not. If there are, then it is reasonable to assume that unethical advertisers will return to using them if their access to IDFA is gated. So, whether or not IDFA exists, the only robust way to protect users is to block apps from having access to anything about the host device that implicitly provides a unique method of identifying the user. This is what other platforms have been trying to achieve. For example, in the web browser ecosystem, software has been restricting programmatic access to features that can be used for fingerprinting or deliberately reducing the level of detail exposed by some APIs. With control of the entire ecosystem, why is Apple not better placed to adopt this strategy than anyone else, and whether or not Apple is technically capable of achieving the perfect result, how does introducing IDFA make any difference?
    - g_p 6y ago
      It does seem like when IDFA goes, apps will be struggling for identifers, at least on iOS. I've seen a few articles suggesting they will be back to trying to fingerprint devices (in manners that break the App Store terms of service). I agree entirely - it seems that the solution going forwards is to prevent any access to any kind of persistent identifier that is part of the runtime environment. This might get in the way of some security mitigations (which seem pretty weak to begin with) and some monetisation models (i.e. enabling pervasive tracking across apps), but the end result feels more "clean" and like users would expect - the app runs in a sandbox where there's no access to anything to distinguish the app from any other instance of it. Clearly keeping this up at the network level is far harder (and some app developers will probably fall back to using the WAN IP and other factors), but perhaps there are even solutions here - perhaps TCP relay servers mix user traffic (while leaving it HTTPS-protected) to prevent services from seeing user IPs, and a virtual network interface internally in the runtime ensures apps only see an IP of 10.0.0.1. It seems a worthy goal to try to ensuer that runtime environments are indistinguishable, at least to end cross-service ad tracking once-and-for-all. Handling it within apps probably comes down to policy - not sure any technical mitigations can prevent this while apps can remain Turing complete (as they can simply store their own identifier).
- g_p 6y ago
  Agreed - it really is absurd. One time I tried to design as a thought experiment a "platform" where each execution environment of the app was absolutely indistinguishable from any other. Unfortunately to make it work you can't give it network access (easily, at least). But you have a whole host of stuff in /proc and /sys that you also need to block (at least on Android) - there's just too much unique per-device information available to apps. Clearly ensuring runtimes are indistinguishable was never a design goal (as some simple chroot'ing together a virtual filesystem would help to prevent a lot of this, as long as the APIs are limited enough). But alas, when your phone OS comes from an adtech company, that is probably a hint they are not interested in making it indistinguishable from others.
littlecranky67 6y ago
> there's no outbound traffic filtering to check the system isn't leeching user data and/or device identifiers But there is the iOS sandbox FS. So if an App gets exploited, it can only every leech the data from exactly THAT app. Just the same as an auto-update might just start to leech and upload that data. Given the real-world practices, I think it is more likely an App creator choses to upload the data, than some malicious hacker doing it. > It's trivial to make an app that leeches a user's contacts regularly to a server On iOS this is not possible - either the App requests access to the contacts list then I have to consent via iOS sandbox features, or it doesn't get access. And if I didn't give this consent, any security hole that exploits the App will need to get that consent too (at which I will not give it).
- g_p 6y ago
  From a technical perspective, you're of course right. I fear however that the majority of "regualar users" are being coerced into giving consent without realising what is happening - seeing the number of people end up in a FOMO-induced panic to join Clubhouse (or whatever the next big popular phone number based app is), a simple "give access to your contacts to invite a friend" masks the fact the app uploads your contacts to the server every time you open the invite tab. It feels we need to address coercive practices or at least try to do some kind of taint analysis to allow iOS to alert that it believes the memory buffer about to go into a networking API originates from a permission-protected memory buffer, and are you sure you want to let the app upload your contacts... But I suspect we just end up shifting the problem, and they coerce users again, ad infinitum, until they harvest their social graph (illegally, at least in Europe/UK).

by g_p 6y ago

Silhouette 6y ago

hopefully Apple will require consent soon for the ID for advertisers Just think through the implications of that phrase for a moment, though. Your own device comes with a built-in mechanism specifically designed for advertisers to track you. Why was that ever a good idea in the first place?

sjwright 6y ago
Such mechanisms have already existed and never needed OS-level sanction. It’s pretty clear that Apple is employing the strategy of “embrace, extend, extinguish” against tracking and privacy compromising dark patterns. In other words, force developers to use a special API, then give consumers the ability to block it. The current stoush with Facebook is only the most formidable hurdle Apple has encountered so far.
- Silhouette 6y ago
  That is the usual argument, but I don't see how it stands up to scrutiny. Either there are alternative ways to track a user of an Apple device without IDFA or there are not. If there are, then it is reasonable to assume that unethical advertisers will return to using them if their access to IDFA is gated. So, whether or not IDFA exists, the only robust way to protect users is to block apps from having access to anything about the host device that implicitly provides a unique method of identifying the user. This is what other platforms have been trying to achieve. For example, in the web browser ecosystem, software has been restricting programmatic access to features that can be used for fingerprinting or deliberately reducing the level of detail exposed by some APIs. With control of the entire ecosystem, why is Apple not better placed to adopt this strategy than anyone else, and whether or not Apple is technically capable of achieving the perfect result, how does introducing IDFA make any difference?
  - g_p 6y ago
    It does seem like when IDFA goes, apps will be struggling for identifers, at least on iOS. I've seen a few articles suggesting they will be back to trying to fingerprint devices (in manners that break the App Store terms of service). I agree entirely - it seems that the solution going forwards is to prevent any access to any kind of persistent identifier that is part of the runtime environment. This might get in the way of some security mitigations (which seem pretty weak to begin with) and some monetisation models (i.e. enabling pervasive tracking across apps), but the end result feels more "clean" and like users would expect - the app runs in a sandbox where there's no access to anything to distinguish the app from any other instance of it. Clearly keeping this up at the network level is far harder (and some app developers will probably fall back to using the WAN IP and other factors), but perhaps there are even solutions here - perhaps TCP relay servers mix user traffic (while leaving it HTTPS-protected) to prevent services from seeing user IPs, and a virtual network interface internally in the runtime ensures apps only see an IP of 10.0.0.1. It seems a worthy goal to try to ensuer that runtime environments are indistinguishable, at least to end cross-service ad tracking once-and-for-all. Handling it within apps probably comes down to policy - not sure any technical mitigations can prevent this while apps can remain Turing complete (as they can simply store their own identifier).
g_p 6y ago
Agreed - it really is absurd. One time I tried to design as a thought experiment a "platform" where each execution environment of the app was absolutely indistinguishable from any other. Unfortunately to make it work you can't give it network access (easily, at least). But you have a whole host of stuff in /proc and /sys that you also need to block (at least on Android) - there's just too much unique per-device information available to apps. Clearly ensuring runtimes are indistinguishable was never a design goal (as some simple chroot'ing together a virtual filesystem would help to prevent a lot of this, as long as the APIs are limited enough). But alas, when your phone OS comes from an adtech company, that is probably a hint they are not interested in making it indistinguishable from others.

littlecranky67 6y ago

> there's no outbound traffic filtering to check the system isn't leeching user data and/or device identifiers But there is the iOS sandbox FS. So if an App gets exploited, it can only every leech the data from exactly THAT app. Just the same as an auto-update might just start to leech and upload that data. Given the real-world practices, I think it is more likely an App creator choses to upload the data, than some malicious hacker doing it. > It's trivial to make an app that leeches a user's contacts regularly to a server On iOS this is not possible - either the App requests access to the contacts list then I have to consent via iOS sandbox features, or it doesn't get access. And if I didn't give this consent, any security hole that exploits the App will need to get that consent too (at which I will not give it).

g_p 6y ago
From a technical perspective, you're of course right. I fear however that the majority of "regualar users" are being coerced into giving consent without realising what is happening - seeing the number of people end up in a FOMO-induced panic to join Clubhouse (or whatever the next big popular phone number based app is), a simple "give access to your contacts to invite a friend" masks the fact the app uploads your contacts to the server every time you open the invite tab. It feels we need to address coercive practices or at least try to do some kind of taint analysis to allow iOS to alert that it believes the memory buffer about to go into a networking API originates from a permission-protected memory buffer, and are you sure you want to let the app upload your contacts... But I suspect we just end up shifting the problem, and they coerce users again, ad infinitum, until they harvest their social graph (illegally, at least in Europe/UK).