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
example:
* 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,
Libor
popup.svg