Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

Thanks all.   https://crbug.com/1478065 is exactly the issue some of our
customers encountered. But unfortunately it didn't give any clue to debug
why chrome did not obey the header even if its indeed present though more
than once. Hence, it will be helpful to add some warnings or something to
indicate on DevTools console why chrome could not interpret the header
properly.

On Thu, Oct 12, 2023 at 10:39 PM W. James MacLean 
wrote:

> Thanks creis@ ... I learned something new today!
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo
> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>,
> Canada
>
>
>
> On Thu, 12 Oct 2023 at 12:51, Charlie Reis  wrote:
>
>> Actually, I think that's not quite true-- there was a recent report about
>> duplicate headers in https://crbug.com/1478065, and it turns out to be
>> required by spec to not allow duplicates.  (See comment 13
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1478065#c13> on
>> that bug.)  I think it will be necessary to only return one copy of the
>> header, and there's a bug filed <https://crbug.com/1484583> to have
>> DevTools display a warning in that case.
>>
>> Charlie
>>
>>
>> On Thu, Oct 12, 2023 at 9:30 AM 'W. James MacLean' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> While it would obviously be better for the header to only be sent once
>>> (less bytes transmitted), I don't think sending it twice should cause a
>>> problem so long as both headers are the same, e.g. they both specify "?0".
>>> If you're seeing the problem with two headers but not with one, then that's
>>> a bug. In that case filing a bug report at crbug.com, including as much
>>> information as possible, would be appreciated.
>>>
>>> I tried this with a simple test case on my own server, and it seems to
>>> work fine.
>>>
>>> [image: GoogleAnimated.gif]
>>>
>>> ⭘ W. James MacLean
>>>
>>> ⭘ Software Engineer
>>>
>>> ⭘ Google Waterloo
>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>,
>>> Canada
>>>
>>>
>>>
>>> On Fri, 6 Oct 2023 at 01:41, Madanagopal Damodharan <
>>> dmadanago...@gmail.com> wrote:
>>>
>>>> Thanks James. We are able to add the header from our server's servlet
>>>> filter code. It now appends the header for each response including static
>>>> html files. It seems to be working fine so far. There are instances where
>>>> it still gets blocked when a link is opened on new window. I believe we
>>>> need to make sure the new window response contains the header as well,
>>>> right? Also, if the header gets duplicated i.e. if the response contains
>>>> the same header twice, it does not work. It looks as if the header is not
>>>> sent at all. Is this how it is supposed to behave?
>>>>
>>>> On Monday, 25 September 2023 at 20:23:51 UTC+5:30 W. James MacLean
>>>> wrote:
>>>>
>>>>> No, I think you need to get the server to send the header. Once you
>>>>> get as far as the meta tags, the origin's isolation state has already been
>>>>> decided. I'm not an expert on servers, but my experience in specifying
>>>>> headers to be sent with static pages is to edit the .htaccess file in the
>>>>> directory with the content, and include
>>>>>
>>>>> HEADER add Origin-Agent-Cluster: ?0
>>>>>
>>>>> But the exact details will depend on your setup.
>>>>>
>>>>> For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html
>>>>>
>>>>> [image: GoogleAnimated.gif]
>>>>>
>>>>> ⭘ W. James MacLean
>>>>>
>>>>> ⭘ Software Engineer
>>>>>
>>>>> ⭘ Google Waterloo
>>>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>,
>>>>> Canada
>>>>>
>>>>> On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan <
>>>>> dmadan...@gmail.com> wrote:
>>>>>
>>>>>> This helped us identify the response that did not have the header. We
>>>>>> noticed that we have a static html called signon.html as our first entry
>>>>>> into the application. Since this

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

Thanks James. We are able to add the header from our server's servlet 
filter code. It now appends the header for each response including static 
html files. It seems to be working fine so far. There are instances where 
it still gets blocked when a link is opened on new window. I believe we 
need to make sure the new window response contains the header as well, 
right? Also, if the header gets duplicated i.e. if the response contains 
the same header twice, it does not work. It looks as if the header is not 
sent at all. Is this how it is supposed to behave?

On Monday, 25 September 2023 at 20:23:51 UTC+5:30 W. James MacLean wrote:

