[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Levels of protection update proposal

From: Libor Polčák
Subject: Re: Levels of protection update proposal
Date: Mon, 12 Jul 2021 16:48:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.8

Hello, I am bumping an old proposal as suggested at today meeting


Hi everyone,

porting of Brave's fingerprinting protection is finished and there aren't 
compatibility issues as far as I know. So far testing revealed that ported 
countermeasures are working as intended.
Therefore I think we should change protection levels as follows:

Level 2: Change all covered APIs to randomizing approach based on 
session/domain keys, thus - Canvas methods will return slightly modified image 
data, methods isPointInPath and isPointInStroke will return false with ~5% 
probability, Web Audio methods will return slightly modified audio data, WebGL 
methods will mask vendor and renderer, alter whole number return values in some 
functions and return modified image data from readPixels, deviceMemory and 
hardwareConcurrency values will be randomized (but valid), enumerateDevices 
will return shuffled list with additional 0-4 fake devices, navigator.plugins 
will return shuffled list with additional 2 fake plugins. Rest of options 
should remain the same as current level 2.

Level 3: Canvas methods isPointInPath and isPointInStroke will always return 
false. Rest should be fine as it is.

This is just a summary, you can see which methods/functions are affected in 
specific wrappers. There may be things needing changes but generally tests have 
so far shown that proposed Level 2  breaks less sites than current level 2 
while providing better protection. Hit me up if you have any 
comments/suggestions or I didn't explain something clearly enough.

Thanks for feedback,
Matúš Švancár

Hello all,

thank you, Matúš, for the contribution.

Also following Ruben's post on the GUI redesign and mine on the web page 
redesign, I propose to change how levels work and how we can display them to 
the user. See the attached file.

I propose that we keep providing several suggested levels of protection, for 

* no protection based on current level 0 with NBS off,
* minimalistic based on current level 1,
* recommended based on what Matúš proposes for the level 2,
* strong based on level 3 with the modification from Matúš.

The no protection level allows the user to manually control what is modified by 
the extension. So all the modifications (including any future modification) are 
opt in. The other levels will allow us to provide future updates based on the 
wishes of the user. Level 1: I want some protection but do not break pages. 
Level 2: I want a meaningful protection which should not break pages but some 
incompatibilities are tolerable. Level 3: I want the best protection that you 
offer and I am willing to cope with the broken pages on my own.

The user should set a default level (the * column in the advanced view in the 
attachment), it can be one of the 4 levels mentioned above or a modification of 
one that was created by the user.

The user should be able to modify the default behaviour for each visited subdomain. 
Currently, the user needs to assign a completely new level, nothing is 
"inherited" from the default level. I propose to change this so that a user can 
modify the default level for a specific domain. In the example, the user has some 
modifications for .cz, vutbr.cz, fit.vutbr.cz, and www.fit.vutbr.cz domains. In the 
advanced view, the user sees exactly how the current modifications are applied while in 
the simplified view, the user just sees the level for the current page (we can use 
colours to indicate what is the default, what is redefined for one of the super domains, 
and what is specific for the current domain.

To determine what might be breaking the pages, the user sees the number of 
calls to each API by the page (we can suggest better representation later, mine 
is just an example).

The user can see a detailed break down of the calls, see the Detail view on 
fake fingerprint values. Like Ruben said we should also educate the users so 
they should be able to click on the attack and get to the docs on how the 
protection work and other details.

Also I think that we will need to have more options that just "no modifications" and 
"modified" value that we talked about on one of the recent meeting. Right now, the 
options depend on the blocked properties and I doubt that we will be able to create an 
one-size-fits-all approach.

(Of course all the names and details above are subject to change, I am now 
thinking mainly on the generic approach.)

As a step 1, I propose to keep using the groups as defined in 
https://pagure.io/JS-Shield/JS-Shield/blob/master/f/common/levels.js#_51 and 
redesign how the levels internally work. Basically, the behaviour of the 
extension and what is displayed would be the same as is now but the internal 
structures will be prepared for the future changes.

I am asking this because I also maintain an update script 
https://pagure.io/JS-Shield/JS-Shield/blob/master/f/common/update.js#_60 which 
tries to apply simple heuristic to modify user-defined levels with the new 
APIs. I admit that it is inspired on how I am using the extension and how I 
create my levels. All are modifications of my default level, typically 
modifying a single feature. With the proposed step 1, the update script will 
not need to modify such user-defined levels as all would be connected to the 
default level which in turn will be connected to a predefined level.

But it is possible that my views are cluttered with how I use the extension, so 
if you think that we should go for a different approach, please tell me before 
I start working on the changes.

Best wishes,


Attachment: popup.svg
Description: image/svg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]