[bug#68577] [PATCH v2 2/2] gnu: Add mullvadbrowser.

[André Batista]

Hi guix,

qua 31 jan 2024 às 17:20:14 (1706732414), clement@lassieur.org enviou:
>
> (...)
> 
> To make things clear : our goal is for our Tor Browser users to be in
> the same bucket as upstream Tor Browser users, and for our Mullvad
> Browser users to be in the same bucket as Mullvad Browser upstream
> users.

I think we should aim for that and be as close as possible but no closer.

What I mean is that we should not strive for bug for bug compatibility.
Suppose there's a new torbrowser release and then, one week later, a
new noscript release. Should we then freeze noscript and wait for a new
torbrowser? Should we create a new noscript/torbrowser package? What
about other inputs? The build system?

I don't know if it's at all possible to guarantee that guix users will be
on the same bucket as other GNU/Linux users of the upstream binaries, but
I guess it will be way too much work to even try it. That's what I meant
way back when I suggested the 'torbrowser-unbundle' name and said that
if one wants the strongest possible guarantee of anonymity, one should
then use the upstream binaries (they are sure the largest anonymity
bucket).

In that sense, having torbrowser on guix is a sure improvement over using
tor+icecat. All guix users in this scenario are on a bucket that is easy
to tell apart (not even the user-agent string is the same). So we've made
the work needed to tell apart guix users from other GNU/Linux users way
harder.

>From now on, what I suggest is that we think on the economics of getting
each step closer to be indistinguishable from upstream. Are the proposed
changes easily maintainable? Do they substantially increase the burden on
guix build servers? Is the change making the work of those trying to
deanonymize surely more expensive?

If the burden is heavy on us but the proposed changes do not make the
work of those intent on deanonymizing way harder/more expensive, it's
unreasonable to apply them.

Thoughts?