> No, I think you need to get the server to send the header. Once you get as 
> far as the meta tags, the origin's isolation state has already been 
> decided. I'm not an expert on servers, but my experience in specifying 
> headers to be sent with static pages is to edit the .htaccess file in the 
> directory with the content, and include
>
> HEADER add Origin-Agent-Cluster: ?0
>
> But the exact details will depend on your setup.
>
> For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo 
> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, 
> Canada
>
> On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan  
> wrote:
>
>> This helped us identify the response that did not have the header. We 
>> noticed that we have a static html called signon.html as our first entry 
>> into the application. Since this is a static html, our servlet changes to 
>> add response header does not hit when users invoke this signon.html. I 
>> think Chrome puts this origin into Origin-keyed cluster at this point and 
>> hence when users login and encounter document.domain, they get the error 
>> blocked frame error. 
>>
>> meta tags with http-equiv does not recognize this custom response header 
>> Origin-Agent-Cluster. Is there a way to add response headers in a static 
>> html page response?  
>>
>> On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James MacLean 
>> wrote:
>>
>>> Perhaps try this:
>>> 1) open a new tab page (or about:blank if you prefer)
>>> 2) right-click and select "Inspect" at the bottom of the popup menu
>>> 3) in the DevTools menu at the top, click "Network"
>>> 4) then check the "Preserve Logs" checkbox in the row under that menu
>>> 5) finally, manually type the url for your app/site in the url bar
>>>
>>> As your content loads, the DevTools window will populate with an (in 
>>> order) list of all the network transactions. You can click on each element 
>>> in the list and see the response headers for each request. This should help 
>>> you determine which request is missing the Origin-Agent-Cluster:?0 header 
>>> and causing the origin keying to be applied for the tab.
>>>
>>> Let me know if that helps.
>>>
>>>
>>> [image: GoogleAnimated.gif]
>>>
>>> ⭘ W. James MacLean
>>>
>>> ⭘ Software Engineer
>>>
>>> ⭘ Google Waterloo 
>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, 
>>> Canada
>>>
>>>
>>>
>>> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan <
>>> dmadan...@gmail.com> wrote:
>>>
>>>> An update on the issue I am facing: We have a static html in web server 
>>>> called signon.html. Users access this static html page first which has a 
>>>> refresh directive with content=1. As soon as the user invokes this html 
>>>> page first time from the origin, this redirects to a login form page. This 
>>>> response contains the header too. But still chrome console says the origin 
>>>> was in origin-keyed cluster. If I change the refresh directive content=5, 
>>>> it takes 5 sec to redirect from signon.html to login form, this time I 
>>>> don't get the console warning. Now I can login and dont see any errors. I 
>>>> am not sure why the refresh directive 5 works but not 1. Is it because 
>>>> Chrome could not capture request and place the origin in appropriate 
>>>> cluster within its 1 second?
>>>>
>>>> Modified the CONTENT=5 from CONTENT=1 in the below line to get it 
>>>> working - 
>>>>
>>>> Any thoughts?
>>>>
>>>> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal 
>&g

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

This helped us identify the response that did not have the header. We 
noticed that we have a static html called signon.html as our first entry 
into the application. Since this is a static html, our servlet changes to 
add response header does not hit when users invoke this signon.html. I 
think Chrome puts this origin into Origin-keyed cluster at this point and 
hence when users login and encounter document.domain, they get the error 
blocked frame error. 

meta tags with http-equiv does not recognize this custom response header 
Origin-Agent-Cluster. Is there a way to add response headers in a static 
html page response?  

On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James MacLean wrote:

