Most active commenters
  • fastball(3)
  • Sayrus(3)

←back to thread

428 points coronadisaster | 33 comments | | HN request time: 1.131s | source | bottom
Show context
philistine ◴[] No.23677180[source]
I’ve heard so many people complain on HN about Safari’s lack of support for APIs. Before now, we didn’t have a public justification why Apple refused to implement them. Now we know.

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-...

replies(8): >>23677237 #>>23677240 #>>23677307 #>>23677333 #>>23677632 #>>23678116 #>>23681749 #>>23682896 #
fastball ◴[] No.23677307[source]
Except "privacy" as a justification is BS.

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.

replies(7): >>23677413 #>>23677496 #>>23677509 #>>23677610 #>>23679646 #>>23679893 #>>23680797 #
1. user5994461 ◴[] No.23677413[source]
I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer. A website has no business doing any of that. There is no justification for these API to exist.
replies(5): >>23677428 #>>23677459 #>>23677466 #>>23677539 #>>23679532 #
2. fastball ◴[] No.23677428[source]
I disagree. I want that. Therefore a website does have business asking for those things.
replies(2): >>23677512 #>>23678674 #
3. capableweb ◴[] No.23677459[source]
Same argument could be made for JS in general. The justification for those APIs to exist is because developers want to implement features using them, same as with JS in general too.
4. Alex3917 ◴[] No.23677466[source]
> I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer.

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.

replies(2): >>23679259 #>>23680834 #
5. fennecfoxen ◴[] No.23677512[source]
You're wrong. Therefore the developers' effort should not be wasted, and certainly not while exposing their users to privacy risks, exploits, and such other dangers as will inevitably arise when placing the capabilities to perform sensitive operations in software which also deals with untrusted input from the Internet.
replies(3): >>23677590 #>>23677660 #>>23677769 #
6. Sayrus ◴[] No.23677539[source]
I don't want _most_ websites doing this. There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

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)

replies(2): >>23677704 #>>23680191 #
7. Sayrus ◴[] No.23677590{3}[source]
This is definitely going to be downvoted.

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?

replies(1): >>23679683 #
8. fastball ◴[] No.23677660{3}[source]
How can I be "wrong" about wanting these features? They're features that I want. I literally can't be wrong about that.

> 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.

replies(2): >>23679810 #>>23683643 #
9. ornxka ◴[] No.23677704[source]
>There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

How can this be so when the web browser itself is a heavy client?

replies(2): >>23677750 #>>23678331 #
10. Sayrus ◴[] No.23677750{3}[source]
You could argue that, however, I don't think it change the fact that you already have it installed. So, in my honest opinion, it is indeed replacing a second heavy client that you might have installed if you browser did not have this capability.
11. ◴[] No.23677769{3}[source]
12. josephcsible ◴[] No.23678331{3}[source]
Unless you only use one such website ever, then it's a win for the browser to be the heavy client instead of having separate ones for each.
13. danaris ◴[] No.23678674[source]
You (or a small minority of users) actively wanting it is not sufficient justification for creating APIs that will, with near-certainty, enable additional widespread surveillance and data gathering of the public by entities whose only interest is in profiting from that data, not better serving the public.
14. nemothekid ◴[] No.23679259[source]
Because every other site will start asking you to scan Bluetooth when some ad network starts using it to fingerprint you
15. halostatue ◴[] No.23679532[source]
I’m tired of websites asking if I want to enable push notifications from them. The answer is, and will always be, GTFO.
replies(1): >>23679717 #
16. otterley ◴[] No.23679683{4}[source]
Isn't App store apps (Not reserved to Apple's one, this also works for Google, Microsoft and many others) untrusted code too?

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.

replies(1): >>23681336 #
17. Hedja ◴[] No.23679717[source]
In most browsers, you can go into settings and default it to block without asking.
replies(1): >>23680519 #
18. close04 ◴[] No.23679810{4}[source]
Apps go through some for of validation by the "gatekeepers", and as a user you curate them a bit, you install the trustworthy looking ones. I mean you have a greater degree of control over what apps you install and use.

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.

replies(2): >>23680251 #>>23680636 #
19. jfkebwjsbx ◴[] No.23680191[source]
Why would you ever want a PWA when a native version exists?

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.

replies(2): >>23680656 #>>23685020 #
20. kilburn ◴[] No.23680251{5}[source]
Following your analogy, we should erradicate candy from this world and never allow anyone to produce more. This way surely kids won't get candy-induced diabetes.

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...

replies(2): >>23681580 #>>23681623 #
21. joking ◴[] No.23680519{3}[source]
most sites use a html modal to ask for the permission, and if you answer yes they make the request to the browser api which shows his own modal.
22. rstupek ◴[] No.23680636{5}[source]
Also a website you approve of today can be totally different tomorrow without you knowing of the change. The domain can expire, be picked up by scammers/spammers/porn hosters and you've given them the access to things you wouldn't intend to.
replies(1): >>23681363 #
23. ta576248_743568 ◴[] No.23680656{3}[source]
PWAs run from the browser sandbox which is generally much stricter than restrictions for native apps. Permission systems for native applications seems to be starting to follow browsers (flatpak, snap, .appx, etc.), but don't offer nearly the ability to restrict what a native app can do like the browser does.

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).

replies(1): >>23681228 #
24. mitchdoogle ◴[] No.23680834[source]
I don't want random sites to ask to use anything on my computer. It's like a popup ad - it's annoying and blocks the site. Sure, there are legitimate use cases, but if it's anything like push notifications it will be heavily abused and far too many sites will ask for permissions.
25. jfkebwjsbx ◴[] No.23681228{4}[source]
I talked about paid or open source productive software, usually desktop based, nor ad-riddled mobile apps with the Facebook SDK which by definition are not trusted.

Mobile apps are increasingly sandboxed too, like websites, precisely because of that.

26. searchableguy ◴[] No.23681336{5}[source]
How did facebook, tiktok and many others get past through that lol?
replies(1): >>23685025 #
27. searchableguy ◴[] No.23681363{6}[source]
I don't understand. The same can happen to apps. Apps can remotely change behavior and update OTA. Do you think people verify the code before clicking auto update on their phones?
replies(1): >>23682234 #
28. ◴[] No.23681580{6}[source]
29. close04 ◴[] No.23681623{6}[source]
> Following your analogy

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.

30. andrekandre ◴[] No.23682234{7}[source]
> Do you think people verify the code before clicking auto update on their phones?

thats a very good reason then for an app-store to enforce rules and code checking then, isnt it?

31. fennecfoxen ◴[] No.23683643{4}[source]
> But native apps don't deal with input coming from the internet? If that's what you think, you're... wrong.

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.

32. saagarjha ◴[] No.23685020{3}[source]
I already have a browser, and the PWA uses that.
33. saagarjha ◴[] No.23685025{6}[source]
Because Apple does not enforce their rules consistently.