From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id +MncC0lLvGVjxAAAqHPOHw:P1 (envelope-from ) for ; Fri, 02 Feb 2024 02:54:17 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id +MncC0lLvGVjxAAAqHPOHw (envelope-from ) for ; Fri, 02 Feb 2024 02:54:17 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b="fC/iLKn5"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706838853; a=rsa-sha256; cv=none; b=dzfyiHinoA4cv2GRRisXNeaSvvmgoJLMCkKrPDTwdQHQAe01JjzSFQTiGgLKZ+qfkX9U6e AHYx0XKS54SyWQXNTZTROUTY3zJoY+oOUD/PU/K9e4f+So4Y5wyhiG3l/2wkYrdqRCTo8S Ly05Rh1FxoGFQrsSw/vQ8rYfq+xN/oY29rxtBVPXmHzQLP9I8IfiJsHOYrUj7Dp8GZSCN9 nmN1VJXk07/fu1fMSZ7nazAqImf+wKMTZvouXWdwdUP45C9giDn7ZsatyQQa5TmSSOS3MD DjlEwStCDTmNmchbjzeJDbUWbivBApMT2LIqt1uDkxf/xXpc2bhz7kGoT/mLwQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b="fC/iLKn5"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706838853; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=X613grWcpTMBpF3LkwLJGo+HAB3fR6AUPVKww4lnJVI=; b=DvQyScNb5kKYJbtyV4mBASdkC1Y83meHW0v3i16G4ncbGz4UoRh2v3CXMl5YKWTTCIXU/C QrT7k6b6OoUcnK7ctNo82IiU0XhQ0TEq519NVikuuTxHsaZs7KXJhHB9rI2nJSm/+/bvSJ tqiH2kFkvCgF/NEJP5/3F0BBIRgY+t4MgkQCIKRtMxT6k5ewe72t9W7Lk3wW2KUt+jekgh HDmnIbpZ8lY2LSFUrHMsADnShNTQQXJVdKYg46dIKhh/a8V+gm7fYz/tiyK0GOFSAvNMyr d3OUyloN0TSiqCjEDll/mV5sJbtXE4+lKqUqjEefjeo1LJX5a+7HF84zLHDnAA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CAADA6A0BB for ; Fri, 2 Feb 2024 02:54:12 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVikb-0005dF-FV; Thu, 01 Feb 2024 20:53:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVika-0005d7-8d for guix-patches@gnu.org; Thu, 01 Feb 2024 20:53:52 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rVikZ-0006S3-TZ for guix-patches@gnu.org; Thu, 01 Feb 2024 20:53:51 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rVikk-000632-A0 for guix-patches@gnu.org; Thu, 01 Feb 2024 20:54:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#68577] [PATCH v2 2/2] gnu: Add mullvadbrowser. Resent-From: =?UTF-8?Q?Andr=C3=A9?= Batista Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 02 Feb 2024 01:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68577 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Cc: Mark H Weaver , 68577@debbugs.gnu.org, Jonathan Brielmaier , Ian Eure Received: via spool by 68577-submit@debbugs.gnu.org id=B68577.170683881923215 (code B ref 68577); Fri, 02 Feb 2024 01:54:02 +0000 Received: (at 68577) by debbugs.gnu.org; 2 Feb 2024 01:53:39 +0000 Received: from localhost ([127.0.0.1]:43372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVikN-00062N-63 for submit@debbugs.gnu.org; Thu, 01 Feb 2024 20:53:39 -0500 Received: from mx0.riseup.net ([198.252.153.6]:41436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rVikK-000629-Gc for 68577@debbugs.gnu.org; Thu, 01 Feb 2024 20:53:37 -0500 Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4TQzM36NkVz9tMg; Fri, 2 Feb 2024 01:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1706838800; bh=rJ05fjC/993h0/o5Tfu6R+ZfSyY8/zN9TYQtVQXpg98=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fC/iLKn55hVB/bH2ZMK/hwr/voBwVK8bikw/XzR1M5VE88zCRuRl8uRiNYxQnWI1U iWl/Gybs7M1n1X4njiGcouaCJCQHGw/KTjxJ3bN8cRvh11pnAJ8mGj8hZN751EItCq JTFefn/+FmTG5V9Sm8HfXdV/HGYSxDAvduJtFaJ8= X-Riseup-User-ID: 13AF77C3E52DF95F1DDC398206A41D61C0528F741967916E292E3226CA02B340 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4TQzM129KczFv3r; Fri, 2 Feb 2024 01:53:17 +0000 (UTC) Date: Thu, 1 Feb 2024 22:52:52 -0300 From: =?UTF-8?Q?Andr=C3=A9?= Batista Message-ID: References: <994cb541ca6331c8e69c9be725c1fce72bd8b08f.1706222112.git.clement@lassieur.org> <87jznp8og1.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87jznp8og1.fsf@lassieur.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Spam-Score: -5.17 X-Migadu-Queue-Id: CAADA6A0BB X-Migadu-Spam-Score: -5.17 X-TUID: bEYUlTb95U7Z 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?