Re: Levels of protection update proposal

[Ruben Rodriguez]

>From the proposal I see these types of information being conveyed:

 * Level
 * wrapper name/description
 * domain of application
 * type of solution applied
 * number of calls
 * name of JS calls referred

We need to decide what amount of detail to show, I think the proposal
provides a technical depth that is good for researchers and wrapper
developers, but would be intimidating to end users. Some thoughts:

 * Levels: My suggestion is to allow per-domain, to:
  - Select a level other than the global default.
  - Turn a wrapper on/off, overriding the level.

I think this would cover most user cases, while keeping the interface
and the internal management of per-domain settings simple enough. Also,
the more we facilitate the creation of custom levels the more unique the
user's feature set becomes.

 * wrapper name: looks fine, we may be able to display more detail when
hovering or through a (?) clickable icon pointing to the documentation.
Not clear from the svg, I suggest only listing triggered wrappers.

 * domain of application, I think it is not necessary to break it into
each domain component (e.g. no sense in applying a rule to a tld). It
should be sufficient to be able to apply it to the request domain as-is,
or every subdomain of the root one (e.g. x.y.foo.bar or *.foo.bar).

 * For type of solution (on, high, white lie), I think it also needs to
be simplified. IMO going any further than on/off on the popup
interface would be too intimidating.

 * Number of calls, does 15/117 mean "this time/total (for the source
domain)"? Maybe it would be better to just display the number of calls
for that load, and when hovering the number more detail is shown?
Wouldn't this require collecting stats for all domains anyway?

 * Name of function called, I think it goes into a technical detail that
is useful to wrapper developers more than to end users. At least for now
I suggest listing results per wrapper and have the wrapper name link to
the detailed documentation site for those with the technical curiosity.

An example layout:

----------------------------------------------

    Configuration | Documentation | About

            Default level : 01[2]3

 |------------------------|--------|-------|
 | www.foo.bar    01[2]3  | action | count |
 |------------------------|--------|-------|
 | Canvas fingerprinting  |   ON   |  3    |
 | Hardware information   |   OFF  |  5    |
 | ArrayBuffer exploit    |   ON   |  1    |
 |------------------------|--------|-------|
 | www.baz.bat    01[2]3  | action | count |
 |------------------------|--------|-------|
 | Geolocation API        |   OFF  |  12   |
 | Battery status         |   OFF  |  8    |
 | Canvas fingerprinting  |   ON   |  4    |
 |------------------------|--------|-------|
 | im.evil.com     012[3] | action | count |
 |------------------------|--------|-------|
 | Geolocation API        |   ON   |  5    |
 | Battery status         |   ON   |  14   |
 | Canvas fingerprinting  |   ON   |  3    |
 |------------------------|--------|-------|

----------------------------------------------

>>
>> 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