> In that case, if PWAs were good enough on Android and they could avoid the 30% cut, why bother making native Android apps at all?
I don't want to skirt too close to HN guidelines here, but I'm genuinely curious if you actually read my comment or not.
This is exactly what I asked you. If PWAs are (as Apple claims) good enough alternatives to the app store, why isn't anyone using them?
You can complain about Electron, but developers build Electron apps. They don't build PWAs. Because Electron apps are actually a feasible alternative to more native GUIs, and PWAs are not. The question you and I are asking (why isn't anyone using PWAs) reveals exactly how bullcrap Apple's legal arguments about PWAs are. They are not reasonable alternatives to the app store.
> All of the HN commenters blame mean old Apple for holding the web back
I don't blame Apple exclusively for holding the web back. They're a part of it, but so is Google. I don't think I've ever had much good to say about Google on here, and as the US and EU are actively proving right now, it is possible to pursue regulation for multiple companies at the same time.
> You have much better ways to track on the we[b] then through native apps - at least on iOS with a much better permission model.
This is not true by any metric. Native apps have more access to fingerprinting vectors than web apps do, are capable of requesting deeper levels of user information like contacts. Native Facebook on iOS got called out for injecting custom code into the in-app web view when users clicked on links within Facebook for 3rd-party sites. That's something that's not possible to do in any modern web browser.
Native apps are indisputably easier to use to fingerprint and track users on both iOS and Android.
Even if you're unfamiliar with the technical side of this, you can still think of it this way: if apps like Facebook had an easier time tracking you on the web than on mobile devices, they wouldn't try to get you to install mobile apps. They would force you to use the website. The reason why Facebook ships an iOS app is because it is easier to track you via iOS than through the Facebook website.
I’m very familiar both - exactly how can apps track you - without your permission that the web can’t?
And your example of how Facebook can track you by knowing what links you clicked on off the site from the app, of course Facebook could do that from the web.
There are at least a dozen ways to do fingerprinting o the web
> The Safari version is exposed and the Safari version is tied to the OS version for iOS.
User agents can be changed by users in Safari. I wouldn't recommend doing so, but it is possible to tell Safari to stop reporting the version number to websites. I'm unaware of any way to do the same for native apps.
> There is also a battery level API that is not supported by Safari.
Note that native iOS apps do have access to battery level, which is another fingerprinting vector that can be avoided by using websites through Safari or Firefox.
Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
And which way are you arguing that Apple should add more OS level APIs for web apps or should have less for native apps?
You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
> Yes, I’m sure all of the people who are going to download an extension to change the user agent version in iOS are really going to mess with analytics
Mechanisms to protect ourselves are not less valuable just because they're not universal. In any case, you shouldn't mess with your user agent primarily because a fake user agent on Safari is likely a bigger tracking vector than reporting the version -- but that's a separate conversation. The point being, you can do so if you have a need, unlike on native platforms.
Apple could also of course de-bundle Safari from OS updates, which would be a large security/privacy benefit, but that would get in the way of the all-too-convenient coupling of Safari to iOS's security model. It might force them to actually build security layers into their OS rather than relying on privileged applications.
And notably, this is likely to get better on the web, there is an ongoing conversation about how to handle user agent strings and how to reduce the information they leak without breaking capability tests. It's a complicated issue, but there are some interesting ideas that are being proposed for the web. As far as I know, I don't really see that conversation happening for native platforms, which seem to have an expectation that running an app should just privilege the app to know everything about the hardware.
----
> You can’t have it both ways. Either you want the wonderful world of PWAs where random websites have more access to your hardware and more parity with native apps and less privacy and security or you want it to remain more restrictive.
You can in fact have it both ways, you can implement native APIs via sensible changes that push those capabilities behind permissions. Notably, the battery life API does not currently require a permission in Chrome; it should.
Apple also had a good idea where PWA permissions were restricted to "installed" webapps. This shouldn't get rid of permission requirements, but it does significantly discourage webapps from requiring those permissions. The web is generally pretty good about this, but certain Google-proposed changes like the battery API are lagging. It would be good for the web and for users for Apple to be more involved in the standards process.
And as I've advocated for a while, you can take things even one step further than the web currently does and you can refuse to tell applications when permissions are denied, instead faking data. For the battery API, rather than reporting that a permission is disabled, browsers should instead report fake numbers.
But the idea that the web can't handle more advanced capabilities is false. Permissions are a complicated UX problem, but we have mechanisms to deal with them, and generally speaking the web has led the way on those mechanisms, with native platforms benefiting to a huge degree by imitating and building on web permission models and lessons.
People tend to forget how bad mobile permissions used to be. I would argue that the mainstream adoption of native platforms for runtime permissions, required optional permissions -- these are ideas that were popularized on the web and I would argue the web still often does a better job of handling that UX. Not that the web couldn't do better, but it is in comparison to other platforms doing a noticeably better job.
----
> These and more are all APIs that Apple has refused to implement that HN users are clamoring for. Which side do you fall on?
I agree with Apple that the majority of the APIs on this list (with a few exceptions) are unnecessary for web apps and should be approached with caution. In particular Web USB is extremely reckless, does not (as far as I can tell) have sufficient sandboxing to prevent device tampering or side-channel attacks through USB devices onto other parts of the OS, and at the very least it probably requires more safeguarding than just a permission prompt. Chrome is reckless in implementing those APIs, Apple is right to defer them.
That's not to say that they shouldn't be researched; NFC, Bluetooth, and MIDI input would be extremely important capabilities for the web if Google was proposing better privacy and security controls for them. Apple's policy around powerful web capabilities is often to stand to the side doing and saying nothing while Google develops bad specs, so that Apple has an excuse not to implement them. Needless to say, I don't give Apple credit for that. The world of notifications online would look very different if other stakeholders beyond Google had taken on bigger roles in shaping the API.
Of course, there are also plenty of APIs that Safari hasn't implemented that are not privacy risks. App badges are a good example, there's no privacy or security risk from being able to notify users that an app's state has changed. And of course it's been talked about to death, but the entire web notifications API as implemented by both Google and Apple actively encourages apps to be less private and to be looser with data. That didn't need to happen, Apple's negligence is part of the reason why web notifications are primarily only useful for advertisements and interaction reminders. Apple could easily lead the way on doing something better.
There is a lot of room for improvement here that doesn't require touching contentious or dangerous APIs. Typically when we talk about PWA capabilities on iOS, we're not talking about the ability to read device memory. What we're talking about is the ability to do much more innocuous things like schedule offline notifications without relying on a 3rd-party web server to trigger the notification -- something that would not only make PWAs more capable but would also make them more private and more secure.
Facebook could insert custom code into 3rd-party domains that have no relationship with it?
No, it can't. If Facebook could perform arbitrary XSS on 3rd-party websites it had no relationship with when you clicked on links on the Facebook website, that would be rightly treated as critical zero-day security flaw in any web browser.
I mean, you're saying you're familiar with this stuff, but you're also saying that Facebook can do arbitrary XSS via links, so forgive me for doubting you. Of course fingerprinting is possible on the web. It's easier with native apps. The web at least tries to shut down fingerprinting vectors; native platforms like iOS largely don't. Far from shutting down fingerprinting vectors, both Android and iOS have platform-supported device-specific advertising IDs that don't even require fingerprinting. At least Apple (eventually) started clearing the low, low bar of forcing applications to ask permission to access it, but that's a far cry from the kind of sandboxing and site/app isolation that happens in Safari.
> And what do you think is going to happen if there are more native APIs exposed in browsers?
I'm sorry, your defense for privileging native apps over browser apps is "if browsers could do everything native apps could do, it would be a nightmare for privacy"?
What do you think that says about the privacy and security of native apps?
> No, it can't. If Facebook could perform arbitrary XSS on 3rd-party websites it had no relationship with when you clicked on links on the Facebook website,
If you click on a link from Facebook on the web - the only reason you would view a page in a web view on the app - you don’t think FB could know that you clicked on the link?
I also see that you ignored the dozen or so well known ways that you can track someone across the web.
Are you really saying you’ve never searched for something on one site and seen ads follow you around on other sites?
> At least Apple (eventually) started clearing the low, low bar of forcing applications to ask permission to access it, but that's a far cry from the kind of sandboxing and site/app isolation that happens in Safari.
I just cited a list of ways that apps can’t track you across the web that you keep ignoring.
> If you click on a link from Facebook on the web - the only reason you would view a page in a web view on the app - you don’t think FB could know that you clicked on the link?
If you click on a link from Facebook on the web Facebook cannot perform arbitrary 3rd-party XSS on that page. On iOS, they could. You are misunderstanding what the native vulnerability was. I still feel like you do not understand what the vulnerability here is.
Facebook was allowed to insert arbitrary code into the system web view. That is not the same thing as knowing when you click on a link, it is the ability to arbitrarily execute code on 3rd-party domains regardless of whether or not those domains have any relationship with Facebook and regardless of whether they are fetching any Facebook resources/scripts. It is the ability to run custom Facebook code on sites like HN that do not normally insert Facebook pixels or tracking code.
It is not the same thing as a link ID or tracking what link you clicked on.
----
> I just cited a list of ways that apps can’t track you across the web that you keep ignoring.
I'm not ignoring any tracking vectors on the web, I'm pointing out (correctly) that every single tracking vector on that list and then some is available for native apps. Which... obviously, of course native apps can do graphics fingerprinting. They have access to the same system libraries.
You've never searched for something in a mobile app and then seen an add for it elsewhere? You don't think that tracking networks exist for mobile apps? They do. I hate to be the one to break this to you, but native apps can also run low-level graphics code to fingerprint you. They can also look at connected media devices. They can also do audio fingerprinting.
None of this is unique to the web.
The big difference is details like the fact that those mobile apps can't be used with adblockers or anti-tracking protections, and of course that the embedded web views for apps like Instagram/Facebook allow for arbitrary 3rd-party XSS, and that the native platforms expose device-specific tracking IDs and additional fingerprinting vectors in addition to all of the fingerprinting APIs that exist on the web.
You're not citing anything that's unique to the web.
And you keep ignoring the fact that native Facebook on iOS could do arbitrary XSS attacks on 3rd-party sites! Something that is not possible on the web and that is a much bigger deal than canvas fingerprinting. I don't understand what part of this is tripping you up. This really is not something that is debatable; fingerprinting is not unique to the web, every tracking vector you're bringing up exists for native apps, and in general native platforms do a worse job at allowing users to block them.
This really genuinely is not a subjective take -- it is an objective fact that mobile platforms expose more fingerprinting and tracking vectors than browsers do. This is not just an opinion, the device capabilities for native apps are higher than the capabilities exposed to websites and all of those capabilities are tracking vectors. In addition, native platforms like iOS allow nested content and inspection of nested content in a way that is not possible on the web, and allow for persistent storage and identifiers that are more difficult to construct on the web. And native platforms do not provide user-controller mechanisms like adblockers to reduce or eliminate trackers within apps. That is true of both iOS and Android.
And native mobile platforms do all that in addition to supporting all of the fingerprinting vectors that the web supports.
----
> Are you really saying you’ve never searched for something on one site and seen ads follow you around on other sites?
Generally no, on the web I use an adblocker so I don't see ads at all, let alone ads that follow me around. Notably, adblocking is not possible for native iOS applications to the same degree as it is even in browsers like Safari. That is yet another reason why native apps are worse for privacy and security than webapps are.
> You've never searched for something in a mobile app and then seen an add for it elsewhere? You don't think that tracking networks exist for mobile apps?
Well Apple decimated that ability with ATT. Facebook even admitted for instance they projected losing billions when Apple made cross app tracking opt in.
> The big difference is details like the fact that those mobile apps can't be used with adblockers or anti-tracking protections
> This really genuinely is not a subjective take -- it is an objective fact that mobile platforms expose more fingerprinting and tracking vectors than browsers do.
You named one additional way that you can track on an app if a user uses a web view.
There are dozens of ways that websites can track you without your permission that aren’t available in apps.
> and allow for persistent storage and identifiers that are more difficult to construct on the web
Really? You can’t do persistent storage on the web that’s available cross site?
> And native platforms do not provide user-controller mechanisms like adblockers to reduce or eliminate trackers within apps. That is true of both iOS and Android.
In fact they do, I just cited a list of VPNs you can install.
> Generally no, on the web I use an adblocker so I don't see ads at all, let alone ads that follow me around. Notably, adblocking is not possible for native iOS applications
Good thing that every single person or even the majority of people use ad blockers…
It is unclear to me that this vulnerability has ever been patched, though of course Facebook denies that they use it for tracking (but of course they do). In the interest of being diplomatic to Apple I am operating under the assumption that they eventually patched it, but I have never been able to find a source verifying that they did.
As far as I know, Facebook is still doing this today in iOS.
It is of course also notable that when Apple discovered that Facebook was essentially performing malware attacks on 3rd-party sites, they didn't remove Facebook from the app store or punish Facebook in any way. So let's also get rid of the idea that moderation is a solution here, because Apple has repeatedly proven that they are not willing to remove apps like Facebook that violate privacy rules. 3rd-party XSS was not a big enough deal to Apple to remove the Facebook app.
----
> [censored VPN advertising site]
VPNs are not a suitable alternative to native adblockers for a myriad of reasons that get discussed to death whenever VPNs come up in these conversations. Also, please do not link to a recommendation site that recommends NordVPN as the best VPN for privacy. NordVPN should be avoided.
In general, while I take a much more positive view on VPNs than many other HN commenters and while I do think they can enhance privacy, I still agree with the advice of many security professionals that VPNs can open up users to substantial privacy risks and should not be lightly used without a good reason or without a lot of research into their privacy policies and management.
> You named one additional way that you can track on an app if a user uses a web view.
No, many. Low-level graphics, contacts, device IDs, webview injection, long-term storage, precise location, bluetooth connections, etc, etc... the list goes on and on.
> There are dozens of ways that websites can track you without your permission that aren’t available in apps.
Such as? I can't think of a single one.
----
> Really? You can’t do persistent storage on the web that’s available cross site?
No, you can't! How is this a surprise to you?
The lack of persistent cross-site storage and the fact that any available cross-site storage is strictly opt-in is one of the biggest things that the web does. It used to be a little bit worse with 3rd-party cookies, but not only was that still subject to cross-origin restrictions and still required opt-in from every participating site, but also every major browser is now restricting 3rd-party cookies (even Chrome).
Even with PWAs on iOS, you can't access cross-site storage. In fact, Apple's entire justification for shutting down PWAs was that they wanted to ensure that cross-site storage restrictions continued to be respected (which is a bullcrap reason since every other browser already does this, but whatever).
Seriously, I'm trying to be diplomatic and respectful about this, but you need to look up how security models on the web work before you spout nonsense like this. 3rd-party site isolation is a big deal on the web, as is easily cleared storage that is treated like a temporary container. Safari goes a step further and auto-clears some of that storage. It was a big deal with PWAs when they announced a single way to get just 1st-party storage to reliably persist long-term.
There is no shared storage pool for the web that every site is subjected to, that is the entire point of cross-origin restrictions.
----
> In fact they do, I just cited a list of VPNs you can install.
See above.
> Good thing that every single person or even the majority of people use ad blockers…
More than the people using adblockers for iOS. Like seriously, do you think the number of people who pay for a VPN adblocker is higher than the number of people who install for free ublock origin or a similar Safari-compatible adblocker?
This is absurd, you're looking at a tangible way in which native privacy is worse and you're saying, "but nobody uses the better solution." That's not exactly a convincing argument. I use adblockers online. My whole family does. Having at least the ability to protect oneself to some degree is important. You're not denying that for anyone that actually cares about privacy, the web is easier to secure -- you're just arguing that nobody cares about privacy. But some of us do.
And if you're talking about what the average user does, the average user A) doesn't pay for VPNs (even if VPNs were a substitute for adblockers, which they're not), and B) doesn't turn down invasive data requests from native apps, of which there are far more available to make on native platforms than on the web.
Objectively, factually, native app privacy is worse. It just is; you can either accept that or you can keep pretending that reality is something that it's not. But your lack of acceptance doesn't change anything about the reality that native platforms expose more fingerprinting vectors, have fewer ways for users to protect themselves, and are generally capable of much more invasive and malicious behavior.
> It is unclear to me that this vulnerability has ever been patched
To my understanding Apple has provided a solution in the form of a new type of webview available to apps that protects privacy. Last I checked (I don’t have the FB app installed for this exact reason so I’m not up to date) FB have not switched to using this new webview. It would be difficult to remove the functionality from the original API (WKWebView) because app developers like myself use it for legitimate reasons with internal web content. There have been some moves to lock advanced features behind an app-defined list of domains but it’s far from comprehensive. Maybe in iOS 18 (he said skeptically).
The answer is simple: Apple just needs to deny FB App Store approval until they switch APIs. Of course they haven’t done that, and they won’t.
Thanks for the details, I've been curious for a while how this would shape up and I'm glad to get some information about the current state of things. Cross-origin privileges for inserting code would be my naive guess about how to lock that down, so it's good to hear that there's at least some dialog about it, even if it unfortunately seems to have not gone beyond the dialog.
> The answer is simple: Apple just needs to deny FB App Store approval until they switch APIs. Of course they haven’t done that, and they won’t.
Right, I guess to be a bit more fair to Apple, there are things they could do here that would make me more sympathetic to their arguments about moderation. The reason I'm generally unsympathetic to arguments that Apple moderation keeps the app store safe is because they don't moderate enough. I feel like I have a lot stricter standards about what apps should be able to get away with than Apple does.
If Apple had when this story broke literally removed Facebook from the app store and forced them to disable that code, that would have been decent evidence to me that their moderation of the app store could have a substantial impact on privacy.
I do think there are things Apple could do that would better justify their hold over the app store.
I don't want to skirt too close to HN guidelines here, but I'm genuinely curious if you actually read my comment or not.
This is exactly what I asked you. If PWAs are (as Apple claims) good enough alternatives to the app store, why isn't anyone using them?
You can complain about Electron, but developers build Electron apps. They don't build PWAs. Because Electron apps are actually a feasible alternative to more native GUIs, and PWAs are not. The question you and I are asking (why isn't anyone using PWAs) reveals exactly how bullcrap Apple's legal arguments about PWAs are. They are not reasonable alternatives to the app store.
> All of the HN commenters blame mean old Apple for holding the web back
I don't blame Apple exclusively for holding the web back. They're a part of it, but so is Google. I don't think I've ever had much good to say about Google on here, and as the US and EU are actively proving right now, it is possible to pursue regulation for multiple companies at the same time.
> You have much better ways to track on the we[b] then through native apps - at least on iOS with a much better permission model.
This is not true by any metric. Native apps have more access to fingerprinting vectors than web apps do, are capable of requesting deeper levels of user information like contacts. Native Facebook on iOS got called out for injecting custom code into the in-app web view when users clicked on links within Facebook for 3rd-party sites. That's something that's not possible to do in any modern web browser.
Native apps are indisputably easier to use to fingerprint and track users on both iOS and Android.
Even if you're unfamiliar with the technical side of this, you can still think of it this way: if apps like Facebook had an easier time tracking you on the web than on mobile devices, they wouldn't try to get you to install mobile apps. They would force you to use the website. The reason why Facebook ships an iOS app is because it is easier to track you via iOS than through the Facebook website.