[tbb-dev] Exposing TB as Tor Browser

Georg Koppen gk at torproject.org
Fri Nov 17 09:48:00 UTC 2017


Tom Ritter:
> 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.

I agree with Roger here. If we can avoid it (and I think we can) we
should not introduce yet another way of differentiating users of
different browsers.

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

I think the solution to #2 is a good one but I agree the amount of work
we'd need to do to establish it is pretty high and might not be worth
it. So, yes, doing something along the lines you outlined above to fix
#1 seems reasonable to me. Is there a bug for that on Mozilla's Bugzilla
already?

I don't understand, though, why this is an issue for Tor Browser at all
right now as the combination of "comes from a Tor exit AND is using the
Tor Browser user agent" could pretty easily be used to decide whether to
show the canvas warning or not, without adding additional strings to our
User Agent which then would get sent with *every* request. We don't
support Tor being used in other browsers than Tor Browser at the moment
which makes that approach okay for me. Things might break in that
scenario for non-Tor Browser users that have configured their browser to
use Tor, yes, but they are very likely already in trouble by not using
Tor Browser anyway.

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20171117/85a85725/attachment.sig>


More information about the tbb-dev mailing list