[webkit-dev] Site isolation platform code

[Alex Christensen via webkit-dev]

Hey everyone!  I’ve been doing a bunch of work on site isolation recently, and 
I’ve been doing my best to make all my changes platform-independent so it just 
works for everyone.  However, there are two places I could use some 
collaboration with other WebKit developers:

1. createNewPage in WebKitUIClient.cpp needs some hooking up of the 
API::PageConfiguration in a way I couldn’t figure out in the few minutes I 
looked at it.  This should be pretty straightforward to someone who knows the 
glib code better than I do.
2. We have a growing number of tests in LayoutTests/http/tests/site-isolation 
that exercise drawing code, which will take a significant amount of work to get 
implemented on non-Cocoa platforms.  A lot of changes are happening in this 
area right now with the adoption of Skia, and it would be great if it were done 
in a way that could support site isolation.

Thanks,
Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Alex Christensen via webkit-dev]

Herb, if you run “git log --grep MSVC” in a git checkout of WebKit, you’ll find 
many quirks we’ve done in our code to get it to compile with MSVC.  Here are 
some of the most recent ones:

https://commits.webkit.org/272595@main
https://commits.webkit.org/271031@main
Some warning differences in https://commits.webkit.org/276799@main and 
https://commits.webkit.org/277563@main
The COMPILER(MSVC) addition necessary in https://commits.webkit.org/265366@main 
puzzled me a lot for a while, but I stopped looking into it.

And many more.  I don’t have a strong opinion about WebKit’s use of MSVC, but 
WebKit is certainly a wealth of real-world code that has worked around compiler 
differences over the last few decades that could be analyzed by the MSVC team 
if you’re interested.

> On May 2, 2024, at 3:49 PM, Olmstead, Don via webkit-dev 
>  wrote:
> 
> Hey Herb,
>  
> Not everyone whose embedding WebKit on Windows announces to us that they’re 
> using it so unsure if someone is still compiling using MSVC. All the 
> documentation we have points to clang-cl being the preferred way. The ones we 
> know of Bun, https://bun.sh/ , and Playwright, https://playwright.dev/ , have 
> switched to clang-cl.
>  
> I was personally keeping the dream alive and would compile out WebKit with 
> MSVC. WebKit on Windows doesn’t have the highest tier JITs because we don’t 
> have anyone working on it for Windows and the maintenance costs around MSVC 
> are centered around that. If MSVC had the functionality that helps the JSC 
> folks make the VM run fast we wouldn’t be in this situation. If that 
> functionality is added to the roadmap then we’d definitely reconsider at that 
> time.
>  
> Don
>  
> From: Herb Sutter  
> Sent: Thursday, May 2, 2024 1:28 PM
> To: Olmstead, Don ; 'Jean-Yves Avenard' 
> 
> Cc: 'WebKit-Dev Development' 
> Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Thank you, Jean-Yves and Don!
>  
> One followup: I don’t know WebKit well but was surprised that it was being 
> built with MSVC, and Yusuke mentioned Windows projects that build with 
> clang-cl instead. Are there known users/products who are building with WebKit 
> that are important not to break, so that we (Microsoft) should be thinking 
> about doing work so you can keep using MSVC, or is this really an unused 
> configuration that it makes sense to just drop?
>  
> Herb
>  
>  
> From: Olmstead, Don mailto:don.olmst...@sony.com>>
> Sent: Thursday, May 2, 2024 12:06 PM
> To: Jean-Yves Avenard  >; Herb Sutter  >
> Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org 
> )  >
> Subject: RE: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Hi Herb
>  
> If you grep around the WebKit codebase for COMPILER(MSVC) there are a number 
> of workarounds hanging out. Some may have been fixed over time but the 
> workaround wasn’t removed.
>  
> Biggest issue was around the JIT and some other low level features the JSC 
> folks utilize that isn’t present in MSVC. The lion’s share of JSC development 
> is done using Clang and those working on it don’t have a Windows box handy so 
> we have seen the JIT break on Windows. Yusuke I’m sure has a list of feature 
> requests that would improve the quality of MSVC for people developing VMs.
>  
> MSVC has definitely caught some issues in the code and compiler mono-culture 
> isn’t great but realistically we don’t have the resources to keep MSVC up and 
> running.
>  
> Regards,
> Don
>  
> From: Jean-Yves Avenard via webkit-dev  >
> Sent: Wednesday, May 1, 2024 5:10 PM
> To: Herb Sutter mailto:herb.sut...@gmail.com>>
> Cc: Webkit Development List  >
> Subject: Re: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl 
> exclusively on Windows
>  
> Hi
>  
> 
> On 2 May 2024, at 10:07 am, Herb Sutter via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
>  
>  
> We’ve had full C++20 including concepts for a couple of years so I wasn’t 
> sure what problem you were running into… are you encountering bugs in those 
> features? or you can’t turn on /std:c++20 for some reason? or are you using 
> an older pre-concepts (pre-VS2022 17.0) compiler?
>  
> Thanks for any feedback you have time to share.
>  
> Herb
>  
>  
> We’ve had issues where some use of concepts made the latest MSVC compiler 
> crash
> See https://searchfox.org/wubkat/source/Source/WTF/wtf/TypeTraits.h#145-172
>  
> See https://bugs.webkit.org/show_bug.cgi?id=261598
>  
> Jean-Yves
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list

[webkit-dev] maybe_unused vs UNUSED_PARAM

[Alex Christensen via webkit-dev]

For many years we have used the UNUSED_PARAM macros, and we have almost 3000 of 
them.  C++17 introduced [[maybe_unused]] for this purpose, and a few uses of it 
are starting to pop up in WebKit.  Should we switch, should we transition, 
should we allow both, or should we just stick with UNUSED_PARAM?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] ENABLE macro placement between includes

[Alex Christensen via webkit-dev]

Our coding style says to include config.h, then the primary header, then other 
headers.  It does not say where to put any ENABLE macros in that list.

We have about 1700 places where we follow this pattern:

#include "config.h"
#include "RemoteSampler.h"

#if ENABLE(GPU_PROCESS)
…
#endif

We have about 350 places where we follow this pattern:

#include "config.h"

#if ENABLE(WEBGL)

#include "WebGLUniformLocation.h"
…
#endif

The less common pattern has the advantage of not needing to search the 
directory where the header is if the feature is not enabled, but I like the 
more common pattern more and I think it matches our style guidelines better.  
Should we specify one or the other, or should we not specify this in our coding 
style?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Site isolation

[Alex Christensen via webkit-dev]

The SiteIsolation feature is beginning to work in the simplest of cases, but I 
had to do some work in the Source/WebKit/Shared/RemoteLayerTree directory, 
which is platform-specific.  Basically all the use of 
LayerHostingContextIdentifier in that directory needs an equivalent 
implementation for other graphics implementations, like in the 
CoordinatedGraphics directories.  There is one layout test in 
LayoutTests/http/tests/site-isolation/basic-iframe.html that is currently 
skipped on all non-Cocoa platforms.

Is someone willing to collaborate to design and implement the feature in 
non-Cocoa ports?  We are in the early stages of the project and have a long way 
to go, so I imagine things will continue to come up, like deciding how to 
implement event handling and other platform dependent features.

Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unsigned to avoid negative values

[Alex Christensen via webkit-dev]

If you are subtracting things that have not been verified to produce a positive 
value, then you hopefully aren’t dealing with values that can’t be negative, so 
this wouldn’t apply then.  Forgetting to verify things is a bug in many places. 
 I also think that a buffer offset of -1 is just about as bad as a buffer 
offset of 4294967295.

> On Jan 26, 2023, at 6:44 PM, Simon Fraser via webkit-dev 
>  wrote:
> 
> Late to the party but….
> 
> Avoiding unsigned is usually recommended to avoid inadvertent underflow:
> 
> unsigned big = 200;
> unsigned small = 100;
> auto result = small - big; // underflow
> 
> This is particularly bad when doing math on buffer offsets and sizes, and can 
> result in OOB bugs. I believe Apple’s media frameworks code has a “no 
> unsigned usage” rule because of that. I’m surprised that no-one has raised it 
> in this discussion.
> 
> Simon
> 
>> On Jan 24, 2023, at 2:00 AM, Myles Maxfield via webkit-dev 
>>  wrote:
>> 
>> Hello!
>> 
>> I recently learned that the C++ core guidelines recommend against using 
>> unsigned to avoid negative values. Section 4.4 on page 73 of The C++ 
>> Programming Language says unsigned types should be used for bitfields and 
>> not in an attempt to ensure values are positive. Some talks by people on the 
>> C++ standards committee (e.g., Herb Sutter) recommend against using unsigned 
>> types simply because the value is expected to by positive.
>> 
>> Should we be avoiding unsigneds for these purposes? WebKit uses unsigneds 
>> all over the place, and I’m assuming a fair many of them are there to 
>> indicate that negative values are avoided. The C++ recommendation goes 
>> against my intuition that the type is there for clarity, to indicate 
>> expectations about the meaning and behavior of its value. But if it’s 
>> standard practice to just use int instead, perhaps we should update the 
>> style guide?
>> 
>> What do you think?
>> 
>> —Myles
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unsigned to avoid negative values

[Alex Christensen via webkit-dev]

If a value represents a size or a count or something that inherently cannot be 
negative, I strongly prefer using unsigned types.  It reduces the number of 
places where we need to ask ourselves “what if it’s negative?” when it can 
never be negative, leading to more straightforward code that doesn’t have to 
handle impossible cases.  It also eliminates the possibility of malicious 
content somehow incrementing a signed 32 bit integer past its maximum value and 
executing code with unexpected negative values used in signed comparison 
operations.

> On Jan 24, 2023, at 11:44 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> 
>> On Jan 24, 2023, at 2:00 AM, Myles Maxfield via webkit-dev 
>>  wrote:
>> 
>> I recently learned that the C++ core guidelines recommend against using 
>> unsigned to avoid negative values. Section 4.4 on page 73 of The C++ 
>> Programming Language says unsigned types should be used for bitfields and 
>> not in an attempt to ensure values are positive. Some talks by people on the 
>> C++ standards committee (e.g., Herb Sutter) recommend against using unsigned 
>> types simply because the value is expected to by positive.
>> 
>> Should we be avoiding unsigneds for these purposes? WebKit uses unsigneds 
>> all over the place, and I’m assuming a fair many of them are there to 
>> indicate that negative values are avoided. The C++ recommendation goes 
>> against my intuition that the type is there for clarity, to indicate 
>> expectations about the meaning and behavior of its value. But if it’s 
>> standard practice to just use int instead, perhaps we should update the 
>> style guide?
>> 
>> What do you think?
> 
> I don’t think we should change our coding style guidelines just because C++ 
> core guideline says something.
> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] GPU Process on all platforms eventually?

[Alex Christensen via webkit-dev]

I remember several years ago there was a configuration to run WebKit2 without a 
network process, which was eventually removed.  Given the current work to make 
the GPU Process on more platforms, is there an agreement that eventually (like 
in a year or two or three) all platforms running WebKit should have a GPU 
Process?  It is a considerable security improvement, a lot of work is being 
done to support it, and I imagine there will come a point when we don’t want to 
support all the code and abstractions needed to have a configuration with a GPU 
Process and a configuration without, but to get there we would need consensus 
of some sort.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

