[derefr]

Yeah, but for the apps that are on iOS devices, Apple is effectively currently standing in the position of "the lawyer who writes a 4000 page contract to de-risk the wish they're making with the evil wish-granting genie", so that we don't have to. Apple forces apps on their store to obey certain restrictions that make life better (less tracked, especially) for consumers; and those restrictions are begrudgingly accepted by the developers, because there's no other way for the dev to access the iOS user-base.

As soon as those devs can avoid Apple's restrictions and deliver their apps directly to users with the "intended" experience, they will.

Personally, I like neutered-evil-genie apps, and will be sad to lose them (i.e. have them turn into unfettered-evil-genie apps, which I won't use.)

[easton]

Isn't the answer for Apple to provide operating-system level restrictions to apps (regardless of source) that make it so the only way any application on the system can access the identifier is by permission from the user? I wouldn't be surprised if this is how it works right now anyway, just because an app is deployed by an enterprise developer doesn't mean it should be able to bypass the app tracking transparency prompt.

Or does the EU law prevent them from having private APIs/system components period? It seems like many people are making the assumption that this means that every single sideloaded app will be able to bypass all of the privacy/security features on the device, and I don't see why that would be. My understanding is that this is for "fairness", which would mean that apps that are sideloaded would have the same level of access as those on the App Store, meaning they use the same APIs that trigger the same prompts.

[derefr]

No, because this isn't about OS-level identifiers; it's about things like e.g. applications working together to track you by passing permacookies through Shared Containers; or about apps that ask for microphone privileges then listening for ultrasound beacons in retail stores to determine their location.

These are the sorts of prohibited behaviors that can be heuristically recognized by technical means (e.g. static analysis), but where any such recognition would necessarily result result in tons of false positives; and so those issues, when raised, must be passed to a team of human auditors for determination.

This is, by-and-large, why App Store submissions — even for updates — still require that human-auditor step. They're always watching for those seemingly-minor "this app got sold to someone evil" updates that slip in spyware — the kind you see often with Chrome Extensions.

[easton]

Your point is valid, but I think those examples are fixable. Permacookies could be fixed as simply as "Would you like to allow {EvilApp} to access data from {EvilPartnerApp}?", as there aren't a lot of reasons that apps should be passing data between each other without user consent (or the share sheet).

The second example has already been fixed with the microphone indicator from 1-2 versions back, where a light shows up in the corner whenever the microphone has been activated (and swiping down tells you what app activated it). A notification could be added if an app tried to activate the microphone when it wasn't in the foreground (but I don't think the OS lets you do that anyway?)

[derefr]

One other obvious "Turing-hard" spyware side-channel, is that it's basically up to the application developer to come up with a list of Internet domains it should be able to connect to, to put into the app's entitlements; and it's up to humans at Apple to determine whether that list is sane — often by starting up the app with syscalls to the network stack shimmed/traced, doing packet captures, and seeing what the app says to each of the domains it lists itself as entitled to talk to.

You'd think that maybe restricting connections to e.g. domains that are rooted in a zone the developer has proven ownership of, would be fine... but there are third-party advertising, analytics, and fingerprinting services that allow you to CNAME them as subdomains of your domain to evade ad-blocker signature recognition.

And, of course, no user could ever be expected to figure any of this out if asked in a prompt. "Example App is asking me to allow it to connect to abcdefg.example.com? Well, they own that, don't they? Why wouldn't I allow that?"

[TylerE]

Asking the user sucks. All it does is train users to click yes without thinking about it because they just want to get on with their life. (See: The ubiquitous GDPR cookie prompts).

ANY "solution" that puts more burden on the user isn't.

[petre]

They could just ask once for defaults not every time and have a per app dialog where the user could tweak the permissions, like browsers do. For instance I have almost everything blocked in the browser: camera, location etc.

[easton]

They do it for location access, calendar access, notification access, and clipboard access for every app. Access to shared containers shouldn’t be a common occurrence outside of once when the app is set up.

[tekknik]

You didn’t disprove what your parent said. People still just tap yes on them. I ran an experiment and put little snitch on my wife’s laptop. She just clicked “accept” every time it popped up without question.

[thirdsun]

Well, I'd love it if the GDPR consent prompts were anything like Apple's privacy prompts.

The problem with consent prompts on websites is that they are rarely in compliance with the GDPR.

[tekknik]

The industry will always find ways around regulation. And what we’re left with is a confusing set of spaghetti laws.

[nodamage]

People always make this argument in these kinds of threads and I wonder how it isn't blatantly obvious that operating-system level restrictions are woefully inadequate to deal with unscrupulous developers. Put yourself in the mindset of an unscrupulous developer for a moment, can't you think of a hundred ways to abuse permissions granted by the user or operating system to violate privacy?

Take, for example, this: https://www.reddit.com/r/ios/comments/w27x6j/uber_does_not_r...

[Apocryphon]

If these abuses happen under the aegis of the current App Store, doesn't that nullify the argument that App Store review is sufficient protection?

This also ignores that it's conceivable that Apple can harden iOS's existing permissions system.

[nodamage]

> If these abuses happen under the aegis of the current App Store, doesn't that nullify the argument that App Store review is sufficient protection?

Not at all. App Store review is not perfect and no one expects it to be. That doesn't mean it has no value or that we should get rid of it entirely. Otherwise you could make the same argument about any system involving unscrupulous actors: "people still kill despite there being laws against murder, doesn't that mean the law is pointless?"

> This also ignores that it's conceivable that Apple can harden iOS's existing permissions system.

Curious how you think this would actually solve the issue I linked above.

