|
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
DDG.png
Description: PNG image
disconnect.png
Description: PNG image
ghostery.png
Description: PNG image
NoScript.png
Description: PNG image
privacy_badger.png
Description: PNG image
umatrix.png
Description: PNG image
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |