When you allow an app functionality it can be exploited. Security comes through only allowing apps that are vetted and routinely monitored (apps stored and repositories do this). The only way around this is to extremely limit softwares access to the rest of the system, which impairs functionality. Even access to sensors can be exploited to spy on users and access passwords.
When Apple allows users in the EU to install different browsers PWA would have apple relinquish all control over vetting of how PWA can interact with the system. The new browser would now be responsible for this.
Apple won’t be able to control it, but they will be liable in reputation for the damage that happens. Their walled garden doesn’t only keep their users in, it keeps hostile actors out (for the most part). iPhone users expect this and may see it as a feature. The same way Linux users see their distros repository as a feature. Remove this security will devalue the device in the minds of many of their customers.
I think you’re confused on this topic, because Apple has to allow users to sideload full applications soon. This is a much bigger attack vector than PWAs, which are still sandboxed in the respective browser. PWAs need to find a browser exploit + an iOS exploit, whereas native apps only need an iOS exploit.
No, they don’t only need a browser exploit, because the browser itself is sandboxed too. Otherwise the danger exists for literally every webpage - no need to install a PWA to break out if you have a browser exploit! You understand that a PWA is just a website and nothing more, right?
You understand that a PWA is just a website and nothing more, right?
This is sort of reductive. Yes, and no. It’s more than just a link on your home screen. More than just a set of html pages saved locally. It downloads the entire javascript app, the manifest, the icons, all that stuff and packages it up. When you run one of these you’d have no indication that you’re in a website. There is no browser URL bar or any of that. Only the controls in the app. It’s not really “just a website and nothing more”. It’s a javascript program running on a phones javascript engine (which is currently webkit and locked down). An app in just about every sense of the word. https://app.starbucks.com is a great example. Even works offline once you save it.
This is sort of reductive. Yes, and no. It’s more than just a link on your home screen. More than just a set of html pages saved locally. It downloads the entire javascript app, the manifest, the icons, all that stuff and packages it up. When you run one of these you’d have no indication that you’re in a website. There is no browser URL bar or any of that. Only the controls in the app. It’s not really “just a website and nothing more”.
No, it really is just a website and nothing more. Just because the browser UI is different doesn’t mean it’s a different thing. All of the technology itself is available to all websites, which is what is relevant for PWAs being “a massive vector for malware”, as initially claimed.
It’s a javascript program running on a phones javascript engine (which is currently webkit and locked down).
Yes, just like with any other website that uses Javascript. And Apple will have to allow other Javascript engines - so what’s the difference with PWAs specifically?
An app in just about every sense of the word. https://app.starbucks.com is a great example. Even works offline once you save it.
Yes, and the same APIs are available to other websites. Look up service workers.
PWAs traditionally have had hardware access not available to web pages within the browser. This makes a PWA more of a security risk than a web page, but also means you can have a PWA compass, or a PWA wifi troubleshooting app, or a PWA government ID app that can use the camera and microphone to validate the user outside Apple’s own APIs. It’s more than just extra cookie storage and expanded localstorage.
So if a PWA was deployed via Chrome, Apple would also have to give the Chrome PWA instance those permissions, without Apple being able to have intimate knowledge of the consequences on the back end, since Chrome isn’t WebKit. And Apple doesn’t have the same level of security vetting for third party software (like Chrome) that they do for OS internals (like WebKit).
If this doesn’t represent what you had in mind, could you quote specific comments?
I would disagree with the premise. A website and an application aren’t the same thing just because they are written in the same language (javascript).
This isn’t what I claimed. You are correct that using the same programming language doesn’t mean two things are in the same category, but that’s not my point. They are using the same:
Programming language
Runtime environment
Layout engine
Style & formatting engine
Markup language
Style language
Browser APIs
The only difference is that a few additional APIs are available and some browser restrictions have different value. That’s because Progressive Web Apps are literally meant to be websites that provide functionality and have progressive enhancements (i.e. feature detection, you use what you can without breaking because of what you can’t). This means we’re talking about the PWA being the same website, displayed in the same application, served from the same server.
Many, if not most, PWAs are websites that provide the same actual functionality with or without being installed, maybe without a couple niceties (e.g. bigger offline storage). Many don’t use features beyond what they offer as a normal website. This means all there is to distinguish PWAs and websites is how the user opened them on their phone.
How so? If they actually have a secure operating system, even a buggy/insecure browser wouldn’t allow malware to do anything bad.
All this theater makes it look like a lot of their security is dependent on App Store verification. I hope it isn’t.
It really sounds like it. And then idiots will say apple was right when exploit come out
When you allow an app functionality it can be exploited. Security comes through only allowing apps that are vetted and routinely monitored (apps stored and repositories do this). The only way around this is to extremely limit softwares access to the rest of the system, which impairs functionality. Even access to sensors can be exploited to spy on users and access passwords.
When Apple allows users in the EU to install different browsers PWA would have apple relinquish all control over vetting of how PWA can interact with the system. The new browser would now be responsible for this.
Apple won’t be able to control it, but they will be liable in reputation for the damage that happens. Their walled garden doesn’t only keep their users in, it keeps hostile actors out (for the most part). iPhone users expect this and may see it as a feature. The same way Linux users see their distros repository as a feature. Remove this security will devalue the device in the minds of many of their customers.
I think you’re confused on this topic, because Apple has to allow users to sideload full applications soon. This is a much bigger attack vector than PWAs, which are still sandboxed in the respective browser. PWAs need to find a browser exploit + an iOS exploit, whereas native apps only need an iOS exploit.
PWAs only need a browser exploit. If alternative browsers are allowed apple no longer controls this mechanism.
It’s also easier to slip a PWA by a user, making it confusing for uniformed users who would be targeted.
No, they don’t only need a browser exploit, because the browser itself is sandboxed too. Otherwise the danger exists for literally every webpage - no need to install a PWA to break out if you have a browser exploit! You understand that a PWA is just a website and nothing more, right?
This is sort of reductive. Yes, and no. It’s more than just a link on your home screen. More than just a set of html pages saved locally. It downloads the entire javascript app, the manifest, the icons, all that stuff and packages it up. When you run one of these you’d have no indication that you’re in a website. There is no browser URL bar or any of that. Only the controls in the app. It’s not really “just a website and nothing more”. It’s a javascript program running on a phones javascript engine (which is currently webkit and locked down). An app in just about every sense of the word. https://app.starbucks.com is a great example. Even works offline once you save it.
You just described a website…
No, it really is just a website and nothing more. Just because the browser UI is different doesn’t mean it’s a different thing. All of the technology itself is available to all websites, which is what is relevant for PWAs being “a massive vector for malware”, as initially claimed.
Yes, just like with any other website that uses Javascript. And Apple will have to allow other Javascript engines - so what’s the difference with PWAs specifically?
Yes, and the same APIs are available to other websites. Look up service workers.
I would disagree with the premise. A website and an application aren’t the same thing just because they are written in the same language (javascript). PWAs are apps in every sense of the word. Websites are not. I think the comments section on this Ars techinca article cover it pretty well, rather than re-hashing the same. https://arstechnica.com/gadgets/2024/03/apple-changes-course-will-keep-iphone-eu-web-apps-how-they-are-in-ios-17-4/?comments=1&comments-page=2
I presume you’re talking about e.g. this comment:
If this doesn’t represent what you had in mind, could you quote specific comments?
This isn’t what I claimed. You are correct that using the same programming language doesn’t mean two things are in the same category, but that’s not my point. They are using the same:
The only difference is that a few additional APIs are available and some browser restrictions have different value. That’s because Progressive Web Apps are literally meant to be websites that provide functionality and have progressive enhancements (i.e. feature detection, you use what you can without breaking because of what you can’t). This means we’re talking about the PWA being the same website, displayed in the same application, served from the same server.
Many, if not most, PWAs are websites that provide the same actual functionality with or without being installed, maybe without a couple niceties (e.g. bigger offline storage). Many don’t use features beyond what they offer as a normal website. This means all there is to distinguish PWAs and websites is how the user opened them on their phone.