Re: Request-Off-The-Record Mode header

[Mike West <[e-mail]>]

On Mon 12. Jun 2023 at 15:22 Caleb Queern <[e-mail]> wrote:

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

A small not: Clear-Site-Data does not offer developers the ability to clear
browser history. It offers the ability to clear already web-visible
storage, as well as cache.

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 <
> [e-mail]> wrote:
>
>> Hey Caleb,
>>
>> On Thu, 8 Jun 2023 at 14:58, Caleb Queern <[e-mail]> 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 <[e-mail]>
>>> 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 <
>>>> [e-mail]> 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 <[e-mail]>
>>>>> *Sent:* Thursday, June 8, 2023 2:14 PM
>>>>> *To:* [e-mail]; HTTP Working Group <[e-mail]
>>>>> >
>>>>> *Subject:* Request-Off-The-Record Mode header
>>>>>
>>>>>
>>>>>
>>>>> You don't often get email from [e-mail]. 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
-mike