It really doesn't make sense. By that logic, I shouldn't be allowed to load web pages because it's impossible to secure a browser. PWA's only need a few extra integration privileges like badge- and window control, rest is just a web as usual.
What you link is a case of one app (edge) reading the data of another app (chrome), which is entirely unrelated to PWAs.
> By that logic, I shouldn't be allowed to load web pages because it's impossible to secure a browser.
Indeeed, and 'whatever browser engine you picked here' is responsible for correctly implementing these additional security features.
That's the argument; if you write an app that lets you run other apps inside it how do we make sure your app does security correctly?
When you look at it from that perspective, you can see that unless at an OS level you provide additional 'meta-security' features that allow apps that run in other apps to have fine grains access control that is managed by the OS, it's pretty much "security? Well, whatever...".
Right? I mean, whether you agree or not, it's a pretty reasonable position to take and it entirely makes sense.
> Indeeed, and 'whatever browser engine you picked here' is responsible for correctly implementing these additional security features.
Yes, and Apple now (against their will) allow me to select this browser myself to browser the web with.
Whether I use this to load a webpage normally or as a PWA does not change the risk I was exposed to. PWAs just let a web application ask the browser to run "fullscreen" without browser chrome, to set its badge and colors, to register as a handler for certain URL types, and to open the share panel. All actions already taken regularly by said browser.
Even if we assume Apple's statement that other browsers are insecure is correct, there is no value in blocking PWAs and requiring me to instead use bookmarks: I am still loading said application in said browser that implements and uses all this functionality itself. To the OS, a PWA is nothing more than a type of bookmark for a browser.
So, no - this is not reasonable and their argument makes no sense. If it was true that Safari was actually safer, then Apple should instead spend energy sharing how so that other apps can be equally safe - it would be incredibly irresponsible for the platform owner to keep security as secret sauce - rather than handicapping other apps.
> if you write an app that lets you run other apps inside it how do we make sure your app does security correctly?
But browsers already have this security features that isolates websites from each other? How come PWA, which essentially just placing a website shortcut in the home screen and hiding browser ui, affect browser's existing security features?
It doesn’t, of course. Apple’s real concern is that if Chrome is allowed to host standalone PWAs, it can also remove some of the unnecessary pain points that Apple’s Safari maliciously injected to kneecap PWAs in the first place. For example, Chrome could make it easy for users to install a PWA. Chrome could support more web standards. Etc. This would create a true alternative to the App Store, with no Apple tax, and of course Apple isn’t going to let that happen without kicking and screaming.
Right. Because downloading from alternate app stores or from the web is really easier than creating a PWA and is easier for discoverability.
But that is a new retort when I ask that same question most of the time. Often it’s because of mean old Apple that PWAs aren’t more popular on Android.
But since now that there will be alternate means of distribution in the EU, you should be okay with no PWAs in the EU?
Do you have a coherent point you're trying to make? We're discussing Apple here. These wanna be "gotchas" aren't nearly as clever as you think.
> But since now that there will be alternate means of distribution in the EU, you should be okay with no PWAs in the EU?
I see, a hardened Apple defender. Nice show of cards! There are no alternative means of distribution in the EU that don't involve paying large sums of money to Apple, but you already knew that.
My points are the same neither consumers or the companies that make most of the money from mobile care about PWAs
My second point is if it just Apple and Safari holding back the adoption of PWAs, then why aren’t they more popular on Android if Chrome is so much better?
Why aren’t companies creating PWAs for Android to avoid the same 30% cut? Are they okay with paying “large sums of money” to Google?
Why aren’t they using third party app stores on Android or letting users download directly from them?
I thought the whole point of PWAs was that they could access user files directly, which they wouldn't be able to as a webpage inside a browser's sandbox? If that's not the case it's just a bookmark.
> you can see that unless at an OS level you provide additional 'meta-security' features that allow apps that run in other apps to have fine grains access control that is managed by the OS, it's pretty much "security? Well, whatever...".
I don't think that's the only solution. A simple alternative is to declare that "apps that run in other apps don't get to do anything at all."
I.e. in this case, in response to a EU requirement to support alternative browser engines, Apple could — rather than disabling PWA integration altogether — drop all additional privileges that PWAs have that regular webpages don't.
Make installed PWAs in the EU market into just "webpages, but with a home-screen icon, a separate task-manager card, and no address bar." Which is 99% of the reason anyone installs a PWA anyway. No camera/microphone, no extra storage, etc. Not for Chrome PWAs, not for Safari PWAs; not for any PWAs (on these devices.) They're just webpages presented differently. No "meta-security" required!
That’s what I meant/said — they’d neuter the PWA framework itself, which would mean that any PWA (including Safari PWAs) would just become “regular webpages but standalone.”
But only in the EU, and only on iOS. They'd still get enhanced capabilities elsewhere. (On iOS on any other continent; on Android anywhere; on ChromiumOS anywhere, or just Chrome on desktop anywhere; etc.)
And the nice thing about PWAs, is that there's no way for a PWA to know or care that it's being run "installed", and change its expectations/requirements — as there's just no web API for that. Instead, a PWA must just attempt to talk to each of these permission-gated APIs it wants to use, and find that it's now being [prompted for and] given access to them, rather than silently refused them.
So, unlike tightening the security model around regular native apps, tightening the security sandbox around PWAs shouldn't actually fundamentally break them — they should be designed to gracefully degrade when refused these capabilities. Presuming these PWAs were already ordinary fully-functional web-apps, which have just been progressively enhanced with these features when and where available, they'll just act like they do "on the web" — which should still deliver on the app's use-case. That's what the "Progressive" in "Progressive Web Apps" is supposed to mean!
Of course, some PWAs 1. will have been designed from the ground up as PWAs, and 2. will have a purpose/use-case that's very specific to the use of these high-integrity web APIs, such that they're completely useless without these PWA-only permissions. A video-chat PWA, for example, won't do much without access to your camera + microphone. There's no point to using these webapps as webapps — and often they don't even let you do so (i.e. they attempt to access the specific API they need on launch; if they succeed, they render the app UI; if they fail, they render a prompt to install the PWA.)
I don't know if you'd really call these PWAs, since there's nothing progressive about them — there almost needs to be a different term for these apps that need the high-trust APIs to do anything-at-all. For the sake of discussion, I'll refer to these as "Elevated Web Apps" (EWAs), since they require elevated permissions to be useful.
It's only these Elevated Web Apps that would benefit from having what the GP called "meta-security": the ability to interact with the OS security on a per-webapp basis, through e.g. an Android-like install-time gate where the app presents a capabilities manifest (displayed to the user as a set of permissions it wants) and the user makes a decision of whether to accept that.
And, if Apple simply neutered PWAs rather than removing them, it's only these Elevated Web Apps that people would "miss out on."
As cool as PWAs are as a technology, these Elevated Web Apps are a true minority or them — maybe 1% or so.
And — at least as far as I know — almost all Elevated Web apps only exist for one of two reasons:
1. to serve use-cases that users with access to native apps from an app store, just have no reason to care about. (Specifically, they were developed to allow users to accomplish native-app-equivalent things on OSes that don't support any kind of native apps — like FirefoxOS nee KaiOS, or early ChromiumOS.)
2. to benefit the developer at the user's expense, by forcing the user to give the developer permissions that allow the developer to spy on the user more effectively, before the app will work — but where the app doesn't actually do anything with these permissions to serve the use-case. (I've seen a few scammy Chinese dating sites demand to be installed as a PWA for this reason.)
In other words: on iOS, at least, you probably won't miss them! (Especially with the third-party App Store ruling also in place in the EU! Things like emulators don't need to be relegated to "WASM running in a PWA" any more; in the EU, they can just be third-party-store apps!)
I don't see how this refutes GP's point. Yes, it's a big challenge but when they are allowing other browsers, the challenge is met already. The "install to home screen" feature adds but very minute extra features.
My understanding is that Apple can provide security guarantees only for their own browser, because it's tightly integrated with the rest of their stack.
I guess the issue is that PWA is more deeply integrated… so instead of having this integration within the OS using their WKWebView component, they need to make it a user choice which browser component is used.
This component then has to be installable through the App Store.
This then also means an ‘app’ is hosted by another ‘app’, and to do this properly that host app needs to many permissions
>and 'whatever browser engine you picked here' is responsible for correctly implementing these additional security features.
so, Apple? Since Apple has also required browsers for years to use their own safari backend, this isn't even an issue of "oh well it doesn't work on Firefox".
Apple’s hand has been forced to implement changes that didn’t fit their vision and roadmap.
I imagine that if you’re on HN you are close to developers or are a developer yourself.
And if so, I imagine that you have already had an important customer (to who you cannot say “no”), completely change your plans and architecture with a new feature request while setting an aggressive deadline (ie, you don’t have time to implement everything and must make choices)
Now replace you with “Apple” and “important customer” with EU.
>I imagine that you have already had an important customer (to who you cannot say “no”), completely change your plans and architecture with a new feature request while setting an aggressive deadline
Sure. I sure do wish the demands were actually consumer centric, and not "force all these advertising tracking into your site, tank performance, and grab a bunch of unneeded user data".
And of course, if I maliciously complied and "oops the tracking only gets 1% of user data", I would simply be fired instead of get another strongly worded letter leading to meetings re-defining what "grab a bunch if unneeded user data" is.
You are confusing the “important customer” with “other customers”.
EU is the “important customer”, the users of PWA are “other customers”.
Using your example, you would implement tracking for that important customer (and comply 100% to the requirements as Apple did) but because of this additional bloat, the website would load 2 times slower.
After a discussion with your colleagues, you would realize that:
- Most users won’t care about the slow loading (including the important customer)
- Re-architecturing the website to keep the same level of performance while adding the necessary tracking required by the important customer would delay shipping the tracking by 1 year, past the 2 months deadline required by the important customer.
Back to your desk, you start implementing the tracking that will incur a 2x slower load time.
>You are confusing the “important customer” with “other customers”.
I'd love to one day work for a place where I can dismiss monetization as "the other customer". But alas, my career hasn't been that friendly.
>Using your example, you would implement tracking for that important customer (and comply 100% to the requirements as Apple did) but because of this additional bloat, the website would load 2 times slower.
Given how the topic is:
>Following developer complaints and press reports about how PWAs were no longer functional in the EU after installing the most recent iOS betas
I fail to see how the EU is the "important customer" here. And not the powers that be in Apple telling me to maliciously comply.
The EU said "allow other app stores to exist" and my theoretical manager at Apple is saying "okay, PWAs can exist but they don't have to run well. Add in unnecessary security (because the NA version doesn't have it) that disables functionality". I don't even see how it has to do with complying with the EU, unless it's soke long term OS lock down for future app stores.
Tell me how the EU here is the one telling me to slow down my OS/browser?
They had 1,5 years from the time of being identified as gatekeepers to work on this.
The DMA was voted on by the EU parliament and then the council in july 2022, Apple was identified as a gatekeeper in september 2022, the law became legally implemented in november 2022, with gatekeepers required to comply with it by march 6th 2024.
I do not buy for a second that the richest tech company on the planet, that owns, designs and manufactures the whole tech stack their product uses was unable to respond in due time to the legally required changes and so 'just had to go this route due to time constraints'.
> What you link is a case of one app (edge) reading the data of another app (chrome), which is entirely unrelated to PWAs.
In one sense, sure.
But in another sense Edge taking Chrome's tabs means Microsoft is getting insight into Google's data. A lot of Apple's defenses seem really targeted at reducing the ability of Microsoft, Google, and Meta to extract value from Apple's users. Apple sees the union of all the app data, but their competitors can't put together that picture. So in that sense, Edge eating Chrome data may be the sort of thing they're looking to prevent.
They are a cash flow generating financial product, like a bond ETF. Apple packages users, resell them to the highest bidder, and interest is collected as return on investment from the payments users make.
Ofc, like a bond, a user pays for a reason: he gets something out of the facility provided by Apple, in kind.
The EU gave them six months after being designated as a gatekeeper. The regulation already entered into force an additional ten months earlier, so Apple arguably could have already prepared for their likely designation.
The real issue, however, is that Apple is not saying “we need more time to implement the APIs”, which the EU would very likely concede, but “we don’t think it’s worth it for us”.
Is that teally an issue? From a legal perspective (as a layman) Apples decision seems fine for me. So how can we say "bad Apple" if they're legally doing it correct?
That does not mean that their decision is the proper one, just that it's legally ok.
Why are you limiting this to the legal perspective? They are not doing what is in the interest of their users (and the spirit of the DMA), for petty reasons. As a user, that’s obviously bad.
What you link is a case of one app (edge) reading the data of another app (chrome), which is entirely unrelated to PWAs.