Closed Bug 1382111 Opened 7 years ago Closed 7 years ago

UX improvement for permission prompt to allow extracting HTML5 Canvas data

Categories

(Toolkit Graveyard :: Notifications and Alerts, enhancement, P2)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ethan, Assigned: jsavory)

References

Details

(Whiteboard: [tor][fingerprinting][fp:m3][ux])

Attachments

(4 files, 3 obsolete files)

Attached image prompt_for_html5_canvas.png (obsolete) —
In order to reduce the fingerprinting threat from HTML5 Canvas image extraction, we have a patch (in bug 967895) to prompt before returning valid image data to the Canvas APIs. The current patch was based on the Tor Browser, and we need to adapt it to the Firefox template for permission prompts in terms of layout and style. Our UX design also wants to consider rewording some of the messaging as the particular case might be difficult for users to understand. We should be as clear as possible. The attached screenshot is the current permission prompt. The current message: "This website (<hostname>) attempted to extract HTML5 canvas image data, which may be used to uniquely identify your computer.\n\nShould <brandShortName> allow this website to extract HTML5 canvas image data?"
Blocks: 967895
Priority: -- → P2
Whiteboard: [tor][fingerprinting][fp:m2]
Hi Jacqueline, Per our discussion in SF work week, could you provide your design in this bug?
Flags: needinfo?(jsavory)
FYI, the doorhangers that will come out of bug 967895 should look much different than attachment 8887783 [details] and pretty much the same as the current permission doorhangers (same styling, same set of options with a checkbox, slightly improved logo). I guess the primary message and the logo could still use some love, though. Let me know if you have any questions.
(In reply to Johann Hofmann [:johannh] from comment #2) > FYI, the doorhangers that will come out of bug 967895 should look much > different than attachment 8887783 [details] and pretty much the same as the > current permission doorhangers (same styling, same set of options with a > checkbox, slightly improved logo). Thanks for pointing out this, Johann. Jonathan, could you update the screenshot here using your patch in bug 967895?
Flags: needinfo?(jhao)
This is the screenshot before addressing Johann's latest review comments.
Attachment #8887783 - Attachment is obsolete: true
Flags: needinfo?(jhao)
Attached image ImagePermission_V1.png (obsolete) —
Sorry for the delay, I've attached an image of how the prompt could look. I've taken out some of the text as I'm thinking that it might make more sense to have that text in the preferences page rather than cluttering up the permission prompt. Let me know if anyone has any changes they would recommend for this prompt. I have a question about the preferences page, from my understanding this is a form of fingerprinting protection, but I wasn't sure if we would label it as such since it is only one aspect of fingerprint protection? Or should we just use the term "HTML5 Image canvas data" in the prefs until we have a more complete form of fingerprint protection? Sorry for the questions, I'm just not sure I completely understand how all of this works yet :) In terms of the icon, I am working with a visual designer who can create an icon, but he and I are both on PTO next week, so it will be ready the week after. Thanks!
Flags: needinfo?(jsavory)
(In reply to Jacqueline Savory [:jsavory] UX from comment #5) > Sorry for the delay, I've attached an image of how the prompt could look. > I've taken out some of the text as I'm thinking that it might make more > sense to have that text in the preferences page rather than cluttering up > the permission prompt. Let me know if anyone has any changes they would > recommend for this prompt. Hi Jacqueline -- thanks for your work on this! I would like to suggest mentioning "tracking" or "fingerprinting" in this prompt so that users understand the risk in allowing canvas image extraction (and the purpose for showing the prompt). > I have a question about the preferences page, from my understanding this is > a form of fingerprinting protection, but I wasn't sure if we would label it > as such since it is only one aspect of fingerprint protection? Or should we > just use the term "HTML5 Image canvas data" in the prefs until we have a > more complete form of fingerprint protection? Sorry for the questions, I'm > just not sure I completely understand how all of this works yet :) As part of uplifting Tor Browser's anti-fingerprinting protections, we introduced a single boolean pref, "privacy.resistFingerprinting" that is false by default. Flipping this pref to true turns on all fingerprinting protections (including the canvas prompt) together. Our reason for introducing this single controlling pref is that anti-fingerprinting protections aren't useful in isolation -- they need to be operating together to be effective (plugging all the leaks at once). So, for the preferences page, in bug 1308340 we have proposed a checkbox to let the user control the "privacy.resistFingerprinting" pref. > In terms of the icon, I am working with a visual designer who can create an > icon, but he and I are both on PTO next week, so it will be ready the week > after. I'm excited to see this icon! :)
(In reply to Jacqueline Savory [:jsavory] UX from comment #5) > Sorry for the delay, I've attached an image of how the prompt could look. > I've taken out some of the text as I'm thinking that it might make more > sense to have that text in the preferences page rather than cluttering up > the permission prompt. Let me know if anyone has any changes they would > recommend for this prompt. Thanks, Jacqueline. The new prompt looks neat! I am not sure about the process of UX bug. We will need a sign-off for the UX design, won't we?
Assignee: nobody → jsavory
(In reply to Jacqueline Savory [:jsavory] UX from comment #5) > Created attachment 8891680 [details] > ImagePermission_V1.png According to our discussion in a meeting, since fingerprinting resistance is still a hidden feature (behind a pref) in Firefox and there is no UI checkbox, it would be better to mention "tracking" in the prompt so the user can easily realize the danger and why he/she has to make a decision there. Jacqueline will update the design for this. (with the new icon, maybe?)
Flags: needinfo?(jsavory)
Whiteboard: [tor][fingerprinting][fp:m2] → [tor][fingerprinting][fp:m3]
Attached image ImagePermission_V2.png (obsolete) —
I've updated the prompt and added the additional wording 'This may be used to uniquely identify your computer' as I've seen in the original Tor prompt. I think this adds the additional warning but let me know if its needs more. :) NI? Eric - would you be able to provide an icon for this prompt? Thanks!
Attachment #8891680 - Attachment is obsolete: true
Flags: needinfo?(jsavory) → needinfo?(epang)
Attached image image_permission.svg
svg icon to be used in the permissions panel. The colour should be set to #646464. Thanks!
Flags: needinfo?(epang)
Whiteboard: [tor][fingerprinting][fp:m3] → [tor][fingerprinting][fp:m3][ux]
Hi Jacqueline, Thank you for the great design. I'm applying it to bug 967895 but got a question. In attachment 8897596 [details], the host name is styled with bold font. However, it seems that notification messages are rendered by the "label" attribute instead of HTML. http://searchfox.org/mozilla-central/rev/999385a5e8c2d360cc37286882508075fc2078bd/toolkit/modules/PopupNotifications.jsm#769 So I'm afraid that we are not able to change the style of the notification message. Can you accept if the host name is not bold? Besides, if you think of any popup notifications with styled messages, please let me know so that I can try to implement that in our design. Thank you very much.
Flags: needinfo?(jsavory)
Jacqueline, There is another loose end we need to tie up. We have not decided where should the "Learn more..." hyperlink go. Should we create a new help page for that?
This is how it looks like now.
I'm going to make a suggestion everyone is free to ignore. Instead of: "Would you like to allow X to use your canvas image data?" What about: "May X use your canvas image data?" Changes (what I think is) passive voice to active and uses a lot less words. Fewer words, less to read, more likely someone would read it. Obviously an English-centric phrasing, unsure about translations.
(In reply to Tom Ritter [:tjr] from comment #14) > Changes (what I think is) passive voice to active and uses a lot less words. > Fewer words, less to read, more likely someone would read it. Obviously an > English-centric phrasing, unsure about translations. Thanks for the suggestion! Per discussion in the meeting, Jacqueline will update the wording based on the latest permission prompt template.
(In reply to Ethan Tseng [:ethan] from comment #12) > There is another loose end we need to tie up. > We have not decided where should the "Learn more..." hyperlink go. > Should we create a new help page for that? I filed bug 1397757 for this.
(In reply to Chung-Sheng Fu [:cfu] from comment #11) > I'm applying it to bug 967895 but got a question. In attachment 8897596 [details] > [details], the host name is styled with bold font. However, it seems that > notification messages are rendered by the "label" attribute instead of HTML. > So I'm afraid that we are not able to change the style of the notification > message. Can you accept if the host name is not bold? Per Jacqueline, the style with bold font was out-of-date. We don't need to worry about the bold font.
Flags: needinfo?(jsavory)
See Also: → 1397757
Jacqueline, As we discussed in the meeting, you will update the wording to shorten the message. Needinfo for you as a reminder. :)
Flags: needinfo?(jsavory)
Attached image ImagePermission_V3.png
Updated the permission design based on the feedback from our meeting yesterday. Let me know if this covered everything we talked about. I can add the 'Learn more' link back once we have an outcome on whether we have somewhere to link it to.
Attachment #8897596 - Attachment is obsolete: true
Flags: needinfo?(jsavory)
(In reply to Jacqueline Savory [:jsavory] UX from comment #19) > Updated the permission design based on the feedback from our meeting > yesterday. Let me know if this covered everything we talked about. Thanks, Jacqueline. CS, please update your patch accordingly. > I can add the 'Learn more' link back once we have an outcome on whether we > have somewhere to link it to. Sure, bug 1397757 is tracking this.
Close this bug since Jacqueline and Eric already provided us the UX design.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Verification failed on Mac OS 10.12.6 with Nightly 58.0a1 (2017-10-28) (64-bit) Verification steps: ##### Test case 1 ######: 1. Set parameter privacy.resistFingerprinting to true 2. Open a new tab and go to https://browserleaks.com/canvas 3. In the pop-up, *allow* the website to access canvas, and check the checkmark to remember this setting 4. Reload the page 20 times by Shift+reload Expected results: After each page reload, the "Uniqueness" in "Your Fingerprint" section on the website should NOT say "False" Actual results: After some of the reloads, the "Uniqueness" in "Your Fingerprint" section on the website says "False - (Tor Browser signature)", which should not be the case since we allowed the website to retrieve the canvas. Another issue is that there is no easy way to figure out whether this particular site has permission to access the canvas. Normally, I would expect to see this information after clicking the "i" icon in the URL bar, but it only says that "you have not granted this site any special permissions", which is not true because I granted it the permanent permission to access the canvas. How can I deny this website from accessing my canvas in the future? ##### Test case 2 ######: 1. Set parameter privacy.resistFingerprinting to true 2. Open a new tab and go to https://browserleaks.com/canvas 3. In the pop-up, *deny* the website to access canvas, and check the checkmark to remember this setting Expected results: The "Uniqueness" in "Your Fingerprint" section on the website should say "False" Actual results: Even before I had the chance to make the decision whether this website is allowed to access canvas, I can see that the website already got the canvas information. So my choice doesn't matter since the website has already fingerprinted my browser.
Status: RESOLVED → REOPENED
Flags: needinfo?(ettseng)
Resolution: FIXED → ---
(In reply to Tom Grabowski [:TomGrab] from comment #22) > Verification failed on Mac OS 10.12.6 with Nightly 58.0a1 (2017-10-28) > (64-bit) > > Verification steps: > > ##### Test case 1 ######: > 1. Set parameter privacy.resistFingerprinting to true > 2. Open a new tab and go to https://browserleaks.com/canvas > 3. In the pop-up, *allow* the website to access canvas, and check the > checkmark to remember this setting > 4. Reload the page 20 times by Shift+reload > > Expected results: > After each page reload, the "Uniqueness" in "Your Fingerprint" section on > the website should NOT say "False" > > Actual results: > After some of the reloads, the "Uniqueness" in "Your Fingerprint" section on > the website says "False - (Tor Browser signature)", which should not be the > case since we allowed the website to retrieve the canvas. I need some more investigations because the popup never shows for this site on my machine. > Another issue is that there is no easy way to figure out whether this > particular site has permission to access the canvas. Normally, I would > expect to see this information after clicking the "i" icon in the URL bar, > but it only says that "you have not granted this site any special > permissions", which is not true because I granted it the permanent > permission to access the canvas. How can I deny this website from accessing > my canvas in the future? Oh this is a bug. I have prepared a patch fixing this and will send a review request once other problems are also clarified. > ##### Test case 2 ######: > 1. Set parameter privacy.resistFingerprinting to true > 2. Open a new tab and go to https://browserleaks.com/canvas > 3. In the pop-up, *deny* the website to access canvas, and check the > checkmark to remember this setting > > Expected results: > The "Uniqueness" in "Your Fingerprint" section on the website should say > "False" > > Actual results: > Even before I had the chance to make the decision whether this website is > allowed to access canvas, I can see that the website already got the canvas > information. So my choice doesn't matter since the website has already > fingerprinted my browser. Thank you very much for your help!
Flags: needinfo?(ettseng)
We have a check if the canvas data is going to be extracted in third-party domain. http://searchfox.org/mozilla-central/rev/1c4901d060e3953e41088c038b62a0c026c1e1fb/dom/canvas/CanvasUtils.cpp#110 The test creates the canvas in an iframe, whose src is empty. In this case, the first-party URI is https://browserleaks.com/canvas and the document URI of the canvas is about:blank, so it is regarded as third-party and the function returns false (denies the permission) without showing the popup. To be more precise, the ThirdPartyUtil::IsThirdPartyURI function compares the host of the 2 URIs. http://searchfox.org/mozilla-central/rev/1c4901d060e3953e41088c038b62a0c026c1e1fb/dom/base/ThirdPartyUtil.cpp#93 But about:blank has no host and is not a file:// URI, it leads to an error. http://searchfox.org/mozilla-central/rev/1c4901d060e3953e41088c038b62a0c026c1e1fb/dom/base/ThirdPartyUtil.cpp#316 Finally the check reaches this line instead of the isThirdParty block. http://searchfox.org/mozilla-central/rev/1c4901d060e3953e41088c038b62a0c026c1e1fb/dom/canvas/CanvasUtils.cpp#111 In conclusion, https://browserleaks.com/canvas should not make the canvas popup show, and Uniqueness should always be "False (Tor Browser signature)". Hi Tom, According to your test steps, it seems that the canvas popup shows when you visit the site. Could you please help check that again? If you need other sites for test, please try this: https://amiunique.org/fp. Once it finished running the script, please click "View more details" and find the "Canvas" row. You can check if it is just filled with white color. Here are some tips: 1. When you first visit the site, the popup will show. No matter what you choose, the canvas will be a white rectangle this time. 2. If you choose *allow* and then refresh the page, the canvas will NOT be a white rectangle. 3. If you choose *deny* and then refresh the page, the canvas will be a white rectangle. Besides, should I upload the patch that makes canvas permissions visible in page information panel to this bug, Bug 967895, or a new bug?
Flags: needinfo?(tgrabowski)
(In reply to Chung-Sheng Fu [:cfu] from comment #24) > In conclusion, https://browserleaks.com/canvas should not make the canvas > popup show, and Uniqueness should always be "False (Tor Browser signature)". > > > Hi Tom, > > According to your test steps, it seems that the canvas popup shows when you > visit the site. Could you please help check that again? Tried with the latest Tor Browser (7.0.8) and the popup doesn't show either, so I think this is an expected behavior. > Besides, should I upload the patch that makes canvas permissions visible in > page information panel to this bug, Bug 967895, or a new bug? Bug 1413780 is filed for this.
This bug doesn't have to be open for this discussion. In general, please move your discussion to follow-up bugs. The correct bug to block is bug 967895, not this one. This bug was about improvements to the user interface of the prompt.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
> According to your test steps, it seems that the canvas popup shows when you > visit the site. Could you please help check that again? I tested it multiple times and I cannot see the popup anymore. Although I'm sure I saw it a few days ago when I was testing it. The only explanation I have at this point is that they have changed the code on that website. Maybe they were updating something there at that time. > If you need other sites for test, please try this: https://amiunique.org/fp. > Once it finished running the script, please click "View more details" and > find the "Canvas" row. You can check if it is just filled with white color. > Here are some tips: > 1. When you first visit the site, the popup will show. No matter what you > choose, the canvas will be a white rectangle this time. > 2. If you choose *allow* and then refresh the page, the canvas will NOT be a > white rectangle. > 3. If you choose *deny* and then refresh the page, the canvas will be a > white rectangle. Works exactly as described here. All good.
Flags: needinfo?(tgrabowski)
Status: RESOLVED → VERIFIED
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: