Georg Koppen:
> sajolida:
>> anonym:
>>> Georg Koppen:
>>>> Tails - News:
>>>>> This release is an emergency release to fix a critical security vulnerability
>>>>> in _Tor Browser_.
>>>>>
>>>>> It also fixes [other security
>>>>> vulnerabilities](https://tails.boum.org/security/Numerous_security_holes_in_3.13.1/).
>>>>> You should upgrade as soon as possible.
>>>>>
>>>>> # Changes
>>>>>
>>>>> ## Fixed _NoScript_ activation in _Tor Browser_
>>>>>
>>>>> Starting from Friday May 3, a problem in _Firefox_ and _Tor Browser_ disabled
>>>>> all add-ons. This release reactivates all add-ons in _Tor Browser_, especially
>>>>> _NoScript_ which is used to:
>>>>>
>>>>> * Most importantly, protect against a very strong fingerprinting technique called _HTML5 canvas fingerprinting_ which can break your anonymity.
>>>>
>>>> Hm. How does it do that? In particular, what does it do in addition to
>>>> the defense we baked into Tor Browser and which is not NoScript
>>>> dependent? (see the: "Specific Fingerprinting Defenses in the Tor
>>>> Browser", subsection 2. HTML5 Canvas Extraction at
>>>> https://2019.www.torproject.org/projects/torbrowser/design/)
>>>
>>> There's been a misunderstanding. We were supposed to talk about fingerprinting enabled by the loss of NoScript's WebGL click-to-play, not HTML5 canvas fingerprinting.
>>
>> I'm acting here as a mere translator of the technical knowledge that
>> intrigeri transmitted to me in
>> https://redmine.tails.boum.org/code/issues/16694#note-14 and that I
>> could read on https://2019.www.torproject.org/projects/torbrowser/design/.
>>
>> I understood that HTML5 canvas fingerprint can use a combination of
>> "WebGL, font, and named color" and that "WebGL Canvases have
>> click-to-play placeholders (provided by NoScript)".
>>
>> So, a website could benefit from NoScript being deactivated to use WebGL
>> to do HTML5 canvas fingerprinting; even though Tor Browser on its own
>> could block other canvas fingerprinting attempts.
>>
>> And from a user's point of view, NoScript protects them from (some types
>> of) canvas fingerprinting.
>>
>> Isn't it?
>
> Well, not really. First of all, the canvas fingerprinting blocker is
> effective regardless whether one has WebGL allowed or not. Before
> anything is extracted from an HTML <canvas> element you get at least a
> prompt whether you want to allow to return valid image data or not.
> That's regardless whether WebGL is available in that process or not.
> Thus, even if NoScript would not be enabled there should be no way that
> WebGL could be used for canvas-based fingerprinting without the user
> allowing it.
Thanks for the detailed analysis!
> Now, you could argue that *if* users allowed canvas fingerprinting they
> would be better off entropy-wise if the potentially available WebGL
> parts would be behind a click-to-play option. Maybe. I am not convinced
> yet, though, that this would make a big or an actual difference.
Right, I'm not convinced either.
So I dropped this paragraph from our release notes and security advisory.
--
sajolida
