Opened 7 years ago

Closed 5 years ago

#7265 closed enhancement (fixed)

Only display Canvas message for first parties; simply log third parties

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: Firefox Patch Issues Version:
Severity: Keywords: tbb-fingerprinting, tbb-bounty, TorBrowserTeam201408, MikePerry201408R
Cc: gk, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #6253, we created a prompt before allowing sites to extract image data from the HTML5 canvas. We did this for fingerprinting reasons.

However, since deploying that patch, I have noticed the warning on at least two random sites.

Unfortunately, the warning is not reproducible, and likely came from a particular 3rd party advertising network. Extra unfortunately, we display only the first party URL in the warning, for usability reasons and for first party-jailed content permissions.

We should provide some mouseover tooltip or other way of determining the full third party url in such warning boxes.

We need to be careful that such a notification does not clutter the warning box or confuse users, and we also need to be mindful of string updates, since the strings are stored in Torbutton but are used in Tor Browser (for translation expedience).

Child Tickets

Attachments (1)

7265-diffs.txt (2.9 KB) - added by mcs 6 years ago.
proposed fix

Download all attachments as: .zip

Change History (22)

comment:1 Changed 7 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 6 years ago by mikeperry

Summary: Canvas extraction message should provide path to full urlOnly display Canvas message for first parties; simply log third parties

In #7084, proper points out this message is frequent and annoying. He's right. Perhaps only displaying it for first party URLs would be an improvement. We can then just silently block and log third parties to the error console.

It might also be that we have a false positive in this patch and that one of these APIs that cause this prompting isn't actually being used to extract image data. It does seem weird that it is so prevalent. For example, why does github trigger this message?

comment:3 Changed 6 years ago by mcs

Cc: brade added

comment:4 Changed 6 years ago by mcs

Kathy Brade and I could not figure out how to trigger the canvas prompt on github (or on any other site that you would not expect to be using canvas) but blocking and logging attempted access by third parties sounds like the way to go. I will post a patch in a moment.

Changed 6 years ago by mcs

Attachment: 7265-diffs.txt added

proposed fix

comment:5 Changed 6 years ago by mikeperry

Keywords: MikePerry201306 added
Status: newneeds_review

comment:6 Changed 6 years ago by mikeperry

Nearly every github project URL caused me to get a canvas prompt. Or at least it did until today. Perhaps they changed their site? I wonder if we had anything to do with that.

I will keep an eye out for other websites.

I've also noticed that PDF.js uses the canvas for image-heavy PDFs (for example, scroll midway through http://freehaven.net/~arma/slides-dimacs13.pdf in a TBB that has PDF.js installed, such as a Gitian build). It would be nice to find some way to allow PDF.js to use the canvas without allowing the website hosting the PDF to do so..

comment:7 Changed 6 years ago by mikeperry

Keywords: MikePerry201307 added; MikePerry201306 removed

comment:8 in reply to:  6 ; Changed 6 years ago by gk

Replying to mikeperry:

Nearly every github project URL caused me to get a canvas prompt. Or at least it did until today. Perhaps they changed their site? I wonder if we had anything to do with that.

I will keep an eye out for other websites.

http://getfoxyproxy.org/
http://foundation.zurb.com/

But I am still not sure what exactly is causing the prompts in these cases. On the FoxyProxy page that is probably due to Modernizr which checks browser features. But even there a cursory glimpse at the source code did not convince me that this is not a false positive. I don't have a clue why the prompt is shown on foundation.zurb.com yet.

comment:9 in reply to:  8 Changed 6 years ago by mcs

Replying to gk:

http://getfoxyproxy.org/
http://foundation.zurb.com/

But I am still not sure what exactly is causing the prompts in these cases. On the FoxyProxy page that is probably due to Modernizr which checks browser features. But even there a cursory glimpse at the source code did not convince me that this is not a false positive. I don't have a clue why the prompt is shown on foundation.zurb.com yet.

