Open hpsin opened 2 years ago
annevk
commented
2 years ago FWIW, we are planning on moving to this prompt in Firefox:
Allow %S to access cross-site cookies? You should block access if it’s not clear why this is being requested for %S.
It's not clear to me how a website provided enum value or string would work here. As with all user-facing dialogs from websites, %S is assumed to be the attacker.
johannhof
commented
2 years ago Yeah as Anne said we’re removing “tracking” from our UI, at least, so I can see the problem you’re facing.
Context for permission prompts is a really double-edged sword. When done well, it can make prompts a lot more useful and facilitate meaningful user choice. In the worst case we add additional attack surface to the browser and get a bunch of sites lying to the user to make them accept the prompt. This is easier to control in walled garden environments like App Stores, where an App making false claims can simply be punished through removal from the store. On the web it’s more difficult, so browsers have leaned towards not giving website-provided context.
I can see the same thing here. Websites would just choose the enum value which has the highest success rate with users.
Why not instead design your user flow so that it becomes clear that, after clicking a button, they will now see a prompt for sharing information between example.com and example2.com? You’ll have the entire content frame to deliver your messaging.
hpsin
commented
2 years ago Thanks Anne, Johann, that's great to hear. Is there any indication that users understand what cross site cookies are besides "bad"?
Providing context is the goal, for sure. With #83, we'll be able to provide context in line to justify the request. Doing it from inside an iframe is much harder - imagine fitting an explanation of what a cross site cookie is inside the "login with X" button. At a minimum it would require O(million) apps to update manually to fit a new login pattern.
The enums do have to match reality, and can be restrained in scope and browser controlled. If clicking on an ad triggers a "signing in with a %S account, which requires cross site cookies" prompt, users are likely to recognize that they're not signing in/didn't intend to, and will cancel the prompt.
Example, where %P is the parent frame.
Allow %S to access cross-site cookies? %P is trying to sign you in using %S You should block access if it’s not clear why this is being requested for %S.
johnwilander
commented
2 years ago As part of an experiment to fix authentication on our properties, the Storage Access API was used to unblock cookies. Because SAA was required in order for the app to work, users were blocked from continuing until they accepted the prompt. The requirement that users accept a prompt that discusses "tracking" lead to significant customer upset - ultimately, the notion that the user "had to accept tracking" in order to sign in lead to significant confusion and consternation.
I'm not aware of any browser that says third-party cookie access means tracking. The phrasing has always been around what the permission allows the third party to do.
This ultimately resulted in (threats of) complaints to the user's local ICO and/or GDPR representative, as appropriate.
We'd like a way to offer in-browser a way to explain why we need "tracking" privileges to sign them in. We plan to phrase it as "apps need to remember that you're signed in", since our login domain serves as apps' collective "memory". As of right now though, SAA has demonstrably opened us to legal concerns and complaints, so avenues to reduce that risk would make it easier to implement in the future.
This is one of the things that IsLoggedIn is supposed to solve. If the browser knows where the user is logged in, it might be possible to alter the message in the SAA prompt to also mention login. No exact language has been proposed yet and I expect browser vendors will always want to decide for themselves how they communicate security and privacy information with users.
Proposal:
In addition to whatever text a UA wants to provide in this space, an additional "reason" is offered that the site can fill in or influence somehow. This could be a selection from an enum (e.g. you can pick "auth" from a list of enums), or it could be an open text field, as unlikely as that is.
hpsin
commented
2 years ago Thanks John, I think that distinction is beyond what most users can note. We have some experiments coming up to see if requesting SAA helps or hurts our sign in rates, which we'll share here. I expect that we'll see meaningful differences by browser, influenced by the messaging.
For IsLoggedIn, do you propose requiring the SAA prompt to take it into account? I'm leary of adding yet another prompt to our login flow that the user must critically accept otherwise things break. It's a lot of training them to be prompt blind.
As part of an experiment to fix authentication on our properties, the Storage Access API was used to unblock cookies. Because SAA was required in order for the app to work, users were blocked from continuing until they accepted the prompt. The requirement that users accept a prompt that discusses "tracking" lead to significant customer upset - ultimately, the notion that the user "had to accept tracking" in order to sign in lead to significant confusion and consternation.
This ultimately resulted in (threats of) complaints to the user's local ICO and/or GDPR representative, as appropriate.
We'd like a way to offer in-browser a way to explain why we need "tracking" privileges to sign them in. We plan to phrase it as "apps need to remember that you're signed in", since our login domain serves as apps' collective "memory". As of right now though, SAA has demonstrably opened us to legal concerns and complaints, so avenues to reduce that risk would make it easier to implement in the future.
Proposal:
In addition to whatever text a UA wants to provide in this space, an additional "reason" is offered that the site can fill in or influence somehow. This could be a selection from an enum (e.g. you can pick "auth" from a list of enums), or it could be an open text field, as unlikely as that is.