What kind of permission screen(s) should the user see? (To avoid spamming and spoofing) #1
Comments
|
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.
Yes.
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.
Can you explain this in bit more details?
No.
N/A (previous answer).
Yes naturally. We expect to have a mechanism that notifies the app of the success status; most likely return codes.
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.
This can mean two different things:
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. |
|
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.
How does it works today when the manifest file is updated? I just read:
I don't know either. I am just copying an interesting potential question from two other persons in CC, maybe they have some suggestions? |
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. |
|
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>
.
|
|
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. |
|
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>
.
|
|
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 |
Thanks, |
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 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:
+CC @Sauski, @andypaicu, @amtunlimited, @ArthurSonzogni
The text was updated successfully, but these errors were encountered: