Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

LGTM2. Good luck! On 3/20/24 4:30 PM, Yoav Weiss (@Shopify) wrote: LGTM1 On Wed, Mar 20, 2024 at 8:35 PM David Adrian wrote: > What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely? We also worked with a variety of vendors to fix

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

LGTM1 On Wed, Mar 20, 2024 at 8:35 PM David Adrian wrote: > > What's our plan to mitigate that risk? Slow rollout? Enterprise policy? > Both? Something else entirely? > > We also worked with a variety of vendors to fix incompatibilities that > were brought to our attention, including Vercel,

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

LGTM3 On Wed, Mar 20, 2024 at 1:21 PM Daniel Bratell wrote: > (resending to list) > > LGTM2 to go directly to removal (with a flag of course). Also, keep an eye > on enterprise feedback since they are a blind area. > > I took a look at code in github, and there was mostly just documentation, >

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

(resending to list) LGTM2 to go directly to removal (with a flag of course). Also, keep an eye on enterprise feedback since they are a blind area. I took a look at code in github, and there was mostly just documentation, including the Portuguese chrome.com, and I also saw a page from

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

On Wed, Mar 20, 2024 at 9:54 AM Philip Jägenstedt wrote: > LGTM1 to remove without deprecation > Cool, ok! If I get two more of those, then I'll go ahead with the removal. I'd still like to take it slowly and carefully, so I think I'd roll it out via Finch over a milestone or two. But if that's

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

> What's our plan to mitigate that risk? Slow rollout? Enterprise policy? Both? Something else entirely? We also worked with a variety of vendors to fix incompatibilities that were brought to our attention, including Vercel, ZScaler, and PayPal CN (who have all since patched prior to any level

[blink-dev] Intent to Ship: CSS view-transition-class and class VT argument syntax

Contact emailsvmp...@chromium.org, nrosent...@chromium.org Explainer https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-classes.md Specification https://drafts.csswg.org/css-view-transitions-2/#view-transition-class-prop Summary This feature introduces a new CSS

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen wrote: > Contact emails > > pauljen...@chromium.org > > > Explainer > > Split up large trusted signals fetches: > https://github.com/WICG/turtledove/pull/1070 > > deprectedReplaceInURN via auction config: > https://github.com/WICG/turtledove/pull/1069

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

You should be able to see all the various bits for approvals in your chromestatus entry now, can you fill them out please? There have been a few questions/comments about the lack of clarity of what "unimportant cross-origin frames" are. What exactly is the definition? You mention that Safari

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

LGTM1 to remove without deprecation I looked through all 24 sites listed in https://chromestatus.com/metrics/feature/timeline/popularity/4455. 23 of them are the code from client-shim.js minified in various ways, and one site no longer has includeShadowRoots. On Wed, Mar 20, 2024 at 5:11 PM Mike

Re: [blink-dev] Re: Intent to implement and ship: Allow elements with CSS display:contents to be focusable

Which a11y people are we looking for a reply from? Please CC me on whatever thread that is. On Wed, Mar 20, 2024 at 11:38 AM Philip Jägenstedt wrote: > The API owners touched on this today. Just a note that we consider it on > hold until there's a reply to the questions about accessibility. > >

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

Thanks for the comments, and sorry for the confusion. The chromestatus tool, I think, needs a bit of help with deprecations. There are two "Draft Intent to Foobar" links on chromestatus, which for typical launches correspond to "Intent to Prototype" and "Intent to Ship". For deprecations, those

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

On 3/19/24 6:51 PM, Mason Freed wrote: On Tue, Mar 19, 2024 at 1:44 PM Mike Taylor wrote: Hi Mason, Would you mind requesting reviews for the various shipping gates (privacy, security, enterprise, etc.) in your chromestatus entry? Definitely! But I only need to do that

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

We indeed try to avoid open ended deprecation warnings with no planned milestone for removal. Given that the usage is still low (~0.01%) and that you found 8/8 sites analyzed were doing feature detection, this seems fairly low risk. I presume it's OK to gate this removal behind a flag, so that we

Re: [blink-dev] Re: Intent to implement and ship: Allow elements with CSS display:contents to be focusable

The API owners touched on this today. Just a note that we consider it on hold until there's a reply to the questions about accessibility. On Wed, Jan 24, 2024 at 5:48 PM Philip Jägenstedt wrote: > On Wed, Jan 10, 2024 at 5:50 PM David Baron wrote: > >> >> >> On Wed, Jan 10, 2024 at 11:14 AM

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

On 3/18/24 7:17 PM, 'Akash Nadan' via blink-dev wrote: Contact emails akashna...@google.com , lin...@chromium.org , johni...@chromium.org Explainer Attribution Reporting with event-level reports

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

LGTM1 The signals from other vendors and the CG discussion seem encouraging and I agree that the future risk from an "all" value is probably outweighed by its developer-facing benefits. On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula wrote: > I'd guess that, in the future, the semantics around

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

LGTM3 I'm also a bit concerned with the risk, but it sounds like you have it under control and will be able to handle the rollout appropriately. /Daniel On 2024-03-18 07:42, Yoav Weiss (@Shopify) wrote: LGTM2 actually.. On Mon, Mar 18, 2024 at 7:40 AM Yoav Weiss (@Shopify) wrote:

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

I don't think we, in general, want open ended deprecations. Nowadays they are a bit more hidden in DevTools, but they used to be a source of console spam and cause warning fatigue. Many also don't react to deprecations unless there is some kind of timeline so I really prefer there to be a set

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

I'd guess that, in the future, the semantics around 'all' may change in one of two ways: (A) If storage methods included are deprecated, (1) we would start warning developers via a DevTools issue when they use 'all', (2) we would start requiring the deprecated method was specifically included in

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula wrote: > I think the last place it came up was in this thread: > https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352 > > I think it came up at TPAC, but I might me missing the right line: >

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

I think the last place it came up was in this thread: https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352 I think it came up at TPAC, but I might me missing the right line:

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote: Contact emails aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, rosh...@google.com Specification https://privacycg.github.io/saa-non-cookie-storage/ Design Doc