1706425 - Requesting origin in requestStorageAccess prompt is no longer highlighted

Status: RESOLVED FIXED

(Firefox :: Site Permissions, defect, P2)

Description

[Paul Zühlcke [:pbz]]

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.

Comment 1

[Paul Zühlcke [:pbz]]

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!

Comment 2

[Paul Zühlcke [:pbz]]

Attachment: before.png

Comment 3

[Paul Zühlcke [:pbz]]

Attachment: after.png

Comment 4

[Steven Englehardt [:englehardt]]

(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

[Anne (:annevk)]

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

Comment 6

[Romain Testard [:RT]]

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

Comment 7

[Paul Zühlcke [: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

Comment 8

[Tyler Duzan]

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.

Comment 9

[Mike Conley (: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.

Comment 10

[katieC]

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

[Meridel [:meridel]]

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

Comment 12

[Meridel [:meridel]]

Attachment: Screen Shot 2021-04-26 at 2.50.35 PM.png

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.

Comment 13

[Johann Hofmann [:johannh]]

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

[Steven Englehardt [:englehardt]]

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

[Tyler Duzan]

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

[Arthur Edelstein [:arthur]]

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.

Comment 17

[Johann Hofmann [:johannh]]

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

[Meridel [:meridel]]

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

Comment 19

[Johann Hofmann [:johannh]]

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

[Meridel [:meridel]]

Attachment: Storage Access Final.png

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

[Meridel [:meridel]]

Attachment: Storage Access 4.30 Final.png

Caught a tiny typo. Updated screenshot for your review.

Comment 22

[Johann Hofmann [:johannh]]

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

[prangya]

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

Comment 24

[Mike Conley (:mconley) (:⚙️)]

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

[Meridel [:meridel]]

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.

Comment 26

[Johann Hofmann [:johannh]]

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

Comment 27

[Meridel [:meridel]]

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

Comment 28

[Johann Hofmann [:johannh]]

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

[Meridel [:meridel]]

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.

Comment 30

[Meridel [:meridel]]

Attachment: Storage Access Prompt Versions July 2021.png

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

[Anne (:annevk)]

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

Comment 32

[Meridel [:meridel]]

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

[Anne (: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).

Comment 34

[Meridel [:meridel]]

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?

Comment 35

[Paul Zühlcke [:pbz]]

(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

[Meridel [:meridel]]

Attachment: Storage Access Prompt, two options, Simplified .png

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

[Anne (:annevk)]

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

Comment 38

[Johann Hofmann [:johannh]]

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

Comment 39

[Meridel [:meridel]]

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

Comment 40

[Johann Hofmann [:johannh]]

Attachment: Bug 1706425 - Simplify requestStorageAccess prompt. r=pbz

Comment 41

[Anne (:annevk)]

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

[Arthur Edelstein [:arthur]]

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

Comment 43

[Johann Hofmann [:johannh]]

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

[Meridel [:meridel]]

Attachment: New options August 9, 2021.png

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

[Meridel [:meridel]]

Attachment: Final prompt_August 13.png

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

Comment 46

[Meridel [:meridel]]

Legal approved the new version.

Comment 47

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b33267c5cf5
Simplify requestStorageAccess prompt. r=pbz,flod

Comment 48

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/4b33267c5cf5

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Is this something we should uplift to ESR91 still? Presumably we'd need to also bump l10n-changesets.json if we did?

Comment 50

[Francesco Lodolo [:flod]]

For the latter, we would need to uplift localization changes (i.e. uplift l10n-changesets.json).

Comment 51

[Paul Zühlcke [:pbz]]

We don't have to uplift this to ESR.