The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.
https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...
The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.
https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...
You can implement these APIs while at the same time requiring explicit permission from the user before a web application can use them. This preserves privacy while also giving users the option to have much more powerful web applications.
Apple doesn't want to implement these APIs because currently if you want access to these things on iOS, you need to go through their walled garden App Store, where they get a big chunk of any revenue you might make on such a service and can nerf competitors and all the other anti-competitive stuff they're doing.
Why not? It makes complete sense for something like a website that backs up the photos stored on your camera. What's even the counter argument, that if people want to back up their data they should have to pay Apple?
If you've granted a website access to a restricted API, the browser can just paint a flashing red border around the website or whatever, similar to how people configure their terminals when they're SSH'd into prod.
Maybe it shouldn't "asking for permission" but "giving your permission" explicitly. If you don't need such an API, you would never be bothered by it if the model is opt-in without notification/popups.
I understand the problem you have with websites asking for permissions, especially push notifications permissions, as they keep showing up. And I do definitely agree that having a website that does not need any of these permissions ask for it would be even more annoying but there are definitely cases where I'm glad a website can help me out (and I don't have to download a heavy client that might or might not have tracking and analytics in it)
Isn't App store apps (Not reserved to Apple's one, this also works for Google, Microsoft and many others) untrusted code too? It runs with even more privileges than your browser's code and have access to more fingerprinting information if that's what it is going to do.
As far as I see it, a PWA with these permissions has less privacy risks than a native application I can find on a store. I'd really like to understand how installing an app is not an issue but having the access from the browser is. Is it simply the permission framework that is broken and you don't trust it to not leak information when the API is disabled?
> capabilities to perform sensitive operations in software which also deals with untrusted input from the Internet.
But native apps don't deal with input coming from the internet? If that's what you think, you're... wrong.
Apple puts every submitted application through an enormous battery of automated (and sometimes manual) tests and disassembly to look for malicious or non-permitted behavior before publishing apps to the App Store. They don't have that ability with random websites.
Now what's the level of control anyone has over a website? In your lifetime you visited many orders of magnitude more websites than apps. How do you plan on validating every link you ever click on? Every redirect? Browsers are the front line on the internet, they face the biggest threats because they can't afford to work in a walled garden with curated content. You are one minor bug away from giving access to your USB connected devices to some random website without even realizing.
I don't think anyone is arguing that you are wrong about what you want. Just that what you want is wrong. Like a kid wanting more sugar, they can't spell diabetes so it can't be a problem. You're selling your privacy for trinkets and that wouldn't be anyone else's concern if there wasn't a critical mass of such users pushing everyone in the same direction. Every questionable decision made by companies was made with the (ignorant) backing of people like you who saw the shiny feature and couldn't see past that. And again, you have every right to want whatever you want no matter how smart or dumb that may be. But don't be so shocked when people call you out on it. It's only because you brought just your own personal preference into the discussion instead of the merits of giving up every shred of control over your stuff in exchange for some marbles.
And "heavy client" is a fallacy. Operating systems come with runtimes too. Very complex native app can be very small in size if it uses the native controls and APIs. They can be KB in size. Any asset is going to be bigger than the binary itself.
The web-as-native apps are the ones that are huge, because they embed a behemoth (a browser) which is akin to an entire operating system.
There are perfectly valid reasons to want usb/bluetooth support for websites: fingerprint readers, smartcard readers and plenty of special-purpose hardware that would be useful to access through some web apps.
Does this mean every site should have access to all your hardware? Of course not. Let's make sure you have to bless a site to allow such access, make sure that the API can only be used from https-enabled (and trusted) origins, etc..
Your position of "just no because I don't see a need for it today" is a very close-minded one...
In theory native apps are "trusted", but I think for the vast majority of users the trust between a companies website and app are equivalent, vetted the same, and probably do an equivalent amount of tracking if not more by the native app (facebook SDKs are pretty common in native mobile apps).
Mobile apps are increasingly sandboxed too, like websites, precisely because of that.
But you're not following the analogy. You just took it word for word and attacked something that wasn't even the point of it. You may as well have said "but websites aren't made of sugar".
I made concrete points on why websites shouldn't be trusted with such access. You did more of what was shown before, rattled the trinkets. And the use cases you listed don't seem like something you can't achieve now with existing APIs or dedicated apps, which makes more sense.
Stands to prove that the point of the analogy is more appropriate than ever: people can't understand the problem, let alone the solution.
thats a very good reason then for an app-store to enforce rules and code checking then, isnt it?
If you're going to write a native app, I am not subject to any of its radical security implications every time I try to browse the Web in general, and we are no longer in conflict.