By the way, we have many of the same hurdles that you do and we don’t have good 
solutions to all the problems yet.

> On Aug 16, 2022, at 6:46 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Thanks for the analysis, Carlos!  We are only at the beginning of this 
> journey, but I’m glad we’ve begun it together.  There will be many bumps 
> along the way, but I’m confident it’ll be worth it.
> 
>> On Aug 16, 2022, at 6:35 AM, Carlos Garcia Campos via webkit-dev 
>>  wrote:
>> 
>> Here is the list of features in GTK and WPE ports exposed using
>> injected bundle.
>> 
>> JavaScript extensions
>> -
>> 
>> Used by apps to expose current JavaScript APIs using the JSC API. This
>> includes:
>> 
>> - WebKitScriptWorld: The window-object-cleared signal is the initial
>> point for injecting JavaScript. It allows allows to create isolated
>> worlds.
>> - WebKitFrame: To get the JS context. It also allows to get the JS
>> value for a node handle.
>> - WebKitDOMNode: To associate a DOM node to its JSCValue.
>> 
>> We still need a way to run code in the JavaScript process.
>> 
>> 
>> Requests handling
>> -
>> 
>> This is send-request signal to expose willSendRequest. It allows to
>> modify every request before it's sent or even cancel it. This was used
>> by epiphany to implement the adblocker before the content filter api
>> existed. Other apps still use it to modify the uri of requests before
>> being sent.
>> 
>> This is not easy to migrate because going to the UI process for every
>> load would be too much.
>> 
>> 
>> Context Menu
>> 
>> 
>> This is the same API we have in the UI process to provide more
>> information and be able to build the menu based on the DOM node. For
>> example epiphany uses it to determine if the context menu was opened
>> over a node that is editable or a password input field. It's also used
>> to get the currently selected text. All that info is set as user data
>> that is passed to the context menu signal in the UI process.
>> 
>> I think nowadays most of this information is already in
>> WebHitTestResultData and we can add whatever is missing, so this should
>> be easy to migrate.
>> 
>> 
>> Form autofilling
>> 
>> 
>> We expose a signal to notify when form controls are associated to a
>> frame. This is used by epiphany to auto fill password fields.
>> 
>> This could probably be moved to the UI process or implemented entirely
>> using JavaScript.
>> 
>> 
>> Password manager
>> 
>> 
>> Related with previous one we have a signal to notify when a form is
>> going to be submitted. Used by epiphany to remember the passwords.
>> 
>> This could probably be moved to the UI process or implemented entirely
>> using JavaScript.
>> 
>> 
>> Console messages
>> 
>> 
>> API to notify the user when a console message is sent.
>> 
>> This could be easily moved to the UI process, but I think nobody is
>> currently using this API so it can be just removed instead.
>> 
>> 
>> Editor
>> --
>> 
>> Expose the selection changed signal.
>> 
>> This could be implemented with JavaScript. I'm not sure this is
>> currently used by any application.
>> 
>> 
>> Resources load
>> --
>> 
>> This is internal implementation used to implement the UI process API
>> for resources.
>> 
>> There's APIResourceLoadClient now, so we could probably switch to use
>> that or add whatever is missing.
>> 
>> 
>> Page snapshot
>> -
>> 
>> This is also internal implementation for the UI process API for page
>> snapshots.
>> 
>> We could expose this without using injected bundle at all.
>> 
>> 
>> User messages
>> -
>> 
>> API to send custom messages between UI and web process.
>> 
>> We might need this depending on how we migrate other features.
>> 
>> 
>> 
>> 
>> El dom, 14-08-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
>> dev escribió:
>>> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
>>> escribió:
>>>> Hello WebKit developers! We are ramping up to do some serious work
>>>> on
>>>> Site Isolation which includes putting cross-origin iframes in a
>>>> different process than the 

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

Thanks for the analysis, Carlos!  We are only at the beginning of this journey, 
but I’m glad we’ve begun it together.  There will be many bumps along the way, 
but I’m confident it’ll be worth it.

> On Aug 16, 2022, at 6:35 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Here is the list of features in GTK and WPE ports exposed using
> injected bundle.
> 
> JavaScript extensions
> -
> 
> Used by apps to expose current JavaScript APIs using the JSC API. This
> includes:
> 
> - WebKitScriptWorld: The window-object-cleared signal is the initial
> point for injecting JavaScript. It allows allows to create isolated
> worlds.
> - WebKitFrame: To get the JS context. It also allows to get the JS
> value for a node handle.
> - WebKitDOMNode: To associate a DOM node to its JSCValue.
> 
> We still need a way to run code in the JavaScript process.
> 
> 
> Requests handling
> -
> 
> This is send-request signal to expose willSendRequest. It allows to
> modify every request before it's sent or even cancel it. This was used
> by epiphany to implement the adblocker before the content filter api
> existed. Other apps still use it to modify the uri of requests before
> being sent.
> 
> This is not easy to migrate because going to the UI process for every
> load would be too much.
> 
> 
> Context Menu
> 
> 
> This is the same API we have in the UI process to provide more
> information and be able to build the menu based on the DOM node. For
> example epiphany uses it to determine if the context menu was opened
> over a node that is editable or a password input field. It's also used
> to get the currently selected text. All that info is set as user data
> that is passed to the context menu signal in the UI process.
> 
> I think nowadays most of this information is already in
> WebHitTestResultData and we can add whatever is missing, so this should
> be easy to migrate.
> 
> 
> Form autofilling
> 
> 
> We expose a signal to notify when form controls are associated to a
> frame. This is used by epiphany to auto fill password fields.
> 
> This could probably be moved to the UI process or implemented entirely
> using JavaScript.
> 
> 
> Password manager
> 
> 
> Related with previous one we have a signal to notify when a form is
> going to be submitted. Used by epiphany to remember the passwords.
> 
> This could probably be moved to the UI process or implemented entirely
> using JavaScript.
> 
> 
> Console messages
> 
> 
> API to notify the user when a console message is sent.
> 
> This could be easily moved to the UI process, but I think nobody is
> currently using this API so it can be just removed instead.
> 
> 
> Editor
> --
> 
> Expose the selection changed signal.
> 
> This could be implemented with JavaScript. I'm not sure this is
> currently used by any application.
> 
> 
> Resources load
> --
> 
> This is internal implementation used to implement the UI process API
> for resources.
> 
> There's APIResourceLoadClient now, so we could probably switch to use
> that or add whatever is missing.
> 
> 
> Page snapshot
> -
> 
> This is also internal implementation for the UI process API for page
> snapshots.
> 
> We could expose this without using injected bundle at all.
> 
> 
> User messages
> -
> 
> API to send custom messages between UI and web process.
> 
> We might need this depending on how we migrate other features.
> 
> 
> 
> 
> El dom, 14-08-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
> dev escribió:
>> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
>> escribió:
>>> Hello WebKit developers! We are ramping up to do some serious work
>>> on
>>> Site Isolation which includes putting cross-origin iframes in a
>>> different process than the parent frame. Similar efforts have been
>>> done in other browser engines and some related work has already
>>> been
>>> done in WebKit, but not enough.
>>> 
>>> This will do strange things to the InjectedBundle APIs, which have
>>> fundamental assumptions that the whole DOM is in one process and
>>> that
>>> communication only happens with one process at a time. We have
>>> never
>>> exposed InjectedBundle APIs as public API, but some other
>>> distributors of WebKit have. As we make progress on this project,
>>> we
>>> anticipate that anything in
>>> Source/WebKit/WebProcess/InjectedBundl

Re: [webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

I agree that this will be quite disruptive.  I think it would be advantageous 
to deprecate the InjectedBundle APIs asap.  At least for the next year (and 
likely a little longer) we will need to keep a working configuration without 
site isolation.  In the very long term we probably don’t want to keep them 
working, but I’m not sure exactly what that time frame looks like right now.  
I’m not saying it’ll be a sudden change, but it is going to be a big change 
with big consequences that we need to start preparing for now.

> On Aug 12, 2022, at 2:29 PM, Michael Catanzaro  wrote:
> 
> On Fri, Aug 12 2022 at 01:40:02 PM -0700, Alex Christensen via webkit-dev 
>  wrote:
>> Would the maintainers of the GTK and WPE APIs be willing to assist in 
>> migrating from those APIs and designing replacements in the UI process?
> 
> Sigh... we'll need to discuss what to do. Unfortunately, these are public 
> APIs and this will be extremely disruptive. If it's needed for site 
> isolation, I don't see that we have much choice. But if we remove these APIs, 
> Linux distros will get stranded on the last version of WebKit that still 
> supports them and will be unable to take our further updates.
> 
> Deprecation is a lot easier than removal. If we can keep deprecated APIs 
> working and just disable site isolation when they're used, that would be much 
> less disruptive.
> 
> Michael
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] InjectedBundle deprecation

[Alex Christensen via webkit-dev]

Hello WebKit developers! We are ramping up to do some serious work on Site 
Isolation which includes putting cross-origin iframes in a different process 
than the parent frame. Similar efforts have been done in other browser engines 
and some related work has already been done in WebKit, but not enough.

This will do strange things to the InjectedBundle APIs, which have fundamental 
assumptions that the whole DOM is in one process and that communication only 
happens with one process at a time. We have never exposed InjectedBundle APIs 
as public API, but some other distributors of WebKit have. As we make progress 
on this project, we anticipate that anything in 
Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation and 
removal.  This will also allow us to tighten the sandbox on the web process, 
resolve security and performance issues, and have cleaner code.

Would the maintainers of the GTK and WPE APIs be willing to assist in migrating 
from those APIs and designing replacements in the UI process?

Alex Christensen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit is now on GitHub

[Alex Christensen via webkit-dev]

It may be worth considering doing one more commit with a message explaining 
that we moved the repository.  I often find old repositories places without 
knowing where all the newest things are, and sometimes they have a last git 
commit pointing to the new repository location and I find that quite helpful.  
That may cause tooling problems and it has been quite well communicated that we 
are moving to GitHub, so there are also reasons not to.

> On Jun 23, 2022, at 3:24 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Thu, Jun 23 2022 at 03:21:59 PM -0700, Jonathan Bedard  
> wrote:
>> I´m aware of the WebKitGTK branches, please reach out about the WPE ones, 
>> I´m not sure which ones those are.
> 
> The WPE releases actually use the WebKitGTK branches! They are shared 
> branches. I suppose that is pretty confusing, but naming things is hard.
> 
> Sounds like you already have this under control.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on COEP reflection

[Alex Christensen via webkit-dev]

Seems reasonable.

> On May 31, 2022, at 6:14 AM, Arthur Sonzogni via webkit-dev 
>  wrote:
> 
> Greetings webkit-dev,
> 
> I am requesting your feedback about exposing:
> ```js
> self.crossOriginEmbedderPolicy;
> ```
> It reflects the environment's crossOriginEmbedderPolicy's value.
> 
> More details on:
> https://github.com/ArthurSonzogni/coep-reflection 
> 
> Thanks
> Arthur @arthursonzogni
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on FedCM (was WebID)