[Apocryphon]

> App Store review is not perfect and no one expects it to be.

But Apple is clearly presenting it as such.

> That doesn't mean it has no value or that we should get rid of it entirely.

That is correct, but right now it is the only game in town. There's no secondary stores that present it with competition. Already we read about top-10 grossing apps that are actually scammy. Perhaps Apple will strengthen its App Store when presented with alternatives.

> Curious how you think this would actually solve the issue I linked above.

It really depends on what mechanism that Uber is using to bypass the notifications systems. But off the bat, iOS could force even more granular alerts to the user when sensitive permissions are required.

Curious too, how you think that App Store review currently solves this issue. Uber is already too significant to the platform for Apple to do much more than give them a slap on the wrist, as seen historically.

https://www.cnet.com/news/privacy/apple-tim-cook-threatened-...

[nodamage]

> But off the bat, iOS could force even more granular alerts to the user when sensitive permissions are required.

How does having more granular alerts actually solve this issue?

> Curious too, how you think that App Store review currently solves this issue.

Well, obviously it doesn't, currently. App Store review needs to update their rules to address this type of abuse. Uber is big but they've taken hard line stances against bigger apps before (e.g. Facebook).

> https://www.cnet.com/news/privacy/apple-tim-cook-threatened-...

Sounds like a success story, imagine the alternative scenario where there was no review process and Uber could get away with this unimpeded.

[blub]

Many of the restrictions that Apple added along the years were reactions to abuse by app developers (which in reality nowadays are "legal malware developers"). Everything you can think of has been tried: from reading the installed list of apps, spying on the clipboard, scraping location data from pictures, fingerprinting phones based on camera sensor or motion sensor and many others.

Permissions represent one of two pillars of their strategy against legal malware developers. The second one is the rulebook associated with the AppStore, preventing publishing non-compliant apps and banning developers for breaking said rules. A classic example is Facebook misusing enterprise certificates to install "Facebook research" which allowed them almost unrestricted access to the data of the users. Apple revoked their enterprise certificate, which also affected internal applications that Facebook employees were using. Facebook relented.

If Facebook launches their own app store, the second pillar is completely circumvented. Additionally they will find ways around the technical limitations, be it through use of private APIs, tricking users into clicking confirmations or bribing them. Technical limitations are not enough when dealing with malicious actors.

[petre]

> If Facebook launches their own app store, the second pillar is completely circumvented

Meta be forced to offer their adware/spyware Facebook app through the Apple app store as well, as many people will not agree or won't have the technical knowledge to install more than one alternative app store. Apple will probably be forced to provide a list of alphabetically ordered app stores to choose from in the initial iPhone setup. It's quite convenient that their own app store starts with an A.

[nuker]

> that make it so the only way any application on the system can access the identifier is by permission from the user?

And let's say the user says No. Today the app will be forced to work without it. By Apple Store rules. Tomorrow the app will say "this permission is required for app to work".

[8note]

So nobody downloads the app? Or are you afraid that other app users don't care about your needs, and are trying to force them into agreeing with you?

The government offers a democratic way to determine these requirements

[nikanj]

When we tried to restrict cookie tracking via voluntary consent, every site installed an cookie consent overlay, where agreeing to cookies is one click, not agreeing is seventy-eight clicks.

[headsoup]

Almost every site I've had this pop-up on required no more than 2-5 clicks -> manage cookie options -> either select ok because everything but 'required' is already off or deselect a couple of options then ok. That's easy after doing it a couple of times, it's pure laziness to say that's too hard, and we should not accept that as a good excuse to remove it.

[tekknik]

It’s easy but very annoying. Especially when you have a secure setup that randomizes identifiers or removes cookies after the session such that the next session and every session after that you get the prompt. And how many people do you think actually take the time to deselect things? Your example here is the simplest case. Many sites it’s much more than 5-7 clicks as the pop up has a tabbed interface with 10+ checkboxes per tab. What was this supposed to accomplish again? Harass users?

[nuker]

> So nobody downloads the app?

Some apps are unavoidable for most people, like whatsapp or facebook.

[ThatPlayer]

WhatsApp is avoidable with this same law forcing interoperability with other messaging clients. Facebook's app is avoidable with a browser and Facebook.com . Actually WhatsApp's app is avoidable in the same way.

[tekknik]

They’re all avoidable by just not using them. Use that fancy text message feature of your phone to communicate. 30 years ago these apps didn’t exist and people somehow continued to exist without them.

[tekknik]

Those are very avoidable. Try work apps like slack, teams, concur.

[hammyhavoc]

I just bridge them to Matrix, and get it all in Element.

[kmeisthax]

The obvious counterargument here is that having lawyers write 4000 page de-risked evil genie wishes just normalized the concept of dealing with evil genies. Apple can negotiate around the margins - maybe they stop making their ad tracking identifier opt-out or something. And indeed, that seems good, we increased privacy compared to the alternative. However, this isn't the full picture. Apple is the one who provided that ad tracking identifier in the first place. More generally, they brought a lot of users straight into Facebook's open, gaping maw.

Furthermore, the lawyer isn't just de-risking one evil genie wish, they're de-risking millions of them. Apple does not just have Facebook on the App Store. They have millions of apps. And as you can imagine, many of them are barely reviewed garbage or outright scams. If these apps tried to get distributed outside of the App Store, nobody would trust them. But them being on the App Store gives users a false sense of security. Apple switched from being highly selective in the early days of iOS to doing bare-minimum checks because the latter made them more money.

[8note]

Why not have the government do that? That's the role of government regulations