[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52236: PRIVACY: Integrate arkenfox for icecat configuration
From: |
Jacob Hrbek |
Subject: |
bug#52236: PRIVACY: Integrate arkenfox for icecat configuration |
Date: |
Sat, 04 Dec 2021 00:31:30 +0000 |
> 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.
publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature