Re: Request-Off-The-Record Mode header

Caleb Queern <cqueern@gmail.com> Mon, 12 June 2023 13:27 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 4D6CDC151988 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 06:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.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 A9TDqk6d5Ee1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 12 Jun 2023 06:27:37 -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 25CC3C151079 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 12 Jun 2023 06:27:36 -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 1q8hXk-00EvDT-Ua for ietf-http-wg-dist@listhub.w3.org; Mon, 12 Jun 2023 13:25:12 +0000
Resent-Date: Mon, 12 Jun 2023 13:25:12 +0000
Resent-Message-Id: <E1q8hXk-00EvDT-Ua@lyra.w3.org>
Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from <cqueern@gmail.com>) id 1q8hXj-00EvCb-8g for ietf-http-wg@listhub.w3.org; Mon, 12 Jun 2023 13:25:11 +0000
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 <cqueern@gmail.com>) id 1q8hU3-00EuqQ-Ne; Mon, 12 Jun 2023 13:21:23 +0000
Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <cqueern@gmail.com>) id 1q8hU1-00G2Rr-PM; Mon, 12 Jun 2023 13:21:23 +0000
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-514953b3aa6so6075538a12.1; Mon, 12 Jun 2023 06:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686576077; x=1689168077; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tL7baxDkJpcL8j9aceuiegwnmHdmxvc9hFnELHXVWtw=; b=SyYsAA2YMgRGh1/YB2Lwu1LlVggXWykvXsn+D/FbhZBoVofvMmyYI1mmP6XU/BHBOP UbOYDLxmeYrHAJJ+3u1I0210gUD4KvWueRaG834QUxe6FLEM1yXkQt3/yBCQj+4iT/7f 76wyfkiZpqoIL2tkvlwonD/HE9CDKxeLR4ZeEbTWmrNRN/iiuSzLMoIV28woUCYIZeKz W4DwqjYoIAaybFZnAcyAQ+owqu2aLW78g7s/11iuYpql6ZG9iKq8FawtRVJ5vknDmFH7 TAYVUgZNgJslE7OJmd3GHZIZsURq67Jl/DiMUnRu7nUtzC1vg6BkBeXEiB5mzjwX1Coo kD1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686576077; x=1689168077; 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=tL7baxDkJpcL8j9aceuiegwnmHdmxvc9hFnELHXVWtw=; b=FfhH708KS0SKN+xspdqreB6LbfIcs0g1kja3ng5RrZxzNXwyNZihYMzyF2SlAKp3UZ KpF6fbog3HO8jdEDs+S5RCGoNwNnRtZrcl0E6C3ukj/iVpe5iVI/9Xx8rcU8ykvg8s2/ AEfZKhDQNeSm31ZInty4mNjLDzApV3GB2bpSHsQHSGo45GkdRWVJXzqtQU6a3j2ysBru LRNDBHNyeigIa+0RYoKJj5Mnfs0xt4XZ4k9t0d8PoeNw0vFafHnhOhzi5XggxuBcuVwQ 7jLlU6zX9NBmB4nNJjcl/kRgPSv4+InxmJBh/GiU2S/xeghz3o719orsEulqHrJTTDA9 Ljmw==
X-Gm-Message-State: AC+VfDyHaC+/bqE/bsAZAOej9TySfSkN9/m8BWDLm4bPvHsTAbofhgcS udAQZvM1XgSeTXVWHTbDe5x9TzV1hM/+PCF1PlM=
X-Google-Smtp-Source: ACHHUZ5VoUSKi608BDL3kz1N/GvrMGLTFC7woeHjlR6R5AOxX0hEZedQ6dce/dZF3ksqW/yoNsD6Q/LkVfn1V5DV33g=
X-Received: by 2002:a05:6402:352:b0:514:9c7c:8a37 with SMTP id r18-20020a056402035200b005149c7c8a37mr4503154edw.28.1686576076594; Mon, 12 Jun 2023 06:21:16 -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: Caleb Queern <cqueern@gmail.com>
Date: Mon, 12 Jun 2023 08:21:05 -0500
Message-ID: <CAEnXMMr409TgrPtf+mSwbK1A6+Ezz=P7X7sth=+8ujgWDNsbUA@mail.gmail.com>
To: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000eeae6705fdee97cf"
Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=cqueern@gmail.com; helo=mail-ed1-x52f.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=cqueern@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-3.1
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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1q8hU1-00G2Rr-PM 8e4f205c512821ed37549687ec3c0725
X-caa-id: 4ffbc972a5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Request-Off-The-Record Mode header
Archived-At: <https://www.w3.org/mid/CAEnXMMr409TgrPtf+mSwbK1A6+Ezz=P7X7sth=+8ujgWDNsbUA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51163
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 Shivan,

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
>

If I'm not mistaken Clear-Site-Data can be sent "along the way" from the
first navigation so that user agents don't store anything in storage or
record the site visit in history etc.  as well.

My concern is that these seem to have overlapping functionality and after
more than a decade of adding new security headers for developers to think
about, there's only so much we can reasonably expect them to consider (and
leading to compensatory efforts like Mike's Baseline Header
https://github.com/mikewest/baseline-header ).

Our options might be:
a) agree on Off-The-Record header, have browsers implement it, educate devs
on OTR usage
b) educate devs on CSD usage

I'll defer to the broader group of course.

On Mon, Jun 12, 2023 at 1:55 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>