- From: Caleb Queern <cqueern@gmail.com>
- Date: Mon, 12 Jun 2023 08:21:05 -0500
- To: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAEnXMMr409TgrPtf+mSwbK1A6+Ezz=P7X7sth=+8ujgWDNsbUA@mail.gmail.com>
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. >>>> >>>> >>>> >>>> >>>> >>>
Received on Monday, 12 June 2023 13:21:24 UTC