3 ms·

Those 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

Those 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 ago
This 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 ago
  So basically Apple screw up writing their iOS kernel and Safari?
- fallingsquirrel 2y ago
  Do 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 ago
    That 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
      We're straying a bit from the original topic of direct access to hardware, but I'll humor you. Let's look at one of your users who does click yes to everything. In $YEAR, spam websites will say "enable push notifications to view this funny cat image. In $YEAR+1, spam websites will say "install our PWA to view this funny cat image" or "install our native app to view this funny cat image" and our user will still obey because the popup is in the way. For the clueless user, nothing has changed other than which button they obediently push. For the savvy user, you've added an arbitrary special case and a hoop to jump through to get the functionality you wanted in the first place. Neither case is improved in the end.

ocdtrekkie 2y ago

This 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 ago
So basically Apple screw up writing their iOS kernel and Safari?
fallingsquirrel 2y ago
Do 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 ago
  That 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
    We're straying a bit from the original topic of direct access to hardware, but I'll humor you. Let's look at one of your users who does click yes to everything. In $YEAR, spam websites will say "enable push notifications to view this funny cat image. In $YEAR+1, spam websites will say "install our PWA to view this funny cat image" or "install our native app to view this funny cat image" and our user will still obey because the popup is in the way. For the clueless user, nothing has changed other than which button they obediently push. For the savvy user, you've added an arbitrary special case and a hoop to jump through to get the functionality you wanted in the first place. Neither case is improved in the end.