From: "Clément Lassieur" <clement@lassieur.org>
To: "André Batista" <nandre@riseup.net>
Cc: Mark H Weaver <mhw@netris.org>,
68577@debbugs.gnu.org,
Jonathan Brielmaier <jonathan.brielmaier@web.de>,
Ian Eure <ian@retrospec.tv>
Subject: [bug#68577] [PATCH v2 2/2] gnu: Add mullvadbrowser.
Date: Fri, 02 Feb 2024 13:03:30 +0100 [thread overview]
Message-ID: <87ttmrcbu5.fsf@lassieur.org> (raw)
In-Reply-To: <ZbxK9DmFgkxnHZMx@andel> ("André Batista"'s message of "Thu, 1 Feb 2024 22:52:52 -0300")
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...)
next prev parent reply other threads:[~2024-02-02 12:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 23:14 [bug#68577] [PATCH 0/2] gnu: Add Mullvad Browser Clément Lassieur
2024-01-18 23:19 ` [bug#68577] [PATCH 1/2] gnu: icecat: Improve inheritance Clément Lassieur
2024-01-22 6:09 ` Mark H Weaver
2024-01-22 11:25 ` Clément Lassieur
2024-01-22 18:42 ` André Batista
2024-02-03 19:28 ` Mark H Weaver
2024-02-07 15:52 ` Clément Lassieur
2024-01-18 23:19 ` [bug#68577] [PATCH 2/2] gnu: Add mullvad-browser Clément Lassieur
2024-01-22 5:57 ` Mark H Weaver
2024-01-22 6:15 ` Mark H Weaver
2024-01-22 11:41 ` Clément Lassieur
2024-01-22 10:33 ` Clément Lassieur
2024-01-19 5:49 ` [bug#68577] [PATCH v2 0/2] gnu: Add Mullvad Browser Clément Lassieur
2024-01-19 5:11 ` [bug#68577] [PATCH v2 1/2] gnu: icecat: Improve inheritance Clément Lassieur
2024-01-19 5:12 ` [bug#68577] [PATCH v2 2/2] gnu: Add mullvadbrowser Clément Lassieur
2024-01-22 5:29 ` [bug#68577] [PATCH 0/2] gnu: Add Mullvad Browser Mark H Weaver
2024-01-22 10:23 ` Clément Lassieur
2024-01-22 12:10 ` Clément Lassieur
2024-01-25 22:41 ` [bug#68577] [PATCH v2 0/2] Stop inheriting Icecat and add " Clément Lassieur
2024-01-25 22:54 ` [bug#68577] [PATCH v2 1/2] gnu: torbrowser: Stop inheriting Icecat Clément Lassieur
2024-02-01 23:46 ` André Batista
2024-02-02 11:04 ` Clément Lassieur
2024-01-25 22:55 ` [bug#68577] [PATCH v2 2/2] gnu: Add mullvadbrowser Clément Lassieur
2024-01-31 16:20 ` Clément Lassieur
2024-02-02 1:52 ` André Batista
2024-02-02 12:03 ` Clément Lassieur [this message]
2024-02-04 1:53 ` Clément Lassieur
2024-02-04 1:48 ` [bug#68577] [PATCH v3] " Clément Lassieur
2024-02-05 14:10 ` bug#68577: " Clément Lassieur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttmrcbu5.fsf@lassieur.org \
--to=clement@lassieur.org \
--cc=68577@debbugs.gnu.org \
--cc=ian@retrospec.tv \
--cc=jonathan.brielmaier@web.de \
--cc=mhw@netris.org \
--cc=nandre@riseup.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).