Re: GUI design ideas

[Giorgio Maone]

Hi Ruben,

thanks for this draft: it looks like a good starting point I'm looking
forward to discussing.

Just to be sure: is the design meeting at 16 on
https://testgreenlight.fsf.org/qui-udh-d6u (I can see nobody there) or
is it at a different time/place than the development one?

Best

-- G


On 21/05/21 14:41, Ruben wrote:
> 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,


-- 
Giorgio Maone
https://maone.net