[tbb-dev] Exposing TB as Tor Browser

Tom Ritter tom at ritter.vg
Fri Nov 3 19:29:07 UTC 2017

On 3 November 2017 at 14:12, Roger Dingledine <arma at mit.edu> wrote:
> On Fri, Nov 03, 2017 at 02:05:29PM -0500, Tom Ritter wrote:
>> Wordpress would like to detect Tor Browser so it doesn't perform the
>> check and therefore doesn't pop the prompt. This would significantly
>> reduce the number of prompts Tor Browser users are seeing. The (old)
>> ticket is here: https://trac.torproject.org/projects/tor/ticket/18195
>> PS: Unless FF with privacy.resistFingerprinting identified itself as
>> Tor Browser, this wouldn't help FF, just TB.  But maybe FF _should_
>> identify itself as TB if TB starts identifying itself as TB?
> Shouldn't Wordpress be wanting to detect whether the browser has a canvas
> fingerprinting warning feature, not whether the browser is Tor Browser?
> That difference will become more important as we continue migrating
> features like that one into other mainstream browsers.


There are two problems here actually:

1) Some browsers throw a permission and others don't. How does the
webmaster know whether the prompt will be thrown?
2) The Canvas image extraction API is synchronous. What we do today is
return all-white so script execution continues, and if you accept the
permission any subsequent calls will succeed. This often breaks
legitimate uses of canvas because they aren't set up to handle this
possibility. (Fortunately, there are so few legitimate uses of this
canvas feature it's not a big deal!)

To solve #2, the canvas image extraction API should be turned into an
asynchronous promise-based API, which can succeed or fail. And more
importantly will give the user the opportunity to accept or reject the
permission before the call completes (as opposed to today where we
return blank data to the synchronous API call so script execution
continues). The problem is that the entire web has to migrate to the
Promise-based API.

To solve #1 we may need to make something up. I'm not sure if there is
any existing mechanism or API that is defined to provide information
about capabilities. Normally it's just done through feature detection
I think. If we did make something up, Wordpress could use that though,
and so could Firefox. It won't be as easy as the User Agent approach,
because it will require more bikeshedding, but I suppose it is the
'right way' to do it.

I think the right thing to do is figure out how to make Canvas not
fingerprintable once and for all.  Until that's figured out though, I
think solving #1 is okay. I guess I worry that we'd spend forever
bikeshedding on something that we hope to throw away once Canvas
Fingerprinting is 'solved'.

But maybe we wouldn't through it away. Maybe there's other things we'd
expose through it, like "AntiFingerprinting Mode is On" so the website
knows not to rely on a bunch of data it knows will be faked.


More information about the tbb-dev mailing list