bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Jacob Hrbek]

[-- Attachment #1.1.1: Type: text/plain, Size: 634 bytes --]

Arkenfox <https://github.com/arkenfox/user.js> is a community maintained user.js file used for browser hardening.

Proposing to implement it's configuration in GNU Guix's IceCat mainly:

- geo.provider.network.uri (it's pinging google servers currently)

- Actual disabling of WebRTC

- Clearing on re-start (privacy.clearOnShutdown.*)

- toolkit.telemetry.enable = false instead of forced true

- etc..

Additional configuration should be defined in guix-home with sane default so that the browser can be a sufficient replacement for Tor Browser Bundle.

-- Jacob "Kreyren" Hrbek

Sent with ProtonMail Secure Email.

[-- Attachment #1.1.2.1: Type: text/html, Size: 996 bytes --]

[-- Attachment #1.2: publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc --]
[-- Type: application/pgp-keys, Size: 737 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Maxime Devos]

Jacob Hrbek schreef op do 02-12-2021 om 03:58 [+0000]:
> Arkenfox <https://github.com/arkenfox/user.js> is a community
> maintained user.js file used for browser hardening. 
> 
> Proposing to implement it's configuration in GNU Guix's IceCat
> mainly: [...]

These things might be useful, but wouldn't IceCat's mailing lists be
more appropriate for suggesting different configuration defaults?
(See https://www.gnu.org/software/gnuzilla/ for the mailing lists of
IceCat and other GNUzilla software.)

> Additional configuration should be defined in guix-home with sane
> default [...]

I don't think guix home is necessary for this, wouldn't some kind of
parametrised packages be sufficient? E.g., something like:

(packages->manifest
  ;; This creates a wrapper around ticecat instructing the firefox
  ;; derivative to use the supplied user.js instead of wherever firefox
  ;; normally goes looking for things. (I don't know how to do that,
  ;; but should be possible?)
  (icecat-with-configuration ; (defined in gnu packages gnuzilla)
    #:user.js arkenfox ; defined in (gnu packages gnuzilla)
    #:package the-base-icecat-package)) ; by default icecat, but any
firefox derivative will do 
  emacs other-packages ...)

That could be useful for both "guix shell --manifest=manifest.scm" and
guix home users.

> [...] so that the browser can be a sufficient replacement for Tor
> Browser Bundle.

The Tor project advised against using anything but their Tor Browser,
to avoid fingerprinting. It also advised against customisation, for the
same reasons. I cannot find the web page explaining the details, but
<https://support.torproject.org/tbb/tbb-14/> comes close. Tor makes
modifications to the browser, so simply modifying some settings isn't
sufficient.

Also, from the arkenfox/user.js README:

‘Note that we do not recommend connecting over Tor on Firefox. Use the
Tor Browser if your threat model calls for it, or for accessing hidden
services.’

Greetings,
Maxime.

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Mark H Weaver]

Hi Maxime, Jacob, and others,

Maxime Devos <maximedevos@telenet.be> writes:

> Jacob Hrbek schreef op do 02-12-2021 om 03:58 [+0000]:
[...]
>> [...] so that the browser can be a sufficient replacement for Tor
>> Browser Bundle.
>
> The Tor project advised against using anything but their Tor Browser,
> to avoid fingerprinting. It also advised against customisation, for the
> same reasons. I cannot find the web page explaining the details, but
> <https://support.torproject.org/tbb/tbb-14/> comes close.

I agree with everything Maxime wrote here.  For an in-depth discussion
of the relevant issues, please see:

  <https://2019.www.torproject.org/projects/torbrowser/design/>

Regarding this specific issue, see the "Sources of Fingerprinting
Issues" subsection of section 4.6 (Cross-Origin Fingerprinting
Unlinkability) of the document above.

      Thanks,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Jacob Hrbek]

[-- Attachment #1.1: Type: text/plain, Size: 10917 bytes --]

> These things might be useful, but wouldn't IceCat's mailing lists be more appropriate for suggesting different configuration defaults? (See https://www.gnu.org/software/gnuzilla/ for the mailing lists of IceCat and other GNUzilla software.) -- Devos

Yes there should be more effort done incecat, but I also see it being important integrated in guix for reasons below.

Be it icecat should only provide sane defaults for further configuration.

> I don't think guix home is necessary for this, wouldn't some kind of parametrised packages be sufficient? E.g., something like -- Devos

arkenfox is a **TEMPLATE** we can't just paste it in userland and expect peak security instead we should process the template and integrate the configuration in parametrisation with cherrypicked defaults to **generate** the user.js and enable the user to configure it from config.scm or alike.

> The Tor project advised against using anything but their Tor Browser, to avoid fingerprinting. -- Devos

DISCLAIMER: This is from my personal and unqualified research, the information provided should be discussed with a qualified professional and you should **ALWAYS** decide for yourself in relation to your threat model.

To provide context: Browser fingerprinting works by either using:
- Javascript which functions are used to provide unique data -> Mitigation is disabling fingerprint or utilizing NoScript-like functionality to disable specific javascript functions and making libreJS less useless.
- WebGL which provides unique data about user's hardware -> Mitigation is to disable WebGL which iceCat already does and we could also make icecat to run in a Virtual Machine (VM) like Xen's paravirtualization to provide the common VM values for reported hardware
- CSS which uses exfil to pass malicious payload which can be mitigated through upstream and by using functionality alike https://addons.mozilla.org/en-US/firefox/addon/css-exfil-protection
- Link tracking to pass unique identifiers in the URLs which can be mitigated by removing those e.g. using ClearURL-like functionality

Among other things that we can do to adapt more mitigations:
- Reducing the dependency on bigtech solutions by using invidious, nitter, libreddit, wikiless, etc..
- Containerization of tabs so that cross-side cookies can't reach across tabs and using one tab per website.
- Removing all stored data including cookies, history, etc.. on restart without the ability to restore the session.
- Using uBlock origin to block ads and trackers

That's bare minimum in terms of configuration that we should definitively expand on over time, now in terms of randomization of the fingerprint:

- Adapting random user-agent which seems to be the most common way of tracking users 

- Letterboxing and use of floating windows to randomize the reported window lenght and width
- and various randomization of values in user.js on runtime since the file is JS and we can use JS to do that there.
- Onion-routing to randomize the IP where currently we should only use torproject's implementation as lokinet didn't yet pass independent security review to my knowledge.. once it does we should randomly change the onion-routing implementation and if there is a VPN provider that provides a transparent deployment with verifiable configuration to not keep any logs then we can also randomize the IP with that, but i wouldn't trust my payload to any VPN provider.

So to summarize we need to:
1. sanitize javascript and it's functions used across websites
2. Randomize user.js values
3. Cookies management
4. WebGL management
5. CSS mitigations
6. Be progressive on new things

Now in terms of a threat model if you are a journalist, political activist or any person who's leak of data can be life threatening then you are less likely to be put in such situation on TBB, but even on TBB there are ways that are unknown to us that can be used to track invidual tor users such as https://thehackernews.com/2021/11/researchers-demonstrate-new.html and there are companies investing $$$$$+ in new ways to track users through browser fingerprinting such as https://fingerprintjs.com where new ways are constantly showing up.

For those reasons on a theoretical bases if we can make randomized fingerprinting then we can basically deprecated TBB, but practically both of these solutions are flawed and will be flawed as long as we keep updating firefox/icecat to expose new issues during development where it is unreasonable to just stop development as that might expose the software to more issues over time. So this solution is mostly for power-users and regular users with relaxed threat model or for high-profile targets who prefer to have more control over their browser.

Meaning layering defences for specific known issues (my proposal) vs relying on one huge wall (TBB).

And on top of this arkenfox provides a huge amount of tests that we should integrate to enforce out solution.

NOTE: For those reasons minimal browsers such as nyxt and surf have the potential to be more private, but from the point of view of an attacker it's just different vector for an attack so firefox should be preferred as it gets more development to address these issues quickly.

> Geolocation is disabled by default in IceCat.  When you say that "it's pinging google servers currently", have you observed this in its default configuration, or did you enable Geolocation?  -- Weaver

I use custom configuration so I was not aware of that being default, but even then just simple "default" is not enough where the issue is that there might be vulnerabilities that access the geolocation data even when it's disabled so everything in the browser (in my proposal) should be treated as compromised and layer defences so in this example:

Even if geolocation is disabled we can't afford treating the value in prefs.js as not a concern and just keep google there we have to treat it as compromised at all time and treat it as that it might get used at some point to use either:
a) value that breaks geolocation when accessed (vulnerability might allow the attacker to inject their own value)
b) if it's ever accessed or use more privacy-oriented provider such as mozilla allegedly (preferably if GNUzilla made their own geolocating thing).

I know that this might sound too paranoid, but due to the amount of new vulnerabilities in browsers (Like hell they can even use CSS now to track people! on top of AI used to find new vulnerabilities which is allegedly what Facebook is doing) i believe that it's reasonable way of looking at it.

> Your use of the word "Actual" above seems to suggest that the IceCat project aims to disable WebRTC.  I'm not aware of any such decision by the IceCat project. -- Weaver

I was told by FSF representative that icecat's compilation does not include support for WebRTC by default when i was invitted on the associate member meetup so i was basing that opinion on that.

If that is not a goal then disabling it in the settings is sufficient and preferred for me where i assumed there being reasoning for it to be outcompiled like that due to it being reasonably new technology which seems to be the common reason to do such thing.

> <Other IceCat-relevant proposals> -- Weaver

This is a discussion that gets exponentially more complicated the more we talk about it so i propose some written way of managing all these values to be used for implementation where my initial idea was wiki? So that the end-user can just search the value and find all the relevant information to make the decision for their threat model.

> Please see Maxime's comments on this, which I agree with.  I'm sorry to say that I don't see a way for IceCat users to hide that they are probably using IceCat. -- Weaver

On top of what was provided I highlight the importance of making icecat seem as firefox to the web e.g. by using firefox useragent instead of icecat as icecat has significantly more unique fingerprint to firefox if it's being treated as a it's own separate thing. + the randomization of the fingerprint.

---

NOTE: I would also argue for icecat to just have disabled settings page with prefs.js set as read-only and owned by room with permission to read by the relevant user to reduce the risk of vulnerability or malicious extension altering the config.

-- Jacob "Kreyren" Hrbek

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, December 2nd, 2021 at 3:50 PM, Maxime Devos <maximedevos@telenet.be> wrote:

> Jacob Hrbek schreef op do 02-12-2021 om 03:58 [+0000]:
> 

> > Arkenfox https://github.com/arkenfox/user.js is a community
> > 

> > maintained user.js file used for browser hardening.
> > 

> > Proposing to implement it's configuration in GNU Guix's IceCat
> > 

> > mainly: [...]
> 

> These things might be useful, but wouldn't IceCat's mailing lists be
> 

> more appropriate for suggesting different configuration defaults?
> 

> (See https://www.gnu.org/software/gnuzilla/ for the mailing lists of
> 

> IceCat and other GNUzilla software.)
> 

> > Additional configuration should be defined in guix-home with sane
> > 

> > default [...]
> 

> I don't think guix home is necessary for this, wouldn't some kind of
> 

> parametrised packages be sufficient? E.g., something like:
> 

> (packages->manifest
> 

> ;; This creates a wrapper around ticecat instructing the firefox
> 

> ;; derivative to use the supplied user.js instead of wherever firefox
> 

> ;; normally goes looking for things. (I don't know how to do that,
> 

> ;; but should be possible?)
> 

> (icecat-with-configuration ; (defined in gnu packages gnuzilla)
> 

> #:user.js arkenfox ; defined in (gnu packages gnuzilla)
> 

> #:package the-base-icecat-package)) ; by default icecat, but any
> 

> firefox derivative will do
> 

> emacs other-packages ...)
> 

> That could be useful for both "guix shell --manifest=manifest.scm" and
> 

> guix home users.
> 

> > [...] so that the browser can be a sufficient replacement for Tor
> > 

> > Browser Bundle.
> 

> The Tor project advised against using anything but their Tor Browser,
> 

> to avoid fingerprinting. It also advised against customisation, for the
> 

> same reasons. I cannot find the web page explaining the details, but
> 

> https://support.torproject.org/tbb/tbb-14/ comes close. Tor makes
> 

> modifications to the browser, so simply modifying some settings isn't
> 

> sufficient.
> 

> Also, from the arkenfox/user.js README:
> 

> ‘Note that we do not recommend connecting over Tor on Firefox. Use the
> 

> Tor Browser if your threat model calls for it, or for accessing hidden
> 

> services.’
> 

> Greetings,
> 

> Maxime.

[-- Attachment #1.2: publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc --]
[-- Type: application/pgp-keys, Size: 737 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Liliana Marie Prikler]

Am Samstag, den 04.12.2021, 00:31 +0000 schrieb Jacob Hrbek:
> arkenfox is a **TEMPLATE** we can't just paste it in userland and
> expect peak security instead we should process the template and
> integrate the configuration in parametrisation with cherrypicked
> defaults to **generate** the user.js and enable the user to configure
> it from config.scm or alike.
This is the thing that makes the least sense about this proposal. 
Like, even if we were to write a service that allows user.js generation
through guix home, there'd be no reason to adopt arkenfox or any other
template for that matter.  People would have to adapt their templates
to the guix home workflow, which would hopefully not be more difficult
than writing some gexp.

> To provide context: Browser fingerprinting works by using [a bunch of
> side-channels that are hard to all disable completely...]

> [...]

> NOTE: For those reasons minimal browsers such as nyxt and surf have
> the potential to be more private, but from the point of view of an
> attacker it's just different vector for an attack so firefox should
> be preferred as it gets more development to address these issues
> quickly.
I'm pretty sure that using (a) Firefox (variant) is the only reliable
way to circumvent side-channel based fingerprinting as noted above
since you probably won't be able to patch all variants (especially not
those you aren't aware of yet), so better to only leak that you're "a
Firefox user".  That is until Chromium has all the market share and we
need to switch to the bigger fish for anonymity.  

> > Geolocation is disabled by default in IceCat.  When you say that
> > "it's pinging google servers currently", have you observed this in
> > its default configuration, or did you enable Geolocation?  --
> > Weaver
> 
> I use custom configuration so I was not aware of that being default
You might want to generate your custom configuration with arkenfox
then, so that Geolocation is always disabled.

> but even then just simple "default" is not enough where the issue is
> that there might be vulnerabilities that access the geolocation data
> even when it's disabled so everything in the browser (in my proposal)
> should be treated as compromised and layer defences so in this
> example:
Again, have you observed this?

> Even if geolocation is disabled we can't afford treating the value in
> prefs.js as not a concern and just keep google there we have to treat
> it as compromised at all time and treat it as that it might get used
> at some point to use either:
> a) value that breaks geolocation when accessed (vulnerability might
> allow the attacker to inject their own value)
> b) if it's ever accessed or use more privacy-oriented provider such
> as mozilla allegedly (preferably if GNUzilla made their own
> geolocating thing).
It'd probably be feasible to clear the value by default, but then
again, that'd not really help with custom configs created from a
"trusted" template, would it?

> > Your use of the word "Actual" above seems to suggest that the
> > IceCat project aims to disable WebRTC.  I'm not aware of any such
> > decision by the IceCat project. -- Weaver
> 
> I was told by FSF representative that icecat's compilation does not
> include support for WebRTC by default when i was invitted on the
> associate member meetup so i was basing that opinion on that.
This does not mean, that it's intentional, however.  It could also be
just a bug that they haven't figured out yet.  For example, WebRTC in
Webkit requires gst-plugins-bad, which is bad...

> If that is not a goal then disabling it in the settings is sufficient
> and preferred for me where i assumed there being reasoning for it to
> be outcompiled like that due to it being reasonably new technology
> which seems to be the common reason to do such thing.
Again, no statement about an "aim".

> > <Other IceCat-relevant proposals> -- Weaver
> 
> This is a discussion that gets exponentially more complicated the
> more we talk about it so i propose some written way of managing all
> these values to be used for implementation where my initial idea was
> wiki? So that the end-user can just search the value and find all the
> relevant information to make the decision for their threat model.
I'm pretty sure you don't need a Wiki to look up the invocation for ls,
do you?  Similarly, to configure Emacs you would first consult the
Emacs manual, no?  Guix does currently in no way interfere with your
ability to mess with Icecat's configuration, any documentation with
that regard is therefore Icecat/Firefox' burden, not Guix'.

> NOTE: I would also argue for icecat to just have disabled settings
> page with prefs.js set as read-only and owned by room with permission
> to read by the relevant user to reduce the risk of vulnerability or
> malicious extension altering the config.
To be fair, that'd be a nice quality to have, but you'd also have to
make the directory itself read-only in that case and at least I
personally haven't checked how well browsers like not being able to
write in their "dump everything" directories.  You might have more
success using containers in which the files are writable, but not
synced back to disc.  That also gives you a playground to experiment
with potentially malicious extensions.

On that note, you probably shouldn't mess around with extensions as a
journalist.

Cheers

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Maxim Cournoyer]

Hello,

Maxime Devos <maximedevos@telenet.be> writes:

> Jacob Hrbek schreef op do 02-12-2021 om 03:58 [+0000]:
>> Arkenfox <https://github.com/arkenfox/user.js> is a community
>> maintained user.js file used for browser hardening. 
>> 
>> Proposing to implement it's configuration in GNU Guix's IceCat
>> mainly: [...]
>
> These things might be useful, but wouldn't IceCat's mailing lists be
> more appropriate for suggesting different configuration defaults?
> (See https://www.gnu.org/software/gnuzilla/ for the mailing lists of
> IceCat and other GNUzilla software.)

Agreed.  GNU IceCat is not developed as part of Guix (although Guix is
used to develop IceCat, I suppose!).  Please redirect your suggestions
to the appropriate channels mentioned above.

Thanks for the report,

Maxim

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

[Mark H Weaver]

Hi Jacob,

Jacob Hrbek <kreyren@rixotstudio.cz> writes:
> Arkenfox <https://github.com/arkenfox/user.js> is a community
> maintained user.js file used for browser hardening.

In the past, I've investigated and integrated some ideas from similar
"user.js"-style projects into IceCat.  I'm open to integrating more, but
I'd prefer to see proposals in manageable chunks on the gnuzilla mailing
lists.

> Proposing to implement it's configuration in GNU Guix's IceCat mainly:
>
> - geo.provider.network.uri (it's pinging google servers currently)

Geolocation is disabled by default in IceCat.  When you say that "it's
pinging google servers currently", have you observed this in its default
configuration, or did you enable Geolocation?

FWIW, I've test-run IceCat on my own system and monitored the network
traffic on a number of occasions, including after the update to 91, and
I've not seen evidence of the pinging you describe.  Can you please
elaborate?

> - Actual disabling of WebRTC

Your use of the word "Actual" above seems to suggest that the IceCat
project aims to disable WebRTC.  I'm not aware of any such decision by
the IceCat project.  IceCat *does* set both
"media.peerconnection.ice.no_host" and
"media.peerconnection.ice.default_address_only" to true by default,
however.

Anyway, I'm open to discussing proposed changes to IceCat's default
settings, preferably on the gnuzilla mailing lists.

> - Clearing on re-start (privacy.clearOnShutdown.*)

I'm open to discussing proposed changes to IceCat's default settings,
but I don't think this is what most of our users want by default.

There's at least one setting in <about:preferences#privacy> about this
("Delete cookies and site data when IceCat is closed"), and I'm open to
adding more settings to that page.

> - toolkit.telemetry.enable = false instead of forced true

I consider it a high priority to disable *all* telemetry in IceCat, and
I've made an effort to do so.  I've looked for evidence of telemetry by
monitoring network activity when using IceCat, and I haven't found any.
If you have evidence that any telemetry is actually enabled in IceCat,
*please* show us the evidence.

It is indeed interesting that in <about:config>,
"toolkit.telemetry.enable" is presented as being forced set to true.
I hadn't previously noticed that.

I should say that in addition to (attempting to) set
"toolkit.telemetry.enable" to "false", just as Arkenfox does, we also
set "toolkit.telemetry.server" to "".

  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/data/settings.js?id=32631cac00953abbac61dc7ab1a0eafbdd59b53a#n131

Moreover, we apply some patches to IceCat to fix issues that I
discovered while monitoring IceCat's network activity:

  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/data/patches/moz-configure-changes.patch?id=32631cac00953abbac61dc7ab1a0eafbdd59b53a
  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/data/patches/fix-data-reporting-check.patch?id=32631cac00953abbac61dc7ab1a0eafbdd59b53a
  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/data/patches/disable-settings-services.patch?id=32631cac00953abbac61dc7ab1a0eafbdd59b53a

> Additional configuration should be defined in guix-home with sane
> default so that the browser can be a sufficient replacement for Tor
> Browser Bundle.

Please see Maxime's comments on this, which I agree with.  I'm sorry to
say that I don't see a way for IceCat users to hide that they are
probably using IceCat.  If you require strong anonymity, your best bet
is to use Tor Browser Bundle.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.