Addition of data for browsers' secure profiles #20619
Comments
|
Possibly relevant: Brave has “forgetful browsing”
|
|
On Mon Aug 28, 2023 at 8:32 PM PDT, Šime Vidas wrote:
Possibly relevant: Brave has “forgetful browsing”
> When this option is set, Brave will clear first-party storage for the site a few seconds after there are no more open tabs for the site. Forgetful Browsing clears both explicitly stored values (e.g. cookies, localStorage, or indexedDB) and indirectly stored values (e.g. HTTP cache or DNS cache).
No, that isn't what this is about. The feature you reference makes pages amnesiac by default. I describe browser modes that remove a specific set of BCD-tracked features from those available to web developers. Rather than "supported" or "unsupported", BCD should also say something resembling "unsupported in secure profile".
|
|
This isn't in the scope of BCD. We don't even document if something is available only in secure context. |
|
@Josh-Cena I suppose you could consider this issue a proposal to revise the scope of BCD to include this. Perhaps "Safari Lockdown Mode" could be treated as a separate browser from "Safari". |
|
Then I reckon it would go through the same process as adding a new browser, in https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/browsers.md. I don't anticipate it to be straightforward, but I'm not a BCD maintainer, so probably don't take my word for it :) |
Actually, this statement is false. For features gated behind a secure context, we add a
Given how little difference there would be between the two, adding an entire new "browser" doesn't seem like the right way to go about it. It's the same reason why we don't add Chrome on iOS. Anyways, this is something that we'll have to assess. |
|
On Wed Aug 30, 2023 at 9:28 AM PDT, queengooborg wrote:
Given how little difference there would be between the two, adding an entire new "browser" doesn't seem like the right way to go about it. It's the same reason why we don't add Chrome on iOS.
I believe that Microsoft Edge and Google Chrome, or Chrome for Android and Android WebView, are closer together than Safari Lockdown Mode and vanilla Safari. If you look at the host of disabled features and APIs I listed, there's a big gap that web developers need to know about.
Moreover: Lockdown Mode impacts all iOS browsers, not just Safari. There would still be no need to add alternative iOS browsers, as they'd support more or less the same features as Safari. The distinguishing feature wouldn't be which WebKit-based browser is used; it would be whether Lockdown Mode is enabled.
I also think that including the Tor Browser is important from a human rights and web compatibility perspective. The Tor Browser lags behind Firefox ESR:
<https://seirdy.one/notes/2022/09/19/state-of-the-tor-uplift/>
This means compatibility information goes beyond just checking which Firefox version is ESR. "Safer" and "Safest" modes are encouraged but are almost never catered to, even by developers who would like to, because browser compatibility documentation is missing. A lack of attention from web developers translates into websites that don't work in these modes, which then translates into at-risk users feeling pressured to relax their security settings.
In short: this is undocumented information that *needs* to be documented somewhere. Developers need to know that these modes/browsers exist and that they require attention. I can think of no better place.
|
|
I've since found that Lockdown Mode since at least Safari 17 also breaks most or all AVIF and JPEG-XL images. |
What type of issue is this?
Missing compatibility data
What information was incorrect, unhelpful, or incomplete?
Some browsers offer secure profiles that disable unsafe features:
Documentation on which features aren't available in these modes is missing. This makes them very difficult to learn about, let alone target.
What browsers does this problem apply to, if applicable?
Chromium (Chrome, Edge 79+, Opera, Samsung Internet), Firefox, Safari
What did you expect to see?
Safari
Safari offers "Lockdown mode" which disables several features. Lockdown mode in Safari 16.4 does the following:
Lockdown mode in Safari 16.5 also disables the WebCodecs API. Lockdown mode in the upcoming Safari 17 does the following:
<embed>element.Tor Browser
The Tor Browser is based on Firefox ESR (though it lags several months behind new major releases). It offers a security slider that disables several features.
"Safer" mode disables:
"Safest" mode includes the changes in "Safer", but also disables:
Microsoft Edge
Microsoft Edge's "enhanced" security mode (also known as "Super Duper Security Mode") disables Just-In-Time compilation (note that it now bundles a WebAssembly interpreter, allowing WebAssembly to run without JIT compilation on certain CPU architectures). It can be enabled across an organization via an enterprise policy. I'm not aware of any other changes yet, but I believe more will land with time.
Did you test this? If so, how?
Not applicable; this issue is requesting a new category of BCD documentation, not a single correction/addition.
Can you link to any release notes, bugs, pull requests, or MDN pages related to this?
The WebKit Blog covers updates to Lockdown Mode in Safari:
Tor Browser official documentation and source code for its Security Levels module describe the changes it makes.
Microsoft Edge Enhanced Security documentation details how it disables JIT but still supports WebAssembly. Enhanced Security's introductory blog post also details how they added the "Drumbrake" WebAssembly interpreter.
Do you have anything more you want to share?
Current BCD data excludes at-risk users who depend on secure browsing profiles to stay safe, especially Lockdown Mode in Safari or the Tor Browser's "safer" and "safest" modes. Developers who need to build with security in mind should target these modes. Right now, documentation is scattered which makes this task very difficult. BCD is in a unique place to fix this.
BCD should highlight unsafe features that are only available in insecure modes, but are disabled in secure profiles.
MDN URL
No response
MDN metadata
No response
The text was updated successfully, but these errors were encountered: