Requesting origin in requestStorageAccess prompt is no longer highlighted
Categories
(Firefox :: Site Permissions, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | wontfix |
firefox87 | --- | unaffected |
firefox88 | --- | unaffected |
firefox89 | --- | wontfix |
firefox90 | --- | wontfix |
firefox91 | --- | wontfix |
firefox92 | --- | wontfix |
firefox93 | --- | fixed |
People
(Reporter: emz, Assigned: johannh)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [proton-door-hangers] [priority:2b])
Attachments
(10 files)
52.18 KB,
image/png
|
Details | |
50.28 KB,
image/png
|
Details | |
152.43 KB,
image/png
|
Details | |
25.78 KB,
image/png
|
Details | |
25.70 KB,
image/png
|
Details | |
641.88 KB,
image/png
|
Details | |
601.82 KB,
image/png
|
Details | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
108.16 KB,
image/png
|
Details | |
19.14 KB,
image/png
|
Details |
Since Bug 1697943 we no longer show text in <b>
tags as bold in permission prompts. This makes the the origin in the requestStorageAccess permission doorhanger really difficult to see. It's important that users can clearly identify the requesting origin in this prompt.
This is a regression of Bug 1697943.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
If we have text that's explicitly set to bold, in this case for security reasons, we should not drop that style.
Romain, do you think this is something we could address for 89? Thanks!
Reporter | ||
Comment 2•4 years ago
|
||
Reporter | ||
Comment 3•4 years ago
|
||
Comment 4•4 years ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #1)
If we have text that's explicitly set to bold, in this case for security reasons, we should not drop that style.
I want to chime in with some extra context. It's important to highlight the requesting origin (as we did in the design in Comment 2) to bring the user's attention to the origin they should be making decisions about. If that origin seems unfamiliar or suspicious given the context, we want the user to take a moment to consider their decision (e.g., "why is social-media.example
requesting something on my bank's website"). Given the amount of text, it seems like someone could skim over when the entire prompt is bold.
Comment 5•4 years ago
|
||
Drive-by nit: shouldn't we be using <strong>
to markup important things?
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Paul, can you please help me understand how to trigger this panel? I don't think it was part of the designed panels, is this active on release?
ccing Tyler for visibility
Reporter | ||
Comment 7•4 years ago
•
|
||
We show the prompt when an embedded 3rd-party site calls requestStorageAccess
via the Storage Access API. The prompt is shown when state partitioning is enabled. In release that's the case for users who have strict tracking protection enabled (FX 86) and in private browsing (FX 89).
We automatically allow up to 5 concurrent grants without showing a prompt.
You can see the prompt if you set dom.storage_access.max_concurrent_auto_grants
to 0 and click "requestStorageAccess" in the third frame on this test site: https://senglehardt.com/test/dfpi/storage_access_api.html
Comment 8•4 years ago
|
||
I was able to replicate this. For some permissions panels, including this one, they only had styling changes applied for MR1 and nothing else. There wasn't a complete rework. I'm not sure why the bold is not being respected, but this does appear to be a regression and should be fixed.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 9•4 years ago
|
||
The bold is not being respected because the spec calls for the first line of our permission panels to be a uniform boldness. This was done in bug 1697943.
Please see the Figma specification for how the "example.com" domain is treated in each of the permission panels.
Over to KatieC if this is a decision we want to revisit.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Permission panels (like modals) MR1 spec update the title / the first line as a heavier weight than the body copy. The screenshot in Comment 3, doesn't look like it's following other MR1 button string updates Block / Allow - this signals it was not part of the review and initial set/scope of Permission Panels? I differ to Tyler on that.
Thanks for sharing a screenshot for the UX team.
Meridel will take a quick ux review...
Comment 11•4 years ago
|
||
Indeed, the previous content and design do not work well with MR1 styling applied, and looking at this works many months later, I do see ways this can be tightened.
Below is a revised version of the prompt. Is it in scope to make these changes (assuming Arthur and Steven sign off on the updates), either now (I assume it is too late for string changes), or in MR1.1 ?
Comment 12•4 years ago
|
||
To make things easier-to-access, here's a screenshot of what I propose. Arthur, I think this is much better than what we had previously— more concise and still makes clear what is happening.
Assignee | ||
Comment 13•4 years ago
|
||
I like the new version, a few thoughts:
- Still a bit concerned that the origin isn't highlighted but not as big of a concern anymore.
- I like "you may want to block access if it's not clear why this data is needed" a lot!!
- I'm really not sure if people get what "cross-site' cookies and site data is.
Comment 14•4 years ago
|
||
Overall I like the simplified text, this is much more readable! I agree with Johann that we should still bold the requesting origin (i.e. amazonpay.com
in Comment 12).
Comment 15•4 years ago
|
||
Marking Meridel as needinfo so she can see the feedback from Johann and Steven. I'll follow-up in Slack with Arthur today and bring this to his attention, but this is out of scope for MR1. I think this will need to happen in MR1.1
Comment 16•4 years ago
|
||
I agree with Johann's comments. The second paragraph text is great; I'm wondering some of that verbage could be used in the title. Something like "Allow amazonpay.com to see what you do on oldnavy.com?" And then maybe the paragraph could mention cookies and site data.
Assignee | ||
Comment 17•4 years ago
|
||
Allow amazonpay.com to see what you do on oldnavy.com
I feel like that is a bit misleading, because "see what you do" can be misinterpreted in various ways, e.g. to think about screen sharing, which this clearly isn't. Full access to all information on the first party matches our own adversarial worst case of a first and third party cooperating, but I'm not sure we can impress that on the user. In this case it doesn't apply, for example. Amazon Pay isn't interested in seeing what you do on oldnavy.com, but a user might be hesitant to give it permission to do so, even when they initiated the request for Amazon Pay.
Conversely, it also doesn't fully capture the threat of tracking across sites. I don't necessarily mind whether a third party could observe my interactions on a certain site (and they can already do so without storage access), I do mind the fact that it's using my presence on the site to build an advertising profile through access to cross-site cookies.
I still think we should focus on cookie/data access in the title in some way :)
Comment 18•4 years ago
|
||
Can you help refresh my memory— why is it that we call out 'site data' here? I agree this is confusing.
Assignee | ||
Comment 19•4 years ago
|
||
Because there's much more information than just cookies being stored, but I guess at this point that's an irrelevant detail to most people, if you feel like just using "cookies" would be more understandable, feel free to change it. :)
Comment 20•4 years ago
|
||
I checked and we use only "cross-site cookies" as our umbrella term in the site information panel header. I think we can do the same here. Here is the final version. Arthur, please confirm sign-off and then I will get legal approval.
Comment 21•4 years ago
|
||
Caught a tiny typo. Updated screenshot for your review.
Assignee | ||
Comment 22•4 years ago
•
|
||
Sorry, another idea to deal with "cross-site cookies" not being super intuitive for users, how about:
Allow amazonpay.com to track you on this site?
amazonpay.com is requesting access to cross-site cookies that can be used to track what you do on oldnavy.com. You may want to block access if it's not clear why this data is needed.
Also, while we're bikeshedding, I wonder how much this sentence really helps:
You may want to block access if it's not clear why this data is needed.
Maybe we could refactor it to
You should block access if you're not familiar with amazonpay.com
Since the requesting party should have introduced itself in-content in some way.
Thoughts?
Comment 23•4 years ago
|
||
Hi, Can someone confirm if this has been uplifted for MR1/89 release OR we slipping this to 90?
Comment 24•4 years ago
|
||
Hi prangya,
I'm not sure what you mean. There's no fix in this bug, so nothing has been landed in 90 or uplifted to 89.
If you mean the original regressor (bug 1697943), that is in both 89 and 90. At this point, unless Product or Security deems this a P1, I believe any fix that lands in this bug will not be uplifted to 89.
Comment 25•4 years ago
|
||
Thanks, Johann. Since these strings won't land until after 89, I am happy to iterate a bit.
Re: "Allow amazonpay.com to track you on this site?" I like this plainer language but I see two issues:
- I did not think that the requesting site was definitely going to track you — only that it "could," and I assumed if a site did track your activity it was more likely to be a bad actor, and that bad actors are on the rare side. Is that correct?
- I suspect asking the question in that way will lead more users to decline access, when this is not necessarily what we want users to do since the vast majority of requests are innocuous.
Re: "You should block access if you're not familiar with amazonpay.com." I prefer the specificity of "You may want to block access if it's not clear why this data is needed.", and I am trying to avoid repeating the third-party domain name multiple times in the panel.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 26•4 years ago
|
||
Sorry for the delayed response, but we should still really get this changed!
(In reply to Meridel [:meridel] from comment #25)
Thanks, Johann. Since these strings won't land until after 89, I am happy to iterate a bit.
Re: "Allow amazonpay.com to track you on this site?" I like this plainer language but I see two issues:
- I did not think that the requesting site was definitely going to track you — only that it "could," and I assumed if a site did track your activity it was more likely to be a bad actor, and that bad actors are on the rare side. Is that correct?
- I suspect asking the question in that way will lead more users to decline access, when this is not necessarily what we want users to do since the vast majority of requests are innocuous.
I mean, the prompt is shown very rarely in innocuous cases since they'd have to beat the "5 sites for free" heuristics first, and I think it's important to inform the user of this possibility. However, I agree that "allow x to track you" may be misrepresenting the intent of most callers. See suggestion below for a more accurate description.
Re: "You should block access if you're not familiar with amazonpay.com." I prefer the specificity of "You may want to block access if it's not clear why this data is needed.", and I am trying to avoid repeating the third-party domain name multiple times in the panel.
I really like having this sentence overall, but since we removed "and site data" from the title, it's unclear what "why this data is needed" is referring to (the title in your prompt just says "cross-site cookies" which I don't think all users will immediately connect to "data").
Another suggestion:
Allow amazonpay.com to access data that can identify you across websites?
amazonpay.com is requesting access to cross-site cookies that can be used to share data between oldnavy.com and other websites, possibly tracking your activity. You should block access if it's not clear why access to this data is needed.
Would be cool to have another user study...
Comment 27•4 years ago
|
||
I'd like to keep the header shorter and simpler, relying on the body copy and 'Learn more' for details. How about this?
Allow amazonpay.com to access data about you?
amazonpay.com is requesting access to cross-site cookies, which can be used to track you across websites. You should block access if it's not clear why this data is needed.
Agree it would be nice to have a user research study but we would need someone to staff from UR — I'm not able to provide that level of support right now, unfortunately. On that note, can we have telemetry available to see if this phrasing change impacts what people do with this modal (# who select Block vs. Allow). And, are we able to tell how many of the requests are malicious? (I assume not).
Assignee | ||
Comment 28•4 years ago
|
||
Hmm I don't think that would work, "access data about you" doesn't really capture what this is doing. If you want short then I think I'd rather go back to "cross-site cookies"., but then IMO we'd need to get rid of the last sentence or revise it not to mention data anymore.
Comment 29•4 years ago
•
|
||
Is it that Amazon will be able to track you on Old Navy or that it could track you across sites? Below is the latest, but will revise depending on answer to this question.
Allow amazonpay.com to access cross-site cookies?
You should block access if it's not clear why this is being requested. If you allow access, amazonpay.com may be able to track you across websites.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 30•4 years ago
|
||
Hi Arthur, after some back-and-forth here in the thread, this is my recommendation — balancing brevity with clarity within the confines of the new panel design. Please review.
Comment 31•4 years ago
|
||
I'm afraid this prompt does not make it clear the grant is scoped to oldnavy.com.
Comment 32•4 years ago
|
||
I thought by granting access to use cross-site cookies, the third party domain COULD then get access to cross-site cookies on other sites (and not just oldnavy.com). Is that true?
Comment 33•4 years ago
|
||
I hope that's not true, but I see that Johann didn't address your question in comment 29 (at least not in this bug).
What it thus far has meant is that amazonpay.com would get access to the same cookies when embedded on oldnavy.com as it would get when you visit amazonpay.com directly. But it would not mean that if you then visit xyz.com which also embeds amazonpay.com that amazonpay.com would get access to those cookies there (and you would likely see another prompt, if you end up in the same kind of checkout flow).
Comment 34•4 years ago
|
||
Thank you — that's helpful.
Johann, to make sure I am clear about what potential tracking risk there is, please answer this: Is it true that granting the third party domain access to cross-site cookies means that the third party domain could then track you across other websites if it wanted to? Or is the tracking restricted to oldnavy.com?
Reporter | ||
Comment 35•4 years ago
•
|
||
(In reply to Meridel [:meridel] from comment #34)
Thank you — that's helpful.
Johann, to make sure I am clear about what potential tracking risk there is, please answer this: Is it true that granting the third party domain access to cross-site cookies means that the third party domain could then track you across other websites if it wanted to? Or is the tracking restricted to oldnavy.com?
The storage access is restricted to oldnavy.com. The third-party would need to request storage access again, if it needs access under a different top level site.
This is implemented with the 3rdPartyStorage
permission, which is double keyed. For example oldnavy.com
would set the permission 3rdPartyStorage^https://amazonpay.com
Comment 36•4 years ago
|
||
Options updated based on this clarification.
I am wondering if we can simplify further, removing the line "If you allow access, amazonpay.com may be able to track what you do on this site." I don't think this line adds a lot of clarity ("track me how"?), and by saying why you should block access, perhaps we have given enough information for the user to make an informed decision.
Comment 37•4 years ago
|
||
Thanks Meridel! I like Option 2 personally. Short and to the point and puts the onus clearly on the site to make things clear.
Assignee | ||
Comment 38•4 years ago
|
||
Agree with Anne, this should work! Thanks so much! We have this on our list for 93.
Comment 39•4 years ago
|
||
Great! Arthur, do we have the greenlight from you on Option 2?
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 40•4 years ago
|
||
Updated•4 years ago
|
Comment 41•4 years ago
|
||
I belatedly realized that Option 2 doesn't address the scope concern I brought up in comment 31. So I think we need something like (Option 3):
Allow A to access its cross-site cookies on B?
You should block access if it’s not clear why this is being requested for B.
I think we could remove "cross-site" from this language thereby shorten it to (Option 4):
Allow A to access its cookies on B?
You should block access if it’s not clear why this is being requested for B.
(I don't think "cross-site" adds a lot of value here and technically these are the "first-party" cookies.)
I also have this slightly shorter alternative for the second sentence (Option Xb):
You should block access if it's not clear why B needs this.
Comment 42•4 years ago
•
|
||
(In reply to Meridel [:meridel] from comment #39)
Great! Arthur, do we have the greenlight from you on Option 2?
Still discussing this within the team.
Assignee | ||
Comment 43•4 years ago
•
|
||
Sorry for backtracking on this, but we just discussed the prompts in our anti-tracking meeting and think that option 4) or 4b) from Anne (in Comment 41) are best, because:
- "Cross-site" could imply that the requestor is getting access to all "foreign" cookies, no just its own cross-site cookies
- The scope that applies to the grant is unclear, it's just on oldnavy.com
- This could work better with potential out-of-scope grants e.g. as proposed in https://github.com/privacycg/storage-access/issues/83#issuecomment-877310438 where the target origin (the scope) isn't visible in the URL bar.
Meridel, Arthur, would you be okay with either option 4) or 4b)? Which do you prefer?
Comment 44•4 years ago
|
||
Thanks, Johann. I tried option 4) and that was a bit of a mouthful for the title. I agree "cross-site cookies" is confusing, but it is currently the terminology we use in Preferences and elsewhere so it may be helpful to continue to use it here until we make a larger terminology change. I am good with either of these two versions. Arthur, please advise.
Comment 45•4 years ago
|
||
Reviewed versions with Arthur. Here is the final. I will share with legal on Monday. Please let me know if any concerns!
Comment 47•4 years ago
|
||
Comment 48•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 49•3 years ago
|
||
Is this something we should uplift to ESR91 still? Presumably we'd need to also bump l10n-changesets.json if we did?
Comment 50•3 years ago
|
||
For the latter, we would need to uplift localization changes (i.e. uplift l10n-changesets.json).
Updated•3 years ago
|
Description
•