Android allows adb install over usb and still sandbox the application. Sandboxing is a feature of the OS and not the store. What's missing from parent description is the publisher signature to retain allowed permissions after upgrades, which still is a feature of the OS and not the store.
Stricter sandboxing makes it more difficult to fingerprint the user and lessens the burden and dependency on legal contracts and policies. Which is what Apple just did by blocking the access to unique device id.
This is accurate. HOWEVER being hostile to your OS can result in problems. If google REALLY wanted to do something, they could build in a form of adblocking into the OS layer itself. They can also keep that up to date via app updates from their side. Its definitely a battle, but facebook analytics is well documented by adblock communities and google keeping that list in the OS would be a possibility.
Having said that, google has no intention of waging war against facebook. They have an understanding already.
You can't realistically keep apps from tracking users without permission unless you're rejecting apps that are discovered to be doing that. If they have network access, they can track. The behavior is too abstract to be handled with permissions alone.
The apps cannot track if they have no permission to access the respective APIs that give them data they are tracking. What are they going to send via the network? Only things that the users specifically give to the app.
Look up what the Apple's tracking-prevention policy prevents for users that don't opt-in to tracking. You cannot ban generating device or user identifiers with OS permissions alone. Prevent using the built-in ones, sure, but fingerprinting or otherwise creating device or user IDs to share with 3rd parties and other apps? I'd love to see what a permissions model would look like that could do that automatically, at the OS level. I don't think such a thing exists. Not for any app with enough access to the system to do anything remotely useful in the first place.
Getting sued for stealing software from the users, and for interfering with the business of the suppliers, neither of whom have any agreement with Apple to let them ‘reject’ software arbitrarily.
Apple would not be 'stealing' software. Nobody promised that OSX could run any software the user wishes. Does Apple steal software and "interfere with the business of suppliers" every time they break backward compatibility?
They just need to time a new policy to a major release (say they make it apply only from that release on), and that would be no different then any other breaking change.
It wouldn't be popular on HN, but it's technically possible and legal. I'm sure that the Apple fans here will support it unreservedly.
>>Nobody promised that OSX could run any software the user wishes.
>In fact they have said this publicly in interviews.
So I can sue them for not running Apple II programs? Cool! There were always programs that failed to run for some reason or another, and programs taken out of the Mac store, etc.
>Apple doesn’t force you to install operating system upgrades, and many people don’t upgrade if it will break the software they work with.
Sure, just apply a new rejection policy after an upgrade, and state it applies from that version on. That's what Apple would normally do anyway. So you're just admitting I'm right.
>>In fact they have said this publicly in interviews.
> So I can sue them for not running Apple II programs? Cool! There were always programs that failed to run for some reason or another, and programs taken out of the Mac store, etc.
No, you just don’t know much about Apple.
They haven’t promised to be backward compatible with everything, but they have promised not to stop you from running what you want to run.
I.e. they have promised not to do what you are saying they should do.
> Sure, just apply a new rejection policy after an upgrade, and state it applies from that version on. That's what Apple would normally do anyway.
Apple has never done this.
> So you're just admitting I'm right.
Obviously not. In fact you have proven yourself completely wrong, by acknowledging that they could not do it under their current license and with their current software and would need to get people to agree to a new contract.
Yes, Apple, (or anyone else) could offer a service for the Max that users sign up for to remotely disable software they disapprove of.
Until the competition publishes an app called iMessage with a surveillance backdoor (unless you’re proposing phones perform DPI?) and the helpful, inevitable “merge app stores together” app that would be necessary in that world subsequently prioritizes the bad one, or users assume the bad one is the right one, or, or, or. There’s a million threat vectors for their model that don’t dissolve down to a technical mechanism.
Much of the security gained from having a single App Store is not technical in nature but rather reflects (conscious) security policy. This should be apparent. Fundamentally server people chafe at this but look at how much security work (and failure) goes into routinely running hostile code not written by you, particularly on the hosting side. Cloud providers have armies dedicated to the exact same security problems that app stores must solve and it is very often not good enough. That’s fine when nerds are involved but more people than nerds use phones.
They could have all the same levels of security without the need to prevent competition.