Re: Request-Off-The-Record Mode header

Mike West <mkwst@google.com> Mon, 12 June 2023 09:48 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 3E92BC15257A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 02:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.244
X-Spam-Level:
X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 6_9Wak35vzJR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 02:48:42 -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 1A2C2C152575 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 12 Jun 2023 02:48:41 -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 1q8e8P-00EJXp-54 for ietf-http-wg-dist@listhub.w3.org; Mon, 12 Jun 2023 09:46:49 +0000
Resent-Date: Mon, 12 Jun 2023 09:46:49 +0000
Resent-Message-Id: <E1q8e8P-00EJXp-54@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mkwst@google.com>) id 1q8e8N-00EJVY-My for ietf-http-wg@listhub.w3.org; Mon, 12 Jun 2023 09:46:47 +0000
Received: from mail-qv1-xf2a.google.com ([2607:f8b0:4864:20::f2a]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <mkwst@google.com>) id 1q8e8L-00FyA0-VU for ietf-http-wg@w3.org; Mon, 12 Jun 2023 09:46:47 +0000
Received: by mail-qv1-xf2a.google.com with SMTP id 6a1803df08f44-62dee8362b8so3231456d6.2 for <ietf-http-wg@w3.org>; Mon, 12 Jun 2023 02:46:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686563202; x=1689155202; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qp6NWA9CDOih9EqkaTsyriOIGBwiI8LB+fvoZnjQPno=; b=QRe78Cl2Qnny+KKf5gRcRzSUMliAmjFPnFGoaODwvZIS2xeq9hzbLjmvlONr2c5wOO W725yZZwoaBvu5e1Pm/msZtn9/+BDDNvbUs9TXWCO21QV40UftGLTzisy2S45Ve0cl7K pebPCZPHf7WO/PNfkvmY1o4oUoaZ0Lefp9nMy+TCZb+C3aL7jTA/FXKZM5TcUchm1+Tu UkXaNVETKbaDpdjqI9cWoLlRztSsLV/hcErQcA1kR+ZEaHtGcK+Lrhn7MTsPKa24OlM3 SCzfow+RUmJPwBf/Wj+i2ERtafeX789T8ot/sCKRmZmKvmlMPJUf5tirIVhYgQ70vpZv hNmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686563202; x=1689155202; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qp6NWA9CDOih9EqkaTsyriOIGBwiI8LB+fvoZnjQPno=; b=FR3GtnCmsDUFjoM1gH3eIDzNpmyRly1okIa/KzY72nrdpfITSmzdnDk/8CZQkc1sOb k4F7QjUxKGz34iRjtpRa0A60EPYCN+czTeWZ9rJV+KGl7a3uO54MgHBv1qD+Ob9uvSj9 swZDKX46vHM9X50rW34DDjcpjJEONajGZDYF56y4qrBCOCAKYh2FXDr7P2hIeGkhIfk2 FDqAAYaKUPMJiYpnLMAW48EwkGExE/eoVTCVCGIqNwI7VavlqIvTEE7fdIp+gYktoBig qvbZn6rjCOPLJp6iBrtDv0cGFNHUiY3FwnnUBAe7I2bTNFZRSUDHcWQOWQDEdMm7cIQY eoXQ==
X-Gm-Message-State: AC+VfDwX70FJMVqHdLwnazu4tk6CCsjfT54QywceN/OjW7F4Ir/tv3zV stlYBVb4HirTrtxZA1O7RNavVIWByF5MZlRgwTBNEw==
X-Google-Smtp-Source: ACHHUZ6k+bcYdeurNrW4wSnFZkZ4Gnj8ndb1zGdhZT3yI/yAXBloZkV62dniMOhYACZEuaK3S61Qkd2k3/sL6RsSivc=
X-Received: by 2002:ad4:5aea:0:b0:625:aa49:19f1 with SMTP id c10-20020ad45aea000000b00625aa4919f1mr11440021qvh.62.1686563201865; Mon, 12 Jun 2023 02:46:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAG3f7Mi=QVLNdxL5LWxzf-2uAT8KO9B-NWFoaM_HHOvpiPzbRA@mail.gmail.com> <SA1PR00MB1461642051E1C9091088F2D8F750A@SA1PR00MB1461.namprd00.prod.outlook.com> <CAPDSy+4dXuF1YTWAC+v0dAVF5E=+D45v35vL69od718KzAWKqQ@mail.gmail.com> <CAEnXMMp-jQSqJx6kc9rxUJCVQ5LFxLu6RPWcLCpnKcc8p2iF6g@mail.gmail.com> <CAG3f7MhOFfhsW_86fS8dgipMDZ8B8Ft7bD6kZ_ftK9ny0iea0w@mail.gmail.com>
In-Reply-To: <CAG3f7MhOFfhsW_86fS8dgipMDZ8B8Ft7bD6kZ_ftK9ny0iea0w@mail.gmail.com>
From: Mike West <mkwst@google.com>
Date: Mon, 12 Jun 2023 11:46:29 +0200
Message-ID: <CAKXHy=dG21YjgoYdPX=kE62EZPscaYNpYj_f0+6er9k2G6Eu2g@mail.gmail.com>
To: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Cc: Caleb Queern <cqueern@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000008a468e05fdeb9819"
Received-SPF: pass client-ip=2607:f8b0:4864:20::f2a; envelope-from=mkwst@google.com; helo=mail-qv1-xf2a.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=mkwst@google.com domain=google.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1q8e8L-00FyA0-VU 85a3611eeada4a45c07be0f25c1fbc06
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Request-Off-The-Record Mode header
Archived-At: <https://www.w3.org/mid/CAKXHy=dG21YjgoYdPX=kE62EZPscaYNpYj_f0+6er9k2G6Eu2g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51161
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>