It looks like both of those sites use a JS framework named Foundation or a close relative (see http://foundation.zurb.com/). That framework uses a canvas to render some text and then uses toDataURL() to grab an image of it... so this is not a false positive.

comment:10 Changed 6 years ago by mikeperry

Keywords: MikePerry201309 added; MikePerry201307 removed
Status: needs_reviewneeds_revision

Hrmm, well if there are third parties actually doing this to track people, perhaps we do want this doorhanger to bring it to their attention, and also log the actual url/script responsible as well..

I can try to fix this up around September.

comment:11 Changed 6 years ago by mikeperry

Keywords: MikePerry201309 removed

comment:12 Changed 5 years ago by arma

This warning sure does seem to be happening a lot lately. For example,
http://www.politico.com/magazine/story/2014/01/tsa-screener-confession-102912.html
triggers it consistently (at least this week).

And the issue came up on the blog comments too:
https://blog.torproject.org/blog/tor-browser-351-released#comment-46455

This warning message is scary and confusing and doesn't tell me what to do. Do you really want users to report such URLs to the EFF? Even with all these apparent false positives? If so, that sounds like a job for an opt-in about:config setting, for users who want to play that game.

comment:13 Changed 5 years ago by cypherpunks

Just for your information:

It is really annoying that this canvas warning box almost always appears on youtube.com. It seems to be an usability killer, at least on youtube.

comment:14 Changed 5 years ago by cypherpunks

With Tor Browser 3.6.2, the warning box about "canvas image data extraction" shows up extremely often. That's bad for user experience.

comment:15 Changed 5 years ago by gk

Cc: gk added; g.koppen@… removed

comment:16 Changed 5 years ago by cypherpunks

As recent media coverage reminds us, canvas fingerprinting is a more and more pervasive tracking method. TorBrowser aims to protect its users against that attack. But it would be even better, if this annoying info box disappeared. Is there any progress on that issue?

comment:17 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201408 MikePerry201408R added

Yes, I think we should reconsider merging this patch to limit display for third parties.

comment:18 Changed 5 years ago by mikeperry

Status: needs_revisionneeds_review

comment:19 in reply to:  10 ; Changed 5 years ago by isis

Replying to mikeperry:

Hrmm, well if there are third parties actually doing this to track people, perhaps we do want this doorhanger to bring it to their attention, and also log the actual url/script responsible as well..

I can try to fix this up around September.


I've revised Pearl Crescent's logging patch to log all attempts to access HTML5 canvas data, not only log third parties. My revision is in my bug12684-with-bug7265-patch branch, and it's based on my changes for #12684.

I've tested it, and I think it still needs revision, as firstPartySpec.get() and docSpec.get() always seem to produce the same value (at least in the ~10 websites I tested). I know that some of these are third party scripts trying to access the canvas, and others are possibly third party sourced into the first party's domain, others are first party... meaning that this patch as it stands is unable to detect the difference, and users are still shown the HTML5 canvas permissions popup.

comment:20 in reply to:  19 Changed 5 years ago by isis

Replying to isis:

I've tested it, and I think it still needs revision, as firstPartySpec.get() and docSpec.get() always seem to produce the same value (at least in the ~10 websites I tested). I know that some of these are third party scripts trying to access the canvas, and others are possibly third party sourced into the first party's domain, others are first party... meaning that this patch as it stands is unable to detect the difference, and users are still shown the HTML5 canvas permissions popup.


I fiddled with this over the weekend, trying to produce some C++ object which would tell me the location of the script which triggered the HTML5 canvas data access popup, and I produced a nasty thing that casts to a nsJSPrinciple... in the end it produced the same URIs as firstPartySpec.get() and docSpec.get().

I don't know my way around Firefox's crazy C++ yet. Please halp?!?!

comment:21 Changed 5 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok, I merged this and added a commit to log the actual script involved. I found an example in some other CSP logging code that uses JSContexts.

While I was at it, I added a commit to improve the GetFirstPartyURI logging, so it tells you which site failed. All of these were merged into both the 3.x and 4.x TBB branches.

Note: See TracTickets for help on using tickets.