←back to thread

428 points coronadisaster | 4 comments | | HN request time: 0s | source
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 #
buran77 ◴[] No.23677509[source]
> requiring explicit permission

Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.

They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.

Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.

replies(4): >>23677676 #>>23679349 #>>23682394 #>>23689536 #
1. jonny_eh ◴[] No.23679349{3}[source]
> Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.

How is that any different from apps on the App Store?

replies(1): >>23679733 #
2. kalleboo ◴[] No.23679733[source]
The App Store can enforce things like "users can deny permissions and the app still works for anything else" or you get booted out of 50% of the US market. A web site can say "oh, you denied access to location? Well, I won't let you continue at all until you do". We saw this on Android - on install apps would require a raft of permissions, but if all your friends were on Facebook you'd be compelled to accept them all anyway.
replies(1): >>23680398 #
3. dafoex ◴[] No.23680398[source]
A way this could be solved would be to provide websites with an interface that appears to be the system with no devices attached (or dummy devices in the case of devices that are always present, such as a power adapter) and only connect the real device when the user give permission. If the website thinks it has permission, but finds no device, it must have to fail gracefully or at the very least ask the user to connect a device (like a midi keyboard).
replies(1): >>23688305 #
4. buran77 ◴[] No.23688305{3}[source]
The OS could to provide a set of "fake" devices to any app or website in a manner that is plausible and consistent. E.g. Not identify as an iPhone with 320x240 resolution, or a battery counter that never goes down, or that always goes down as the exact same rate, and so on.