From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:5f26::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id GBahHOXegWVBMAAAkFu2QA (envelope-from ) for ; Tue, 19 Dec 2023 19:20:21 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id cIlRGeXegWXeFQEAqHPOHw (envelope-from ) for ; Tue, 19 Dec 2023 19:20:21 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lassieur.org header.s=fm1 header.b=HNnMIs5S; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm2 header.b="W n2eHYw"; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1703010021; 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=1BZ8str+1xh1MbX+C4CeRxUDfc982qvkzRDneIlR8QA=; b=QKR4g3n4K+RLgZo3s4Yhu9D+zlcoQcFU+Nwj1T3tX+tkZK6kkeGxF7hRA1Yio1XF4l24jv kycaoxyzAnYD5gakE1vI2STV4g0xEnG5YGNOwlY9WwCFMkr8OtT1ZMY+QNhgx+ZgRo1b38 x2/pOZkE7yhGUtt+iSS2+lhLQ13crCedaV58+qv4HniylNQhORiN+qJSeQ0NVEWPnDgUJq spZe+Q9XKrXnr6r6RorR5rtlFhEe0cSf/qwU/gGnrXWzp9tKUFR6xDC54tDOkXm20DsyJs OlBlQw3DohctGltK7vf9UhnilQezOCPcLtzIYki3FGP4FnotYGknvBPOxjlw6w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lassieur.org header.s=fm1 header.b=HNnMIs5S; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm2 header.b="W n2eHYw"; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1703010021; a=rsa-sha256; cv=none; b=YmoOUOUajStk7BRgX/Oep+UqPzEjBSVgG8ilXrw9RCeZEdw5zQagAT4rHcX1/z6zx4lF+N M8/T3nEu2Xcb4FV2YEeYylnQzNK9hUWDYC35gxZzFMfd7ygMXpVW3odtpPVCZ5SbjNUqZO k+13YB3uoASewbMGDAEKZGfMKXS2EwBtlZ7CzhwKOB89ngT5aEOBNtWxu7P0ysjRL832SC /lSybYh1rl7CkYgrDIZU+4TUA8/upnqKoer0JGG4kwY/G/OjoEKVa48++eOZE7f0mNvFzi zuxH3mZBYMMtE6nfCjfOneiBsjmQtKZLMCpUdolDu11nXwuYPwFcUo0h+vBEjg== 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 421C743242 for ; Tue, 19 Dec 2023 19:20:20 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFehH-0000xe-Kk; Tue, 19 Dec 2023 13:20:03 -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 1rFehE-0000wb-7I for guix-patches@gnu.org; Tue, 19 Dec 2023 13:20:00 -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 1rFehD-0000pT-VL for guix-patches@gnu.org; Tue, 19 Dec 2023 13:19:59 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rFehG-0005Ez-Ar for guix-patches@gnu.org; Tue, 19 Dec 2023 13:20:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#42380] [PATCH] gnu: Add torbrowser. Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 19 Dec 2023 18:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42380 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: =?UTF-8?Q?Andr=C3=A9?= Batista Cc: 42380@debbugs.gnu.org Received: via spool by 42380-submit@debbugs.gnu.org id=B42380.170300999120118 (code B ref 42380); Tue, 19 Dec 2023 18:20:02 +0000 Received: (at 42380) by debbugs.gnu.org; 19 Dec 2023 18:19:51 +0000 Received: from localhost ([127.0.0.1]:37301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rFeh4-0005EP-3S for submit@debbugs.gnu.org; Tue, 19 Dec 2023 13:19:51 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:58297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rFeh0-0005E9-Pc for 42380@debbugs.gnu.org; Tue, 19 Dec 2023 13:19:49 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8165C5C025E; Tue, 19 Dec 2023 13:19:38 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 19 Dec 2023 13:19:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lassieur.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1703009978; x=1703096378; bh=1BZ8str+1xh1MbX+C4CeRxUDfc982qvkzRDneIlR8QA=; b= HNnMIs5Sl0Yt7Wl7Yrmf+5r2yDUFu2LI4BIeRXXv9939vkLR0HKMGqKw4/bHpZGQ YIqwtjpi4wwHQS35l3hh0O/CgLXEjaN2Ymc4LNfe7+QKlnf/6AQ/vKuzfHReBNKJ 6/4w3EIxWTsuQ0wBh1UckZG9D1lQrTPJ4W3jgpjTLfCIDEB71AKewQpNBQSSQ0qn vqhJ0X8aM5sxoXBOFMpoQHUIpqvnzME2dyjzgdCV6KQVxajOoSM8btnZQz+N6tDj t04HaMu6/FIutBZdkj8Ne0P0Ecis/8mR/AwhBf9UvNbaiMRD4qt0zZ6KKsDSPKpa z6A6A3/bt7zXVMigsHBDyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1703009978; x= 1703096378; bh=1BZ8str+1xh1MbX+C4CeRxUDfc982qvkzRDneIlR8QA=; b=W n2eHYwARjoJFsoRqB3iOwVpg95XTNeJvMHTQelrQaAenAK93d8vuznvFZWVImqhZ gUpyVowOCEKHK9Xl+TVuwgwPEWlzyh92+HroqEpokHzSxTsUL6t5w1K6adhtSmkO WWLfqiEet6/1cKvCENGKfbAL8lOi/d/QE3z/YnchsB6ZB5FPtU1Q1fIosFxm03Zx QZ7Ac2NdhBy0H5MBuK6ZeFukTWVIFHkQ2a8Knu1GU1aoZ1DLWwKY+XEIusqzvRWD suHdi83JNNaTH42sTkG/0gHP77xrEi+Bt7Fvzyuv8yJiP5HyNEk5oP7GDTPrAE68 JHeYxS9PmXRcK2kcRrKzA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddutddgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufgjfhffkfgfgggtgfesthhqredttderjeenucfhrhhomhepvehl rohmvghnthcunfgrshhsihgvuhhruceotghlvghmvghntheslhgrshhsihgvuhhrrdhorh hgqeenucggtffrrghtthgvrhhnpeeljeekvddvjeejfeeiueekgfduieeuieekkeejudeu vedtfedthfduueeikedvteenucffohhmrghinhepvghffhdrohhrghdphhhtthhpshdqvg hvvghrhiifhhgvrhgvvgigthgvnhhsihhonhhishhnohifsghuihhlthdqihhnrdhinhdp thhorhhprhhojhgvtghtrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheptghlvghmvghntheslhgrshhsihgvuhhrrdhorhhg X-ME-Proxy: Feedback-ID: i4c21472a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Dec 2023 13:19:36 -0500 (EST) From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur In-Reply-To: ("=?UTF-8?Q?Andr=C3=A9?= Batista"'s message of "Thu, 14 Dec 2023 18:54:48 -0300") References: Date: Tue, 19 Dec 2023 19:19:32 +0100 Message-ID: <878r5q9hsb.fsf@lassieur.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -5.29 X-Spam-Score: -5.29 X-Migadu-Queue-Id: 421C743242 X-TUID: NFbEZiVFVmnW Hi Andr=C3=A9! On Thu, Dec 14 2023, Andr=C3=A9 Batista wrote: > The noscript addon seems to be missing from the browser. If one goes > to the 'about:addons' tab, it is neither listed nor manageable there. > This makes the security slider almost useless and also implies that > as things stand we would lead guixen to run potentialy harmful and > nonfree javascript code unknowingly and without a warning. > > You can check that on https://coveryourtracks.eff.org for the > difference between this browser fingerprint and the upstream one. [in an other mail] > Please, disregard what I've said above: noscript is indeed listed on the > addons tab, manageable there and the browser security slider is also > working as expected. >=20 > I had just built and run from the store, without installing to a profile > so guix was rightfully not picking up any info on noscript. When properly > installed, it is picked up just fine. >=20 > Please accept my appologies for improperly reviewing it, I should've > known that the bug was between the chair and the keyboard. Well you've done the greatest review I've ever seen so no need to apologize :) Indeed NoScript is a propagated input, so it needs to be installed. You can also test it like this: guix shell --emulate-fhs --no-offload --no-cwd --preserve=3DDISPLAY --container --network torbrowser -- torbrowser Or if you want to add ublock-origin: guix shell --emulate-fhs --no-offload --no-cwd --preserve=3DDISPLAY --container --network torbrowser ublock-origin-icecat -- torbrowser (Note that you'll need either to allow ublock0 to run in private windows or to not be in a private window.) My tests with https://coveryourtracks.eff.org give exactly the same results (between 8 and 9 depending on window size) as the official Tor Browser. > Other than that, the current recipe is not deterministic. This is > probably due to the 'BuildID' which is a timestamp. Indeed I had forgotten about this. And Icecat does it well. > See: (#$output)/lib/torbrowser/platform.ini > > Moreover, both upstream torbrowser and guix' icecat build an > internationalized browser with several locales and the browser as is > offers users on startup to change or set the browser locale even though > we did not provide any other than en-US. > > I don't think the current en-US only is a show stopper, but let's make > a note on internationalizing it later. Yes, but I believe we can add the internationalization as an extension, it would be nicer than doing what Icecat does: torbrowser-minimal and torbrowser with internationalization. When we do this we should probably fix Icecat as well. This is, in my opinion, for another patch. >> A few notes: >> - HTTPS-everywhere extension is now built-in. > > In my understading, the extension got removed as the feature it provided > is now part of firefox itself. Exactly. >> - The name is "torbrowser" because it's obvious that we don't bundle an= ything >> in Guix, that's how other distros do and it's simpler. > > What { is || is not } obvious is highly subjective. Maybe to most people > it is obvious that the distro version of some software is not the > upstream one. On the other hand, maybe it's not obvious to many that, > with regards to TorBrowser's goals, this is a significative difference > as it potentialy implies a reduced anonymity set. I agree that potentially there could be a reduced anonymity, but I've not seen any footprint difference yet and when we see it I'm hopeful we'll be able to fix it. > 'torbrowser-unbundle' was a pun on the original torbrowser name ("Tor > Browser Bundle") and it was intended as some kind of warning to users > that the guix package cannot live up to a vital upstream goal, namely > that all users are using an identical browser in order to avoid, best > as possible, any leak which could be used to fingerprint/deanonymize > users. It was also kind of an homage to upstream directives if you > will. Are there directives about it? I haven't been able to find them. Also OpenBSD names it "torbrowser" and they build it from source too. > However, even if some guix users may be unaware, this is an improvement > to the current situation where people use icecat with tor which > undeniably means a reduced anonymity set. Also, the hint may have been > too weak to convey the intended warning. So I won't strongly oppose > naming it simply 'torbrowser' if I'm the only one who sees a point on > doing otherwise. The main benefit of naming it "torbrowser" is, I believe, simplicity, and the fact that it eases adoption. People will know it's Tor Browser and not some variant. The only real difference with upstream is the fact that we don't store the profile where the executable is (because our store is read-only). I believe this feature is for users who have Torbrowser on a USB dongle that can be removed and then the system is still clean. But that's not really a use-case for us anyway. >> +(define-public noscript/icecat >> + (make-icecat-extension noscript)) > > As I understand it, we are not building noscript from source, but getting > a previously built which has minified JS. I never got to build it from > source and also don't think this makes it uncommitable (agains FSDG), but > maybe we could have a note to re-work this definition later in order to > have it built from source (the guix way!). Does it have minified JS though? I had a look at several files but could not find any that is minified. If it does have minified JS, I agree we should fix it. I actually tried to build it from source but there are a ton of missing Node dependencies. :/ >> +(define-public torbrowser >> + (package >> + (inherit icecat-minimal) >> + (name "torbrowser") >> + ;; To find the last version, browse >> + ;; https://archive.torproject.org/tor-package-archive/torbrowser/ >> + ;; ( is the version of the `torbrowser-assets` package). = There >> + ;; should be only one archive that starts with "src-firefox-tor-bro= wser-". >> + (version "115.5.0esr-13.0-1-build4") > > Is there any reason why you chose to use the 'src' version, instead of > the TorBrowser release version (aka torbroser-assets one). At first I > think it would be better if our version were the same as upstream as > it would be clearer to both users and maintainers which version guix > is offering without installing it. I just wanted the source URL to only depend on the version, and not anything else. That makes it easier to maintain, and it reminds people what it really is: a Firefox. > Besides, are you sure this src version number is guaranteed to be > progressive towards higher numbers? > > Decomposing it: > > Firefox version | tb build ver | tb build attempt > 115.5.0esr | 13.0-1 | build4 > > FF version: always increases, but not necessarily in the same step as > torbrowser releases; > > tb build version: usually remains the same throughout a major torbrowser > release series; > > tb build attempt: varies with the release process and sometimes it > decreases. base-browser-115.1.0esr-13.0-1-build1 Tagging build1 for 115.1esr-based= alpha base-browser-115.1.0esr-13.0-1-build2 Tagging build2 for 115.1esr-based= alpha base-browser-115.2.0esr-13.0-1-build1 Tagging build1 for 115.2.0esr-bas= ed Base Browser alpha base-browser-115.2.1esr-13.0-1-build1 Tagging build1 for 115.2.1esr-bas= ed Base Browser alpha base-browser-115.3.0esr-13.0-1-build1 Tagging build1 for 115.3.0esr-bas= ed alpha base-browser-115.3.1esr-13.0-1-build1 Tagging build1 for 115.3.1esr-bas= ed stable base-browser-115.4.0esr-13.0-1-build1 Tagging build1 for 115.4.0esr-bas= ed stable base-browser-115.4.0esr-13.0-1-build2 Tagging build2 for 115.4.0esr-bas= ed stable base-browser-115.4.0esr-13.5-1-build1 Tagging build1 for 115.4.0esr-bas= ed alpha base-browser-91.12.0esr-12.0-1-build1 Tagging build1 for 91.12esr-based= alpha Here are some refs I've found in the git repo. We can see that for the same "tb build version" (13.0-1) there are several base browser versions: 115.1.0, 115.2.0, 115.2.1, etc. build1 goes to build2 only when both "base version" and "tb build version" don't change. In this example we can see a 13.5-1, which means alpha, which we never want. So version string being monotonically increasing doesn't really help: guix package --upgrade won't work anyway. I think the version should describe fully what we are packaging, and in this example, we can see that 13.0.1 isn't enough. I might be wrong though, what do you think? >> + (source >> + (origin >> + (method url-fetch) >> + (uri >> + (string-append >> + "https://archive.torproject.org/tor-package-archive/torbrowser= /" >> + (package-version torbrowser-assets) >> + "/src-firefox-tor-browser-" version ".tar.xz")) >> + (sha256 >> + (base32 >> + "0p0qsfc2l2bicqjr1kxciiij5qz7n8xqyvyn8f13fvk0wyg94c6v")))) >> + (build-system mozilla-build-system) >> + (arguments >> + (substitute-keyword-arguments (package-arguments icecat-minimal) >> + ((#:configure-flags flags '()) >> + #~(cons* >> + "--without-relative-data-dir" ;store is read-only > > Shouldn't we also set '--with-user-appdir=3D.torbrowser' ? > > There is a comment on 'src/browser/config/mozconfigs/tor-browser' that > says we need to set this flag when the relative data dir is unset. They say it indeed, but they don't use it in the code^^. set_define("MOZ_USER_DIR", user_appdir) [...] #define DEFAULT_PRODUCT_DIR nsLiteralCString(MOZ_USER_DIR) [...] #if !defined(TOR_BROWSER) rv =3D localDir->AppendRelativeNativePath(DEFAULT_PRODUCT_DIR); if (NS_FAILED(rv)) { return rv; } #endif But you are right, I'll add it anyway, we never know, they might change the code later. >> + "--disable-base-browser-update" >> + "--enable-update-channel=3Drelease" > > Does this mean that users get notified when there is a new torbrowser > release upstream? Shouldn't this flag be removed? No, there is a channel anyway, we just change it from "default" to "release". Otherwise this code gets executed: @depends("--enable-update-channel") def tor_browser_nightly_build(channel): if channel and channel[0] in ["default", "nightly"]: return True And we get warnings of instability because it thinks it's a nightly while it's not. I'll add a comment! >> + ;; WM_CLASS (default is "$MOZ_APP_NAME-$MOZ_UPDATE_CHAN= NEL"). > > This comment was unclear for me at first, probably due to my own > ignorance. To the benefit of others, this is in line with instructions > on 'src/browser/config/mozconfigs/tor-browser' as a hint to window > managers on GNU/Linux. Yeah it's just a way for windows (e.g. in Gnome) to know to which left-bar button they are associated. >> + (format #t "// first line must be a comment~%") >> + ;; Locking prevents these values being written to >> + ;; prefs.js, avoiding Store path capture. >> + (format #t "lockPref(~s, ~s);~%" >> + "extensions.torlauncher.torrc-defaults_pa= th" >> + (in-vicinity >> + lib "TorBrowser/Data/Tor/torrc-defaults"= )) >> + (format #t "lockPref(~s, ~s);~%" >> + "extensions.torlauncher.tor_path" >> + (search-input-file inputs "bin/tor")) > > This has the undesired side-effect of making impossible to run TorBrowser > with a shepherd tor instance. Is it really needed? I don't think so, I'll change it. > Besides the inefficiency of running two tor processes, using a single one > has the benefit of making eventual onion service auth keys available both > on the browser and to other user software on the same location. Yeah I agree. >> + (replace 'install-desktop-entry >> + (lambda _ >> + (let ((apps (in-vicinity #$output "share/applications")= )) >> + (mkdir-p apps) >> + (make-desktop-entry-file >> + (in-vicinity apps "torbrowser.desktop") >> + #:name "Tor Browser" >> + #:exec >> + (format #f "~a %u" (in-vicinity #$output "bin/torbro= wser")) > > Why do away with the 'start-tor-browser.sh'? Part of the logic there is > redundant or not necessary on a system install, but not everything. The file is 384 lines long, and most of it is not compatible with having a read-only store. Patching it would require a huge patch for almost 0 gain, we would be better off with a small wrapper if really there are things we need to wrap. But are there things we need from this file? I haven't found any. >> + (inputs >> + (modify-inputs (package-inputs icecat-minimal) >> + (append bash-minimal >> + tor > > Why not tor-client instead? I don't see a legitimate use case of running > relays on the torbrowser. Indeed! > Also, shouldn't this be a propagated input so as to not be garbage > collected? > >> + torbrowser-assets))) >> + (propagated-inputs >> + (list noscript/icecat)) I don't think being propagated would change anything regarding to garbage collection. Normal inputs are protected as well. But your point is good, I need to test that everything goes well when tor is upgraded and the previous one garbage collected. I believe worst case scenario is we need to use "lockPref ... tor_path" instead of "pref ... tor_path" to prevent the store paths to go into the profile. > Thanks for your work on guix and cheers! I'll send an updated patch soon, and I'll test garbage collecting tor. Also, I'm working on packaging Mullvad Browser too, which is almost the same work as Tor Browser, so we'll have 2 browsers for the same price! It's more-or-less a Tor Browser without the Tor network, that encourages the use of a VPN. (And WebRTC is enabled in Mullvadbrowser while it's not yet enabled in Tor Browser). Thank you again for this great review Andr=C3=A9 :) Cl=C3=A9ment