> Perhaps try this:
> 1) open a new tab page (or about:blank if you prefer)
> 2) right-click and select "Inspect" at the bottom of the popup menu
> 3) in the DevTools menu at the top, click "Network"
> 4) then check the "Preserve Logs" checkbox in the row under that menu
> 5) finally, manually type the url for your app/site in the url bar
>
> As your content loads, the DevTools window will populate with an (in 
> order) list of all the network transactions. You can click on each element 
> in the list and see the response headers for each request. This should help 
> you determine which request is missing the Origin-Agent-Cluster:?0 header 
> and causing the origin keying to be applied for the tab.
>
> Let me know if that helps.
>
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo 
> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, 
> Canada
>
>
>
> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan  
> wrote:
>
>> An update on the issue I am facing: We have a static html in web server 
>> called signon.html. Users access this static html page first which has a 
>> refresh directive with content=1. As soon as the user invokes this html 
>> page first time from the origin, this redirects to a login form page. This 
>> response contains the header too. But still chrome console says the origin 
>> was in origin-keyed cluster. If I change the refresh directive content=5, 
>> it takes 5 sec to redirect from signon.html to login form, this time I 
>> don't get the console warning. Now I can login and dont see any errors. I 
>> am not sure why the refresh directive 5 works but not 1. Is it because 
>> Chrome could not capture request and place the origin in appropriate 
>> cluster within its 1 second?
>>
>> Modified the CONTENT=5 from CONTENT=1 in the below line to get it working 
>> - 
>>
>> Any thoughts?
>>
>> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal Damodharan 
>> wrote:
>>
>> Thanks for response. In my case, I am getting the error when a new tab is 
>> opened from an existing tab. My existing tab did not throw this error 
>> whereas the new tab shows the error on the first request itself. So based 
>> on what you mentioned, my parent tab should have been part of Origin-Keyed 
>> cluster, right? I am seeing console warning as follows on my new tab that 
>> was opened from an existing tab:
>>
>> "The page did not request an Origin-Keyed agent cluster but was put in 
>> one anyway because the origin had previously been placed in an origin-keyed 
>> agent cluster. Update your headers to uniformly request origin-keying for 
>> all pages on the origin"
>>
>> I am currently trying to figure out which server response did not have 
>> the header ""Origin-Agent-Cluster: ?0" that led my pages to get in 
>> origin-keyed cluster. Is there a way (debug tool etc) I can check which 
>> response decided Origin-Keying? I think this will be crucial for 
>> applications to debug the issues. 
>>
>> One other question: My parent tab has a wss (web socket) request that 
>> does not have its response with this OAC header. Do we need the header in 
>> wss response as well?
>>
>>
>> On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean wrote:
>>
>> If the application is getting loaded inside a tab that has previously 
>> loaded other pages from the same origin (i.e. pages not part of the app) 
>> that do not have the header, then for consistency the new loads will get 
>> OAC isolation even if the header is present. Essentially, the first time 
>> the tab loads anything from a particular origin, that determines how it 
>> will treat the origin for the remainder of the tab's lifetime. This 
>> consistency will also extend to other tabs opened by the tab 

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

An update on the issue I am facing: We have a static html in web server 
called signon.html. Users access this static html page first which has a 
refresh directive with content=1. As soon as the user invokes this html 
page first time from the origin, this redirects to a login form page. This 
response contains the header too. But still chrome console says the origin 
was in origin-keyed cluster. If I change the refresh directive content=5, 
it takes 5 sec to redirect from signon.html to login form, this time I 
don't get the console warning. Now I can login and dont see any errors. I 
am not sure why the refresh directive 5 works but not 1. Is it because 
Chrome could not capture request and place the origin in appropriate 
cluster within its 1 second?

Modified the CONTENT=5 from CONTENT=1 in the below line to get it working - 


Any thoughts?

On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal Damodharan 
wrote:

Thanks for response. In my case, I am getting the error when a new tab is 
opened from an existing tab. My existing tab did not throw this error 
whereas the new tab shows the error on the first request itself. So based 
on what you mentioned, my parent tab should have been part of Origin-Keyed 
cluster, right? I am seeing console warning as follows on my new tab that 
was opened from an existing tab:

"The page did not request an Origin-Keyed agent cluster but was put in one 
anyway because the origin had previously been placed in an origin-keyed 
agent cluster. Update your headers to uniformly request origin-keying for 
all pages on the origin"

I am currently trying to figure out which server response did not have the 
header ""Origin-Agent-Cluster: ?0" that led my pages to get in origin-keyed 
cluster. Is there a way (debug tool etc) I can check which response decided 
Origin-Keying? I think this will be crucial for applications to debug the 
issues. 

One other question: My parent tab has a wss (web socket) request that does 
not have its response with this OAC header. Do we need the header in wss 
response as well?


On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean wrote:

If the application is getting loaded inside a tab that has previously 
loaded other pages from the same origin (i.e. pages not part of the app) 
that do not have the header, then for consistency the new loads will get 
OAC isolation even if the header is present. Essentially, the first time 
the tab loads anything from a particular origin, that determines how it 
will treat the origin for the remainder of the tab's lifetime. This 
consistency will also extend to other tabs opened by the tab (as they live 
in the same "BrowsingInstance").

Also, there may be issues where pages can be loaded from cache without the 
?0 version of the header, so two useful steps would be

1) Clear the cache, and
2) open the app directly in a newly opened tab.

I don't think the header needs to be sent on script/css/image requests, as 
they're used within the context of the .html resource that should have the 
header.

[image: GoogleAnimated.gif]

⭘ W. James MacLean

⭘ Software Engineer

⭘ Google Waterloo 
<http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, 
Canada



On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan  
wrote:

Hi All, 

Is the feature launched in Chrome 115 as updated in 
https://developer.chrome.com/blog/document-domain-setter-deprecation? I 
have some of the customers reporting inconsistent behavior. Our application 
sends  "Origin-Agent-Cluster: ?0" in response headers to opt-out of Origin 
Agent clusters since we rely on document.domain. Is this header needed only 
on document requests or even for script, image, css requests? For some 
customer, their pages get inside origin-keyed cluster even though the 
responses contain the header   "Origin-Agent-Cluster: ?0". Is there a bug 
in the chrome behavior that puts pages in specific cluster? How do we debug 
what caused the pages to get inside origin-keyed cluster?

On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote:

@Maud Nalpas is taking over the DevRel work.

On Sat, May 27, 2023 at 12:21 AM Rick Byers  wrote:

Thanks for the update Daniel. Still LGTM. Good luck!

On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim  
wrote:

Hello all, it's been a while... The bug reports should now be resolved, and 
we'd like to have another go at this in the M115 milestone. That is: Remain 
at 50% on beta; starting with 115 ramp up on stable to 1% / 10% / 50% / 
100%, every 14d. Let's hope it sticks this time.

Daniel

On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim  wrote:

Hello all, I'm afraid I have to delay this a bit more. :(

We have a bug report (tracked in crbug.com/1429587) that breaks existing 
apps. The important thing here is that it does not break document.domain 
setting and subsequent cross-origin acc

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

Thanks for response. In my case, I am getting the error when a new tab is 
opened from an existing tab. My existing tab did not throw this error 
whereas the new tab shows the error on the first request itself. So based 
on what you mentioned, my parent tab should have been part of Origin-Keyed 
cluster, right? I am seeing console warning as follows on my new tab that 
was opened from an existing tab:

"The page did not request an Origin-Keyed agent cluster but was put in one 
anyway because the origin had previously been placed in an origin-keyed 
agent cluster. Update your headers to uniformly request origin-keying for 
all pages on the origin"

I am currently trying to figure out which server response did not have the 
header ""Origin-Agent-Cluster: ?0" that led my pages to get in origin-keyed 
cluster. Is there a way (debug tool etc) I can check which response decided 
Origin-Keying? I think this will be crucial for applications to debug the 
issues. 

One other question: My parent tab has a wss (web socket) request that does 
not have its response with this OAC header. Do we need the header in wss 
response as well?


On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean wrote:

> If the application is getting loaded inside a tab that has previously 
> loaded other pages from the same origin (i.e. pages not part of the app) 
> that do not have the header, then for consistency the new loads will get 
> OAC isolation even if the header is present. Essentially, the first time 
> the tab loads anything from a particular origin, that determines how it 
> will treat the origin for the remainder of the tab's lifetime. This 
> consistency will also extend to other tabs opened by the tab (as they live 
> in the same "BrowsingInstance").
>
> Also, there may be issues where pages can be loaded from cache without the 
> ?0 version of the header, so two useful steps would be
>
> 1) Clear the cache, and
> 2) open the app directly in a newly opened tab.
>
> I don't think the header needs to be sent on script/css/image requests, as 
> they're used within the context of the .html resource that should have the 
> header.
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo 
> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, 
> Canada
>
>
>
> On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan  
> wrote:
>
>> Hi All, 
>>
>> Is the feature launched in Chrome 115 as updated in 
>> https://developer.chrome.com/blog/document-domain-setter-deprecation? I 
>> have some of the customers reporting inconsistent behavior. Our application 
>> sends  "Origin-Agent-Cluster: ?0" in response headers to opt-out of 
>> Origin Agent clusters since we rely on document.domain. Is this header 
>> needed only on document requests or even for script, image, css requests? 
>> For some customer, their pages get inside origin-keyed cluster even though 
>> the responses contain the header   "Origin-Agent-Cluster: ?0". Is there 
>> a bug in the chrome behavior that puts pages in specific cluster? How do we 
>> debug what caused the pages to get inside origin-keyed cluster?
>>
>> On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote:
>>
>>> @Maud Nalpas is taking over the DevRel work.
>>>
>>> On Sat, May 27, 2023 at 12:21 AM Rick Byers  wrote:
>>>
>>>> Thanks for the update Daniel. Still LGTM. Good luck!
>>>>
>>>> On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim  
>>>> wrote:
>>>>
>>>>> Hello all, it's been a while... The bug reports should now be 
>>>>> resolved, and we'd like to have another go at this in the M115 milestone. 
>>>>> That is: Remain at 50% on beta; starting with 115 ramp up on stable to 1% 
>>>>> / 
>>>>> 10% / 50% / 100%, every 14d. Let's hope it sticks this time.
>>>>>
>>>>> Daniel
>>>>>
>>>>> On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim  
>>>>> wrote:
>>>>>
>>>>>> Hello all, I'm afraid I have to delay this a bit more. :(
>>>>>>
>>>>>> We have a bug report (tracked in crbug.com/1429587) that breaks 
>>>>>> existing apps. The important thing here is that it does not break 
>>>>>> document.domain setting and subsequent cross-origin access, but that 
>>>>>> instead -- if the conditions are just right; or arguably just wrong -- 
>>>>>> the 
>>>>

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

