From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 3XwdKGrEqmFRnwAAgWs5BA (envelope-from ) for ; Sat, 04 Dec 2021 02:29:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 2DjvImrEqmGsbQAAbx9fmQ (envelope-from ) for ; Sat, 04 Dec 2021 01:29:14 +0000 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 3FEE1E033 for ; Sat, 4 Dec 2021 02:29:14 +0100 (CET) Received: from localhost ([::1]:51480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtJrV-0000QE-Dp for larch@yhetil.org; Fri, 03 Dec 2021 20:29:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtJrK-0000Pp-PO for bug-guix@gnu.org; Fri, 03 Dec 2021 20:29:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:40937) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mtJrK-0006Zg-JX for bug-guix@gnu.org; Fri, 03 Dec 2021 20:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mtJrK-0003Xn-8Q for bug-guix@gnu.org; Fri, 03 Dec 2021 20:29:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#52236: PRIVACY: Integrate arkenfox for icecat configuration Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 04 Dec 2021 01:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52236 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Jacob Hrbek , Maxime Devos Received: via spool by 52236-submit@debbugs.gnu.org id=B52236.163858128513557 (code B ref 52236); Sat, 04 Dec 2021 01:29:02 +0000 Received: (at 52236) by debbugs.gnu.org; 4 Dec 2021 01:28:05 +0000 Received: from localhost ([127.0.0.1]:52483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtJqP-0003Wa-0M for submit@debbugs.gnu.org; Fri, 03 Dec 2021 20:28:05 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:34367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtJqK-0003W5-MW for 52236@debbugs.gnu.org; Fri, 03 Dec 2021 20:28:04 -0500 Received: by mail-wr1-f68.google.com with SMTP id j3so9417394wrp.1 for <52236@debbugs.gnu.org>; Fri, 03 Dec 2021 17:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=pSBlPhk7Y5N3S8FRcXrh63hJOb2fyYZR2EgJq3QawPw=; b=J6eNh4FvG/Za55/y5plLeb5TsZ+WEbtlOItRc3paGjbXKX5A6ViJaBX0vHzAO2sVkG usAZuTe8dWbwIHWPz33i4MbmiOnVcZMBzSPXOUEaNzD3g1JWCymdT1Bh6OD/57hmKniu XJi0ox1nwkGV5L4H+mWf/txa6jOBJwn8mTw0v4jVuvQ2GYcGTZvsrnf6+ZgYziZxu+ai C/UZxthGx/89EQTu2IJ/Ylcz5q1bQwklVwvDJ5O99/bbi/kSuwlw6UaZ1m5ZtAwJ05sF pmCpxU3SedYnS8Tmb3kaanQwpNVkLXUtjS+jFcA/ZrtBRu+Q5pIIW9SMOA/Npb0Tr2S2 e8zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=pSBlPhk7Y5N3S8FRcXrh63hJOb2fyYZR2EgJq3QawPw=; b=lT8PKcnL0nWqp6Oi8tbugDrfpimTtxfDyDL+HsKY1mJ0+Q4KwkrgjLWiFdjJLeZtlx YnNnd/MLnDU/znyjD+9sVUykxAYud8CbQvpGIAvg/w6HqWkDj5rONkTEXLhmmDEgdO6J LS+7vNnR4yHYXqynnJM5/8IigPWckxmZWK7NisyrWz7spmYxQuoM2CJJ0HVgp+XkKtKR rn04I2TPD5Yu45GkhsxavaFp9J9hflc5O4CeXlbcdBlwedftupceZ++S84trvIzsDnak Kbi0eAgjJJWq7bRyddEI+ZGc3+SdjPzBPIz/53uw0QO2SxDIS1eXQlCsD0VpwJMYL95v cf7A== X-Gm-Message-State: AOAM531RXzsDhwz6xUFBvoJI71Re/cEiJMvFuqLXLeJOuhmaSpZG0K9F f9lvqQ1b8nKohq/Gjmd6OUg= X-Google-Smtp-Source: ABdhPJw69yz2BlyXXEc3j8pw9sHAVGfPokwCuINGEnNL3ncRkjxD+nlfXAd5bnXqecRuut+cXEq3IA== X-Received: by 2002:a5d:6707:: with SMTP id o7mr26399279wru.172.1638581274519; Fri, 03 Dec 2021 17:27:54 -0800 (PST) Received: from nijino.fritz.box ([85.127.52.93]) by smtp.gmail.com with ESMTPSA id v8sm3934106wrd.84.2021.12.03.17.27.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 17:27:53 -0800 (PST) Message-ID: <44e17b9e10a321ca6c39ea8328b523170ebf4496.camel@gmail.com> From: Liliana Marie Prikler Date: Sat, 04 Dec 2021 02:27:48 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 52236@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638581354; 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=pSBlPhk7Y5N3S8FRcXrh63hJOb2fyYZR2EgJq3QawPw=; b=T4grfDOh/XXk2UVjMBF7nq7xr1WXc98hQQuFygs6Cd0JFwj+9Rt36LNjmvkpAGM21I9qoJ JijoSMSU4sM7CHEcGkBO//JVMVeJh4FA/CzOnVKnkfBA3x0YF6O6vqflDLKxfdp4UObgri 69cK9JBs+PWk27DKCinc7OWNlR7O5M0zjgKnEslUGjAWGZSsbmhj+fNr3IAVsamtGwLY0L MjS3GcPgJAquFrb93qhDywSliD2lxPYa8pS5YlMF47nQ2GcFxI/P5VY8WKAg+ph6B6deMW pW272JC+iI2jqYyWJ4UYGzvjMPThuDNj+sCQPgnpBXnY2eTWwfdBPgebjaKs/A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638581354; a=rsa-sha256; cv=none; b=WUrAmgQlDyaseeMy6Y9zxORphrO3oZZN0Nv7eFdP/nZDoPZhzTQSVUIJL+YfCjCClQWIYl 5RAyRBn7IVjPgfIlhUfvuo9VdOKwJ84frf2Aq7m/dtPvjRiAbVorhW2SvZXkij4d+VQ78l tvni1wiOymgZ6LdzKFWHVzuiF/84mxzQ6GeEnNm4KdRVy2hNwXPlAFK4FySYKZ+0LXwP1r k4TzipG2ao4qlGq6kv6EfmwHQddU+z9gn1dIu5I0kki/cGwltMDzcJU1tHJlhayZkrlY10 52X6HAhsDZhYd0inxCzhE+ImHAamEFvkAvs7DOELBVj7rp209Oxj77r4OO3wXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=J6eNh4Fv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.83 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=J6eNh4Fv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3FEE1E033 X-Spam-Score: -1.83 X-Migadu-Scanner: scn0.migadu.com X-TUID: //vn89Kd41by Am Samstag, den 04.12.2021, 00:31 +0000 schrieb Jacob Hrbek: > arkenfox is a **TEMPLATE** we can't just paste it in userland and > expect peak security instead we should process the template and > integrate the configuration in parametrisation with cherrypicked > defaults to **generate** the user.js and enable the user to configure > it from config.scm or alike. This is the thing that makes the least sense about this proposal. Like, even if we were to write a service that allows user.js generation through guix home, there'd be no reason to adopt arkenfox or any other template for that matter. People would have to adapt their templates to the guix home workflow, which would hopefully not be more difficult than writing some gexp. > To provide context: Browser fingerprinting works by using [a bunch of > side-channels that are hard to all disable completely...] > [...] > NOTE: For those reasons minimal browsers such as nyxt and surf have > the potential to be more private, but from the point of view of an > attacker it's just different vector for an attack so firefox should > be preferred as it gets more development to address these issues > quickly. I'm pretty sure that using (a) Firefox (variant) is the only reliable way to circumvent side-channel based fingerprinting as noted above since you probably won't be able to patch all variants (especially not those you aren't aware of yet), so better to only leak that you're "a Firefox user". That is until Chromium has all the market share and we need to switch to the bigger fish for anonymity. > > Geolocation is disabled by default in IceCat. When you say that > > "it's pinging google servers currently", have you observed this in > > its default configuration, or did you enable Geolocation? -- > > Weaver > > I use custom configuration so I was not aware of that being default You might want to generate your custom configuration with arkenfox then, so that Geolocation is always disabled. > but even then just simple "default" is not enough where the issue is > that there might be vulnerabilities that access the geolocation data > even when it's disabled so everything in the browser (in my proposal) > should be treated as compromised and layer defences so in this > example: Again, have you observed this? > Even if geolocation is disabled we can't afford treating the value in > prefs.js as not a concern and just keep google there we have to treat > it as compromised at all time and treat it as that it might get used > at some point to use either: > a) value that breaks geolocation when accessed (vulnerability might > allow the attacker to inject their own value) > b) if it's ever accessed or use more privacy-oriented provider such > as mozilla allegedly (preferably if GNUzilla made their own > geolocating thing). It'd probably be feasible to clear the value by default, but then again, that'd not really help with custom configs created from a "trusted" template, would it? > > Your use of the word "Actual" above seems to suggest that the > > IceCat project aims to disable WebRTC. I'm not aware of any such > > decision by the IceCat project. -- Weaver > > I was told by FSF representative that icecat's compilation does not > include support for WebRTC by default when i was invitted on the > associate member meetup so i was basing that opinion on that. This does not mean, that it's intentional, however. It could also be just a bug that they haven't figured out yet. For example, WebRTC in Webkit requires gst-plugins-bad, which is bad... > If that is not a goal then disabling it in the settings is sufficient > and preferred for me where i assumed there being reasoning for it to > be outcompiled like that due to it being reasonably new technology > which seems to be the common reason to do such thing. Again, no statement about an "aim". > > -- Weaver > > This is a discussion that gets exponentially more complicated the > more we talk about it so i propose some written way of managing all > these values to be used for implementation where my initial idea was > wiki? So that the end-user can just search the value and find all the > relevant information to make the decision for their threat model. I'm pretty sure you don't need a Wiki to look up the invocation for ls, do you? Similarly, to configure Emacs you would first consult the Emacs manual, no? Guix does currently in no way interfere with your ability to mess with Icecat's configuration, any documentation with that regard is therefore Icecat/Firefox' burden, not Guix'. > NOTE: I would also argue for icecat to just have disabled settings > page with prefs.js set as read-only and owned by room with permission > to read by the relevant user to reduce the risk of vulnerability or > malicious extension altering the config. To be fair, that'd be a nice quality to have, but you'd also have to make the directory itself read-only in that case and at least I personally haven't checked how well browsers like not being able to write in their "dump everything" directories. You might have more success using containers in which the files are writable, but not synced back to disc. That also gives you a playground to experiment with potentially malicious extensions. On that note, you probably shouldn't mess around with extensions as a journalist. Cheers