Hacker News new | past | comments | ask | show | jobs | submit login

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






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.


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


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


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.

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

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.

My opinion is informed by my experience with JS.

I love the web that actual dynamic logic on the frontend has allowed. I want more of that, not less.

The alternative to web apps that can do these things is native apps that can do these things. If you don't think native apps are tracking your behavior, you are sorely mistaken.


> I love the web that actual dynamic logic on the frontend has allowed.

I think you missed my point, I also truly love that 1% of useful stuff that JS brings and wouldn't want to lose the functionality. But I absolutely hate the other 99% which I have no control over or I have to jump through uMatrix hoops to control.

Let's put it another way. You probably love that electricians and plumbers exist to fix your stuff. But if once you let them in they could invisibly camp in any room of your house without you even knowing where they are and what they're doing, would you still open the door for them?

These APIs can either give you a relatively broad "Allow on this site" option, or they can flood you with granular choices. The first opens the door for them camping in bed with you. The second is like someone triggering your alarm every 5 seconds until you disable it. Accept all. Then they can camp in bed with you.

Doesn't your experience tell you the same?

> If you don't think native apps are tracking your behavior, you are sorely mistaken

You see, this is exactly what I meant. "Those guys are screwing you over so it's OK if these ones do too". This is how the "screw the user over" arms race happens where everybody tries to outdo the others with even more invasive techniques, and users take it because each is just a slight escalation from before. When native apps were adding these "features" someone loved them for one reason or another. Frog in hot water.

P.S. Example of how the innocent battery API access can be sold as "to save battery" and then repurposed to screw you over:

https://metro.co.uk/2019/09/27/uber-charge-battery-lower-107...


Unequal progress of privacy improvements on the web and app fronts does not make it okay to walk back progress on the web front just to provide API parity.

If the only way to have privacy is to nuke functionality, then I’d rather have the functionality.

Luckily you can have both, despite Apple wanting to pretend otherwise.


> Luckily you can have both

I have a bridge to sell you...


Please just explain your point, instead of being snarky.

I think there are ways to get (a bit of) both. It's not simple though.


The point (which I vehemently disagree with) is that prompting for permission is insufficient because illiterate users will just click accept on the dialogs.

So apparently we now have to restrict all interesting functionality in the name of keeping the lowest common denominator from shooting their metaphorical feet. If there's a more charitable way to read their stance, I'd love to hear it.


> The point (which I vehemently disagree with) is that prompting for permission is insufficient because illiterate users will just click accept on the dialogs.

I had 2 points actually, which I thought I made very legibly. I didn't think they they need a fourth reading but here we are... They are both solidly confirmed by present day reality. 1) is what you mentioned already. As seen with cookie prompts, app permissions, actual scientific studies, etc. if you pester people with alerts and popups they are desensitized and start ignoring and accepting them. 2) is that once you give a website permission you lost control. They lack even the modicum of oversight apps receive.

> So apparently we now have to restrict all interesting functionality

All? Hyperbole much? Or did you just decide that these 16 APIs are the crux of "interesting functionality" and freedom? It doesn't matter how much you allow there's always going to be someone to shout "they restricting eeeeverything around here". This is what security and privacy measures do, restrict some things because the benefit doesn't outweigh the cost/risk. All those features are sold as "essential" when in fact most of them at best address some minor nuisance. Then they're promptly hijacked for nefarious purposes because there's always going to be some wannabe coder who insists that his website needs to know my battery level for some (undoubtedly good) reason.

Care to ponder how we got here in the first place? With every piece of tech around trying to steal data from you one way or another, usually in a dishonest way? There's a reason Google is championing this and it's not that they want to give you "interesting features".

It's always a compromise and for the past decade+ we've been compromising a lot more on the privacy side. If you truly believe you can have both privacy and aaaaalll interesting functionality in the real world you're either naive or sitting on a gold mine.


>It doesn't matter how much you allow there's always going to be someone to shout "they restricting eeeeverything around here".

A good example here would be the MIDI interface getting blocked because it allows binary uploads via certain control message, as well as device enumeration.

If privacy is the main issue with this API, then the allowed control messages that the API would accept could be limited strictly to note on, note off, key velocity, etc.. things that have no realistic possibility of data leakage or compromise.

