March 2022 - webkit-dev - lists.webkit.org

Request for position on FedCM (was WebID)
by Sam Goto 25 Mar '22

25 Mar '22

Hi WebKit-Dev, We've been working on a Web Platform API that allows users to login to websites with their federated accounts in a privacy preserving manner. We've been calling it FedCM (was WebID) and we would like to hear what you think! Here is our explainer, spec and a brief introduction: - explainer <https://github.com/fedidcg/FedCM/blob/main/explainer.md> - specification <https://fedidcg.github.io/FedCM/> - TPAC2021 <https://watch.videodelivery.net/29bab61e04e8cabf1517e5885c9fe4cf> presentation (video introduction) WDYT? One specific area of coordination is its relationship to the Login Status API and the Storage Access API. We'd be happy to learn more from you about both of these APIs and how they relate to FedCM, but just as a starting point, here [1 <https://github.com/fedidcg/FedCM/blob/main/explainer.md#the--login-status-a…>, 2 <https://github.com/fedidcg/FedCM/blob/main/explainer.md#the-storage-access-…>] is our interpretation of each. Looking forward to hearing from you, Sam Various other past reviews: - WebID? <https://github.com/fedidcg/FedCM/issues/41> - WICG thread <https://discourse.wicg.io/t/proposal-webid-privacy-preserving-federated-sig…> - Federation and Browsers Workshop <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/25-26_May_2021.md> - Intent To Prototype <https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3O…> - FedID CG <https://www.w3.org/community/fed-id/> - early TAG review <https://github.com/w3ctag/design-reviews/issues/622> - Ready For Trial <https://groups.google.com/a/chromium.org/g/blink-dev/c/jlV_1m7uUAg> - spec TAG review <https://github.com/w3ctag/design-reviews/issues/718> - Mozilla's Standards Position <https://github.com/mozilla/standards-positions/issues/618>

2 2

@scope
by Anders Hartvoll Ruud 25 Mar '22

25 Mar '22

Hello, We're about to start experimenting with @scope and scoped styles in Chromium. Do you have any thoughts or plans for @scope? https://www.w3.org/TR/css-cascade-6/#scope-atrule (Linking to TR, since editor's draft is down at the moment). Thanks!

1 0

Request for thoughts on the need to control screen brightness
by François Beaufort 🇫🇷 22 Mar '22

22 Mar '22

Hello WebKit folks, Since 2018, the W3C Devices and Sensors Working Group has received significant requests from web developers surrounding the need to increase the brightness of a device's screen. Multiple solutions have been proposed in https://github.com/w3c/screen-wake-lock/blob/gh-pages/brightness-mode-expla… : - Screen extension: await screen.requestBrightnessIncrease(); - Screen Wake Lock integration: await navigator.wakeLock.request({ increaseBrightness: true }); - navigator.screenBrightness - and more. We would really appreciate WebKit's folks reviewing this document and possibly providing alternative solutions. Thank you very much for your time and consideration! Francois.

1 0

Request for position: Speculation Rules (Prefetch)
by Jeremy Roman 16 Mar '22

16 Mar '22

Hello WebKit! We're working on an API to allow developers to declarative permit prefetch, and new prefetching which contemplates the need to avoid sending first-party cookies to other sites until the user navigates. Mostly in these two drafts: * https://wicg.github.io/nav-speculation/speculation-rules.html * https://wicg.github.io/nav-speculation/prefetch.html Managed as part of https://github.com/WICG/nav-speculation Thoughts and feedback are welcome. Thanks, Jeremy Roman Google Chrome team

1 0

Request for position: Region Capture
by Elad Alon 16 Mar '22

16 Mar '22

This is a request for WebKit's position on introducing an API that allows cropping video tracks resulting from the capture of the current tab. Links: * Explainer: https://github.com/w3c/mediacapture-region/blob/main/README.md * Spec: https://w3c.github.io/mediacapture-region/ * ChromeStatus entry: https://chromestatus.com/feature/5712447794053120

1 0

Request for position: Capture Handle Identity
by Elad Alon 14 Mar '22

14 Mar '22

This is a request for WebKit's position on introducing an API that allows captured Web-applications to declare their identity to a would-be capturing Web-application. Links: * Explainer: https://github.com/WICG/capture-handle/blob/main/README.md * Spec: https://wicg.github.io/capture-handle/ * ChromeStatus entry: https://chromestatus.com/feature/4854125411958784

2 2

Request for Position on Sanitizer API
by Daniel Vogelheim 14 Mar '22

14 Mar '22