Thanks for sending this proposal over. I think it's interesting to both
folks in HTTPWG and WebAppSec, though it seems to me that the protocol
definition is fairly straightforward, while the privacy and implementation
considerations for user agents are likely the important part of the
proposal.

WebAppSec's next meeting is on the 21st. If you're interested in presenting
it there for discussion, I think we'll have room in the agenda:
https://github.com/w3c/webappsec/issues/624.

-mike


On Mon, Jun 12, 2023 at 8:56 AM Shivan Kaul Sahib <shivankaulsahib@gmail.com>
wrote:

> Hey Caleb,
>
> On Thu, 8 Jun 2023 at 14:58, Caleb Queern <cqueern@gmail.com> wrote:
>
>> This feels very similar to what <ahem> some have said about the
>> Clear-Site-Data header both in its utility and risks.
>>
>
> I think one big difference between Off-The-Record and Clear-Site-Data is
> that Off-The-Record is preventative, while Clear-Site-Data is sent after
> the fact. Also, in the case of Clear-Site-Data, the website specifies
> what to clear, while with Off-The-Record the website leaves it up to the
> user agent.
>
>>
>> On Thu, Jun 8, 2023 at 4:52 PM David Schinazi <dschinazi.ietf@gmail.com>
>> wrote:
>>
>>> This sounds very useful for the domestic violence resources use case,
>>> but at the same time I could imagine malware websites abusing it to erase
>>> traces of how a machine got infected. Would it be possible to get user
>>> consent per origin for this?
>>> David
>>>
>>> On Thu, Jun 8, 2023 at 2:42 PM Eric Lawrence <
>>> Eric.Lawrence@microsoft.com> wrote:
>>>
>>>> This generally seems useful.
>>>>
>>>>
>>>>
>>>> I can foresee some user confusion if a user encountered the
>>>> interstitial page when visiting the target site in InPrivate/Incognito
>>>> mode, but I also wouldn’t want to skip the interstitial page in those
>>>> privacy modes (because it could be abused as an oracle that would reveal to
>>>> the site whether a visitor is using a Private Mode already).
>>>>
>>>> In Chromium-based browsers, browser extensions are disabled by default
>>>> while in Private Mode. It does not look like you propose to disable
>>>> extensions from interacting with “Off-the-record” sites?
>>>>
>>>>
>>>>
>>>> *From:* Shivan Kaul Sahib <shivankaulsahib@gmail.com>
>>>> *Sent:* Thursday, June 8, 2023 2:14 PM
>>>> *To:* public-webappsec@w3.org; HTTP Working Group <ietf-http-wg@w3.org>
>>>> *Subject:* Request-Off-The-Record Mode header
>>>>
>>>>
>>>>
>>>> You don't often get email from shivankaulsahib@gmail.com. Learn why
>>>> this is important <https://aka.ms/LearnAboutSenderIdentification>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>