But instead, no, we lose the whole thing, even though a more nuanced approach (and in this case, one that's easy to implement - MIDI being rather straightforward) would satisfy any privacy concerns.

So with that in mind, the fact that a privacy-respecting alternative exists, no. I don't believe for a hot minute that that this is all about privacy - that is mere marketing fluff. I instead believe it is Apple is using privacy as a pretext for ensuring that PWAs remain as gimped second-class citizens on the platform in furtherance of their lock-in.


> have no possibility of data leakage

Oh if I had a penny for every time someone said with such certainty that "this is safe" only to be proven wrong sooner rather than later I'd have a second yacht :).

> I don't believe for a hot minute that that this is all about privacy

Of course it's not. It's about appealing to the customer base Google and the likes are losing by using an actually useful feature as a bridge to them. For the moment our interests align, whether by side effect or not. That's it.

But while you get your "first class interesting features" in apps, and second class shaky experience in the browser, what do I get for privacy? They're both already turning (turned?) to malignancy with too much of the code dedicated to actual data extraction. You have your apps, let others have their browser at least. That was the escape when you wanted to touch Facebook and Google Maps and no 10ft pole was around. If you think I'm unreasonable for wanting a last bastion of privacy (saying this is a bit of a stretch), just think that you're the one who insists everything should be how you want it by turning even the browser into the hot mess that apps already are. And this in exchange for some "interesting features" that you already have if you need them just not in every single piece of software.

You're ostensibly a coder so I don't need to point you to all the instances of trust being breached via conscious decisions. But surely this time they won't abuse that power. Neither will the host of obscure and completely unvetted websites one may access.

I don't think there's more to be said. It never ceases too amaze me how cheaply people are willing to sell their privacy for and how much they're willing to fight to make sure this is everybody else's only option.


How many browser exploits are you aware of that target the user's keyboard input directly? Because that's the level of complexity we're talking about here with MIDI. You only need to pass through what key was hit, for how long, and how hard, to have reasonable functionality.

Those EU "accepts cookies" boxes have done an amazing job at making people ignore every popup on the internet.

By this logic, permission prompts shouldn't exist at all. I think you're gonna have to provide proof for your "we all know" assertion, because I do not know that users will individually grant dozens of permissions on each site they visit.

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.

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)


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


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.

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.

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.


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


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.


I already have a browser, and the PWA uses that.

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


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.

Because every other site will start asking you to scan Bluetooth when some ad network starts using it to fingerprint you

I’m tired of websites asking if I want to enable push notifications from them. The answer is, and will always be, GTFO.

In most browsers, you can go into settings and default it to block without asking.

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.

I disagree. I want that. Therefore a website does have business asking for those things.

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.

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.

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?


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.


How did facebook, tiktok and many others get past through that lol?

Because Apple does not enforce their rules consistently.

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.


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


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.


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


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


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.

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?

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


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.

I've seen Apple get away with this bad monopolistic behavior through hypocrisy more and more.

Apple is denying people their real rights to install whatever they want in their own machines, forcing everything to go through their app store, where they have the last word of who can or cannot distribute software to the platforms they have created.

They know that if they use the common "we are thinking of your well being" their customers and fans will just believe they are a good-willing company with no other interests than their users safety and well being.

I don't know why the majority of the crowd here in HN, who use to be so harsh in pointing out this kind of behavior in companies like Google and Microsoft, have this blindness with everything that has to do with Apple.

It will worth nothing, if after have defeated this beast with GNU, Linux, the Web, open software revolution, etc.. we end up not protecting what we have achieved so far, because somehow one company trying to secure their profits and its position in the market, get away with behaviors that can ultimately destroy the culture of freedom, open-source software and ultimately, digital rights, which our legislators are not prepared to defend, really understanding the threats and the dire future they represent if we dont uncover the true intentions behind this BS.


Recently I’ve seen a jump in the number of random sites popping up a “this site wants to access VR hardware” dialogs in FireFox; news articles nothing to do with VR or visualisation. I don’t have any VR devices.

How do you do this bit “requiring explicit permission from the user before a web application can use them” without the fallout of “its just a hundred thousand popups and you’re done!” on every page?


Easy. You don't have them in popups, you have them in a dropdown that the user selects themselves. Websites then need to learn to fail gracefully if not given certain permissions, otherwise consumers need to stop using those websites.

The solution to privacy concerns is not "nuke functionality", it's "don't let websites abuse functionality for tracking purposes".

Just like how with native apps on iOS, the solution is not "don't let apps ever access GPS data", it's provide a UX that makes it fairly easy to choose and don't provide permissions to apps that don't need them.


"Just like iOS"? The iOS solution to GPS data permissions is a modal popup: https://support.apple.com/library/content/dam/edam/applecare...

from the page https://support.apple.com/en-gb/HT203033


I'd argue that what Firefox do with the tilting icon for Push Notification is not that bad. I'm surprised they do not do the same for other type of permission as they are these request popups are equally annoying.

However, I have to admit that displaying one icon per permission would not scale great when having a dozen of them.


Just the constant "this website would like to send you push notifications" on every last damn site.

Part of me wishes that browsers dropped support for web push notifications entirely. Or at least bury it in the browser settings somewhere. At best, they provide marginal value to me, and at worse, they're just spammy.

My parents aren't techsavy at all, so when they get those push notification requests, they just hit "accept". They now get dozens of spammy ads sent to them via push notifications (eg, "30% off sale, buy now!")

I've disabled web push notifications entirely, but I still get JavaScript-based prompts asking me for permission to turn on notifications. I already explicitly said no, yet web developers still feel compelled to find workarounds to interrupt my work and ask me for permissions (why?).

I get that in theory, web notifications are supposed to be valuable, but in practice its been nothing more than a constant annoyance for me.


next headline: "Apple devices won't display any video other than those from tv+"

Apple bros on HN: "Good! finally someone standing up to the BigTech abuse of privacy"


I sympathise with the walled garden App Store argument. I hate it that Apple keep such a tight grip on the application distribution channel. At the same time, I really hate the trend where browsers are operating systems and I use native apps whenever possible.

Apple has the ability to put every submitted app through rigorous analysis before publication on the App Store to look for forbidden behavior, in order to protect their customers. They don't have that ability with arbitrary websites.

So you trust a third-party, a company, to define what is 'forbidden' for you to install, if they say they do this "to protect our customers"?

At least in democracy we can elect the people who define whats allowed or forbidden to us, and they can only do it, in the constraints of a constitution.

If we let companies get away with it, we are allowing them to create shadow states, a sort of new digital feudalism, where our digital overlords can control a big part of our lives. (Remember that we are going to a process of digitalization of our lives and experience, with IOT, AI, smart gadgets, to take into account how powerful a entity who can control all of this can be)

Today, its just Apple. But with people normalizing this kind of behavior, it will be more and more over time, til its too late for all of us.

By enforcing other browsers to use their implementation of Web platform, for instance, they knew they could control the Web from being a good contender to their exclusive application platform.

This kind of action alone, should be outlawed, because is pure uncompetitive behavior, not to say its hurting their customers freedom to choose whats best for them, and that actually have nothing to do with the privacy or safety of their users.


You vote with your wallet. If you don't want to patronize Apple, go with Android, or find some other phone and browser vendor.

Also, you mention without evidence that Apple's actions have no relation to the safety or privacy of users. Are you claiming that their actions are merely a pretext, and that Apple provides no such value, or that they have no such intent? If so, how do you know?


I already do. I never touched anything Apple because i don't want to be owned by what i own.

Apple has no proper concept of digital property, as it thinks its entitled to do anything with the machines that i own, and of course, to make it less offensive, they will use the card that they are doing this always thinking of me like a loving mother.

Its not just Apple, but any company, giving the financial games they need to play, the goal is to maximize profits, so the well being of its user or consumer is secondary to that (You know that CEO XYZ that actually were thinking about the user first? gone.. the board kick him out of the company because the profits were bad in the last quarter). If they can get away with using BS, where people buy the reasons their are using to justify their actions, they will do it, because its good for their real goals.

If you want context, we can use the same on this thread. Where you can clearly see that is reasonable from the security perspective to bar some of them, but a lot of others, is to bar the web platform to compete with their app platform.

Its not just now, nor just this.. if you have been following closely, aware that they do this kind of thing, you see this pattern in a lot of other places.

With Apple is not even difficult to create a Dossie to point this out. But if you didnt notice this since the beginning of the iphone launch, i guess theres little i can do here.

Apple is very good at creating a emotional bound with its things.

I dont like this "evil vs. good" kind of narrative, and Apple is not evil or good per-se (this is a childish pointf of view). Its a tech company that will use their power and position to survive and thrive. But we also need to be aware that with novelties, new problems will arrive. And we need to be aware that sometimes with the sweet, there's also this sour taste that may become a big trouble in the following years, if we are not aware of it.

Cant you see which web apis, from the ones that were bared, that are not actually security threats, but would become a threat not to security but to their monopoly on the app platform in the devices they ship?

But wait, we can just use Chrome right? nope.. because Apple is forcing every other browser to use their own version of Webkit.

Even without the need to go through every move Apple is making, isn't that clear to you?

Its clear for me how Apple is and will be the new "IE 6" of tech, being a impediment not just to the evolution of the web, but all the tech moving forward, all because they need to maintain their feud where we end with less and less option of what we can do with the stuff that we own.

Its not very clear right now, because they are still moving the needle, but if you looked into te Microsoft of the nineties, you would also not believe it.. and yet in the 2000's it happened..


any company, giving the financial games they need to play, the goal is to maximize profits, so the well being of its user or consumer is secondary to that (You know that CEO XYZ that actually were thinking about the user first? gone.. the board kick him out of the company because the profits were bad in the last quarter).

This is an old trope that has been disproven not only in law but also in practice. Many public companies' boards allow their executive teams the discretion to sacrifice short-term profits for long-term gains and to build customer trust. Apple is one such company; Amazon another.

Cant you see which web apis, from the ones that were bared, that are not actually security threats, but would become a threat not to security...

I'm no security expert, but Apple is full of security experts. When they say a web API has the potential to be a security vulnerability, I believe them. They've earned my trust. Perhaps they haven't earned yours--which is fine--but if you disagree with one of their conclusions, why don't you point out which ones you think they are wrong about, and the specific bases for your disagreement?


> This is an old trope that has been disproven not only in law but also in practice.

Which practice? Boeing? which law? the same one that have a tendency to favor this bad practice?

What about blind trust? People trusted their children to Priests, thinking they deserve trust because "of course they are priests, and priests are inherently good people right?"

People trusted their lives to Boeing entering their airplanes, because "Hey, its Boeing! they care a lot about safety, and you know those Boeing board members, CEO and that top management, and top airplanes experts cares a lot about my safety, i dont even need to bother".

An yet, there was something rot. And for me, its in the design of the whole system. It eventually will lead to another disaster like this, and i bet a lot of us will just point to the direct culprits, as to not spoil the whole game where a lot of people are doing great..

About the security aspect of those, the web have a permission system, have sandboxes, and a lot of security already implemented, that could let to the user to see if the site he is visiting really need what they are asking for. In the end isn't how people install apps anyway? If thoses features are security threats, why apps can use them? But you wont get Apple to discuss in this level, because they know, they wont be able to stand their argumentation, if its showed to them that the same level of security of apps, can also be there in the Web. They wont, because its not in their interest to do so, and it has nothing to do with their users.

Truth to be told, i dont like the trend of the web to become a whole OS... its flawed by design to do this sort of thing. But i expect Apple to be the worst kind of judge to this sort of thing, because they know that theres a tendency to develop for the Web even for phones, because its cheap for companies to follow this path.

They will as long as they can, to make the web platform appear weak in comparison to their private offerings. Why not? I even expect them to do this, as long as they can get away with it. And as long as Apple has users that believe and trust them, they will get away with it. As you have said, you voted with your wallet, and a lot of people are willing, not aware, or dont care.. they just dont want to bother.

The same security they implement for apps, they can implement for the web, permissions systems, sandboxes and the like.

I've seen the list, and as long as there a permission system, and there's not a security flaw in the browser being exploited, i cant see a reason why not to allow this, except for the most obvious reason, and a lot of other practices from Apple that make obvious that they care more about being in control, otherwise not only its users security, but freedoms would being taking into account.

