3 ms·
The PWA block has more nuance than that. PWAs are locked to Safari's engine and Apple interpreted that as potentially against the law. And part of the problem i
by ocdtrekkie 2y ago
The PWA block has more nuance than that. PWAs are locked to Safari's engine and Apple interpreted that as potentially against the law. And part of the problem is that some competing web engines allow extremely dangerous APIs in their web platform which Mozilla has considered harmful.
Which isn't to say that Apple isn't playing malicious compliance hard, the entire CTF thing is ridiculous and demonstrates how desperately they do abuse the claim of security when it is actually all about profit... but the PWA thing isn't really part of that.
- dangus 2y agoSo why are PWAs and alternative browser engines okay on macOS but not iOS? These security excuses are bullshit and that does include PWAs.
- ocdtrekkie 2y agoI mean, I think those alternative browser engines are dangerous on other OSes too. Both at work at home I enforce policy on computers which disables a lot of harmful web APIs. It is much harder to protect mobile devices with policy.
- fallingsquirrel 2y agoThose so-called "dangerous" APIs are available in a normal browser visiting a normal website too. The APIs don't somehow become more dangerous if you let people put an icon for your site on the home screen.
- ocdtrekkie 2y agoThis isn't true on iOS. Because allowing arbitrary websites access to system hardware is pretty dangerous and stupid, Safari gates some of the newer APIs they do support behind PWA installation.
- TheLoafOfBread 2y agoSo basically Apple screw up writing their iOS kernel and Safari?
- fallingsquirrel 2y agoDo you have a source for that? At any rate, it's not clear to me that granting hardware permissions when you install a PWA is any better than letting the user choose what permissions to grant when you first visit a page. If that really is how it works, maybe alternate browsers will be able to improve over Safari's permission model too.
- ocdtrekkie 2y agoThat request really kinda falls into "let me google that for you" territory, but, you know, here you go: https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/ https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-a... > it's not clear to me So, you may not have watched normal users operate a web browser. But... they click on everything in their way. This is why, for example, most "malware" calls I get are just dozens upon dozens of Notifications API permissions being granted in Chrome to random websites. The best way to fix this is... just destroy the Notifications API as a thing, it's a terrible idea. But the next best way is to ensure access to it is limited to contexts where it's obvious a user is interested in persistent communication with a given site or app. Like installing it. At any point where you thought "just asking the user when they first visit the page for permission" was an adequate concept, you were wrong. And most malicious websites abuse this wrongness ad-nauseum, to the point that browsers now include ways to block websites from making repetitive requests as a attempt to fix it without fixing it. Firefox has a pretty good record, and I consider their standards positions (https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/) the gold standard. iOS/Safari moves a little more slowly, but generally aligns with good practice. Google and Microsoft are the two companies everyone else (including Safari) is significantly improving over by actually paying attention to how real users interact with the Internet.
- fallingsquirrel 2y ago