← Back to context

Comment by Sayrus

5 years ago

I don't want _most_ websites doing this. There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

Maybe it shouldn't "asking for permission" but "giving your permission" explicitly. If you don't need such an API, you would never be bothered by it if the model is opt-in without notification/popups.

I understand the problem you have with websites asking for permissions, especially push notifications permissions, as they keep showing up. And I do definitely agree that having a website that does not need any of these permissions ask for it would be even more annoying but there are definitely cases where I'm glad a website can help me out (and I don't have to download a heavy client that might or might not have tracking and analytics in it)

7 comments

Sayrus

Reply
ornxka  5 years ago

>There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

How can this be so when the web browser itself is a heavy client?

  • josephcsible  5 years ago

    Unless you only use one such website ever, then it's a win for the browser to be the heavy client instead of having separate ones for each.

  • Sayrus  5 years ago

    You could argue that, however, I don't think it change the fact that you already have it installed. So, in my honest opinion, it is indeed replacing a second heavy client that you might have installed if you browser did not have this capability.

jfkebwjsbx  5 years ago

Why would you ever want a PWA when a native version exists?

And "heavy client" is a fallacy. Operating systems come with runtimes too. Very complex native app can be very small in size if it uses the native controls and APIs. They can be KB in size. Any asset is going to be bigger than the binary itself.

The web-as-native apps are the ones that are huge, because they embed a behemoth (a browser) which is akin to an entire operating system.

  • ta576248_743568  5 years ago

    PWAs run from the browser sandbox which is generally much stricter than restrictions for native apps. Permission systems for native applications seems to be starting to follow browsers (flatpak, snap, .appx, etc.), but don't offer nearly the ability to restrict what a native app can do like the browser does.

    In theory native apps are "trusted", but I think for the vast majority of users the trust between a companies website and app are equivalent, vetted the same, and probably do an equivalent amount of tracking if not more by the native app (facebook SDKs are pretty common in native mobile apps).

    • jfkebwjsbx  5 years ago

      I talked about paid or open source productive software, usually desktop based, nor ad-riddled mobile apps with the Facebook SDK which by definition are not trusted.

      Mobile apps are increasingly sandboxed too, like websites, precisely because of that.