Less features, more secure, of course.. So they will always be able to get away with this kind of excuse.

But as Microsoft have learned, its not just about the users, but also making the developers happy. In the end is the collective of devs, and all the hours they expend in the platform, that will make the experience in that platform great for the end users.


You made the same point before but again, how did tiktok, facebook and all the other crap gets past it? What about all the other chinese spyware?

> Apple has the ability to put every submitted app through rigorous analysis before publication on the App Store to look for forbidden behavior, in order to protect their customers.

Note that Apple does not regularly exercise that ability…


Firefox doesn't support them either. Most of these are implemented on Chromium, for Google's ChromeOS primarily.

They're kinda useless for web browsers, but people see them in Chromium and believe they must be there for a reason other than ChromeOS. Apple and Firefox are doing it right. These things don't have a place in browsers.


They didn’t mention the biggest one that people (including me) complain about, which is the push notification API. That’s intellectually honest of them (it inherently requires explicit permission before activating for a particular origin), but pointing to these far less likely to be used APIs is not making a good case for neutering PWAs on privacy grounds.

Safari already implements API that leaks enough information to uniquely fingerprint a device.

For instance, the Audio API. You can test it using OpenWPM [1][2] and you will get the same ID in both normal and incognito mode. And this is only one of many things not blocked by default. ETAG tracking is pretty popular on pixels.

I'm not saying they aren't right, I'm just saying that they are somehow doing more PR than anything else. And as other comments are calling out, this makes it even harder to compete on IOS using PWA (How is a website asking for permission different from an app? Can't we have a permission framework just like apps?).

[1] https://audiofingerprint.openwpm.com/

[2] https://github.com/mozilla/OpenWPM


Safari already implements API that leaks enough information to uniquely fingerprint a device.

What's your point? Because one API can be used for something, Apple should let Safari be a free-for-all?


Native apps are much, much more privacy-invasive.

Apple forces you to use those. You have no choice, like on other platforms.


I agree, with a caveat - Apple can and does remove apps which are caught stealing data permanently. The App Store and Apple's policies act as a safeguard for users. As far as I know, there is no reliable way to do that for web apps.

Don't fool yourself, Apple will never remove killer apps, only small insignificant apps. Instagram for example "steals" way too much data than necessary, yet apple does not remove them. TikTok just got caught for some stuff - still there.

So they might catch some rogue apps, but far from reliable or trustworthy. They protect their platform image, nothing more.

With webapps at least I can take some measures like ad and tracking blocking myself. I don't have to give access to the system unless some case really warrants it.


Outside this list Safari's support is limited or nor for many other APIs. MediaRecorder and many WebRTC APIs have no clear roadmap for support.

Many APIs including getUserMedia and all of WebRTC are not supported in WkWebView (only way Firefox/Chrome works on iOS due to Apple policy blocking them from building their own browser) Means some apps will only work in iOS-Safari and not in iOS-Chrome/Firefox.

None of this has to do with privacy, being able to record media locally without sending to STUN/TURN server increases privacy not reduce it.


There's an unintended consequence in this, though. Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads. So in addition to keeping a private presence you're required to use an ad blocker. And services which have built their business around being ad-supported will see you as a deadbeat. Which motivates them to be more aggressive in upselling you, or denying service if you don't whitelist their ads.

Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads

I haven't worked with web ads in a while, but from what I remember when I did, people with little data on file with the advertising networks got more ads, and better ads, because there was no record of them having seen the high-paying ads already.

The longer you surfed, and the longer you were tracked, the lower quality the ads became.

Again, I haven't been in this arena for a while, but that was true at the time, as told to me by the president of one of the larger non-FAANG advertising networks, over coffee.

But it's all a red herring anyway, isn't it? Are there any people out there saying, "I wish there was a way to give Google more information about me so that I can see better quality ads!"


> Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads.

Is this a thing? Do people in demographics which are less appealing to advertisers also see more intrusive ads?


To me, intrusive ads mean ads which intrude on my privacy. So if you use Safari, no, you will not see more intrusive ads, quite the contrary.

Those ads might be terrible chum bucket stuff, but they would not be intruding into your privacy.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: