3 ms·
What technical restrictions can they do? It can't be sandboxing, as the entitlements and/or existence of sandboxing for an app is enforced by the App Store, an
by olliej 5y ago
What technical restrictions can they do?
It can't be sandboxing, as the entitlements and/or existence of sandboxing for an app is enforced by the App Store, and we've just said we're not using that.
It also removes privacy protections: Facebook is required to ask permission to track you on iOS. It's only required to by platform policy in the App Store license agreement. They're not using that any more, so goodbye opt-in tracking.
- ThatPlayer 5y agoWhy couldn't they make the entitlements enforced by the operating system with user prompts, rather than the App Store (or both)? Just because that's how it's done right now doesn't mean we're just flipping a switch and suddenly allowing everything. It's still up to Apple on how they implement it. If that's how they choose to implement it, that's on Apple.
- olliej 5y agoPrompt based security has been shown to be a bad "solution" over and over again. The primary goal of which degenerates to "blame the user". Even if you do want to do that, what do you ask the user? Even the basic entitlements often require some amount of knowledge a regular user simply doesn't have. Then the law itself has rules prohibiting restrictions, and I would bet someone will claim dialog based security counts as a restriction. The law even makes it hard (impossible?) for a platform to protect even a modicum of user privacy. Section 2 (b) 3&4 explicitly prohibits a platform owner from placing restrictions on collection and use of user data.
- ThatPlayer 5y agoAs opposed to the current primary goal of giving all the power to Apple to decide what the user gets? And once again, that's on Apple to implement. If they choose to continue to keep entitlements in the same format, that's on them to explain it to the user. See Android, they handle permissions fine. That section doesn't place restrictions on the generation of user data, only access to generated data. So don't generate it. In my opinion that's to prevent the platform holder from getting an unfair advantage by keeping the data for themselves. If the user doesn't give permission, the device doesn't generate the data, you're not restricting access to data because it doesn't exist.
- olliej 5y agoYou mean the android that has a massive malware problem? That android? As for the second bit, the "generated information" is things like device ids, location, etc. The stuff that is necessary for a phone. But clearly you're of the view that requiring malware, people having to give CC information to innumerable other companies, is a good thing, so I doubt we're ever going to agree on this. I would rather not have to worry about software installing a persistent crypto miner in the background, and not having to worry about software invading my privacy, than installing whatever mysterious apps aren't currently permitted on the App Store, but you do you.
- ThatPlayer 5y agoNo, it's only "generated through an interaction of a covered platform user with the business's products or services". Device ID and Locations aren't exactly generated through an interaction unless the user decides to give it. Exactly that's your choice. You can choose to continue being on Apple's App Store where they do check for all of these if you want. No one is forcing you to install give that credit card info. Don't take away my choice to choose otherwise. If I want to pay for something with credit card, shouldn't I be allowed to? Or if I wanted to run background processes on my devices?
- olliej 5y agoYou do have a choice, for all of your examples: you can buy an android device. The iOS ecosystem is successful because that is what many people want. You want the android experience, but rather than getting an android, you want to force that on the people who prefer the iOS model. They like not having to worry about malware. Currently an iOS user can get all the software that they want from the iOS AppStore, and they don’t have to give random companies their CC#, they don’t have to worry about the app subverting their privacy, because they know apple kills software that does that whenever they find it. This law means they have to deal with multiple different stores, that have no incentive to maintain platform security or user privacy. In fact they’re incentivized to abuse user privacy. As an iOS user I do not want the android experience. This law basically forces ios to have that. Malware and all. The only things this does is reduce user security, and give scummy publishers the ability to bypass AppStore rules the protect users (like “you must make discounting if subscriptions trivial”, “you don’t get to run a cruptominer in the background”, etc). Again, if you want to have the android experience, use android. Literally no one is stopping you.
- vineyardmike 5y agoApple is being extremely dishonest. The App Store changes shouldn't impact sandboxing. > App Sandbox is an access control technology provided in macOS, enforced at the kernel level. https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html https://developer.apple.com/library/archive/documentation/Se...
- petmon 5y agoDid Apple claim it would impact sandboxing? I don't think they did. A realistic example: today if your iOS app wants to track users, it must go through AppTrackingTransparency.framework, which allows the user to opt-out, and use the device’s advertising identifier which the user may reset. Of course this cannot be enforced by the kernel; it's enforced by App Store review. Sideloaded apps would presumably not be subject to this rule.
- vineyardmike 5y ago> Did Apple claim it would impact sandboxing? I don't think they did. Apple claims that security would be impacted. They implied that sandbox=app store. Its all FUD marketing, of course, but they heavily implied that the app store review was the safety method for customers. > if your iOS app wants to track users, it must go through AppTrackingTransparency.framework, which allows the user to opt-out, and use the device’s advertising identifier which the user may reset. No reason you can't make access to the ATT DeviceID a call to OS. It'd return 000000 in generic case, and prompt the user at OS level to approve. If no approval, then it'd return 0 to app. You can't guarantee what they're doing with the number in-app, but apple barely does that now with review so probably not much loss. Sure some apps could try to access restricted memory or file paths that they aren't supposed to... but thats what the sandbox is for. BUT maybe apple should just kill DeviceId for everyone since im sure most people opted out. The real loss to apple is that first party apps may have to play by their rules, and lose access to privileged APIs, or open them up to sideloaded apps (since the trust boundary is moved from source of app, to OS calls). They don't want to have to play by their own rules.
- olliej 5y ago
- hulitu 5y ago> It also removes privacy protections: Facebook is required to ask permission to track you on iOS. I think they are require to ask permission to track you using iOS API. They still track you based on what you access on Facebook.
- olliej 5y agoThey can minimally track you - the only technical restrictions apple can do is block device I’d, etc. The App Store policies ostensibly also prohibit an app from tracking a user via any other means once that user has said no to tracking.