Re: Request-Off-The-Record Mode header

[Shivan Kaul Sahib <[e-mail]>]

Hi Eric,

On Thu, 8 Jun 2023 at 14:40, 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?
>

That was the original plan (we were also considering only enabling those
extensions in OTR mode which a user opts-in to seeing in private windows),
but we ran into implementation issues, because extensions are per-profile
in Chromium, not per-tab/WebContents. We would like to disable/selectively
enable extensions for off-the-record websites.


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