Re: Development meeting notes 14/Jun/2021

[Libor Polčák]

Hello,

some comments to the meeting notes.

> * Ebay was using some security scripts to detect open local ports, which
> is something that JSR had implemented. It was nice to see it being
> useful to deploy in the field with this use case.

I wrote a blog post on the issue

https://polcak.github.io/jsrestrictor/blogarticles/localportscanning.html

...
>    * In brave these functions are turned on for all users and may be
> possible to turn off for some sites.

https://github.com/brave/brave-browser/issues/8787


Off: Don’t apply any fingerprinting protections
Default: A useful set of protections that may not fundamentally prevent 
fingerprinting attacks, but re practical against real world fingerprinting 
attacks. Carries a small but non-zero chance of breaking sites.
Maximum: The strongest set of protections, that disables or otherwise modifies 
page functionality to prevent sites from accessing or learning the underlying 
data needed for fingerprinting attacks. Carries larger, non-trivial web-compat 
risks.

>    * Georgio asks, since the original work is in C and the new
> implementation is a rewrite into JS, there should be no need to use the
> mozilla license instead of GPL. Libor will provide sample source files
> for Ruben to pass to Licensing to confirm this.

I'll get to this issue soon.

>    * Libor may contact the brave people about their implementation
> method, they used a session key and domain key, to be able to be random
> but stay across sessions. This key system was ported to our system, and
> may need to be further reviewed. Giorgio looked a bit into this
> functionality, thinks that the best way to implement this is with domain
> keys in memory, and a different set to be used in incognito. Libor
> agrees, the session key should not be needed, the worry is to have a
> large list of keys of domains
> * Right now each level needs to specify everything, so it cannot be

Each level does not have to specify everything. But

A) items not specified are not wrapped
B) a level cannot inherit wrapping properties from another level.

> customized. Every time that a new wrapper is added we need to define
> them in the level definition. We want to prevent the case in where an
> update is done, that adds new wrappers changing the behavior of a level,
> taking the user by surprise. Libor is thinking of working on the backend

The worry is mainly with user-defined levels. A user cannot create, for 
example, a level working as level 2 but with a window.name not wrapped. A user 
can create a level that is now similar to level 2 with the desired tweaks. With 
time such user-deifned level can de-sync as new wrappers are added to built-in 
levels or their behaviour changes. Hence I modify user-generated levels with 
update.js to try to keep user-defined levels in sync (so far I only added 
wrappers and not modified the behaviour). I use a (very very simple) heuristic 
to determine what levels should be changed. If the heuristics are not right, 
then a level can change without the user ever realise that.

So I want to create a mechanism that is not so fragile and that does not change 
user-defined levels.

I think that we should tweak built-in levels as we see necessary, for example, 
like now with farbling, it seems to make sense to change level 2 to include 
farbling.

Best

Libor