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.
>
>