←back to thread

Apple declined to implement 16 Web APIs in Safari due to privacy concerns

(www.zdnet.com)
428 points coronadisaster | 8 comments | 29 Jun 20 10:16 UTC | HN request time: 0.159s | source | bottom
Show context
philistine ◴[29 Jun 20 13:03 UTC] 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 ◴[29 Jun 20 13:21 UTC] 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 #
user5994461 ◴[29 Jun 20 13:35 UTC] 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 #
1. Sayrus ◴[29 Jun 20 13:48 UTC] 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 #
2. ornxka ◴[29 Jun 20 14:04 UTC] 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 #
3. Sayrus ◴[29 Jun 20 14:10 UTC] No.23677750[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.
4. josephcsible ◴[29 Jun 20 15:13 UTC] No.23678331[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.
5. jfkebwjsbx ◴[29 Jun 20 17:55 UTC] 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 #
6. ta576248_743568 ◴[29 Jun 20 18:27 UTC] No.23680656[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 #
7. jfkebwjsbx ◴[29 Jun 20 19:06 UTC] No.23681228{3}[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.

8. saagarjha ◴[30 Jun 20 00:07 UTC] No.23685020[source]▶
I already have a browser, and the PWA uses that.