Closed Bug 1706425 Opened 5 months ago Closed 1 month ago

Requesting origin in requestStorageAccess prompt is no longer highlighted

Categories

(Firefox :: Site Permissions, defect, P2)

defect
Points:
1

Tracking

()

RESOLVED FIXED
93 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- affected
firefox87 --- unaffected
firefox88 --- unaffected
firefox89 --- wontfix
firefox90 --- wontfix
firefox91 --- wontfix
firefox92 --- wontfix
firefox93 --- fixed

People

(Reporter: pbz, Assigned: johannh)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression, Whiteboard: [proton-door-hangers] [priority:2b])

Attachments

(10 files)

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.

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!

Flags: needinfo?(rtestard)
Attached image before.png
Attached image after.png

(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.

Drive-by nit: shouldn't we be using <strong> to markup important things?

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

Flags: needinfo?(rtestard) → needinfo?(pbz)

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

Flags: needinfo?(pbz)

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.

Priority: P1 → P2
Whiteboard: [proton-door-hangers] [priority:2a]
Flags: needinfo?(mconley)

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.

Flags: needinfo?(mconley) → needinfo?(kcaldwell)

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...

Flags: needinfo?(kcaldwell) → needinfo?(mwalkington)

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 ?

https://docs.google.com/presentation/d/1OWIVLOVyWHmqr385W6KSA_HupFa7m3XfCwmkKJZacBs/edit#slide=id.gd545ddb80b_0_0

Flags: needinfo?(mwalkington) → needinfo?(tduzan)

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.

Flags: needinfo?(arthur)

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.

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).

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

Flags: needinfo?(tduzan) → needinfo?(mwalkington)

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.

Flags: needinfo?(arthur)

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 :)

Can you help refresh my memory— why is it that we call out 'site data' here? I agree this is confusing.

Flags: needinfo?(mwalkington) → needinfo?(jhofmann)

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. :)

Flags: needinfo?(jhofmann)

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.

Flags: needinfo?(arthur)

Caught a tiny typo. Updated screenshot for your review.

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?

Flags: needinfo?(mwalkington)

Hi, Can someone confirm if this has been uplifted for MR1/89 release OR we slipping this to 90?

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.

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:

  1. 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?
  2. 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.

Flags: needinfo?(mwalkington) → needinfo?(jhofmann)
Whiteboard: [proton-door-hangers] [priority:2a] → [proton-door-hangers] [priority:2b]

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:

  1. 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?
  2. 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...

Flags: needinfo?(jhofmann) → needinfo?(mwalkington)

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).

Flags: needinfo?(mwalkington) → needinfo?(jhofmann)

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.

Flags: needinfo?(jhofmann)

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.

Flags: needinfo?(jhofmann)
Blocks: dfpi-hq
Flags: needinfo?(jhofmann)

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.

I'm afraid this prompt does not make it clear the grant is scoped to oldnavy.com.

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?

Flags: needinfo?(annevk)

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).

Flags: needinfo?(annevk)

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?

Flags: needinfo?(jhofmann)

(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

Flags: needinfo?(jhofmann)

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.

Thanks Meridel! I like Option 2 personally. Short and to the point and puts the onus clearly on the site to make things clear.

Agree with Anne, this should work! Thanks so much! We have this on our list for 93.

Great! Arthur, do we have the greenlight from you on Option 2?

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Points: --- → 1

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.

(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.

Flags: needinfo?(arthur)

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?

Flags: needinfo?(mwalkington)
Flags: needinfo?(arthur)

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.

Flags: needinfo?(mwalkington)

Reviewed versions with Arthur. Here is the final. I will share with legal on Monday. Please let me know if any concerns!

Flags: needinfo?(jhofmann)

Legal approved the new version.

Flags: needinfo?(arthur)
Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4b33267c5cf5
Simplify requestStorageAccess prompt. r=pbz,flod
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
Flags: needinfo?(jhofmann)
You need to log in before you can comment on or make changes to this bug.