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)
Toolkit Graveyard
Notifications and Alerts
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ethan, Assigned: jsavory)
References
Details
(Whiteboard: [tor][fingerprinting][fp:m3][ux])
Attachments
(4 files, 3 obsolete files)
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?"
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Comment 1•7 years ago
|
||
Hi Jacqueline,
Per our discussion in SF work week, could you provide your design in this bug?
Flags: needinfo?(jsavory)
Comment 2•7 years ago
|
||
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.
Reporter | ||
Comment 3•7 years ago
|
||
(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)
Comment 4•7 years ago
|
||
This is the screenshot before addressing Johann's latest review comments.
Attachment #8887783 -
Attachment is obsolete: true
Flags: needinfo?(jhao)
Assignee | ||
Comment 5•7 years ago
|
||
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)
Comment 6•7 years ago
|
||
(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! :)
Reporter | ||
Comment 7•7 years ago
|
||
(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
Reporter | ||
Comment 8•7 years ago
|
||
(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)
Reporter | ||
Updated•7 years ago
|
Whiteboard: [tor][fingerprinting][fp:m2] → [tor][fingerprinting][fp:m3]
Assignee | ||
Comment 9•7 years ago
|
||
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)
Comment 10•7 years ago
|
||
svg icon to be used in the permissions panel. The colour should be set to #646464. Thanks!
Flags: needinfo?(epang)
Reporter | ||
Updated•7 years ago
|
Whiteboard: [tor][fingerprinting][fp:m3] → [tor][fingerprinting][fp:m3][ux]
Comment 11•7 years ago
|
||
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)
Reporter | ||
Comment 12•7 years ago
|
||
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?
Comment 13•7 years ago
|
||
This is how it looks like now.
Comment 14•7 years ago
|
||
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.
Reporter | ||
Comment 15•7 years ago
|
||
(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.
Reporter | ||
Comment 16•7 years ago
|
||
(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.
Reporter | ||
Comment 17•7 years ago
|
||
(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
Reporter | ||
Comment 18•7 years ago
|
||
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)
Assignee | ||
Comment 19•7 years ago
|
||
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)
Reporter | ||
Comment 20•7 years ago
|
||
(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.
Reporter | ||
Comment 21•7 years ago
|
||
Close this bug since Jacqueline and Eric already provided us the UX design.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment 22•7 years ago
|
||
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 → ---
Comment 23•7 years ago
|
||
(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)
Comment 24•7 years ago
|
||
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)
Comment 25•7 years ago
|
||
(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.
Comment 26•7 years ago
|
||
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 ago → 7 years ago
Resolution: --- → FIXED
Comment 27•7 years ago
|
||
> 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)
Updated•7 years ago
|
Status: RESOLVED → VERIFIED
Updated•1 year ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•