[Alex Christensen via webkit-dev]

We are generally supportive and interested in working together to make this 
coexist well with passkeys.

> On Mar 10, 2022, at 3:42 PM, Sam Goto via webkit-dev 
>  wrote:
> 
> 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 
> specification 
> TPAC2021  
> 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 
> ,
>  2 
> ]
>  is our interpretation of each.
> 
> Looking forward to hearing from you,
> 
> Sam
> Various other past reviews:
> 
> WebID? 
> WICG thread 
> 
> Federation and Browsers Workshop 
> 
> Intent To Prototype 
> 
> FedID CG 
> early TAG review 
> Ready For Trial 
> 
> spec TAG review 
> Mozilla's Standards Position 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

Apple and Sony are finishing updating our build infrastructure to Visual Studio 
2022, and we are considering requiring it to build WebKit starting next week.  
If anyone has a reason to delay further, please let me know on this list or 
directly.

> On Jan 24, 2022, at 1:43 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Ok.  We won’t raise the minimum CMake version for all of WebKit right now 
> then, just on Windows when we start requiring VS2022.
> 
>> On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>  wrote:
>> 
>> On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
>>> While we’re updating things, is there any objection to updating the
>>> minimum version of CMake required?  Right now it is 3.12, which was
>>> released in 2018.  Does anyone have any limitations we should consider
>>> when picking a new minimum version?
>>> 
>> 
>> Yes.
>> 
>> CMake is one of the core dependencies for GTK and WPE ports, so the
>> policy of dependencies applies [1]
>> 
>> In practical terms that means that we should support the version of
>> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
>> 
>> However, If the purpose of raising the version is to take advantage of
>> the new Visual Studio generator then I don't think raising the minimum
>> version is needed.
>> 
>> As far as I know you can take advantage of newer CMake features (like
>> support for a newer generator) without needing to raise the minimum
>> version required.
>> 
>> So if you have a newer version of CMake you can simply pass the flag
>> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
>> required of CMake is not needed to use a newer CMake generator, using it
>> can be made optional for those that want (and can) use it.
>> 
>> 
>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for Position: Fetch Metadata

[Alex Christensen via webkit-dev]

I’m interested in this work, and would be happy to review patches.  I noticed 
that Chrome and Firefox both implement it and we don’t.  Some of the 
implementation might be a little involved, so I’m happy to answer questions and 
point in the right direction when I can.

I’m not thrilled that it adds more bytes to each request, especially when using 
HTTP 1.1 where headers are not compressed.  The day may also come when we need 
to either omit the metadata or send incorrect metadata for privacy or security 
reasons, but I haven’t thought it through well enough yet and I’m not aware of 
cases where that would be necessary right now.

> On Feb 16, 2022, at 12:43 PM, Patrick Griffis via webkit-dev 
>  wrote:
> 
> On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote:
>> However Sec-Fetch-User I believe will require more
>> significant changes that will have to be exposed to each port. It
>> requires knowing if a request was initiated by a user, exact details are
>> specified here[2], which I think will require integration at the
>> Safari/WebKitGTK/etc layers.
> 
> Looking more into this Firefox takes a more heuristic approach to
> figuring this out (was there a referrer and what is the request type)
> and if that approach works out for WebKit it wouldn't require any
> port-specific changes. Chromium itself does just ask the `ui` layer what
> type of "transition" caused the request which is more in-line with the
> spec.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

Ok.  We won’t raise the minimum CMake version for all of WebKit right now then, 
just on Windows when we start requiring VS2022.

> On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev 
>  wrote:
> 
> On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
>> While we’re updating things, is there any objection to updating the
>> minimum version of CMake required?  Right now it is 3.12, which was
>> released in 2018.  Does anyone have any limitations we should consider
>> when picking a new minimum version?
>> 
> 
> Yes.
> 
> CMake is one of the core dependencies for GTK and WPE ports, so the
> policy of dependencies applies [1]
> 
> In practical terms that means that we should support the version of
> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
> 
> However, If the purpose of raising the version is to take advantage of
> the new Visual Studio generator then I don't think raising the minimum
> version is needed.
> 
> As far as I know you can take advantage of newer CMake features (like
> support for a newer generator) without needing to raise the minimum
> version required.
> 
> So if you have a newer version of CMake you can simply pass the flag
> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
> required of CMake is not needed to use a newer CMake generator, using it
> can be made optional for those that want (and can) use it.
> 
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

While we’re updating things, is there any objection to updating the minimum 
version of CMake required?  Right now it is 3.12, which was released in 2018.  
Does anyone have any limitations we should consider when picking a new minimum 
version?

