Some design decisions/questions/thoughts for today (and likely future) meetings

[Libor Polčák]

Hello all,

In the paper, we say:

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

\jshelter{} does not aim at providing a perfect solution either. Our goals are
as follows:

\begin{enumerate}

  \item Create a webextension because webextensions work across multiple
    browsers and consequently can be easily installed into any browser that
    supports webextensions, including Firefox and all browsers based on 
Chromium.

  \item Do not create a perfect solution instead focus on what other
    webextensions lack: a consistent approach to the threat T2(Browser and 
computer
fingerprinting) and protection
    from T3 (Very rich browser APIs), T4 (Hostile third-party scripts - 
Currently, \jshelter{} does not provide any protection
    for T4 but we evaluate possibilities to add such support in the future. For
    example, we supervise a diploma thesis in the area that should be defended
    in 2022.), T5 (Local network scanning), and T6 (Microarchitectural attacks).

  \item Make the webextension friendly for people without technical knowledge.

\end{enumerate}

...

We are not aware of any isolated side-effect that reveals
\jshelter{}. For example, some similar webextensions do not
modify \verb|toString|. A page script could detect such a webextension as each
webextension modifying the call by the same technique will likely use a 
different
code. Nevertheless, we are aware and do not hide that users of \jshelter{} are
vulnerable to focused attacks. Our goal is to offer a protection
indistinguishable from another privacy-improving tool for each modified API.
Nevertheless, a focused observer will very likely be always able to learn that a
user is using \jshelter{} if they aggregate the observable inconsistencies of
all APIs produced by \jshelter{}.

...

Another reason is that users do not understand the little lies fingerprint
prevention. They want to hide in the crowd (see §\ref{sec:3antifp}). The
most controversial of which is WebGL vendor, unmasked vendor, renderer, and 
unmasked
renderer spoofing. We do not know any list of real-world strings, and even if we
knew, we are not sure if we could avoid inconsistencies. Hence we decided that
the threat model defending from a fingerprinter not focused on revealing 
\jshelter{} users
allows for the generation of random strings per origin and session for the 
little
lies JSS profile (see §\ref{sec:jss}). Some users do not understand the
explanation even though we highlight that similar randomly generated strings are
already available through \verb|MediaDevices.prototype.enumerateDevices|, the
created profile is unique by design.

A common problem is that users do not understand what \jshelter{} is doing and
that several modules work in parallel and can be enabled and
configured separately. We tweaked the UI several times to make the UI as
straightforward as possible and we added explanations and want to add even more
explanations (for example, to the popup window).

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

Question 1: Are we OK with the text?

Question 2: We are likely loosing users over issues like 
https://pagure.io/JShelter/webextension/issue/42 and 
https://pagure.io/JShelter/webextension/issue/16. The problem is that the 
issues are likely unfixable.

42: We emulate webworker in the main thread so the processing is slower due to 
the lack of paralelism. We replace native code with JS.

16: Both my comments are relevant.

So the root question is: Do we want to provide a protection that we think works 
or do we want to provide a protection that can be side-stepped or do we want to 
create some kind of heuristics that might mitigate 42? Do we think that the 
tweak UI option to remove the protection more accessible to non-technical 
people? I mean the user in 42 did what I think is an expected behaviour: the 
page broke due to the wrapper, the user decided to trust the page and the page 
now works. But what I see as expected workflow, the user sees as a problem 
worth filling an excellent bug report (it took a lot of time).

Question 3: Depending on the answer to Q2, we should think about 
https://pagure.io/JShelter/webextension/issue/20 (Explore possibilities to 
enable community to create exceptions).

Question 4: Are we OK that the little-lies-based fingerprinting prevention 
works in a way that provides different values on each domain and session? Do we 
want to change to each page load and reimplement, for example MediaDevices 
wrapper?

Question 5: We need to address the problem of writing new wrappers and the 
complex injection code that results in issues like 
https://pagure.io/JShelter/webextension/issue/22 and 
https://pagure.io/JShelter/webextension/issue/32.

Question 6: I noticed that Firefox warns me a lot about JShelter slowing 
Firefox down. It appears to happen here or there. In one session, I find a page 
where it reliably happens but it is OK the other day. Is there a way how to 
profile a webextension? It appeared on a page where the UI reported only access 
to time wrappers. I am unsure how to proceed.

Question 7: https://pagure.io/JShelter/webextension/issue/41, discuss 
differences between JShelter and NoScript, do we want to keep both?

Question 8: Are we OK with recommending User Agent Switcher or we want to take 
additional actions? https://pagure.io/JShelter/webextension/issue/44

Question 9: Document how security issues can be reported to the jShelter and 
nscl projects, for example via a public security@ mail address that is listed 
in the README.md or a dedicated SECURITY.md with more information on the 
project policy for security reports. We also discussed AMO accounts connected 
to the extension. Does FSF has possibilities to redirect e-mails sent to 
addresses like security@jshelter.org, or developers@jshelter.org?

Question 10: Michael, please ask Ruben to remove 
https://pagure.io/JShelter/JShelter or pull the note from 
https://pagure.io/JS-Shield/JS-Shield.

Best wishes,

Libor