4 ms·

> 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' i

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

derefr 3y ago
> 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!
- giantrobot 3y ago
  Then everyone will just bitch PWAs can't do anything.
  - Izkata 3y ago
    The Peapod grocery delivery app was already just single webview to their website. Worked fine.
  - derefr 3y ago
    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!)
- deleted 3y ago
  [deleted]
- rahkiin 3y ago
  This would run foul against the DMA, unless they make safari PWA also less capable.
  - derefr 3y ago
    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.”
johnnyanmac 3y ago
>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". Sounds like they cornered themselves there.
- nip 3y ago
  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.
  - johnnyanmac 3y ago
    >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.
    - nip 3y ago
      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.
kristiandupont 3y ago
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.
- elbear 3y ago
  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.
- rahkiin 3y ago
  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
neurostimulant 3y ago
> 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?
- anon373839 3y ago
  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.
  - scarface_74 3y ago
    Yes because PWAs are so popular on Android
    - Pesthuf 3y ago
      They’re not as necessary on Android because Android has alternative App distribution methods.
      - scarface_74 3y ago
        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?
beeboobaa 3y ago
Nah, it's secure because the OS is secure. No difference between an app itself and an app running "other apps". It's all just code sandboxed by the OS. Apple is just being pathetic because they couldn't force legislators to do their bidding.
arghwhat 3y ago
> 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.

derefr 3y ago

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

giantrobot 3y ago
Then everyone will just bitch PWAs can't do anything.
- Izkata 3y ago
  The Peapod grocery delivery app was already just single webview to their website. Worked fine.
- derefr 3y ago
  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!)
deleted 3y ago
[deleted]
rahkiin 3y ago
This would run foul against the DMA, unless they make safari PWA also less capable.
- derefr 3y ago
  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.”

johnnyanmac 3y ago

>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". Sounds like they cornered themselves there.

nip 3y ago
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.
- johnnyanmac 3y ago
  >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.
  - nip 3y ago
    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.

kristiandupont 3y ago

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.

elbear 3y ago
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.
rahkiin 3y ago
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

neurostimulant 3y ago

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

anon373839 3y ago
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.
- scarface_74 3y ago
  Yes because PWAs are so popular on Android
  - Pesthuf 3y ago
    They’re not as necessary on Android because Android has alternative App distribution methods.
    - scarface_74 3y ago
      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?

beeboobaa 3y ago

Nah, it's secure because the OS is secure. No difference between an app itself and an app running "other apps". It's all just code sandboxed by the OS. Apple is just being pathetic because they couldn't force legislators to do their bidding.

arghwhat 3y ago

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