> On Jan 21, 2022, at 4:51 PM, Yusuke Suzuki  wrote:
> 
> It sounds nice! New CMake (3.21~) already supports VS 2022.
> 
> -Yusuke
> 
>> On Jan 21, 2022, at 10:36 AM, Alex Christensen > <mailto:achristen...@apple.com>> wrote:
>> 
>> Related to the C++20 change, I’m working on moving the Visual Studio build 
>> to Visual Studio 2022.  I’ve informed several involved parties directly, but 
>> now I’ve informed everyone.  If anyone has a reason not to move to VS2022, 
>> please let me know.
>> 
>>> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki >> <mailto:ysuz...@apple.com>> wrote:
>>> 
>>> We cannot use char8_t since it is not available in GCC 8.3.0 :)
>>> 
>>> -Yusuke
>>> 
>>>> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>> 
>>>> I, with great help from several of you, got 
>>>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>>>> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all 
>>>> platforms, but several of the JSC bots are still red.  I’m under the 
>>>> impression that they either need a clean build or I’ve missed something.  
>>>> Could a JSC bot maintainer look into it?
>>>> 
>>>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>>> 
>>>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>>>> As a result, we can use some of C++20 features.
>>>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>>>> used, and it is super useful.
>>>>> 
>>>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>>>> with C++-20 support and to start using the C++-20 features already
>>>>> supported by GCC 8.3.0
>>>>> 
>>>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>>>> features are supported by GCC 8
>>>>> 
>>>>> Before using them I think it would be a good idea to double-check if
>>>>> those are also supported by the minimum version of Clang that we want to
>>>>> support.
>>>>> And maybe also to check if those are supported by MS Visual C++ ?
>>>>> I say maybe because I'm not sure if we support this compiler.
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>>> 
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>> 
>> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

Related to the C++20 change, I’m working on moving the Visual Studio build to 
Visual Studio 2022.  I’ve informed several involved parties directly, but now 
I’ve informed everyone.  If anyone has a reason not to move to VS2022, please 
let me know.

> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki  wrote:
> 
> We cannot use char8_t since it is not available in GCC 8.3.0 :)
> 
> -Yusuke
> 
>> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> I, with great help from several of you, got 
>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all platforms, 
>> but several of the JSC bots are still red.  I’m under the impression that 
>> they either need a clean build or I’ve missed something.  Could a JSC bot 
>> maintainer look into it?
>> 
>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>> As a result, we can use some of C++20 features.
>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>> used, and it is super useful.
>>> 
>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>> with C++-20 support and to start using the C++-20 features already
>>> supported by GCC 8.3.0
>>> 
>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>> features are supported by GCC 8
>>> 
>>> Before using them I think it would be a good idea to double-check if
>>> those are also supported by the minimum version of Clang that we want to
>>> support.
>>> And maybe also to check if those are supported by MS Visual C++ ?
>>> I say maybe because I'm not sure if we support this compiler.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

I, with great help from several of you, got 
https://bugs.webkit.org/show_bug.cgi?id=233963 
 compiling on all platforms, 
but several of the JSC bots are still red.  I’m under the impression that they 
either need a clean build or I’ve missed something.  Could a JSC bot maintainer 
look into it?

> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>  wrote:
> 
> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>> I recently upgraded GCC requirement to 8.3.0 based
>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
>>  
>> (https://trac.webkit.org/changeset/283348/webkit
>> )
>> As a result, we can use some of C++20 features.
>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>> be used since GCC 8.3.0 does not support, but some of features can be
>> used, and it is super useful.
> 
> From the PoV of WebKitGTK I think it is Ok to enable now the building
> with C++-20 support and to start using the C++-20 features already
> supported by GCC 8.3.0
> 
> Check here: https://gcc.gnu.org/projects/cxx-status.html which C++-20
> features are supported by GCC 8
> 
> Before using them I think it would be a good idea to double-check if
> those are also supported by the minimum version of Clang that we want to
> support.
> And maybe also to check if those are supported by MS Visual C++ ?
> I say maybe because I'm not sure if we support this compiler.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

I’m also excited about using coroutines in WebKit.  If there is already a GCC 
requirement for using a compiler that supports C++20, is there a reason not to 
switch from C++17 to C++20 later in 2021?

