js-shield
[Top][All Lists]
Advanced

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

GUI design ideas


From: Ruben
Subject: GUI design ideas
Date: Fri, 21 May 2021 14:41:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0

I've taken a look into the UI design of a few well-known privacy
extensions. Based on the main user interface (the drop-down menu), they
can generally be grouped into 3 categories:

 - Global: simple configuration method where a target level of
protection is selected. This is the current design on JSR, and can also
be seen on others like uBlock, HTTPSEverywhere, DDG, Disconnect. The
pros are that it is less cluttered and friendlier for newcomers. The
cons are that finer tuning require opening an advanced settings interface.
 - One dimension: the UI allows to fine-tune the behavior on one
dimension of its range of application, that is, which features are
blocked, or which visited sites are protected, or which services loaded
by those sites will be blocked. Some examples are NoScript, Ghostery,
Privacy Badger, LibreJS. Pros are that it allows for more customization
and it informs the user about the actions being taken, so it can be more
didactic. Cons are a more complicated interface.
 - Two dimension: the UI allows to fine tune on a table of features X
domains. An example of this is uMatrix, which lists all the domains from
where resources are being fetched by a site, and which type of resource
is coming from each, allowing to choose the type of response for each
combination in a 2 dimension matrix (thus, the program name). This gives
the highest level of control at the expense of a more intimidating
interface. This level of detail may be available in the other
extensions, on an advanced configuration page.

In the examples listed, some extensions focus their use case on either
domains of application or features, so their GUI design reflects the
problem they are targeting. In our case, our application focuses on
features, and the domain of origin is (although important) secondary, so
we should have this in mind on the interface design. I believe that more
important than which domain is triggering a feature, is whether the
request is 1st or 3rd party.

I propose this hybrid design type:

 - A global setting, that applies a default starting point and a method
to increase or decrease the protection-level vs disruption trade-off
with one click, suitable for newcomers.
 - Underneath, a list of each feature that has been triggered by this
site, with a link to the documentation page for that problem/solution,
and buttons to chose the desired behavior for this, any, or 3rd party
domains:

                   ACTION                      SITE
  - Feature 1: [x]allow []replace []block  |  []this [x]any []3rd party
  - Feature 2: []allow [x]replace []block  |  []this []any [x]3rd party
  - ...
  - Other features (not triggered by this site, opens advanced settings)

If the graphical structure is found to be adequate, we can then decide
what is a sane default setting for each protection level, and how is it
reflected on the way this entries are displayed. An example of possible
choices:

  - Default level: action=replace, site=any
  - Permissive level: action=replace, site=3rd party
  - Hardened level: action=block, site=any

The extension icon counter should show the number of events triggered by
the site on the active tab, and the color could indicate the action
taken. It could also reflect a value for how potentially dangerous a JS
feature may be, which we would codify in the wrappers. Care should be
taken for color to convey an intuitive concept, and for preserving
accessibility.

Attached are some of the examples mentioned.

Some questions that popped up while thinking of this:
 - Should there be a "block" action for features, or just allow/replace?
 - Should CSP be trusted by the extension, or be strict on 1st/3rd
domain separation?
 - Should color be used to indicate the action taken, or the level of
risk of a feature, or neither?

Let's start by discussing this and coming up with a mockup. As a next
step we should also discuss what to include in the advanced config page
(e.g. whether to list things by domain or by feature).

Cheers,
-- 
Ruben Rodriguez | Chief Technology Officer, Free Software Foundation
GPG Key: 05EF 1D2F FE61 747D 1FC8  27C3 7FAC 7D26 472F 4409
https://fsf.org | https://gnu.org

Attachment: DDG.png
Description: PNG image

Attachment: disconnect.png
Description: PNG image

Attachment: ghostery.png
Description: PNG image

Attachment: NoScript.png
Description: PNG image

Attachment: privacy_badger.png
Description: PNG image

Attachment: umatrix.png
Description: PNG image

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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