Re: Levels of protection update proposal

[Libor Polčák]

Hello Ruben,

Thank you for your comments. See my comments inline.


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

Definitely.

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

I agree.

It probably was not clear from the original message but I think that the 
simplified view should be the default. The advanced view is an opt-in for power 
users (researchers, wrapper developers etc.).

The issue that I tried to tackle is that there are many web pages like:

* maps,
* voice and video conferences,
* fingerprinters for security purposes (log in),
* and other specialized pages

that needs a per web site exceptions to some processing.

Suppose that a wrapper offers multiple levels of blocking and the user uses the 
highest level. If a page does not work, users will want to try a lower level of 
blocking, would not they? If the option is only on and off than the user might 
want to use a lower level of protection overall.

Also, I propose having two levels of detail in the pop up. One for the 
non-expert users (default) and one for advanced (power) users.

Finally, currently there is not a need to interact with the settings page on a 
daily basis. If we allow setting a different wrapping scheme through the 
settings page but not through the advanced pop up, we will force users to go 
through a more-click approach to achieve the desired outcome.

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

Advanced and simplified look shows all the categories. While "Detail view on fake 
fingerprint values" shows only those methods that were called.

The reasoning behind the former is to show the users that some categories of 
APIs were not called at all so there is no need to change the wrapping. But if 
hiding such categories creates less confusion we can go that way.

>   * 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).

Again the simple view does not allow to specify wrappings for subdomains.

The opportunity to define wrapping for different subdomains was inspired by 
uMatrix. E.g. if I visit www.fit.vutbr.cz, the advanced user has the 
opportunity.

There are TLDs for which it might make sense to define specific wrappings like 
.google.

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

See above.

>   * Number of calls, does 15/117 mean "this time/total (for the source
> domain)"?

My intention was to show the numbers for the current web page load. 15/117 
means that there were 117 calls of APIs from that category, of which 15 were 
modified.

> Maybe it would be better to just display the number of calls
> for that load, and when hovering the number more detail is shown?

If the page breaks, I think that the user will need both values to decide what 
to do next. We can create two columns and provide better heading.

> Wouldn't this require collecting stats for all domains anyway?

We can discuss the amount of stats that we want to collect and display. I had 
in mind only showing statistics for the currently displayed page without any 
need for a storage. But I can see a point in the user wanting to know the APIs 
that were called by all visited pages on the domain. If we go this way, we need 
to decide if and how to display statistics for supper domains.

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


Can you explain the layout further? I am not sure why do you want to list 
multiple domains.


I think that it is probably not clear the connection between my original three 
suggestions.

An example layout:

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

    Configuration | Documentation | About

    *Simple view* | Advanced view

    Detail view on fake fingerprint values

    (The original "Simplified look" table)

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

If the user clicks on Advanced view, the content of the pop up changes to the 
following view. The advanced view will be displayed for each further pop up 
invocation unless the user click on Simple view link again.

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

    Configuration | Documentation | About

    Simple view | *Advanced view*

    Detail view on fake fingerprint values

    (The original "Advanced look" table)

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

The user can also click on the "Detail view on fake fingerprint values". In 
that case, the content of the pop up changes to the view below.

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

    Configuration | Documentation | About

    Simple view | Advanced view

    *Detail view on fake fingerprint values*

    (The original "Detail view on fake fingerprint values" table)

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

Next time, the user opens a pop up, they will see either Simple view or 
Advanced view depending on their past behaviour.


Best wishes,

Libor