5 ms·
What specific protection are you envisioning here? An OS that completely locks down access to user input is one that you can't write a useful application for in
by b3morales 5y ago
What specific protection are you envisioning here? An OS that completely locks down access to user input is one that you can't write a useful application for in the first place. Once the OS has handed the program a string the user entered, or a button tap, it can't prevent the program from recording that.
- Apocryphon 5y agoSomething like Apple’s user anonymizer patents https://venturebeat.com/2012/06/20/new-patent-will-apple-clone-you-to-save-you-from-big-brother/ https://venturebeat.com/2012/06/20/new-patent-will-apple-clo... Looks like they have a recent patent for obfuscating location data, too https://patent.nweon.com/21429 https://patent.nweon.com/21429
- simonh 5y agoCan you give me an example of a third part app that might need access to on-device data outside the app, but for which obfuscated data would be sufficient? Let's say I have a calendar app and ask users for permission to access their address book, how would obfuscated address data be useful to the app? Of if I have a navigation app and need access to location data, how would you obfuscate that and still have it capable of navigation? I suspect you haven't thought this through.
- Apocryphon 5y agoHere, Apple has also invented something that has a use case (albeit an edge one) that is applicable: obfuscating visual data from a camera for the purposes of protecting confidential data (from guest users, presumably): "Obfuscating the display of information and removing the obfuscation using a filter" https://www.patentlyapple.com/patently-apple/2012/01/apple-wins-more-strategic-patents-covering-the-iphone-smart-cables.html https://www.patentlyapple.com/patently-apple/2012/01/apple-w... https://patents.google.com/patent/US20110206285A1/en https://patents.google.com/patent/US20110206285A1/en And a follow-up: "gaze-dependent visual encryption" https://appleinsider.com/articles/20/03/12/gaze-detection-may-help-keep-your-iphone-display-private-from-others https://appleinsider.com/articles/20/03/12/gaze-detection-ma... And even more articles: https://www.patentlyapple.com/patently-apple/2011/05/apple-working-on-privacy-mode-viewing-options-for-future-displays.html https://www.patentlyapple.com/patently-apple/2011/05/apple-w... https://www.patentlyapple.com/patently-apple/2011/08/apple-invents-privacy-glasses-for-reading-confidential-information-or-playing-multi-player-games.html https://www.patentlyapple.com/patently-apple/2011/08/apple-i...
- simonh 5y agoI know obfuscation is possible, that’s fine, but you’re not answering my question. How is that applicable in this case? Can you give me an example of how obfuscation prevents an app, with access to data it needs to function, from sharing that data with the developers. Because as far as I can see it’s irrelevant to this issue.
- Apocryphon 5y agoWait a second, TFA itself talks about how obfuscation can limit the service area of data that third party apps can phone home with. > Trackers can’t send data that they don’t have access to, so the most direct technical fix is to limit or eliminate app access to information that is used to fingerprint devices. In iOS 15, apps are allowed unlimited access to device data that are totally irrelevant to their functionality. For example, why would any app need access to the exact second that the user last restarted their iPhone? And why does iOS give apps access to this data in such a high degree of precision? Data such as an iPhone’s remaining battery and screen brightness (both accurate to 15 decimals), or an iPad’s remaining free space (down to the byte), serve no legitimate, non-fingerprinting purpose for most apps. And for the rare app that might need this level of precision, App Review should approve the usage on a case-by-case basis. Even without App Review, Apple could build into the API the explicit use of a permission requests system (extending beyond the current one), that itemizes all of the types of permissions a developer can ask (to complete specifics), add that to the existing section in the Info.plist, and expose that to the user when downloaded into a UX that goes into specific details about what the user is exposing. Better yet, to turn off features as granular as access to "what keyboards are on this device." Apple could build GDPR into its system itself, while obfuscating the data it leaves out, as with some of the aforementioned links. So I see now obfuscation is only part of the puzzle, the rest is making the permissions system even more robust. > the only way to disincentivize this behaviour is with policies that ban it and the threat of expulsion from the App Store if you're caught. If the claim is that only App Store review is sufficient, then the App Store does not go far enough. The article states "Apple also needs to take a hard line against closed-source trackers — especially the ones that further encrypt the data they’re sending to third-party servers [...] the only way to ensure the tracker isn’t stealing any of this, is for the tracker to reveal their source code." Mandate that tracking APIs and libraries must either be open source, or make themselves open to App Store review. If not, then the App Store is just a fig leaf, a half-measure.