Hi All, 

Is the feature launched in Chrome 115 as updated in 
https://developer.chrome.com/blog/document-domain-setter-deprecation? I 
have some of the customers reporting inconsistent behavior. Our application 
sends  "Origin-Agent-Cluster: ?0" in response headers to opt-out of Origin 
Agent clusters since we rely on document.domain. Is this header needed only 
on document requests or even for script, image, css requests? For some 
customer, their pages get inside origin-keyed cluster even though the 
responses contain the header   "Origin-Agent-Cluster: ?0". Is there a bug 
in the chrome behavior that puts pages in specific cluster? How do we debug 
what caused the pages to get inside origin-keyed cluster?

On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote:

> @Maud Nalpas is taking over the DevRel work.
>
> On Sat, May 27, 2023 at 12:21 AM Rick Byers  wrote:
>
>> Thanks for the update Daniel. Still LGTM. Good luck!
>>
>> On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim  
>> wrote:
>>
>>> Hello all, it's been a while... The bug reports should now be resolved, 
>>> and we'd like to have another go at this in the M115 milestone. That is: 
>>> Remain at 50% on beta; starting with 115 ramp up on stable to 1% / 10% / 
>>> 50% / 100%, every 14d. Let's hope it sticks this time.
>>>
>>> Daniel
>>>
>>> On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim  
>>> wrote:
>>>
 Hello all, I'm afraid I have to delay this a bit more. :(

 We have a bug report (tracked in crbug.com/1429587) that breaks 
 existing apps. The important thing here is that it does not break 
 document.domain setting and subsequent cross-origin access, but that 
 instead -- if the conditions are just right; or arguably just wrong -- the 
 app can get into a state where same-origin accesses are mistakenly 
 blocked. 
 Apparently an app can get into a state where frames within the same page 
 are inconsistently assigned to agent clusters (i.e., frames in the same 
 origin end up in different processes), and thus subsequent accesses within 
 that origin may fail.

 My plan right now is to leave this on at 50% beta, but to not proceed 
 to any stable releases at any percentage. I'll update this thread when I 
 have a better handle on the bug and can suggest a good way to proceed.

 On Fri, Jan 20, 2023 at 5:12 PM Eiji Kitamura  
 wrote:

> FYI, the enterprise bit has been added to the article.
> https://developer.chrome.com/blog/immutable-document-domain/
>
> On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan  
> wrote:
>
>> We'll make the update in the enterprise release notes too. Thanks for 
>> keeping us in the loop
>>
>> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers  
>> wrote:
>>
>>> Thanks so much Eiji!
>>>
>>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura  
>>> wrote:
>>>
 I've updated the blog post 
  stating 
 Chrome 111 is where we ship the feature, but looks like it's rolling 
 out 
 through 111 and 112?
 I'll update the blog post to mention 
 `OriginAgentClusterDefaultEnabled` enterprise policy.


 On Sat, Jan 14, 2023 at 1:37 AM Rick Byers  
 wrote:

> Thanks for the update Daniel, good luck!
>
> In case others, like me, have missed or forgotten the long history 
> of this difficult deprecation and what it means for web developers, 
> this blog 
> post is a good summary 
> . 
> One critical thing it doesn't mention, but probably should, is that 
> the OriginAgentClusterDefaultEnabled 
> enterprise policy 
> 
>  
> can also be used to revert the default on managed devices (though it 
> looks 
> like the launching milestone needs to be updated there too).
>
> Rick
>
> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hello all,
>>
>> We've now handled the bugs we've discovered, and I would like to 
>> make another attempt at launching. I'll follow the plan that was 
>> approved 
>> here, but two milestones later: Launch to 50% beta in M111 (or late 
>> M110, 
>> if I can still catch a bit of that release cycle), and then ramp on 
>> stable 
>> once M112 is out.
>>
>>
>> On Wed, Dec 14, 2022 at 6:36 PM Daniel Vogelheim <
>> voge...@google.com> wrote:
>>
>>> Hello all,
>>>
>>> An update: Unfortunately we have discovered a bug with this 
>>>