What kind of permission screen(s) should the user see? (To avoid spamming and spoofing)

[ArthurSonzogni]

I understand this is still not fully defined, so it might be hard to give a precise answer.

I would like to know what kind of permission screen the user will have to approve before adding new icons. It seems vital the icon and name are present when the prompt is presented to the user. Otherwise, there are risk of spoofing.

Some question, mostly taken from the security/privacy review preparation:

1. Do we show a new prompt for every individual icon?
2. Did you considered throttling requests and then make a "group" prompt?
3. How would we make the prompt repeatable for every icon, but not spammable?
4. Does the decision to block an icon remains permanent?
5. How would users revisit a decision to block an app from adding an additional icon?
6. Would PWAs know which icons have been blocked by the users so they can stop asking for those icons?
7. Is there a limit? Can we add 1000 icons in a single request?
8. Does updating one icon is subject to a "revalidation" via a prompt from the user?
9. Asking too many things to the user might lead to prompt fatigue. Some might auto-pilot after the 3rd prompt. We are wondering how this could be avoided.

+CC @Sauski, @andypaicu, @amtunlimited, @ArthurSonzogni

[ivansandrk]

Hi Arthur, thanks for chiming in!

As mentioned in the "Security & Privacy considerations" section in the explainer, we would prompt the user for adding new icons, and this prompt would include both the icon and the name of what is being added.

1. Do we show a new prompt for every individual icon?

Yes.

2. Did you considered throttling requests and then make a "group" prompt?

It did cross my mind, but that would significantly complicate the feature; we could though have a regular add(), and in addition also have a batchAdd() if it turns out it's needed.

3. How would we make the prompt repeatable for every icon, but not spammable?

Can you explain this in bit more details?

4. Does the decision to block an icon remains permanent?

No.

5. How would users revisit a decision to block an app from adding an additional icon?

N/A (previous answer).

6. Would PWAs know which icons have been blocked by the users so they can stop asking for those icons?

Yes naturally. We expect to have a mechanism that notifies the app of the success status; most likely return codes.

7. Is there a limit? Can we add 1000 icons in a single request?

At this point we weren't planning on implementing a batch approach, but that can be done if necessary and throttled at say 10 icons per request.

8. Does updating one icon is subject to a "revalidation" via a prompt from the user?

This can mean two different things:

1. The app calls an update() on the icon - the user would be prompted again;
2. If we implement the feature with the technical approach that seems most viable atm (shortcuts as main app literally installing its sub apps) then whenever the manifest of the "added icon" (installed sub app) gets updated, that "icon" would be updated as well in the exact same way how installed web apps are usually updated when their manifest gets updated.

9. Asking too many things to the user might lead to prompt fatigue. Some might auto-pilot after the 3rd prompt. We are wondering how this could be avoided.

I wouldn't know what to do about it. Do you have any suggestions? If anything, I don't think this will be a big issue in practice. In addition, we're mostly expecting enterprise partners to use this API, and in enterprise environments we will allow the admins to override the prompt via policy so users won't have to worry about being spammed.

[ArthurSonzogni]

Thanks for those answers!

What you have in mind is a new permission prompt for every individual icons. The most important part is requiring the user to validate and "see" any new icon and icon name. It shouldn't be easy to spoof other applications. This shouldn't depend on the number of new icons, or whether this is an update or not.
From your answers this seems to be the case. Good!

If we implement the feature with the technical approach that seems most viable atm (shortcuts as main app literally installing its sub apps) then whenever the manifest of the "added icon" (installed sub app) gets updated, that "icon" would be updated as well in the exact same way how installed web apps are usually updated when their manifest gets updated.

How does it works today when the manifest file is updated? I just read:
https://web.dev/manifest-updates/#cr-desktop
It seems you can change the icon, without the user being prompted again. You can do it for the icon, but not the icon name.
Is this correct? If yes, then this looks worrying to me, because a website seems to be able to spoof other application this way.

Asking too many things to the user might lead to prompt fatigue. Some might auto-pilot after the 3rd prompt. We are wondering how this could be avoided.

I wouldn't know what to do about it. Do you have any suggestions?

I don't know either. I am just copying an interesting potential question from two other persons in CC, maybe they have some suggestions?

[ivansandrk]

If we implement the feature with the technical approach that seems most viable atm (shortcuts as main app literally installing its sub apps) then whenever the manifest of the "added icon" (installed sub app) gets updated, that "icon" would be updated as well in the exact same way how installed web apps are usually updated when their manifest gets updated.
How does it works today when the manifest file is updated? I just read:

https://web.dev/manifest-updates/#cr-desktop
It seems you can change the icon, without the user being prompted again. You can do it for the icon, but not the icon name.
Is this correct? If yes, then this looks worrying to me, because a website seems to be able to spoof other application this way.

It might or might not be a problem.

If it is, then the problem doesn't exist only for this particular feature, but it exists in general for any installed PWA, and should be solved for the general case.

And if it's not a problem for the general case, then it also isn't a problem for this particular feature since it's not really any different.

[andypaicu]

In order to prevent spoofing we've established that the user needs to be presented with the icon and text in the prompt. If the icon is easy to change after the fact without user approval that renders the prompt half-useless. I would suggest that we re-prompt users when an icon needs updating because: 1) It helps us try to prevent spoofing attempts as explained above 2) It should be a somewhat rare occurrence, I don't imagine PWAs update their app icons that often There might be a case to be made that this is a PWA wide issue but I think there is a difference between having control over the one icon that represents an application and having control over many icons out of which you can sneakily change one to something else. And regardless I do think we should solve it for this feature, regardless of whether that means solving it for all PWAs or just for sub-apps I don't really have good suggestions regarding prompt fatigue, I do think it's an issue that we should consider but if there are no better alternatives (which I currently don't see any) then we might need to accept it. I worry about the spammines potential, there seems to currently be no limit to how much a PWA can prompt the user and user decisions are not final. I would suggest a more defensive approach on behalf of the users, something like: you're allowed to ask 3 times, if you get denied you can't ask for a day. If you get denied again you can't ask for a month and after another block it becomes permanent. Do you see an issue with this type of approach regarding your currently targeted use cases? Kind Regards, Andy Paicu

…

On Tue, Feb 16, 2021 at 2:52 PM ivansandrk ***@***.***> wrote: If we implement the feature with the technical approach that seems most viable atm (shortcuts as main app literally installing its sub apps) then whenever the manifest of the "added icon" (installed sub app) gets updated, that "icon" would be updated as well in the exact same way how installed web apps are usually updated when their manifest gets updated. How does it works today when the manifest file is updated? I just read: https://web.dev/manifest-updates/#cr-desktop It seems you can change the icon, without the user being prompted again. You can do it for the icon, but not the icon name. Is this correct? If yes, then this looks worrying to me, because a website seems to be able to spoof other application this way. It might or might not be a problem. If it is, then the problem doesn't exist only for this particular feature, but it exists in general for any installed PWA, and should be solved for the general case. And if it's not a problem for the general case, then it also isn't a problem for this particular feature since it's not really any different. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGX23EHQVYBBG5ZJZPOEICLS7J2AFANCNFSM4XJLH5RA> .

[ivansandrk]

Hey Andy, thanks for commenting and sharing your thoughts!

#1 There's no functional difference really if you have many PWAs installed and any one of them could sneakily change its icon to something else compared to what this feature is adding. I'll reiterate - if you think this is a problem then you should solve it at the global PWA level, and not special-case this particular feature. Once it's solved there, it will naturally propagate also here as the technical idea behind this feature is in essence "installing" the sub-apps using the same already available infrastructure. Changing that would be very painful and in my opinion unnecessary additional work.

#2 I understand your concerns around spamming the user, but I wouldn't consider them a real issue. I, as a user, expect that my apps are well behaved and I trust the developers of the applications I use to be considerate of this. In the rare case that they aren't, it's easy to just not use them / remove them. As a data point here - I've been using computers since ~1995' (25 years) and I must say I can't even remember if any of the apps that were natively installed on my computers have misbehaved, much less done malicious things, and they had much more power than PWAs have these days.

[andypaicu]

1) Perhaps they are the same, except I would argue that having control over a suit of icons instead of just one opens potential spoofing avenues but maybe that's just too esoteric. I'm still having trouble reconciling this with the fact that we show the icon to the user in the permission prompt as if it's supposed to be a signal that they should base their decision on, even though said icon is subject to change at any point without further confirmation. 2) I am glad that you had good experience with natively installed apps but that's not really a persuasive argument (at least for me). The fact that we don't simply allow apps to do what they want once installed is sufficient to prove that (on behalf of our users) we don't implicitly trust apps to not be malicious once natively installed. Furthermore there is no precedent in terms of permissions, either on Chrome or on Android (as far as I know) where the user has no way to block a permission permanently for a particular app/site and this would be a horrible user experience precedent to set. Simply not using the app might not always be a solution, for example the app might do something entirely unique. Even furthermore PWAs might feel like apps but they are still in essence websites and as such they are subject to the same vulnerabilities, an app can become malicious without the author's intent, something that is very difficult with a native app. Kind Regards, Andy Paicu

…

On Tue, Feb 16, 2021 at 6:17 PM ivansandrk ***@***.***> wrote: Hey Andy, thanks for commenting and sharing your thoughts! #1 <#1> There's no functional difference really if you have many PWAs installed and any one of them could sneakily change its icon to something else compared to what this feature is adding. I'll reiterate - if you think this is a problem then you should solve it at the global PWA level, and not special-case this particular feature. Once it's solved there, it will naturally propagate also here as the technical idea behind this feature is in essence "installing" the sub-apps using the same already available infrastructure. Changing that would be very painful and in my opinion unnecessary additional work. #2 <#2> I understand your concerns around spamming the user, but I wouldn't consider them a real issue. I, as a user, expect that my apps are well behaved and I trust the developers of the applications I use to be considerate of this. In the rare case that they aren't, it's easy to just not use them / remove them. As a data point here - I've been using computers since ~1995' (25 years) and I must say I can't even remember if any of the apps that were *natively* installed on my computers have misbehaved, much less done malicious things, and they had much more power than PWAs have these days. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGX23EFDON3MOCHLRAXLKQLS7KSBTANCNFSM4XJLH5RA> .

[dmurph]

Hello!

Chiming in here regarding the current state of web app updatability - we allow the web app to update their icons, but we do NOT allow the name to be updated. This was seen as a phishing security risk. I think that @michaelwasserman is doing some work here to help prevent possible phishing here even more.

One reason why updatable icons is more understandable than an updatable name is that developers developers often will launch or test with bad / not quite HD icons, and then need to update them later.

This security decision was before my time on the team, but I can try to look up this review. @mgiuca might also have info here on the top of their head

[ivansandrk]

@andypaicu

1. I spent some time digging around the original issue and it will be fixed at the origin (ie. there will be either a warning when the icon changes, or this will be disabled completely).

2. Fair enough, I see your point. What do people usually do in this domain?

Thanks,
Ivan

[ArthurSonzogni]

1. I spent some time digging around the original issue and it will be fixed at the origin (ie. there will be either a warning when the icon changes, or this will be disabled completely).

Nice! I am happy to see the root cause will be fixed at the origin! Do you have some bugs referencing this? This is the path forward I am the most comfortable with.
I was about writing a doc discussing what would be the other options like fixing revalidation only for multi-apps at the cost of inconsistencies or whether we can afford temporarily not to have this bug fixed. If you can fix the issue at the root, that's ideal!