Re: Request-Off-The-Record Mode header
Dennis Jackson <ietf@dennis-jackson.uk> Mon, 12 June 2023 11:05 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794CAC151701 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 04:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.746
X-Spam-Level:
X-Spam-Status: No, score=-7.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8I3oDpNxXyl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 04:05:39 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC049C1516EA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 12 Jun 2023 04:05:39 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1q8fMU-00EWea-SY for ietf-http-wg-dist@listhub.w3.org; Mon, 12 Jun 2023 11:05:26 +0000
Resent-Date: Mon, 12 Jun 2023 11:05:26 +0000
Resent-Message-Id: <E1q8fMU-00EWea-SY@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <ietf@dennis-jackson.uk>) id 1q8fMS-00EWd5-H6 for ietf-http-wg@listhub.w3.org; Mon, 12 Jun 2023 11:05:24 +0000
Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <ietf@dennis-jackson.uk>) id 1q8fMQ-009XW8-JU for ietf-http-wg@w3.org; Mon, 12 Jun 2023 11:05:24 +0000
Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4QfpkK2j85z9sn9 for <ietf-http-wg@w3.org>; Mon, 12 Jun 2023 13:05:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1686567913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Uas3rHqK/nxU6wxh3IVvpOZNQa+8q7VBj74mLL2o0+4=; b=M+Wo2iPcQK2xHqb8+cPNQQIZ3lQq7FEGLsjSwe5vnLKf6WvoCF3VHhP2e+Jud/wwhD6hiT v45FWRh+BJCG6ZZhqPFg8q8mlyTYqzkBIWupsCnrxmLjmH1xSMC9EyGrbSLfvY0IRnxHsE jUx4Bvx0bwrFC6TfbcTUCdBw3hyaetCh9ONhB/0IpMZrh3fpm9ALYPyQVuvg0hUuBzd3+b 77945/xupw8CIkIFv6Z9YF5Jmg9NwhxkET8SltQ0sK7CEdHLla1/bCD/qMQ8v/J9RdVtu3 OrXBVOWfAdB/eQe+iQbpyn454wEj5iqKHMajpZaLURwiP4piEqBir+3AmBTx0A==
Message-ID: <70c8b58a-9b54-3c52-7cee-73e1941203e0@dennis-jackson.uk>
Date: Mon, 12 Jun 2023 12:05:11 +0100
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CAG3f7Mi=QVLNdxL5LWxzf-2uAT8KO9B-NWFoaM_HHOvpiPzbRA@mail.gmail.com>
Content-Language: en-US
From: Dennis Jackson <ietf@dennis-jackson.uk>
In-Reply-To: <CAG3f7Mi=QVLNdxL5LWxzf-2uAT8KO9B-NWFoaM_HHOvpiPzbRA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2001:67c:2050:0:465::101; envelope-from=ietf@dennis-jackson.uk; helo=mout-p-101.mailbox.org
X-W3C-Hub-DKIM-Status: validation passed: (address=ietf@dennis-jackson.uk domain=dennis-jackson.uk), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1q8fMQ-009XW8-JU 5881d3c82b968fcbbc89a6a5456fa293
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Request-Off-The-Record Mode header
Archived-At: <https://www.w3.org/mid/70c8b58a-9b54-3c52-7cee-73e1941203e0@dennis-jackson.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51162
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
I'm concerned about how users are going to understand this kind of feature. My mental model of the current best practice recommended by sensitive sites is: 1. Users open their browser's version of private browsing. 2. Users enter the name of their website into the address bar and perform a search (user's can't bookmark or have browser history suggest this page due to the threat model and few users will type out proper domains). 3. Users navigate to the site. However, if user's neglect to use private browsing and rely on OTR mode, their search term is still going to be saved in their browser history and most likely in their search engine history (e.g. Google Search's Web History). Testing this on Brave Nightly on Linux left my search term "love is respect" in my page history after using OTR mode to visit the site. This information is just as useful to an abuser and means that users of OTR may incorrectly assume it is effective in this common use case and equivalent to using a private browsing mode. The user agent could prune the navigation history leading to the OTR page, but this is going to make the allow-listing safeguard ineffective against abuse since attackers can redirect page loads to benefit from the retrospective wipe. In the announcement post, it was highlighted that you're engaging with academics to evaluate user understanding of this new mode. Have they already weighed in on this question? Is it feasible to evaluate whether this feature's privacy improvement for users navigating directly to a sensitive site without privacy browsing outweighs the privacy reduction for users who would have used private browsing but no longer perceive it as necessary? Best, Dennis On 08/06/2023 20:14, Shivan Kaul Sahib wrote: > Hi folks, this is a head's up and early request for feedback: > > Brave is shipping support for an HTTP response header sent by a > website that wants the client to treat the website as "off-the-record" > i.e. not store anything in storage, not record the site visit in > history etc. Kind of like incognito/private browsing mode but > site-initiated and only for a specific website. The header is simple: > it would look like `Request-OTR: 1`. Some details here: > https://brave.com/privacy-updates/26-request-off-the-record/#request-otr-header. Currently > we bootstrap for websites that have expressed interest in this (mainly > websites that have help resources for domestic violence victims, which > was the driving use-case) by preloading a list of websites into the > browser, but it would be nice to standardize the header. We're > considering doing the work in the HTTP WG at IETF: it's envisioned to > be a simple header. > > I see that this idea was previously discussed in W3C WebAppSec: > https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0016.html, > and there was a draft Mozilla spec: > https://wiki.mozilla.org/Security/Automatic_Private_Browsing_Upgrades, > though as a CSP directive. > > Happy to hear what people think. > >
- Request-Off-The-Record Mode header Shivan Kaul Sahib
- RE: Request-Off-The-Record Mode header Eric Lawrence
- Re: Request-Off-The-Record Mode header David Schinazi
- Re: Request-Off-The-Record Mode header Martin Thomson
- Re: Request-Off-The-Record Mode header Watson Ladd
- Re: Request-Off-The-Record Mode header Anne van Kesteren
- Re: Request-Off-The-Record Mode header Ángel
- Re: Request-Off-The-Record Mode header Shivan Kaul Sahib
- Re: Request-Off-The-Record Mode header Shivan Kaul Sahib
- Re: Request-Off-The-Record Mode header Greg Wilkins
- Re: Request-Off-The-Record Mode header Shivan Kaul Sahib
- Re: Request-Off-The-Record Mode header Shivan Kaul Sahib
- Re: Request-Off-The-Record Mode header Mike West
- Re: Request-Off-The-Record Mode header Dennis Jackson
- Re: Request-Off-The-Record Mode header Caleb Queern
- Re: Request-Off-The-Record Mode header Mike West
- Re: Request-Off-The-Record Mode header Caleb Queern
- Re: Request-Off-The-Record Mode header Shivan Kaul Sahib