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

[Clément Lassieur]

On Thu, Feb 01 2024, André Batista wrote:

> 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?

Yes I agree.  Perfect is the enemy of good.  I was thinking about
changes that don't make it more difficult to maintain, e.g. using the
same build-options as upstream (when it makes sense).  I don't think
being late on a noscript update will change our bucket anyways, and I
know we can't know for sure.

(For the strongest possible anonymity, people should use Tails...)