> On Dec 6, 2021, at 2:36 PM, Yusuke Suzuki  wrote:
> 
> I recently upgraded GCC requirement to 8.3.0 based on 
> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement> 
> (https://trac.webkit.org/changeset/283348/webkit 
> <https://trac.webkit.org/changeset/283348/webkit>)
> As a result, we can use some of C++20 features.
> I wonder if we can flip C++20 now. While some of C++20 features cannot be 
> used since GCC 8.3.0 does not support, but some of features can be used, and 
> it is super useful.
> One of the good features is initializer for bit-fields, which can avoid 
> uninitialized bit-field bugs.
> 
> class A {
> bool m_test : 1 : { false };
> };
> 
> -Yusuke
> 
>> On Dec 6, 2021, at 12:52 PM, Alex Christensen via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> 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?
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Using C++20 in WebKit

[Alex Christensen via webkit-dev]

In April 2019 in 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?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Raw string literals

[Alex Christensen via webkit-dev]

Right now, our style checker disapproves of raw string literals, which were 
introduced in C++11.  It complains with this message:

Multi-line string ("...") found.  This lint script doesn't do well with such 
strings, and may give bogus warnings.  They're ugly and unnecessary, and you 
should use concatenation instead".

https://webkit.org/code-style-guidelines/ 
 says nothing on the subject.  I 
find them quite useful and nice, especially with strings that contain lots of 
quotation marks that would otherwise need escaping.  Would anyone oppose to my 
changing our style checker to allow them if I ever get around to it?

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Review request time limit

[Alex Christensen via webkit-dev]

I just removed r? on all the bugs in http://webkit.org/pending-review 
 that had requested review in 2018 or before 
and had been untouched since then.  I imagine that did not interrupt anyone’s 
work.  I was thinking of removing review requests on bugs that hadn’t been 
updated in one full year to maintain the usefulness of the review queue.  Does 
anyone have any strong opinions that that is too much time or too little time?  
Most reviews are done in a few days or weeks, but occasionally something useful 
sits in the review queue for a few months.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for Position: Compute Pressure API

[Alex Christensen via webkit-dev]

Has anyone discussed how this can increase the precision of fingerprinting?  It 
seems to reveal more information or more precise information about what else is 
going on on a user’s system.

> On May 5, 2021, at 11:37 AM, Olivier Yiptong via webkit-dev 
>  wrote:
> 
> Hello WebKit devs,
> 
> We'd like to get WebKit's position on the Compute Pressure API.
> 
> Description:
> 
> We propose a new API that conveys the utilization of CPU resources on the 
> user's device. This API targets applications that can trade off CPU resources 
> for an improved user experience. For example, many applications can render 
> video effects with varying degrees of sophistication. These applications aim 
> to provide the best user experience, while avoiding driving the user's device 
> in a high CPU utilization regime.
> 
> High CPU utilization is undesirable because it strongly degrades the user 
> experience. Many smartphones, tablets and laptops become uncomfortably hot to 
> the touch. The fans in laptops and desktops become so loud that they disrupt 
> conversations or the users’ ability to focus. In many cases, a device under 
> high CPU utilization appears to be unresponsive, as the operating system may 
> fail to schedule the threads advancing the task that the user is waiting for.
> 
> Thanks!
> 
> Specification Title: Compute Pressure API
> Specification URL: https://oyiptong.github.io/compute-pressure/ 
> 
> Explainger: https://github.com/oyiptong/compute-pressure/blob/main/README.md 
> 
> ChromeStatus.com entry: https://chromestatus.com/features/5597608644968448 
> 
> TAG design review request: 
> https://github.com/w3ctag/design-reviews/issues/621 
> 
> Mozilla Request for Position: 
> https://github.com/mozilla/standards-positions/issues/521 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Alex Christensen via webkit-dev]

Thanks, David.  I think we’re on the same page now.

> On Apr 29, 2021, at 12:47 PM, David Benjamin  wrote:
> 
> Ah yes, that is confusing. Not quite. What's going on here is that we've 
> moved 3DES (and SHA-1 server signatures) under a fallback connection, so our 
> first connection won't advertise them, but on error the second one will. This 
> means that, for compatibility and security purposes, we do support 3DES. But 
> when you look at the ClientHellos, it'll look like we don't.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ
>  
> 
Ah, yes.  Now I see that when connecting to https://3des.badssl.com/ Chrome 
will send a retry client hello with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

> (By the way, it looks like, on my machine, Safari on Big Sur also supports 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.)
You are correct.  I overlooked that one, which upon closer inspection was right 
next to the other ones the whole time.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Alex Christensen via webkit-dev]

I don’t see the goal as “keep non-Unified-Source building” but rather “prevent 
unrelated build fixes when we add another file later”.  Right now when we add a 
new file we often have to sprinkle includes, declarations, and other build 
fixes in files unrelated to the current change.  If we had a bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
> 
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
> 
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Alex Christensen via webkit-dev]

I’d be excited to have this.  Those build failures have been bothering me ever 
since we started using unified builds.  We would have a way to see more 
problems in our code that are currently hidden.

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Alex Christensen via webkit-dev]

They are aware of this thread now, but I can’t comment on any future plans.  I 
do have a few quick questions, though. 

A quick glance at the client hellos sent by browsers shows this:
Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites 
section of the client hello.
Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Chrome 90 sends no cipher suites with 3DES.

This might be why Chrome measures 0.00% use of TLS_RSA_WITH_3DES_EDE_CBC_SHA - 
because it doesn’t advertise that it supports it.  It seems to me that you’ve 
already removed support for 3DES in Chrome.  What was the measured use of 3DES 
cipher suites in the release before you removed support?  We have measured 
slightly above 0.00% use in a browser that does send 3DES cipher suites in its 
client hellos.

If you haven’t already removed support, how would one use it?  I’ll admit I 
haven’t gone through all the possibilities of renegotiation that TLS has.

> On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Your measurement of 0.00% use in Chrome is exciting.
> 
> Making this change would almost certainly not be a change in WebKit but I’ve 
> reached out to the people who manage our crypto code.
> 
>> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>>  wrote:
>> 
>> 
>> Looks like this change is clearly safe.
>> 
>> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
>> they're controlled by the operating system's TLS backend and crypto policy. 
>> 3DES has been disabled for a while now on modern systems, and users have not 
>> reported any compat issues, which is not surprising given your finding of 
>> 0.00%.
>> 
>> Michael
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Removing 3DES from TLS

[Alex Christensen via webkit-dev]

Your measurement of 0.00% use in Chrome is exciting.

Making this change would almost certainly not be a change in WebKit but I’ve 
reached out to the people who manage our crypto code.

> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> 
> Looks like this change is clearly safe.
> 
> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
> they're controlled by the operating system's TLS backend and crypto policy. 
> 3DES has been disabled for a while now on modern systems, and users have not 
> reported any compat issues, which is not surprising given your finding of 
> 0.00%.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

[Alex Christensen via webkit-dev]

I’m also wondering why 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
 says it should only retry GET requests.  Is that just to avoid re-uploading 
large POST requests?  