Greetings webkit-dev, I'd like to ask about your position on the proposed Sanitizer API <https://github.com/WICG/sanitizer-api/>. The Sanitizer API wants to build an HTML Sanitizer right into the web platform. The goal is to make it easier to build XSS-free web applications. I've asked about this API before <https://lists.webkit.org/pipermail/webkit-dev/2021-March/031731.html>, when it was still in an early stage. We now have a more rounded feature set, a better specification <https://wicg.github.io/sanitizer-api/>, WPT tests, and two interoperable implementations in Firefox + Chromium, with an intent to harmonize whatever remaining interop issues we may find. There is also an intent to move the spec from WebAppSec into HTML proper, but this has not yet been executed. The feedback we have received from you last time <https://lists.webkit.org/pipermail/webkit-dev/2021-March/031738.html> raises two specific issues, which I'd like to address: - Usefulness for the clipboard: The clipboard sanitizers indeed perform additional style-related steps that the Sanitizer API doesn't. We're interested in addressing this in a future version of the API. I'll note that Firefox has built their Sanitizer API implementation on top of the implementation used for the clipboard, so those two sanitizers can be sufficiently similar and can co-exist rather well. (For Chromium, we've taken a different path and decided to start with a clean slate.) I'll also note that it'd be helpful to document which additional steps and transformations your clipboard sanitizer takes, so that we can take it into account when specifying that functionality. I unfortunately couldn't find documentation on the clipboard sanitizers for any of the well-known browser engines. - Efficiency of element/attribute maps: In early measurements, I've found the time spent in parsing/unparsing the HTML to dominate the execution, and the actual time spent in sanitizing the node tree (and thus in config lookups) to not be a concern. I intend to re-measure this once I can observe real-world usage of the API. Thanks, Daniel

1 0

GitHub Labels
by Jonathan Bedard 10 Mar '22

10 Mar '22

Hey folks, We’re in the final stage of bringing up support for GitHub pull-requests. To support this effort, we’re starting to add labels to our project. We intend to use labels as a replacement for commit-queue flags and Product/Component/Version fields in bugzilla. Before our tools are too reliant on specific label names, we wanted to solicit feedback to see if folks had specific opinions on certain categories. Bellow I have some preliminary thoughts on what labels the project would find helpful: EWS and Merge-Queue labels: merge-queue (green): Applied to send a PR to merge-queue (equivalent of a modern cq+) fast-merge-queue (green): Applied to send a PR to merge-queue, but skip building and testing merging-blocked (purple): Applied to prevent a change from being merged (equivalent of a modern cq-) Component labels (all white) Use our existing bugzilla component labels and descriptions Version labels (all grey) Use our existing bugzilla version labels and descriptions Misc: regression (red): Addresses a problem that did not previously exist It’s worth noting that changing a labels name does apply to existing labels of that name, so any decisions we make now can be modified without too much disruption. Existing labels: https://github.com/WebKit/WebKit/labels <https://github.com/WebKit/WebKit/labels> Excited to here your thoughts, Jonathan

2 1

Using C++20 in WebKit
by Alex Christensen 10 Mar '22

10 Mar '22

In April 2019 in https://bugs.webkit.org/show_bug.cgi?id=197131 <https://bugs.webkit.org/show_bug.cgi?id=197131> I increased WebKit’s minimum C++ language requirement from C++14 to C++17. In 2022 I’m planning to increase WebKit’s minimum C++ requirement from C++17 to C++20. Would April 2022 be a good time to do that?

4 14

Proposal to update WebKitGTK dependency policy
by Michael Catanzaro 08 Mar '22

08 Mar '22

Hi, I'd like to selfishly propose updating our dependencies policy https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy in order to accommodate RHEL in addition to Debian and Ubuntu. My goal is to provide WebKitGTK updates for the first five years (the "full support" period) of a RHEL major release, not just three years. However, we have some magic I don't understand allows use of newer toolchains, including newer libstdc++. We can actually somehow link newer libstdc++ into the same process as system libstdc++, so we can exempt the entire build toolchain (including CMake) from this policy, so this won't have any effect on discussions like "when can we use C++20 features" or "what version of CMake can we depend on." The primary impact would be on dependencies like ICU, GStreamer, etc. ICU is particularly important because this library bumps its ABI with every major release, so updating ICU to newer major versions is not possible. This would lock us into supporting ICU 67 until spring 2027. If we decide to land https://bugs.webkit.org/show_bug.cgi?id=235367 -- which currently looks unlikely -- then it would additionally lock us into ICU 60 until spring 2024. I think five years' support would benefit Ubuntu as well -- this matches the primary support lifetime of an Ubuntu LTS -- except Ubuntu doesn't seem to have the capability to build with newer toolchains, which means that, in practice, they will stop updating WebKit whenever we require a newer build toolchain. And although I think it would be a good idea to support Ubuntu for longer, I'm not brave enough to propose that we freeze our build toolchain dependencies for five years. So I will not suggest extending the support period for Ubuntu. Specifically, I propose adding the following text to our policy: * "We support the latest minor release of each major version of RHEL until two years after the release of the next major version." (Note: we currently have a three-year time-based release cycle, so that's five years total. If that were to unexpectedly change in the future, then adjusting the text of the policy would be needed.) And: * "For RHEL, WebKit is not expected to remain buildable using the default system libstdc++. The requirement for WebKit to remain buildable may be satisfied using GCC and LLVM toolsets from Application Streams." Michael

2 7