> On Apr 6, 2021, at 10:02 AM, David Benjamin  wrote:
> 
> Hi Alex, thanks for the comments! Responses inline.
> 
> On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen  > wrote:
> I’m glad to see ALPS and bytes sent over the network used instead of 
> additional reliance on state on the client.  We don’t want to introduce a 
> super cookie on the client, and we want to minimize breakage when a user 
> agent decides to remove state to prevent tracking.
> 
> Well, with regards to cross-site tracking, I'll note that Accept-CH cache is 
> already naturally partitioned because it only applies to top-level loads. 
> Subresources follow a delegation model. But, yeah, one of the nice outcomes 
> of Client Hint Reliability is it makes the Accept-CH cache actually a cache, 
> so the UA can scope or clear it with less worry. I think reducing the 
> performance and functionality gap between new and returning clients is 
> generally valuable for this sort of thing. I hope Client Hint Reliability is 
> useful in this regard.
> 
> I can’t say I’ve followed this development closely or even thought through it 
> all completely, but here are some initial thoughts:
> 
> My first thought is that it seems excessive to have a way to specify support 
> of client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
> that’s why you wrote 
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
>  
> 
> 
> I think you may have misunderstood the reference to two mechanisms. The TLS 
> ALPS extension and h2/h3 frames are part of the same mechanism. It's a 
> layering thing. TLS provides a generic spot to stick protocol-specific 
> settings early enough in the handshake, and then HTTP/{2,3} define how to use 
> it. (We don't want every new feature like this to require an update to the 
> TLS server.)
> 
> Rather, the reference is to (1) Critical-CH HTTP response header and (2) TLS 
> ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think this is 
> the best option given all the design constraints. And yeah the explainer 
> discusses why.
>  
> I don’t think that requiring a site to be running software that supports 
> client hints is a good prerequisite to using client hints, so I don’t think 
> that’s a good reason to have two mechanisms.
> 
> I'm not sure I'm parsing this sentence right. It sounds like you both don't 
> think server software changes are a good requisite, but also don't think it's 
> good to have a mechanism with lower server software requirements?
Oops!  Remove the first “don’t” in my sentence.
>  
> Sites can change with open connections, but if a site changes its client 
> hints acceptance, wouldn’t that be a good reason to terminate all the open 
> connections and require renegotiation?
> 
> Sites don't really work that way architecturally. You may have, for instance, 
> a CDN frontend handling TLS and H2/H3, but it contacts the origin server that 
> developers actually upload content to. In such deployments, there usually 
> isn't a way to signal an update to all connections like that. Moreover, 
> there's a race condition here. The client may request the resource at the 
> same time as the server signaling the new preferences.
>  
> Wildcard subdomains in the certificate is an interesting problem.
> 
> I'll add that cross-name pooling further complicates any hope of signaling 
> existing connections above.
>  
> If it is decided that multiple mechanisms are necessary, their interaction 
> should be well defined.  What if the server said one thing in ALPS but said 
> something different in an HTTP/{2,3} frame?  What if I have multiple 
> connections open to the same server and get different client hint headers?
> 
> Agreed it should be well-defined. I touched on this briefly in 
> draft-davidben-http-client-hint-reliability-02, but not in full detail. The 
> IETF and W3C/WHATWG split is a bit fun at the boundaries of the web platform 
> and network protocols. :-) I think we'll probably put the full Fetch 
> integration in https://github.com/WICG/client-hints-infrastructure 
> , alongside the other 
> Client Hints bits.
> 
> The interaction we think works best is that ALPS/frames and 
> Accept-CH/Critical-CH are conceptually two separate sources of hint requests, 
> with the expectation that the former is an optimization for the latter. You 
> end up roughly unioning them. This avoids weird behaviors when they mismatch 
> and meshes well with the constraints that led to two mechanisms in the first 
> place.
>  
> In 
> 

Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

[Alex Christensen via webkit-dev]

I’m glad to see ALPS and bytes sent over the network used instead of additional 
reliance on state on the client.  We don’t want to introduce a super cookie on 
the client, and we want to minimize breakage when a user agent decides to 
remove state to prevent tracking.

I can’t say I’ve followed this development closely or even thought through it 
all completely, but here are some initial thoughts:

My first thought is that it seems excessive to have a way to specify support of 
client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
that’s why you wrote 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
I don’t think that requiring a site to be running software that supports client 
hints is a good prerequisite to using client hints, so I don’t think that’s a 
good reason to have two mechanisms.
Sites can change with open connections, but if a site changes its client hints 
acceptance, wouldn’t that be a good reason to terminate all the open 
connections and require renegotiation?
Wildcard subdomains in the certificate is an interesting problem.

If it is decided that multiple mechanisms are necessary, their interaction 
should be well defined.  What if the server said one thing in ALPS but said 
something different in an HTTP/{2,3} frame?  What if I have multiple 
connections open to the same server and get different client hint headers?

In 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
 you specify that a client should not retry more than once per request to avoid 
infinite loops, but in 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#server-triggered-retry
 you use the possibility of infinite loops as a reason that a server-triggered 
retry isn’t a good solution.  I think a server-triggered retry is a good 
solution and we should be able to expect that if someone wants their website to 
work, then they will do what it takes to make their servers work correctly.  
Don’t we have the possibility of infinite redirects today?

> On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev 
>  wrote:
> 
> Hi there,
> 
> Complimentary to 
> https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html, 
> Chromium intends to ship the ALPS + ACCEPT_CH HTTP/2 and HTTP/3 frames 
> portions of the Client Hints reliability proposal, and we would like to 
> solicit WebKit's position.
> 
> As mentioned in the linked thread, the Client Hint Reliability proposal is a 
> set of features aimed at making Client Hints more reliably available and 
> mitigating mis-matches between a site's preferences and the preferences 
> stored in the browser.
> 
> In particular, The ACCEPT_CH HTTP/2 and HTTP/3 frames, combined with the TLS 
> ALPS extension, are a connection-level optimization to deliver the server’s 
> Client Hint preferences in time for the first HTTP request.
> 
> Specifications:
> 
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability 
> (section 4)
> https://tools.ietf.org/html/draft-vvv-httpbis-alps
> https://tools.ietf.org/html/draft-vvv-tls-alps
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#connection-level-settings
> 
> thanks,
> Mike
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev