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

[David Benjamin]

To clarify, rejecting the header *is* interpreting it properly. It's not
that duplicates aren't allowed, it's that there is no such thing as a
duplicate header in HTTP. Specifying two headers with the same name is *not* a
no-op. Rather, sending two headers with the same name is simply another
syntax for sending one header with the contents concatenated by comma.
(With the exception of the Set-Cookie header, which is processed a bit
strangely.) This is a holdover from the days when people cared about text
protocols being typable via netcat.

So, by sending:
Origin-Agent-Cluster: ?0
Origin-Agent-Cluster: ?0

You are really sending:
Origin-Agent-Cluster: ?0, ?0

"?0, ?0" is not a valid Origin-Agent-Cluster, thus it is rejected. A
DevTools warning for headers we could not parse would indeed be good, but
rejecting it is correct.

On Sun, Oct 29, 2023 at 12:39 PM Madanagopal Damodharan <
dmadanago...@gmail.com> wrote:

> 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
>> ,
>> 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
>>>  on
>>> that bug.)  I think it will be necessary to only return one copy of the
>>> header, and there's a bug filed  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
 ,
 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
>> ,
>> 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. 

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
> ,
> 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
>>  on
>> that bug.)  I think it will be necessary to only return one copy of the
>> header, and there's a bug filed  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
>>> ,
>>> 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
> ,
> 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 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 

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

['W. James MacLean' via blink-dev]

Thanks creis@ ... I learned something new today!

[image: GoogleAnimated.gif]

⭘ W. James MacLean

⭘ Software Engineer

⭘ Google Waterloo
,
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
>  on
> that bug.)  I think it will be necessary to only return one copy of the
> header, and there's a bug filed  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
>> ,
>> 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
 ,
 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 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
>> 

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

['Charlie Reis' via blink-dev]

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
 on that
bug.)  I think it will be necessary to only return one copy of the header,
and there's a bug filed  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
> ,
> 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
>>> ,
>>> 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 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
> ,
> 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 

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

['W. James MacLean' via blink-dev]

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
,
Canada



On Fri, 6 Oct 2023 at 01:41, Madanagopal Damodharan 
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
>> ,
>> 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 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
 ,
 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 

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 
> , 
> 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 
>>> , 
>>> 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 
 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 

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

['W. James MacLean' via blink-dev]

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
,
Canada


On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan <
dmadanago...@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 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
>> ,
>> 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 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 

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 
> , 
> 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 (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]
>>

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

['W. James MacLean' via blink-dev]

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
,
Canada



On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan <
dmadanago...@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 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
> ,
> 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 

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 
, 
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 app can get 

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 
> , 
> 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 
>> 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:
>>

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

['W. James MacLean' via blink-dev]

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
,
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
> 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 

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 

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

['Eiji Kitamura' via blink-dev]

@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 <
 blink-dev@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 <
> vogelh...@google.com> wrote:
>
>> Hello all,
>>
>> An update: Unfortunately we have discovered a bug with this
>> feature, just as I was getting ready to enable it. The bug also 
>> affects
>> pages that have not even set document.domain. Since I have now 
>> missed a
>> substantial portion of the 109 beta cycle I'd like to delay the roll 
>> out
>> once more, and shift it by one milestone (or two; depending on when
>> everything is fixed).
>>
>> On the positive side: Recently the last of the previously
>> identified big document.domain users, that together accounted for 
>> about 50%
>> of remaining usage, has dropped their usage. So current usage is 
>> lower than
>> previously reported. See the usage dip around late November at
>> deprecate.it (1st graph).
>>
>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor <
>> miketa...@chromium.org> wrote:
>>
>>> LGTM3
>>>
>>> On 

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

[Rick Byers]

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 <
>>> blink-dev@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 <
 vogelh...@google.com> wrote:

> Hello all,
>
> An update: Unfortunately we have discovered a bug with this
> feature, just as I was getting ready to enable it. The bug also 
> affects
> pages that have not even set document.domain. Since I have now missed 
> a
> substantial portion of the 109 beta cycle I'd like to delay the roll 
> out
> once more, and shift it by one milestone (or two; depending on when
> everything is fixed).
>
> On the positive side: Recently the last of the previously
> identified big document.domain users, that together accounted for 
> about 50%
> of remaining usage, has dropped their usage. So current usage is 
> lower than
> previously reported. See the usage dip around late November at
> deprecate.it (1st graph).
>
> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor <
> miketa...@chromium.org> wrote:
>
>> LGTM3
>>
>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either 

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

['Daniel Vogelheim' via blink-dev]

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 <
>> blink-dev@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 <
>>> vogelh...@google.com> wrote:
>>>
 Hello all,

 An update: Unfortunately we have discovered a bug with this
 feature, just as I was getting ready to enable it. The bug also affects
 pages that have not even set document.domain. Since I have now missed a
 substantial portion of the 109 beta cycle I'd like to delay the roll 
 out
 once more, and shift it by one milestone (or two; depending on when
 everything is fixed).

 On the positive side: Recently the last of the previously
 identified big document.domain users, that together accounted for 
 about 50%
 of remaining usage, has dropped their usage. So current usage is lower 
 than
 previously reported. See the usage dip around late November at
 deprecate.it (1st graph).

 On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
 wrote:

> LGTM3
>
> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>
> LGTM2
>
> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
> wrote:
>
>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108
>> or M109, and carefully roll this out for M110, once it hits stable.
>>
>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
>> vogelh...@google.com> wrote:
>>
>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor <
>>> 

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

['Eiji Kitamura' via blink-dev]

I've updated the blog
 so that it's
clear that this change is not happening in Chrome 112.
Has the new milestone been determined yet?

On Mon, Apr 3, 2023 at 11:27 PM Marijke Hoste  wrote:

> Thanks for the update indeed!
>
> On the Enterprise-side, we've mentioned this in the past 7 versions of the
> Enterprise Release Notes, so Admins are aware this is coming and have had
> sufficient notification. We don't think that it's necessary to update them
> of the (potential) delays.
>
> On Fri, Mar 31, 2023 at 10:17 AM Mike Taylor 
> wrote:
>
>> Thanks for the update Daniel, and good luck on fixing the bug. :)
>> On 3/31/23 9:54 AM, 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 <
>>> blink-dev@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 <
 vogelh...@google.com> wrote:

> Hello all,
>
> An update: Unfortunately we have discovered a bug with this
> feature, just as I was getting ready to enable it. The bug also 
> affects
> pages that have not even set document.domain. Since I have now missed 
> a
> substantial portion of the 109 beta cycle I'd like to delay the roll 
> out
> once more, and shift it by one milestone (or two; depending on when
> everything is fixed).
>
> On the positive side: Recently the last of the previously
> identified big document.domain users, that together accounted for 
> about 50%
> of remaining usage, has dropped their usage. So current usage is 
> lower than
> previously reported. See the usage dip around late November at
> deprecate.it (1st graph).
>
> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor <
> miketa...@chromium.org> wrote:
>
>> LGTM3

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

['Marijke Hoste' via blink-dev]

Thanks for the update indeed!

On the Enterprise-side, we've mentioned this in the past 7 versions of the
Enterprise Release Notes, so Admins are aware this is coming and have had
sufficient notification. We don't think that it's necessary to update them
of the (potential) delays.

On Fri, Mar 31, 2023 at 10:17 AM Mike Taylor  wrote:

> Thanks for the update Daniel, and good luck on fixing the bug. :)
> On 3/31/23 9:54 AM, 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 <
>> blink-dev@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 <
>>> vogelh...@google.com> wrote:
>>>
 Hello all,

 An update: Unfortunately we have discovered a bug with this
 feature, just as I was getting ready to enable it. The bug also affects
 pages that have not even set document.domain. Since I have now missed a
 substantial portion of the 109 beta cycle I'd like to delay the roll 
 out
 once more, and shift it by one milestone (or two; depending on when
 everything is fixed).

 On the positive side: Recently the last of the previously
 identified big document.domain users, that together accounted for 
 about 50%
 of remaining usage, has dropped their usage. So current usage is lower 
 than
 previously reported. See the usage dip around late November at
 deprecate.it (1st graph).

 On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
 wrote:

> LGTM3
>
> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>
> LGTM2
>
> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
> wrote:
>
>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108
>> or M109, and carefully roll this out for M110, once it hits stable.
>>
>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
>> 

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

[Mike Taylor]

Thanks for the update Daniel, and good luck on fixing the bug. :)

On 3/31/23 9:54 AM, 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  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  wrote:

Hello all,

An update: Unfortunately we have
discovered a bug with this feature, just
as I was getting ready to enable it. The
bug also affects pages that have not even
set document.domain. Since I have now
missed a substantial portion of the 109
beta cycle I'd like to delay the roll out
once more, and shift it by one milestone
(or two; depending on when everything is
fixed).

On the positive side: Recently the last of
the previously identified
big document.domain users, that together
accounted for about 50% of remaining
usage, has dropped their usage. So current
usage is lower than previously reported.
See the usage dip around late November at
deprecate.it  (1st
graph).

On Thu, Nov 10, 2022 at 5:42 PM Mike
 

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

['Daniel Vogelheim' via blink-dev]

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 <
> blink-dev@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 <
>> vogelh...@google.com> wrote:
>>
>>> Hello all,
>>>
>>> An update: Unfortunately we have discovered a bug with this feature,
>>> just as I was getting ready to enable it. The bug also affects pages 
>>> that
>>> have not even set document.domain. Since I have now missed a substantial
>>> portion of the 109 beta cycle I'd like to delay the roll out once more, 
>>> and
>>> shift it by one milestone (or two; depending on when everything is 
>>> fixed).
>>>
>>> On the positive side: Recently the last of the previously identified
>>> big document.domain users, that together accounted for about 50% of
>>> remaining usage, has dropped their usage. So current usage is lower than
>>> previously reported. See the usage dip around late November at
>>> deprecate.it (1st graph).
>>>
>>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
>>> wrote:
>>>
 LGTM3

 On 11/10/22 11:18 AM, Chris Harrelson wrote:

 LGTM2

 On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
 wrote:

> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108
> or M109, and carefully roll this out for M110, once it hits stable.
>
> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
> vogelh...@google.com> wrote:
>
>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor <
>> miketa...@chromium.org> wrote:
>>
>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>>
>>> Hello all,
>>>
>>> The approval for the Intent To Ship for Origin Isolation By
>>> Default / Deprecate document.domain
>>> 
>>> asks for a separate intent for the actual default change
>>> 

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

['Eiji Kitamura' via blink-dev]

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 <
 blink-dev@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 
> wrote:
>
>> Hello all,
>>
>> An update: Unfortunately we have discovered a bug with this feature,
>> just as I was getting ready to enable it. The bug also affects pages that
>> have not even set document.domain. Since I have now missed a substantial
>> portion of the 109 beta cycle I'd like to delay the roll out once more, 
>> and
>> shift it by one milestone (or two; depending on when everything is 
>> fixed).
>>
>> On the positive side: Recently the last of the previously identified
>> big document.domain users, that together accounted for about 50% of
>> remaining usage, has dropped their usage. So current usage is lower than
>> previously reported. See the usage dip around late November at
>> deprecate.it (1st graph).
>>
>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
>> wrote:
>>
>>> LGTM3
>>>
>>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>>
>>> LGTM2
>>>
>>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
>>> wrote:
>>>
 LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
 M109, and carefully roll this out for M110, once it hits stable.

 On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
 vogelh...@google.com> wrote:

> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
> wrote:
>
>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>
>> Hello all,
>>
>> The approval for the Intent To Ship for Origin Isolation By
>> Default / Deprecate document.domain
>> 
>> asks for a separate intent for the actual default change
>> .
>> This is that separate intent.
>>
>> A summary of what happened so far:
>>
>> - Shipping Origin Isolation by Default (and thereby deprecating
>> document.domain) has security benefits, but compatibility risk.
>>
>> - We added warnings to the developer console and issues panel,
>> published a blog post, and engaged in direct outreach. This has 
>> resulted in
>> substantial, measurable reduction of usage. Some sites keep using
>> document.domain, but have mitigated the deprecation with other 
>> means. This
>> makes the risk difficult to measure.
>>
>> - Sampling of sites with document.domain usage and manual
>> inspection yields a potential breakage estimate at ~0.015% of page 
>> views.
>>
>> What we're asking for here is:
>>
>> - Enable the feature at 50% for beta (+ dev + canary) during
>> M109, as a "last call" for web site authors.
>>
>> This sounds like a good idea. Is 

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

['Brandon Heenan' via blink-dev]

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 <
>>> blink-dev@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 
 wrote:

> Hello all,
>
> An update: Unfortunately we have discovered a bug with this feature,
> just as I was getting ready to enable it. The bug also affects pages that
> have not even set document.domain. Since I have now missed a substantial
> portion of the 109 beta cycle I'd like to delay the roll out once more, 
> and
> shift it by one milestone (or two; depending on when everything is fixed).
>
> On the positive side: Recently the last of the previously identified
> big document.domain users, that together accounted for about 50% of
> remaining usage, has dropped their usage. So current usage is lower than
> previously reported. See the usage dip around late November at
> deprecate.it (1st graph).
>
> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
> wrote:
>
>> LGTM3
>>
>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
>>> M109, and carefully roll this out for M110, once it hits stable.
>>>
>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
>>> vogelh...@google.com> wrote:
>>>
 On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
 wrote:

> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>
> Hello all,
>
> The approval for the Intent To Ship for Origin Isolation By
> Default / Deprecate document.domain
> 
> asks for a separate intent for the actual default change
> .
> This is that separate intent.
>
> A summary of what happened so far:
>
> - Shipping Origin Isolation by Default (and thereby deprecating
> document.domain) has security benefits, but compatibility risk.
>
> - We added warnings to the developer console and issues panel,
> published a blog post, and engaged in direct outreach. This has 
> resulted in
> substantial, measurable reduction of usage. Some sites keep using
> document.domain, but have mitigated the deprecation with other means. 
> This
> makes the risk difficult to measure.
>
> - Sampling of sites with document.domain usage and manual
> inspection yields a potential breakage estimate at ~0.015% of page 
> views.
>
> What we're asking for here is:
>
> - Enable the feature at 50% for beta (+ dev + canary) during M109,
> as a "last call" for web site authors.
>
> This sounds like a good idea. Is there any reason we couldn't go
> to 50% in M108 as well (or are you trying to avoid breakage over the 
> winter
> holidays)?
>
 No reason. I'd be happy to go to beta as soon as I receive the
 lgtms. I had conservatively budgeted that to be 109. :-)

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

[Rick Byers]

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 <
>> blink-dev@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 
>>> wrote:
>>>
 Hello all,

 An update: Unfortunately we have discovered a bug with this feature,
 just as I was getting ready to enable it. The bug also affects pages that
 have not even set document.domain. Since I have now missed a substantial
 portion of the 109 beta cycle I'd like to delay the roll out once more, and
 shift it by one milestone (or two; depending on when everything is fixed).

 On the positive side: Recently the last of the previously identified
 big document.domain users, that together accounted for about 50% of
 remaining usage, has dropped their usage. So current usage is lower than
 previously reported. See the usage dip around late November at
 deprecate.it (1st graph).

 On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
 wrote:

> LGTM3
>
> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>
> LGTM2
>
> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
> wrote:
>
>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
>> M109, and carefully roll this out for M110, once it hits stable.
>>
>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
>>> wrote:
>>>
 On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:

 Hello all,

 The approval for the Intent To Ship for Origin Isolation By
 Default / Deprecate document.domain
 
 asks for a separate intent for the actual default change
 .
 This is that separate intent.

 A summary of what happened so far:

 - Shipping Origin Isolation by Default (and thereby deprecating
 document.domain) has security benefits, but compatibility risk.

 - We added warnings to the developer console and issues panel,
 published a blog post, and engaged in direct outreach. This has 
 resulted in
 substantial, measurable reduction of usage. Some sites keep using
 document.domain, but have mitigated the deprecation with other means. 
 This
 makes the risk difficult to measure.

 - Sampling of sites with document.domain usage and manual
 inspection yields a potential breakage estimate at ~0.015% of page 
 views.

 What we're asking for here is:

 - Enable the feature at 50% for beta (+ dev + canary) during M109,
 as a "last call" for web site authors.

 This sounds like a good idea. Is there any reason we couldn't go to
 50% in M108 as well (or are you trying to avoid breakage over the 
 winter
 holidays)?

>>> No reason. I'd be happy to go to beta as soon as I receive the
>>> lgtms. I had conservatively budgeted that to be 109. :-)
>>>
>>>
 Another question: do we have enterprise policies available for this
 change?

>>>
>>> Yes; the policy is here: OriginAgentClusterDefaultEnabled
>>> 

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

['Eiji Kitamura' via blink-dev]

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 <
> blink-dev@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 
>> wrote:
>>
>>> Hello all,
>>>
>>> An update: Unfortunately we have discovered a bug with this feature,
>>> just as I was getting ready to enable it. The bug also affects pages that
>>> have not even set document.domain. Since I have now missed a substantial
>>> portion of the 109 beta cycle I'd like to delay the roll out once more, and
>>> shift it by one milestone (or two; depending on when everything is fixed).
>>>
>>> On the positive side: Recently the last of the previously identified
>>> big document.domain users, that together accounted for about 50% of
>>> remaining usage, has dropped their usage. So current usage is lower than
>>> previously reported. See the usage dip around late November at
>>> deprecate.it (1st graph).
>>>
>>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
>>> wrote:
>>>
 LGTM3

 On 11/10/22 11:18 AM, Chris Harrelson wrote:

 LGTM2

 On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
 wrote:

> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
> M109, and carefully roll this out for M110, once it hits stable.
>
> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
> wrote:
>
>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
>> wrote:
>>
>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>>
>>> Hello all,
>>>
>>> The approval for the Intent To Ship for Origin Isolation By Default
>>> / Deprecate document.domain
>>> 
>>> asks for a separate intent for the actual default change
>>> .
>>> This is that separate intent.
>>>
>>> A summary of what happened so far:
>>>
>>> - Shipping Origin Isolation by Default (and thereby deprecating
>>> document.domain) has security benefits, but compatibility risk.
>>>
>>> - We added warnings to the developer console and issues panel,
>>> published a blog post, and engaged in direct outreach. This has 
>>> resulted in
>>> substantial, measurable reduction of usage. Some sites keep using
>>> document.domain, but have mitigated the deprecation with other means. 
>>> This
>>> makes the risk difficult to measure.
>>>
>>> - Sampling of sites with document.domain usage and manual inspection
>>> yields a potential breakage estimate at ~0.015% of page views.
>>>
>>> What we're asking for here is:
>>>
>>> - Enable the feature at 50% for beta (+ dev + canary) during M109,
>>> as a "last call" for web site authors.
>>>
>>> This sounds like a good idea. Is there any reason we couldn't go to
>>> 50% in M108 as well (or are you trying to avoid breakage over the winter
>>> holidays)?
>>>
>> No reason. I'd be happy to go to beta as soon as I receive the lgtms.
>> I had conservatively budgeted that to be 109. :-)
>>
>>
>>> Another question: do we have enterprise policies available for this
>>> change?
>>>
>>
>> Yes; the policy is here: OriginAgentClusterDefaultEnabled
>> 
>>
>>
>>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>>>
>>>
>>> 
>>>
>>> 

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

[Rick Byers]

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 <
blink-dev@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 
> wrote:
>
>> Hello all,
>>
>> An update: Unfortunately we have discovered a bug with this feature, just
>> as I was getting ready to enable it. The bug also affects pages that
>> have not even set document.domain. Since I have now missed a substantial
>> portion of the 109 beta cycle I'd like to delay the roll out once more, and
>> shift it by one milestone (or two; depending on when everything is fixed).
>>
>> On the positive side: Recently the last of the previously identified
>> big document.domain users, that together accounted for about 50% of
>> remaining usage, has dropped their usage. So current usage is lower than
>> previously reported. See the usage dip around late November at
>> deprecate.it (1st graph).
>>
>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
>> wrote:
>>
>>> LGTM3
>>>
>>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>>
>>> LGTM2
>>>
>>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss  wrote:
>>>
 LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
 M109, and carefully roll this out for M110, once it hits stable.

 On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
 wrote:

> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
> wrote:
>
>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>
>> Hello all,
>>
>> The approval for the Intent To Ship for Origin Isolation By Default
>> / Deprecate document.domain
>> 
>> asks for a separate intent for the actual default change
>> .
>> This is that separate intent.
>>
>> A summary of what happened so far:
>>
>> - Shipping Origin Isolation by Default (and thereby deprecating
>> document.domain) has security benefits, but compatibility risk.
>>
>> - We added warnings to the developer console and issues panel,
>> published a blog post, and engaged in direct outreach. This has resulted 
>> in
>> substantial, measurable reduction of usage. Some sites keep using
>> document.domain, but have mitigated the deprecation with other means. 
>> This
>> makes the risk difficult to measure.
>>
>> - Sampling of sites with document.domain usage and manual inspection
>> yields a potential breakage estimate at ~0.015% of page views.
>>
>> What we're asking for here is:
>>
>> - Enable the feature at 50% for beta (+ dev + canary) during M109, as
>> a "last call" for web site authors.
>>
>> This sounds like a good idea. Is there any reason we couldn't go to
>> 50% in M108 as well (or are you trying to avoid breakage over the winter
>> holidays)?
>>
> No reason. I'd be happy to go to beta as soon as I receive the lgtms.
> I had conservatively budgeted that to be 109. :-)
>
>
>> Another question: do we have enterprise policies available for this
>> change?
>>
>
> Yes; the policy is here: OriginAgentClusterDefaultEnabled
> 
>
>
>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>>
>>
>> 
>>
>> Contact emails v...@chromium.org, vogelh...@chromium.org
>> Specification Explainer:
>> https://github.com/mikewest/deprecating-document-domain HTML Spec
>> draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd
>> API spec Yes
>> Summary
>>
>> This is a follow-on to the Intent to Ship: Origin Isolation By
>> Default / Deprecate document.domain
>> . 
>> 

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

['Daniel Vogelheim' via blink-dev]

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 
wrote:

> Hello all,
>
> An update: Unfortunately we have discovered a bug with this feature, just
> as I was getting ready to enable it. The bug also affects pages that
> have not even set document.domain. Since I have now missed a substantial
> portion of the 109 beta cycle I'd like to delay the roll out once more, and
> shift it by one milestone (or two; depending on when everything is fixed).
>
> On the positive side: Recently the last of the previously identified
> big document.domain users, that together accounted for about 50% of
> remaining usage, has dropped their usage. So current usage is lower than
> previously reported. See the usage dip around late November at
> deprecate.it (1st graph).
>
> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
> wrote:
>
>> LGTM3
>>
>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>
>> LGTM2
>>
>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss  wrote:
>>
>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
>>> M109, and carefully roll this out for M110, once it hits stable.
>>>
>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
 wrote:

> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>
> Hello all,
>
> The approval for the Intent To Ship for Origin Isolation By Default /
> Deprecate document.domain
> 
> asks for a separate intent for the actual default change
> .
> This is that separate intent.
>
> A summary of what happened so far:
>
> - Shipping Origin Isolation by Default (and thereby deprecating
> document.domain) has security benefits, but compatibility risk.
>
> - We added warnings to the developer console and issues panel,
> published a blog post, and engaged in direct outreach. This has resulted 
> in
> substantial, measurable reduction of usage. Some sites keep using
> document.domain, but have mitigated the deprecation with other means. This
> makes the risk difficult to measure.
>
> - Sampling of sites with document.domain usage and manual inspection
> yields a potential breakage estimate at ~0.015% of page views.
>
> What we're asking for here is:
>
> - Enable the feature at 50% for beta (+ dev + canary) during M109, as
> a "last call" for web site authors.
>
> This sounds like a good idea. Is there any reason we couldn't go to
> 50% in M108 as well (or are you trying to avoid breakage over the winter
> holidays)?
>
 No reason. I'd be happy to go to beta as soon as I receive the lgtms. I
 had conservatively budgeted that to be 109. :-)


> Another question: do we have enterprise policies available for this
> change?
>

 Yes; the policy is here: OriginAgentClusterDefaultEnabled
 


> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>
>
> 
>
> Contact emails v...@chromium.org, vogelh...@chromium.org
> Specification Explainer:
> https://github.com/mikewest/deprecating-document-domain HTML Spec
> draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd
> API spec Yes
> Summary
>
> This is a follow-on to the Intent to Ship: Origin Isolation By
> Default / Deprecate document.domain
> . 
> We'd
> like to ship this in M110, stable.
>
> Summary (of the underlying change) Change the default behavior of the
> Origin-Agent-Cluster: header / document.domain settability.
> Presently, pages within Chromium have site-keyed agent clusters by
> default, unless the Origin-Agent-Cluster: header is explicitly set to 
> true.
> This accommodates pages or frames which want to access each other's state,
> despite being on different origins (but within a site). This is fine for
> any pages that wish to do so, but because a page *might* set
> document.domain later on, Chromium currently must use site-keyed agent
> clusters for *all* pages by default even though the overwhelming majority
> of pages do not ever make use of this (mis-)feature. In turn, this 
> requires
> 

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

['Daniel Vogelheim' via blink-dev]

Hello all,

An update: Unfortunately we have discovered a bug with this feature, just
as I was getting ready to enable it. The bug also affects pages that
have not even set document.domain. Since I have now missed a substantial
portion of the 109 beta cycle I'd like to delay the roll out once more, and
shift it by one milestone (or two; depending on when everything is fixed).

On the positive side: Recently the last of the previously identified
big document.domain users, that together accounted for about 50% of
remaining usage, has dropped their usage. So current usage is lower than
previously reported. See the usage dip around late November at
deprecate.it (1st
graph).

On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor  wrote:

> LGTM3
>
> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>
> LGTM2
>
> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss  wrote:
>
>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or M109,
>> and carefully roll this out for M110, once it hits stable.
>>
>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
>>> wrote:
>>>
 On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:

 Hello all,

 The approval for the Intent To Ship for Origin Isolation By Default /
 Deprecate document.domain
 
 asks for a separate intent for the actual default change
 .
 This is that separate intent.

 A summary of what happened so far:

 - Shipping Origin Isolation by Default (and thereby deprecating
 document.domain) has security benefits, but compatibility risk.

 - We added warnings to the developer console and issues panel,
 published a blog post, and engaged in direct outreach. This has resulted in
 substantial, measurable reduction of usage. Some sites keep using
 document.domain, but have mitigated the deprecation with other means. This
 makes the risk difficult to measure.

 - Sampling of sites with document.domain usage and manual inspection
 yields a potential breakage estimate at ~0.015% of page views.

 What we're asking for here is:

 - Enable the feature at 50% for beta (+ dev + canary) during M109, as a
 "last call" for web site authors.

 This sounds like a good idea. Is there any reason we couldn't go to 50%
 in M108 as well (or are you trying to avoid breakage over the winter
 holidays)?

>>> No reason. I'd be happy to go to beta as soon as I receive the lgtms. I
>>> had conservatively budgeted that to be 109. :-)
>>>
>>>
 Another question: do we have enterprise policies available for this
 change?

>>>
>>> Yes; the policy is here: OriginAgentClusterDefaultEnabled
>>> 
>>>
>>>
 - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)


 

 Contact emails v...@chromium.org, vogelh...@chromium.org
 Specification Explainer:
 https://github.com/mikewest/deprecating-document-domain HTML Spec
 draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd
 API spec Yes
 Summary

 This is a follow-on to the Intent to Ship: Origin Isolation By Default
 / Deprecate document.domain
 . We'd
 like to ship this in M110, stable.

 Summary (of the underlying change) Change the default behavior of the
 Origin-Agent-Cluster: header / document.domain settability.
 Presently, pages within Chromium have site-keyed agent clusters by
 default, unless the Origin-Agent-Cluster: header is explicitly set to true.
 This accommodates pages or frames which want to access each other's state,
 despite being on different origins (but within a site). This is fine for
 any pages that wish to do so, but because a page *might* set
 document.domain later on, Chromium currently must use site-keyed agent
 clusters for *all* pages by default even though the overwhelming majority
 of pages do not ever make use of this (mis-)feature. In turn, this requires
 Chromium to use sites as the basis for renderer process isolation (via Site
 Isolation), which exposes origins to same-site but cross-origin attacks
 involving compromised renderer processes or the "Spectre" family of
 side-channel attacks.
 This proposal changes the default behaviour of Origin-Agent-Cluster.
 From a developer's point of view, the new default matches
 "Origin-Agent-Cluster: ?1". The initial implementation will use
 origin-keyed agent clusters for all (non-opted out) origins, without

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

[Mike Taylor]

LGTM3

On 11/10/22 11:18 AM, Chris Harrelson wrote:

LGTM2

On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss  wrote:

LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108
or M109, and carefully roll this out for M110, once it hits stable.

On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim
 wrote:

On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor
 wrote:

On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:


Hello all,


The approval for the Intent To Ship for Origin Isolation
By Default / Deprecate document.domain

asks
for a separate intent for the actual default change

.
This is that separate intent.


A summary of what happened so far:

- Shipping Origin Isolation by Default (and thereby
deprecating document.domain) has security benefits, but
compatibility risk.

- We added warnings to the developer console and issues
panel, published a blog post, and engaged in direct
outreach. This has resulted in substantial, measurable
reduction of usage. Some sites keep using
document.domain, but have mitigated the deprecation with
other means. This makes the risk difficult to measure.

- Sampling of sites with document.domain usage and manual
inspection yields a potential breakage estimate at
~0.015% of page views.


What we're asking for here is:

- Enable the feature at 50% for beta (+ dev + canary)
during M109, as a "last call" for web site authors.


This sounds like a good idea. Is there any reason we
couldn't go to 50% in M108 as well (or are you trying to
avoid breakage over the winter holidays)?

No reason. I'd be happy to go to beta as soon as I receive the
lgtms. I had conservatively budgeted that to be 109. :-)

Another question: do we have enterprise policies available
for this change?


Yes; the policy is here: OriginAgentClusterDefaultEnabled





- Launch on stable on M110. (~ Feb '23, so >12 weeks out
from today)






Contact emails


v...@chromium.org, vogelh...@chromium.org


Specification



Explainer:https://github.com/mikewest/deprecating-document-domain



HTML Spec

draft:https://github.com/whatwg/html/compare/main...otherdaniel:dd




API spec


Yes


Summary

This is a follow-on to the Intent to Ship: Origin
Isolation By Default / Deprecate document.domain

. We'd
like to ship this in M110, stable.


Summary (of the underlying change)


Change the default behavior of the
Origin-Agent-Cluster: header / document.domain
settability.


Presently, pages within Chromium have site-keyed
agent clusters by default, unless the
Origin-Agent-Cluster: header is explicitly set to
true. This accommodates pages or frames which
want to access each other's state, despite being
on different origins (but within a site). This is
fine for any pages that wish to do so, but
because a page *might* set document.domain later
on, Chromium currently must use site-keyed agent
clusters for *all* pages by default even though
the overwhelming majority of pages do not ever
make use of this (mis-)feature. In turn, this
requires Chromium to use sites as the basis for
renderer process isolation (via Site Isolation),
which exposes origins to same-site but
cross-origin attacks involving compromised
renderer processes or the "Spectre" family of
side-channel attacks.


This proposal changes the default behaviour of

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

[Chris Harrelson]

LGTM2

On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss  wrote:

> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or M109,
> and carefully roll this out for M110, once it hits stable.
>
> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
> wrote:
>
>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
>> wrote:
>>
>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>>
>>> Hello all,
>>>
>>> The approval for the Intent To Ship for Origin Isolation By Default /
>>> Deprecate document.domain
>>> 
>>> asks for a separate intent for the actual default change
>>> .
>>> This is that separate intent.
>>>
>>> A summary of what happened so far:
>>>
>>> - Shipping Origin Isolation by Default (and thereby deprecating
>>> document.domain) has security benefits, but compatibility risk.
>>>
>>> - We added warnings to the developer console and issues panel, published
>>> a blog post, and engaged in direct outreach. This has resulted in
>>> substantial, measurable reduction of usage. Some sites keep using
>>> document.domain, but have mitigated the deprecation with other means. This
>>> makes the risk difficult to measure.
>>>
>>> - Sampling of sites with document.domain usage and manual inspection
>>> yields a potential breakage estimate at ~0.015% of page views.
>>>
>>> What we're asking for here is:
>>>
>>> - Enable the feature at 50% for beta (+ dev + canary) during M109, as a
>>> "last call" for web site authors.
>>>
>>> This sounds like a good idea. Is there any reason we couldn't go to 50%
>>> in M108 as well (or are you trying to avoid breakage over the winter
>>> holidays)?
>>>
>> No reason. I'd be happy to go to beta as soon as I receive the lgtms. I
>> had conservatively budgeted that to be 109. :-)
>>
>>
>>> Another question: do we have enterprise policies available for this
>>> change?
>>>
>>
>> Yes; the policy is here: OriginAgentClusterDefaultEnabled
>> 
>>
>>
>>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>>>
>>>
>>> 
>>>
>>> Contact emails v...@chromium.org, vogelh...@chromium.org
>>> Specification Explainer:
>>> https://github.com/mikewest/deprecating-document-domain HTML Spec draft:
>>> https://github.com/whatwg/html/compare/main...otherdaniel:dd
>>> API spec Yes
>>> Summary
>>>
>>> This is a follow-on to the Intent to Ship: Origin Isolation By Default
>>> / Deprecate document.domain
>>> . We'd
>>> like to ship this in M110, stable.
>>>
>>> Summary (of the underlying change) Change the default behavior of the
>>> Origin-Agent-Cluster: header / document.domain settability.
>>> Presently, pages within Chromium have site-keyed agent clusters by
>>> default, unless the Origin-Agent-Cluster: header is explicitly set to true.
>>> This accommodates pages or frames which want to access each other's state,
>>> despite being on different origins (but within a site). This is fine for
>>> any pages that wish to do so, but because a page *might* set
>>> document.domain later on, Chromium currently must use site-keyed agent
>>> clusters for *all* pages by default even though the overwhelming majority
>>> of pages do not ever make use of this (mis-)feature. In turn, this requires
>>> Chromium to use sites as the basis for renderer process isolation (via Site
>>> Isolation), which exposes origins to same-site but cross-origin attacks
>>> involving compromised renderer processes or the "Spectre" family of
>>> side-channel attacks.
>>> This proposal changes the default behaviour of Origin-Agent-Cluster.
>>> From a developer's point of view, the new default matches
>>> "Origin-Agent-Cluster: ?1". The initial implementation will use
>>> origin-keyed agent clusters for all (non-opted out) origins, without
>>> changing how many processes Chromium creates. Over time, we can then adapt
>>> Chromium's isolation strategy towards origin-keyed processes without
>>> further affecting web-visible behaviour.
>>> The developer-visible aspect of this is that for pages with origin-keyed
>>> agent clusters, document.domain is no longer settable. Thus, we have marked
>>> this intent as a deprecation.
>>> Note that this proposal is about the default. Both modes - site-keyed or
>>> origin-keyed agent clusters - remain available to any site, but
>>> origin-keyed agent clusters change from opt-in to opt-out. The current
>>> behaviour remains available by setting "Origin-Agent-Cluster: ?0".
>>> Blink component Blink>SecurityFeature
>>> TAG review https://github.com/w3ctag/design-reviews/issues/564
>>> Risks: Interoperability and Compatibility
>>>
>>> There are compatibility risks, which we have 

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

[Yoav Weiss]

LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or M109,
and carefully roll this out for M110, once it hits stable.

On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim 
wrote:

> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor  wrote:
>
>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>
>> Hello all,
>>
>> The approval for the Intent To Ship for Origin Isolation By Default /
>> Deprecate document.domain
>> 
>> asks for a separate intent for the actual default change
>> .
>> This is that separate intent.
>>
>> A summary of what happened so far:
>>
>> - Shipping Origin Isolation by Default (and thereby deprecating
>> document.domain) has security benefits, but compatibility risk.
>>
>> - We added warnings to the developer console and issues panel, published
>> a blog post, and engaged in direct outreach. This has resulted in
>> substantial, measurable reduction of usage. Some sites keep using
>> document.domain, but have mitigated the deprecation with other means. This
>> makes the risk difficult to measure.
>>
>> - Sampling of sites with document.domain usage and manual inspection
>> yields a potential breakage estimate at ~0.015% of page views.
>>
>> What we're asking for here is:
>>
>> - Enable the feature at 50% for beta (+ dev + canary) during M109, as a
>> "last call" for web site authors.
>>
>> This sounds like a good idea. Is there any reason we couldn't go to 50%
>> in M108 as well (or are you trying to avoid breakage over the winter
>> holidays)?
>>
> No reason. I'd be happy to go to beta as soon as I receive the lgtms. I
> had conservatively budgeted that to be 109. :-)
>
>
>> Another question: do we have enterprise policies available for this
>> change?
>>
>
> Yes; the policy is here: OriginAgentClusterDefaultEnabled
> 
>
>
>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>>
>>
>> 
>>
>> Contact emails v...@chromium.org, vogelh...@chromium.org
>> Specification Explainer:
>> https://github.com/mikewest/deprecating-document-domain HTML Spec draft:
>> https://github.com/whatwg/html/compare/main...otherdaniel:dd
>> API spec Yes
>> Summary
>>
>> This is a follow-on to the Intent to Ship: Origin Isolation By Default /
>> Deprecate document.domain
>> . We'd
>> like to ship this in M110, stable.
>>
>> Summary (of the underlying change) Change the default behavior of the
>> Origin-Agent-Cluster: header / document.domain settability.
>> Presently, pages within Chromium have site-keyed agent clusters by
>> default, unless the Origin-Agent-Cluster: header is explicitly set to true.
>> This accommodates pages or frames which want to access each other's state,
>> despite being on different origins (but within a site). This is fine for
>> any pages that wish to do so, but because a page *might* set
>> document.domain later on, Chromium currently must use site-keyed agent
>> clusters for *all* pages by default even though the overwhelming majority
>> of pages do not ever make use of this (mis-)feature. In turn, this requires
>> Chromium to use sites as the basis for renderer process isolation (via Site
>> Isolation), which exposes origins to same-site but cross-origin attacks
>> involving compromised renderer processes or the "Spectre" family of
>> side-channel attacks.
>> This proposal changes the default behaviour of Origin-Agent-Cluster. From
>> a developer's point of view, the new default matches "Origin-Agent-Cluster:
>> ?1". The initial implementation will use origin-keyed agent clusters for
>> all (non-opted out) origins, without changing how many processes Chromium
>> creates. Over time, we can then adapt Chromium's isolation strategy towards
>> origin-keyed processes without further affecting web-visible behaviour.
>> The developer-visible aspect of this is that for pages with origin-keyed
>> agent clusters, document.domain is no longer settable. Thus, we have marked
>> this intent as a deprecation.
>> Note that this proposal is about the default. Both modes - site-keyed or
>> origin-keyed agent clusters - remain available to any site, but
>> origin-keyed agent clusters change from opt-in to opt-out. The current
>> behaviour remains available by setting "Origin-Agent-Cluster: ?0".
>> Blink component Blink>SecurityFeature
>> TAG review https://github.com/w3ctag/design-reviews/issues/564
>> Risks: Interoperability and Compatibility
>>
>> There are compatibility risks, which we have reduced with outreach and
>> warnings, and we want to mitigate further by launching at 50% of beta
>> first. An extended discussion of the risk (including attempts at
>> 

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

['Daniel Vogelheim' via blink-dev]

On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor  wrote:

> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>
> Hello all,
>
> The approval for the Intent To Ship for Origin Isolation By Default /
> Deprecate document.domain
> 
> asks for a separate intent for the actual default change
> .
> This is that separate intent.
>
> A summary of what happened so far:
>
> - Shipping Origin Isolation by Default (and thereby deprecating
> document.domain) has security benefits, but compatibility risk.
>
> - We added warnings to the developer console and issues panel, published a
> blog post, and engaged in direct outreach. This has resulted in
> substantial, measurable reduction of usage. Some sites keep using
> document.domain, but have mitigated the deprecation with other means. This
> makes the risk difficult to measure.
>
> - Sampling of sites with document.domain usage and manual inspection
> yields a potential breakage estimate at ~0.015% of page views.
>
> What we're asking for here is:
>
> - Enable the feature at 50% for beta (+ dev + canary) during M109, as a
> "last call" for web site authors.
>
> This sounds like a good idea. Is there any reason we couldn't go to 50% in
> M108 as well (or are you trying to avoid breakage over the winter holidays)?
>
No reason. I'd be happy to go to beta as soon as I receive the lgtms. I had
conservatively budgeted that to be 109. :-)


> Another question: do we have enterprise policies available for this change?
>

Yes; the policy is here: OriginAgentClusterDefaultEnabled



> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>
>
> 
>
> Contact emails v...@chromium.org, vogelh...@chromium.org
> Specification Explainer:
> https://github.com/mikewest/deprecating-document-domain HTML Spec draft:
> https://github.com/whatwg/html/compare/main...otherdaniel:dd
> API spec Yes
> Summary
>
> This is a follow-on to the Intent to Ship: Origin Isolation By Default /
> Deprecate document.domain
> . We'd
> like to ship this in M110, stable.
>
> Summary (of the underlying change) Change the default behavior of the
> Origin-Agent-Cluster: header / document.domain settability.
> Presently, pages within Chromium have site-keyed agent clusters by
> default, unless the Origin-Agent-Cluster: header is explicitly set to true.
> This accommodates pages or frames which want to access each other's state,
> despite being on different origins (but within a site). This is fine for
> any pages that wish to do so, but because a page *might* set
> document.domain later on, Chromium currently must use site-keyed agent
> clusters for *all* pages by default even though the overwhelming majority
> of pages do not ever make use of this (mis-)feature. In turn, this requires
> Chromium to use sites as the basis for renderer process isolation (via Site
> Isolation), which exposes origins to same-site but cross-origin attacks
> involving compromised renderer processes or the "Spectre" family of
> side-channel attacks.
> This proposal changes the default behaviour of Origin-Agent-Cluster. From
> a developer's point of view, the new default matches "Origin-Agent-Cluster:
> ?1". The initial implementation will use origin-keyed agent clusters for
> all (non-opted out) origins, without changing how many processes Chromium
> creates. Over time, we can then adapt Chromium's isolation strategy towards
> origin-keyed processes without further affecting web-visible behaviour.
> The developer-visible aspect of this is that for pages with origin-keyed
> agent clusters, document.domain is no longer settable. Thus, we have marked
> this intent as a deprecation.
> Note that this proposal is about the default. Both modes - site-keyed or
> origin-keyed agent clusters - remain available to any site, but
> origin-keyed agent clusters change from opt-in to opt-out. The current
> behaviour remains available by setting "Origin-Agent-Cluster: ?0".
> Blink component Blink>SecurityFeature
> TAG review https://github.com/w3ctag/design-reviews/issues/564
> Risks: Interoperability and Compatibility
>
> There are compatibility risks, which we have reduced with outreach and
> warnings, and we want to mitigate further by launching at 50% of beta
> first. An extended discussion of the risk (including attempts at
> quantitative assessment) can be found in the original intent to ship
> .
>
> Gecko: Standards position request
> . ("Worth
> prototyping")
>
> WebKit:
> 

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

[Mike Taylor]

On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:


Hello all,


The approval for the Intent To Ship for Origin Isolation By Default / 
Deprecate document.domain 
asks 
for a separate intent for the actual default change 
. 
This is that separate intent.



A summary of what happened so far:

- Shipping Origin Isolation by Default (and thereby deprecating 
document.domain) has security benefits, but compatibility risk.


- We added warnings to the developer console and issues panel, 
published a blog post, and engaged in direct outreach. This has 
resulted in substantial, measurable reduction of usage. Some sites 
keep using document.domain, but have mitigated the deprecation with 
other means. This makes the risk difficult to measure.


- Sampling of sites with document.domain usage and manual inspection 
yields a potential breakage estimate at ~0.015% of page views.



What we're asking for here is:

- Enable the feature at 50% for beta (+ dev + canary) during M109, as 
a "last call" for web site authors.


This sounds like a good idea. Is there any reason we couldn't go to 50% 
in M108 as well (or are you trying to avoid breakage over the winter 
holidays)?


Another question: do we have enterprise policies available for this change?


- Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)






Contact emails


v...@chromium.org, vogelh...@chromium.org


Specification


Explainer:https://github.com/mikewest/deprecating-document-domain



HTML Spec
draft:https://github.com/whatwg/html/compare/main...otherdaniel:dd



API spec


Yes


Summary

This is a follow-on to the Intent to Ship: Origin Isolation By Default 
/ Deprecate document.domain 
. We'd 
like to ship this in M110, stable.



Summary (of the underlying change)


Change the default behavior of the Origin-Agent-Cluster:
header / document.domain settability.


Presently, pages within Chromium have site-keyed agent
clusters by default, unless the Origin-Agent-Cluster: header
is explicitly set to true. This accommodates pages or frames
which want to access each other's state, despite being on
different origins (but within a site). This is fine for any
pages that wish to do so, but because a page *might* set
document.domain later on, Chromium currently must use
site-keyed agent clusters for *all* pages by default even
though the overwhelming majority of pages do not ever make use
of this (mis-)feature. In turn, this requires Chromium to use
sites as the basis for renderer process isolation (via Site
Isolation), which exposes origins to same-site but
cross-origin attacks involving compromised renderer processes
or the "Spectre" family of side-channel attacks.


This proposal changes the default behaviour of
Origin-Agent-Cluster. From a developer's point of view, the
new default matches "Origin-Agent-Cluster: ?1". The initial
implementation will use origin-keyed agent clusters for all
(non-opted out) origins, without changing how many processes
Chromium creates. Over time, we can then adapt Chromium's
isolation strategy towards origin-keyed processes without
further affecting web-visible behaviour.


The developer-visible aspect of this is that for pages with
origin-keyed agent clusters, document.domain is no longer
settable. Thus, we have marked this intent as a deprecation.


Note that this proposal is about the default. Both modes -
site-keyed or origin-keyed agent clusters - remain available
to any site, but origin-keyed agent clusters change from
opt-in to opt-out. The current behaviour remains available by
setting "Origin-Agent-Cluster: ?0".


Blink component


Blink>SecurityFeature


TAG review


https://github.com/w3ctag/design-reviews/issues/564



Risks: Interoperability and Compatibility

There are compatibility risks, which we have reduced with outreach and 
warnings, and we want to mitigate further by launching at 50% of beta 
first. An extended discussion of the risk (including attempts at 
quantitative assessment) can be found in the original intent to ship 
.



Gecko:Standards position request 

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

['Daniel Vogelheim' via blink-dev]

Hello all,

The approval for the Intent To Ship for Origin Isolation By Default /
Deprecate document.domain
 asks
for a separate intent for the actual default change
.
This is that separate intent.

A summary of what happened so far:

- Shipping Origin Isolation by Default (and thereby deprecating
document.domain) has security benefits, but compatibility risk.

- We added warnings to the developer console and issues panel, published a
blog post, and engaged in direct outreach. This has resulted in
substantial, measurable reduction of usage. Some sites keep using
document.domain, but have mitigated the deprecation with other means. This
makes the risk difficult to measure.

- Sampling of sites with document.domain usage and manual inspection yields
a potential breakage estimate at ~0.015% of page views.

What we're asking for here is:

- Enable the feature at 50% for beta (+ dev + canary) during M109, as a
"last call" for web site authors.

- Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)




Contact emailsv...@chromium.org, vogelh...@chromium.org
SpecificationExplainer:
https://github.com/mikewest/deprecating-document-domainHTML Spec draft:
https://github.com/whatwg/html/compare/main...otherdaniel:dd
API specYes
Summary

This is a follow-on to the Intent to Ship: Origin Isolation By Default /
Deprecate document.domain
. We'd
like to ship this in M110, stable.

Summary (of the underlying change)Change the default behavior of the
Origin-Agent-Cluster: header / document.domain settability.
Presently, pages within Chromium have site-keyed agent clusters by default,
unless the Origin-Agent-Cluster: header is explicitly set to true. This
accommodates pages or frames which want to access each other's state,
despite being on different origins (but within a site). This is fine for
any pages that wish to do so, but because a page *might* set
document.domain later on, Chromium currently must use site-keyed agent
clusters for *all* pages by default even though the overwhelming majority
of pages do not ever make use of this (mis-)feature. In turn, this requires
Chromium to use sites as the basis for renderer process isolation (via Site
Isolation), which exposes origins to same-site but cross-origin attacks
involving compromised renderer processes or the "Spectre" family of
side-channel attacks.
This proposal changes the default behaviour of Origin-Agent-Cluster. From a
developer's point of view, the new default matches "Origin-Agent-Cluster:
?1". The initial implementation will use origin-keyed agent clusters for
all (non-opted out) origins, without changing how many processes Chromium
creates. Over time, we can then adapt Chromium's isolation strategy towards
origin-keyed processes without further affecting web-visible behaviour.
The developer-visible aspect of this is that for pages with origin-keyed
agent clusters, document.domain is no longer settable. Thus, we have marked
this intent as a deprecation.
Note that this proposal is about the default. Both modes - site-keyed or
origin-keyed agent clusters - remain available to any site, but
origin-keyed agent clusters change from opt-in to opt-out. The current
behaviour remains available by setting "Origin-Agent-Cluster: ?0".
Blink componentBlink>SecurityFeature
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/564
Risks: Interoperability and Compatibility

There are compatibility risks, which we have reduced with outreach and
warnings, and we want to mitigate further by launching at 50% of beta
first. An extended discussion of the risk (including attempts at
quantitative assessment) can be found in the original intent to ship
.

Gecko: Standards position request
. ("Worth
prototyping")

WebKit:
https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html (No
signals.)

Web developers: No signals.

Activation - Deprecation plan
M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on
beta, dev, and canary.

M110: Enable "Origin Agent Cluster by Default" on stable.
 SecurityThis change should be security-positive, since setting
document.domain will not have any impact on the origin of the document any
more.
DebuggabilityA deprecation warning has been added to DevTools console and
to the issues panel in M98. This warning will file a deprecation report as
well using the Reporting API, if so configured.
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes
Is this feature fully tested by web-platform-tests

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

['Thomas Steiner' via blink-dev]

On Thu, Oct 27, 2022 at 1:43 PM Daniel Vogelheim 
wrote:

> Thanks. The link just leads me to an info page about Github code search.
> But regardless:
>

Ah, duh. Looks like GitHub Search is still in developer preview and not
rolled out to everyone. I can't really export the result, but here are some
of the affected repos (emphasis mine, this is Firebase):

‎cypress-io/cypress‎
‎sockjs/sockjs-client‎
‎odoo/odoo‎
‎sparrow-js/sparrow‎
‎react-component/upload‎
‎kindsoft/kindeditor‎
‎barretlee/online-markdown‎
‎RocketChat/Rocket.Chat‎
‎bbc/simorgh‎
‎RubyLouvre/mass-Framework‎
*‎firebase/firebase-js-sdk‎*
‎primus/primus‎
‎AlloyTeam/JX‎
‎jasonday/printThis‎
‎notadd/neditor


> The difficulty with this particular feature is that the "API" has two
> parts: First, setting document.domain (possibly on main page and frame),
> and then later making a cross-origin access that will succeed because of
> this, somewhere else. The setting document.domain part has a specific
> pattern, but the later usage doesn't. What we figured out the hard way is
> that many sites do the first thing, but then don't do the second. Maybe as
> a left-over from no longer used functionality. Or they do the second part,
> but use it only for something optional on the page, so that disabling it
> won't actually affect the user experience. This makes potential breakage
> very hard to measure, since the measurable things - e.g. is document.domain
> being modified? - don't really correspond to user-visible impact.
>

Yeah, makes sense.


> That makes the 3.6k number difficult to interpret: In order to make sense
> of this number, I'd need some indicator of the denominator (that is, 3.6k
> of how many in total?), and some indicator of the "breakage ratio" (that
> is, likelihood of a site failing when setting document.domain no longer
> does anything?).
>

Unfortunately they don't tell the size of their corpus. "All of GitHub",
whatever this may mean.


> On Wed, Oct 26, 2022 at 3:23 PM 'Thomas Steiner' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Here's a RegEx power search where document.domain is being set, finding
>> ~3.6k files on GitHub:
>> https://cs.github.com/?scopeName=All+repos==%2F%5Cbdocument%5C.domain%5Cs*%3D%5B%5E%3D%5D%5Cs*%2F+%28language%3Ajavascript+OR+language%3Atypescript%29
>>
>>
>> On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss 
>> wrote:
>>
>>> Thanks for doing that work, Daniel!
>>>
>>> 0.015% effective breakage is way better than 0.25%, but it's still ~5x
>>> higher than what we're typically comfortable with.
>>> I'm wondering if folks have creative ideas on the outreach front - +Andre
>>> Bandarra  in particular
>>>
>>> Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and
>>> Canary channels, to convince folks this is indeed coming?
>>>
>>> On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim 
>>> wrote:
>>>
 On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss 
 wrote:

> Thanks for the detailed report!!
>
> It's great that we've managed to bring the usage down, but 0.25% is
> still too high for my comfort levels.
> Taking a manual survey of the major users seems like the right
> approach. I wonder if you could, on top of the top sites, also run a 
> random
> survey of the bottom half of usage, to get a sense of breakage there?
>

 The long tail is long. :)  Chromestatus offers a "Sample URLs" table
 for each feature, so I took the top 50 sample URLs for
 CrossOriginAccessBasedOnDocumentDomain
 
 [1] and examined them manually, with & without Origin-Agent-Cluster on by
 default.

 - 47 sites worked without any obvious problems. I usually examined the
 main site and one page linked from the main site.
 - 3 sites did not. Interestingly, one of them was another country
 domain of the site I reported on in the "top 9" cases; and the other two
 were different country domains of the same site. I guess one can now argue
 whether I found 3 or only 2 sites that break. [2]
 - If I assume Chromestatus URL sampling is vaguely proportional to page
 views, then: 0.25% page views use the feature, 3 / 50 with visible issues
 => 0.015% potential of problem page views.


 [1] I'm not sure what their sampling method is; and in particular
 whether it's stable and everyone gets the same list, or whether the random
 sample is random every time. If it's relevant, I can provide the list of
 URLs I used.
 [2] I'm not sure if listing the sites publicly is desired, or even
 permissible. One is a commercial site focused on sports results; the other
 a non-commercial site focused on onscreen keyboards for different 
 languages.


> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
> wrote:
>
>> Hello all,
>>
>> It's been a while and 109 is coming up. As I'm preparing the
>> intent-to-ship 

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

['Daniel Vogelheim' via blink-dev]

Thanks. The link just leads me to an info page about Github code search.
But regardless:

The difficulty with this particular feature is that the "API" has two
parts: First, setting document.domain (possibly on main page and frame),
and then later making a cross-origin access that will succeed because of
this, somewhere else. The setting document.domain part has a specific
pattern, but the later usage doesn't. What we figured out the hard way is
that many sites do the first thing, but then don't do the second. Maybe as
a left-over from no longer used functionality. Or they do the second part,
but use it only for something optional on the page, so that disabling it
won't actually affect the user experience. This makes potential breakage
very hard to measure, since the measurable things - e.g. is document.domain
being modified? - don't really correspond to user-visible impact.

That makes the 3.6k number difficult to interpret: In order to make sense
of this number, I'd need some indicator of the denominator (that is, 3.6k
of how many in total?), and some indicator of the "breakage ratio" (that
is, likelihood of a site failing when setting document.domain no longer
does anything?).

On Wed, Oct 26, 2022 at 3:23 PM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> Here's a RegEx power search where document.domain is being set, finding
> ~3.6k files on GitHub:
> https://cs.github.com/?scopeName=All+repos==%2F%5Cbdocument%5C.domain%5Cs*%3D%5B%5E%3D%5D%5Cs*%2F+%28language%3Ajavascript+OR+language%3Atypescript%29
>
>
> On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss  wrote:
>
>> Thanks for doing that work, Daniel!
>>
>> 0.015% effective breakage is way better than 0.25%, but it's still ~5x
>> higher than what we're typically comfortable with.
>> I'm wondering if folks have creative ideas on the outreach front - +Andre
>> Bandarra  in particular
>>
>> Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and
>> Canary channels, to convince folks this is indeed coming?
>>
>> On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss 
>>> wrote:
>>>
 Thanks for the detailed report!!

 It's great that we've managed to bring the usage down, but 0.25% is
 still too high for my comfort levels.
 Taking a manual survey of the major users seems like the right
 approach. I wonder if you could, on top of the top sites, also run a random
 survey of the bottom half of usage, to get a sense of breakage there?

>>>
>>> The long tail is long. :)  Chromestatus offers a "Sample URLs" table for
>>> each feature, so I took the top 50 sample URLs for
>>> CrossOriginAccessBasedOnDocumentDomain
>>>  [1]
>>> and examined them manually, with & without Origin-Agent-Cluster on by
>>> default.
>>>
>>> - 47 sites worked without any obvious problems. I usually examined the
>>> main site and one page linked from the main site.
>>> - 3 sites did not. Interestingly, one of them was another country domain
>>> of the site I reported on in the "top 9" cases; and the other two were
>>> different country domains of the same site. I guess one can now argue
>>> whether I found 3 or only 2 sites that break. [2]
>>> - If I assume Chromestatus URL sampling is vaguely proportional to page
>>> views, then: 0.25% page views use the feature, 3 / 50 with visible issues
>>> => 0.015% potential of problem page views.
>>>
>>>
>>> [1] I'm not sure what their sampling method is; and in particular
>>> whether it's stable and everyone gets the same list, or whether the random
>>> sample is random every time. If it's relevant, I can provide the list of
>>> URLs I used.
>>> [2] I'm not sure if listing the sites publicly is desired, or even
>>> permissible. One is a commercial site focused on sports results; the other
>>> a non-commercial site focused on onscreen keyboards for different languages.
>>>
>>>
 On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
 wrote:

> Hello all,
>
> It's been a while and 109 is coming up. As I'm preparing the
> intent-to-ship for 109, I'd like to post an update on how the deprecation
> is going:
>
> Current usage: Since announcing the deprecation, usage of
> document.domain-enabled accesses have dropped by about 50%.
>
> - Feature stats: DocumentDomainEnabledCrossOriginAccess
> 
>
> - Note that this *includes* usage when an Origin-Agent-Cluster header
> is explicitly set, which is sustainable use that is not affected by the
> deprecation.
>
> - CrossOriginAccessBasedOnDocumentDomain
> 
> is usage of document.domain enabled access, but only when based on the
> Origin-Agent-Cluster's default (which is what this intent wants to 
> change.)
> 

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

['Daniel Vogelheim' via blink-dev]

On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss  wrote:

> Thanks for doing that work, Daniel!
>
> 0.015% effective breakage is way better than 0.25%, but it's still ~5x
> higher than what we're typically comfortable with.
> I'm wondering if folks have creative ideas on the outreach front - +Andre
> Bandarra  in particular
>
> Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and
> Canary channels, to convince folks this is indeed coming?
>

I think that makes sense. I'll send a separate intent - as requested
earlier - so that it has due visibility.

On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim 
> wrote:
>
>> On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks for the detailed report!!
>>>
>>> It's great that we've managed to bring the usage down, but 0.25% is
>>> still too high for my comfort levels.
>>> Taking a manual survey of the major users seems like the right approach.
>>> I wonder if you could, on top of the top sites, also run a random survey of
>>> the bottom half of usage, to get a sense of breakage there?
>>>
>>
>> The long tail is long. :)  Chromestatus offers a "Sample URLs" table for
>> each feature, so I took the top 50 sample URLs for
>> CrossOriginAccessBasedOnDocumentDomain
>>  [1]
>> and examined them manually, with & without Origin-Agent-Cluster on by
>> default.
>>
>> - 47 sites worked without any obvious problems. I usually examined the
>> main site and one page linked from the main site.
>> - 3 sites did not. Interestingly, one of them was another country domain
>> of the site I reported on in the "top 9" cases; and the other two were
>> different country domains of the same site. I guess one can now argue
>> whether I found 3 or only 2 sites that break. [2]
>> - If I assume Chromestatus URL sampling is vaguely proportional to page
>> views, then: 0.25% page views use the feature, 3 / 50 with visible issues
>> => 0.015% potential of problem page views.
>>
>>
>> [1] I'm not sure what their sampling method is; and in particular whether
>> it's stable and everyone gets the same list, or whether the random sample
>> is random every time. If it's relevant, I can provide the list of URLs I
>> used.
>> [2] I'm not sure if listing the sites publicly is desired, or even
>> permissible. One is a commercial site focused on sports results; the other
>> a non-commercial site focused on onscreen keyboards for different languages.
>>
>>
>>> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
>>> wrote:
>>>
 Hello all,

 It's been a while and 109 is coming up. As I'm preparing the
 intent-to-ship for 109, I'd like to post an update on how the deprecation
 is going:

 Current usage: Since announcing the deprecation, usage of
 document.domain-enabled accesses have dropped by about 50%.

 - Feature stats: DocumentDomainEnabledCrossOriginAccess
 

 - Note that this *includes* usage when an Origin-Agent-Cluster header
 is explicitly set, which is sustainable use that is not affected by the
 deprecation.

 - CrossOriginAccessBasedOnDocumentDomain
  is
 usage of document.domain enabled access, but only when based on the
 Origin-Agent-Cluster's default (which is what this intent wants to change.)
 This graph has the correct numbers for this intent; but makes long-term
 trends harder to see because we only introduced the use counter *during*
 the deprecation period.

 - So basically, usage has dropped form ~0.5% of page views (
 DocumentDomainEnabledCrossOriginAccess
  @
 Nov '21) to about ~0.25% of page views (
 CrossOriginAccessBasedOnDocumentDomain
  @
 Sept '22)

 When gathering the data for this post, I double-checked on a
 particular, well-known media site that we had contacted about the
 deprecation during the past months. I was surprised to notice that despite
 our outreach and communication, they *still* use document.domain and
 document.domain facilitated cross-origin access. But when taking a closer
 look, an interesting find emerged: They are using document.domain setting
 to enable auto-play of their media player, which is hosted on a separate
 domain. Our advice was to use the 'autoplay' permission policy with
 permission delegation instead. They are indeed doing so, but *in addition*
 to document.domain setting. In other words, they opted for a conservative
 implementation strategy where they auto-play their frame with two different
 methods. When I load their page with document.domain setting disabled, it
 works fine. That's a fine implementation strategy, 

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

['Thomas Steiner' via blink-dev]

Here's a RegEx power search where document.domain is being set, finding
~3.6k files on GitHub:
https://cs.github.com/?scopeName=All+repos==%2F%5Cbdocument%5C.domain%5Cs*%3D%5B%5E%3D%5D%5Cs*%2F+%28language%3Ajavascript+OR+language%3Atypescript%29


On Wed, Oct 26, 2022 at 3:09 PM Yoav Weiss  wrote:

> Thanks for doing that work, Daniel!
>
> 0.015% effective breakage is way better than 0.25%, but it's still ~5x
> higher than what we're typically comfortable with.
> I'm wondering if folks have creative ideas on the outreach front - +Andre
> Bandarra  in particular
>
> Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and
> Canary channels, to convince folks this is indeed coming?
>
> On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim 
> wrote:
>
>> On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss 
>> wrote:
>>
>>> Thanks for the detailed report!!
>>>
>>> It's great that we've managed to bring the usage down, but 0.25% is
>>> still too high for my comfort levels.
>>> Taking a manual survey of the major users seems like the right approach.
>>> I wonder if you could, on top of the top sites, also run a random survey of
>>> the bottom half of usage, to get a sense of breakage there?
>>>
>>
>> The long tail is long. :)  Chromestatus offers a "Sample URLs" table for
>> each feature, so I took the top 50 sample URLs for
>> CrossOriginAccessBasedOnDocumentDomain
>>  [1]
>> and examined them manually, with & without Origin-Agent-Cluster on by
>> default.
>>
>> - 47 sites worked without any obvious problems. I usually examined the
>> main site and one page linked from the main site.
>> - 3 sites did not. Interestingly, one of them was another country domain
>> of the site I reported on in the "top 9" cases; and the other two were
>> different country domains of the same site. I guess one can now argue
>> whether I found 3 or only 2 sites that break. [2]
>> - If I assume Chromestatus URL sampling is vaguely proportional to page
>> views, then: 0.25% page views use the feature, 3 / 50 with visible issues
>> => 0.015% potential of problem page views.
>>
>>
>> [1] I'm not sure what their sampling method is; and in particular whether
>> it's stable and everyone gets the same list, or whether the random sample
>> is random every time. If it's relevant, I can provide the list of URLs I
>> used.
>> [2] I'm not sure if listing the sites publicly is desired, or even
>> permissible. One is a commercial site focused on sports results; the other
>> a non-commercial site focused on onscreen keyboards for different languages.
>>
>>
>>> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
>>> wrote:
>>>
 Hello all,

 It's been a while and 109 is coming up. As I'm preparing the
 intent-to-ship for 109, I'd like to post an update on how the deprecation
 is going:

 Current usage: Since announcing the deprecation, usage of
 document.domain-enabled accesses have dropped by about 50%.

 - Feature stats: DocumentDomainEnabledCrossOriginAccess
 

 - Note that this *includes* usage when an Origin-Agent-Cluster header
 is explicitly set, which is sustainable use that is not affected by the
 deprecation.

 - CrossOriginAccessBasedOnDocumentDomain
  is
 usage of document.domain enabled access, but only when based on the
 Origin-Agent-Cluster's default (which is what this intent wants to change.)
 This graph has the correct numbers for this intent; but makes long-term
 trends harder to see because we only introduced the use counter *during*
 the deprecation period.

 - So basically, usage has dropped form ~0.5% of page views (
 DocumentDomainEnabledCrossOriginAccess
  @
 Nov '21) to about ~0.25% of page views (
 CrossOriginAccessBasedOnDocumentDomain
  @
 Sept '22)

 When gathering the data for this post, I double-checked on a
 particular, well-known media site that we had contacted about the
 deprecation during the past months. I was surprised to notice that despite
 our outreach and communication, they *still* use document.domain and
 document.domain facilitated cross-origin access. But when taking a closer
 look, an interesting find emerged: They are using document.domain setting
 to enable auto-play of their media player, which is hosted on a separate
 domain. Our advice was to use the 'autoplay' permission policy with
 permission delegation instead. They are indeed doing so, but *in addition*
 to document.domain setting. In other words, they opted for a conservative
 implementation strategy where they auto-play their frame with two 

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

[Yoav Weiss]

Thanks for doing that work, Daniel!

0.015% effective breakage is way better than 0.25%, but it's still ~5x
higher than what we're typically comfortable with.
I'm wondering if folks have creative ideas on the outreach front - +Andre
Bandarra  in particular

Otherwise, maybe it makes sense to finch this at 50% on Beta, Dev and
Canary channels, to convince folks this is indeed coming?

On Fri, Oct 21, 2022 at 1:40 PM Daniel Vogelheim 
wrote:

> On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss  wrote:
>
>> Thanks for the detailed report!!
>>
>> It's great that we've managed to bring the usage down, but 0.25% is still
>> too high for my comfort levels.
>> Taking a manual survey of the major users seems like the right approach.
>> I wonder if you could, on top of the top sites, also run a random survey of
>> the bottom half of usage, to get a sense of breakage there?
>>
>
> The long tail is long. :)  Chromestatus offers a "Sample URLs" table for
> each feature, so I took the top 50 sample URLs for
> CrossOriginAccessBasedOnDocumentDomain
>  [1]
> and examined them manually, with & without Origin-Agent-Cluster on by
> default.
>
> - 47 sites worked without any obvious problems. I usually examined the
> main site and one page linked from the main site.
> - 3 sites did not. Interestingly, one of them was another country domain
> of the site I reported on in the "top 9" cases; and the other two were
> different country domains of the same site. I guess one can now argue
> whether I found 3 or only 2 sites that break. [2]
> - If I assume Chromestatus URL sampling is vaguely proportional to page
> views, then: 0.25% page views use the feature, 3 / 50 with visible issues
> => 0.015% potential of problem page views.
>
>
> [1] I'm not sure what their sampling method is; and in particular whether
> it's stable and everyone gets the same list, or whether the random sample
> is random every time. If it's relevant, I can provide the list of URLs I
> used.
> [2] I'm not sure if listing the sites publicly is desired, or even
> permissible. One is a commercial site focused on sports results; the other
> a non-commercial site focused on onscreen keyboards for different languages.
>
>
>> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
>> wrote:
>>
>>> Hello all,
>>>
>>> It's been a while and 109 is coming up. As I'm preparing the
>>> intent-to-ship for 109, I'd like to post an update on how the deprecation
>>> is going:
>>>
>>> Current usage: Since announcing the deprecation, usage of
>>> document.domain-enabled accesses have dropped by about 50%.
>>>
>>> - Feature stats: DocumentDomainEnabledCrossOriginAccess
>>> 
>>>
>>> - Note that this *includes* usage when an Origin-Agent-Cluster header is
>>> explicitly set, which is sustainable use that is not affected by the
>>> deprecation.
>>>
>>> - CrossOriginAccessBasedOnDocumentDomain
>>>  is
>>> usage of document.domain enabled access, but only when based on the
>>> Origin-Agent-Cluster's default (which is what this intent wants to change.)
>>> This graph has the correct numbers for this intent; but makes long-term
>>> trends harder to see because we only introduced the use counter *during*
>>> the deprecation period.
>>>
>>> - So basically, usage has dropped form ~0.5% of page views (
>>> DocumentDomainEnabledCrossOriginAccess
>>>  @
>>> Nov '21) to about ~0.25% of page views (
>>> CrossOriginAccessBasedOnDocumentDomain
>>>  @
>>> Sept '22)
>>>
>>> When gathering the data for this post, I double-checked on a particular,
>>> well-known media site that we had contacted about the deprecation during
>>> the past months. I was surprised to notice that despite our outreach and
>>> communication, they *still* use document.domain and document.domain
>>> facilitated cross-origin access. But when taking a closer look, an
>>> interesting find emerged: They are using document.domain setting to enable
>>> auto-play of their media player, which is hosted on a separate domain. Our
>>> advice was to use the 'autoplay' permission policy with permission
>>> delegation instead. They are indeed doing so, but *in addition* to
>>> document.domain setting. In other words, they opted for a conservative
>>> implementation strategy where they auto-play their frame with two different
>>> methods. When I load their page with document.domain setting disabled, it
>>> works fine. That's a fine implementation strategy, but unfortunately it
>>> mucks up our statistics since our use counters cannot know whether other
>>> code exists to compensate for a failed document.domain facilitated access.
>>>
>>> When discussing this finding with another engineer, he suggested that
>>> we're really 

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

['Daniel Vogelheim' via blink-dev]

On Wed, Oct 19, 2022 at 5:23 AM Yoav Weiss  wrote:

> Thanks for the detailed report!!
>
> It's great that we've managed to bring the usage down, but 0.25% is still
> too high for my comfort levels.
> Taking a manual survey of the major users seems like the right approach. I
> wonder if you could, on top of the top sites, also run a random survey of
> the bottom half of usage, to get a sense of breakage there?
>

The long tail is long. :)  Chromestatus offers a "Sample URLs" table for
each feature, so I took the top 50 sample URLs for
CrossOriginAccessBasedOnDocumentDomain
 [1] and
examined them manually, with & without Origin-Agent-Cluster on by default.

- 47 sites worked without any obvious problems. I usually examined the main
site and one page linked from the main site.
- 3 sites did not. Interestingly, one of them was another country domain of
the site I reported on in the "top 9" cases; and the other two were
different country domains of the same site. I guess one can now argue
whether I found 3 or only 2 sites that break. [2]
- If I assume Chromestatus URL sampling is vaguely proportional to page
views, then: 0.25% page views use the feature, 3 / 50 with visible issues
=> 0.015% potential of problem page views.


[1] I'm not sure what their sampling method is; and in particular whether
it's stable and everyone gets the same list, or whether the random sample
is random every time. If it's relevant, I can provide the list of URLs I
used.
[2] I'm not sure if listing the sites publicly is desired, or even
permissible. One is a commercial site focused on sports results; the other
a non-commercial site focused on onscreen keyboards for different languages.


> On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
> wrote:
>
>> Hello all,
>>
>> It's been a while and 109 is coming up. As I'm preparing the
>> intent-to-ship for 109, I'd like to post an update on how the deprecation
>> is going:
>>
>> Current usage: Since announcing the deprecation, usage of
>> document.domain-enabled accesses have dropped by about 50%.
>>
>> - Feature stats: DocumentDomainEnabledCrossOriginAccess
>> 
>>
>> - Note that this *includes* usage when an Origin-Agent-Cluster header is
>> explicitly set, which is sustainable use that is not affected by the
>> deprecation.
>>
>> - CrossOriginAccessBasedOnDocumentDomain
>>  is
>> usage of document.domain enabled access, but only when based on the
>> Origin-Agent-Cluster's default (which is what this intent wants to change.)
>> This graph has the correct numbers for this intent; but makes long-term
>> trends harder to see because we only introduced the use counter *during*
>> the deprecation period.
>>
>> - So basically, usage has dropped form ~0.5% of page views (
>> DocumentDomainEnabledCrossOriginAccess
>>  @
>> Nov '21) to about ~0.25% of page views (
>> CrossOriginAccessBasedOnDocumentDomain
>>  @
>> Sept '22)
>>
>> When gathering the data for this post, I double-checked on a particular,
>> well-known media site that we had contacted about the deprecation during
>> the past months. I was surprised to notice that despite our outreach and
>> communication, they *still* use document.domain and document.domain
>> facilitated cross-origin access. But when taking a closer look, an
>> interesting find emerged: They are using document.domain setting to enable
>> auto-play of their media player, which is hosted on a separate domain. Our
>> advice was to use the 'autoplay' permission policy with permission
>> delegation instead. They are indeed doing so, but *in addition* to
>> document.domain setting. In other words, they opted for a conservative
>> implementation strategy where they auto-play their frame with two different
>> methods. When I load their page with document.domain setting disabled, it
>> works fine. That's a fine implementation strategy, but unfortunately it
>> mucks up our statistics since our use counters cannot know whether other
>> code exists to compensate for a failed document.domain facilitated access.
>>
>> When discussing this finding with another engineer, he suggested that
>> we're really interested in user-visible web breakage. Since I don't know
>> how to measure that directly, I manually looked at all top users of
>> document.domain and loaded each page with/without document.domain setting
>> to see if I could spot any difference. Document.domain usage - like the web
>> in general - is quite "top heavy": 9 sites account for about 50% of all
>> remaining dd usage.
>>
>> - 7 sites work without any discernible difference. (Caveat: Many use
>> languages I do not understand, which makes it difficult to spot subtle
>> differences in 

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

[Yoav Weiss]

Thanks for the detailed report!!

It's great that we've managed to bring the usage down, but 0.25% is still
too high for my comfort levels.
Taking a manual survey of the major users seems like the right approach. I
wonder if you could, on top of the top sites, also run a random survey of
the bottom half of usage, to get a sense of breakage there?


On Mon, Oct 17, 2022 at 4:39 PM Daniel Vogelheim 
wrote:

> Hello all,
>
> It's been a while and 109 is coming up. As I'm preparing the
> intent-to-ship for 109, I'd like to post an update on how the deprecation
> is going:
>
> Current usage: Since announcing the deprecation, usage of
> document.domain-enabled accesses have dropped by about 50%.
>
> - Feature stats: DocumentDomainEnabledCrossOriginAccess
> 
>
> - Note that this *includes* usage when an Origin-Agent-Cluster header is
> explicitly set, which is sustainable use that is not affected by the
> deprecation.
>
> - CrossOriginAccessBasedOnDocumentDomain
>  is
> usage of document.domain enabled access, but only when based on the
> Origin-Agent-Cluster's default (which is what this intent wants to change.)
> This graph has the correct numbers for this intent; but makes long-term
> trends harder to see because we only introduced the use counter *during*
> the deprecation period.
>
> - So basically, usage has dropped form ~0.5% of page views (
> DocumentDomainEnabledCrossOriginAccess
>  @ Nov
> '21) to about ~0.25% of page views (CrossOriginAccessBasedOnDocumentDomain
>  @
> Sept '22)
>
> When gathering the data for this post, I double-checked on a particular,
> well-known media site that we had contacted about the deprecation during
> the past months. I was surprised to notice that despite our outreach and
> communication, they *still* use document.domain and document.domain
> facilitated cross-origin access. But when taking a closer look, an
> interesting find emerged: They are using document.domain setting to enable
> auto-play of their media player, which is hosted on a separate domain. Our
> advice was to use the 'autoplay' permission policy with permission
> delegation instead. They are indeed doing so, but *in addition* to
> document.domain setting. In other words, they opted for a conservative
> implementation strategy where they auto-play their frame with two different
> methods. When I load their page with document.domain setting disabled, it
> works fine. That's a fine implementation strategy, but unfortunately it
> mucks up our statistics since our use counters cannot know whether other
> code exists to compensate for a failed document.domain facilitated access.
>
> When discussing this finding with another engineer, he suggested that
> we're really interested in user-visible web breakage. Since I don't know
> how to measure that directly, I manually looked at all top users of
> document.domain and loaded each page with/without document.domain setting
> to see if I could spot any difference. Document.domain usage - like the web
> in general - is quite "top heavy": 9 sites account for about 50% of all
> remaining dd usage.
>
> - 7 sites work without any discernible difference. (Caveat: Many use
> languages I do not understand, which makes it difficult to spot subtle
> differences in content. But to me, the sites looked and used the same,
> regardless of document.domain setting. Caveat 2: One site requires a login,
> so I could only really test the login page rather than their core
> functionality.)
>
> - 1 site worked just the same, except for a pair of very extra fancy ad
> frames that "framed" the main content left and right. The main content,
> including in-page ads, seemed just fine, but the fancy ad frames were
> missing.
>
> - 1 site was clearly missing content.
>
> For both of the last two, the console showed uncaught DOM exceptions for a
> failed cross-domain access. What I suspect happens in the first case is
> that during construction of the fancy ad frames an exception is thrown and
> hence the frames aren't inserted in the page. In the second case something
> similar happens, but when building up the main content. Or maybe before
> building up the main content. Thus, that part of the main content is
> missing.
>
> (We don't like broken web pages, so we reached out separately to the
> owners of that last page on Friday. Their support has promised to put us in
> contact with one of their developers which, as of this writing, hasn't
> happened yet.)
>
>
> On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss  wrote:
>
>> LGTM1 to deprecate under the following conditions:
>>
>>- As discussed, a 6 months deprecation period, as well as broad-scope
>>and targeted outreach, that would hopefully bring usage down.
>>- A 

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

['Daniel Vogelheim' via blink-dev]

Hello all,

It's been a while and 109 is coming up. As I'm preparing the intent-to-ship
for 109, I'd like to post an update on how the deprecation is going:

Current usage: Since announcing the deprecation, usage of
document.domain-enabled accesses have dropped by about 50%.

- Feature stats: DocumentDomainEnabledCrossOriginAccess


- Note that this *includes* usage when an Origin-Agent-Cluster header is
explicitly set, which is sustainable use that is not affected by the
deprecation.

- CrossOriginAccessBasedOnDocumentDomain
 is
usage of document.domain enabled access, but only when based on the
Origin-Agent-Cluster's default (which is what this intent wants to change.)
This graph has the correct numbers for this intent; but makes long-term
trends harder to see because we only introduced the use counter *during*
the deprecation period.

- So basically, usage has dropped form ~0.5% of page views (
DocumentDomainEnabledCrossOriginAccess
 @ Nov
'21) to about ~0.25% of page views (CrossOriginAccessBasedOnDocumentDomain
 @ Sept
'22)

When gathering the data for this post, I double-checked on a particular,
well-known media site that we had contacted about the deprecation during
the past months. I was surprised to notice that despite our outreach and
communication, they *still* use document.domain and document.domain
facilitated cross-origin access. But when taking a closer look, an
interesting find emerged: They are using document.domain setting to enable
auto-play of their media player, which is hosted on a separate domain. Our
advice was to use the 'autoplay' permission policy with permission
delegation instead. They are indeed doing so, but *in addition* to
document.domain setting. In other words, they opted for a conservative
implementation strategy where they auto-play their frame with two different
methods. When I load their page with document.domain setting disabled, it
works fine. That's a fine implementation strategy, but unfortunately it
mucks up our statistics since our use counters cannot know whether other
code exists to compensate for a failed document.domain facilitated access.

When discussing this finding with another engineer, he suggested that we're
really interested in user-visible web breakage. Since I don't know how to
measure that directly, I manually looked at all top users of
document.domain and loaded each page with/without document.domain setting
to see if I could spot any difference. Document.domain usage - like the web
in general - is quite "top heavy": 9 sites account for about 50% of all
remaining dd usage.

- 7 sites work without any discernible difference. (Caveat: Many use
languages I do not understand, which makes it difficult to spot subtle
differences in content. But to me, the sites looked and used the same,
regardless of document.domain setting. Caveat 2: One site requires a login,
so I could only really test the login page rather than their core
functionality.)

- 1 site worked just the same, except for a pair of very extra fancy ad
frames that "framed" the main content left and right. The main content,
including in-page ads, seemed just fine, but the fancy ad frames were
missing.

- 1 site was clearly missing content.

For both of the last two, the console showed uncaught DOM exceptions for a
failed cross-domain access. What I suspect happens in the first case is
that during construction of the fancy ad frames an exception is thrown and
hence the frames aren't inserted in the page. In the second case something
similar happens, but when building up the main content. Or maybe before
building up the main content. Thus, that part of the main content is
missing.

(We don't like broken web pages, so we reached out separately to the owners
of that last page on Friday. Their support has promised to put us in
contact with one of their developers which, as of this writing, hasn't
happened yet.)


On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss  wrote:

> LGTM1 to deprecate under the following conditions:
>
>- As discussed, a 6 months deprecation period, as well as broad-scope
>and targeted outreach, that would hopefully bring usage down.
>- A well-crafted deprecation message that indicates the timeline, and
>at the same time indicates that we'll be responsive to community feedback
>(or a link to a blog post/documentation page that indicates the same)
>- Sending a separate intent for the actual removal at the end of the
>deprecation period, once the picture is a bit clearer.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.

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

['Daniel Vogelheim' via blink-dev]

On Thu, Mar 10, 2022 at 12:49 AM PhistucK  wrote:

> Just chiming in to say that Cypress apparently relies on setting
> document.domain for its "test across the same-site" feature.
> https://docs.cypress.io/guides/references/trade-offs#Same-origin
>

Thank you. This is a different use-case from what I've seen so far, which
makes it interesting.

Might need either some outreach, or an alternative for them via the Chrome
> debugging protocol.
>

Since they speak of "injecting document.domain" my first guess is that they
might be interested in also injecting the "Origin-Agent-Cluster: ?0" http
header. Either way, I'll try to contact them.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNJp92%2BO%3D5mLmLJPWZjKQL2%3Dg%3DDT1Bq%3DJ64HD5riE%3D2AA%40mail.gmail.com.

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

[PhistucK]

Just chiming in to say that Cypress apparently relies on setting
document.domain for its "test across the same-site" feature.
https://docs.cypress.io/guides/references/trade-offs#Same-origin
Might need either some outreach, or an alternative for them via the Chrome
debugging protocol.

☆*PhistucK*


On Tue, Mar 8, 2022 at 12:12 AM Charlie Reis  wrote:

> I believe you're looking for
> https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled,
> which appears to be supported as of version 100.
>
> Charlie
>
> On Mon, Mar 7, 2022 at 9:07 AM T K  wrote:
>
>> Hi ,
>> When will the Enterprise Policy be released, and how it will look like?
>> For on premise customers patching the system, it is a long process that
>> might take more than M106 (around September)
>> Thanks,
>> Tuvia.
>>
>>
>> On Monday, February 14, 2022 at 7:28:18 PM UTC+2 Daniel Vogelheim wrote:
>>
>>> Hi all, just a brief update:
>>>
>>> - The warning should go live on M100
>>> .
>>> - Flipping the default is planned for M106 but there'll be a
>>> separate intent (and thus additional discussion), as requested.
>>> - A deprecation warning for cross-domain access (based on previous
>>> document.domain setting) is in the works, and will either make it to M100
>>> also, or will land shortly after.
>>> - Additional info: Blog post
>>> ; plus
>>> some technical notes
>>> 
>>> .
>>>
>>> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell 
>>> wrote:
>>>
 LGTM3

 /Daniel
 On 2022-01-14 13:58, Daniel Vogelheim wrote:

 Hi all,
 Hi Yoav,

 Thanks for the feedback. I'd like to modify the intent timeline as
 follows:

 M99: Start showing a deprecation warning.
 M99-105: Watch use counters + outreach to top-N users.
 M105: Deprecate the feature by default.

 Enabling/disabling will be via Finch, so we have an emergency shut-off.

 An enterprise policy is already in place.

 On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss 
 wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon
> https://developer.chrome.com/blog/immutable-document-domain/
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris,
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at
> our stats, and that's even before talking about enterprises, where a lot 
> of
> the API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that
> risk:
>
>- UKM and outreach to specific large users of the API can maybe
>help drive the usage down.
>
>
 Will do. With Lutz' help I just checked the UKM we have on this, and it
 seems the usage is quite heavily concentrated on large sites. The
 top-quartile of remaining public usage is just 9 sites; top-half is ~35.
 We'll try to reach out to them.


>
>- A deprecation period of 3 milestones feels a bit short here. Is
>the expectation that turning on the opt-out header can be done under 
> that
>period?
>
> As above, we'll happily go up on this.

 My reasoning why 3 milestones would be reasonable was that there is a
 "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
 sure, or just wants to postpone the issue, one can just add
 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
 from e.g. CSP, where adding new CSP headers might require a lot of work and
 testing.


>
>- A report-only mode could have allowed sites to try and enable
>this, without risking actual breakage for their documents/properties 
> that
>use document.domain. This is doubly true for platforms that want to 
> warn
>their customers about this upcoming deprecation, but without taking 
> risks
>on their behalf. At the same time, it is true that they could collect
>deprecation reports (thanks for adding those!) instead during the
>deprecation period, which can be considered an on-by-default 
> report-only
>mode. Can y'all add specific guidance on deprecation reports to the
>documentation?
>
>
 We see the deprecation warning - without any behavioural changes - as
 effectively being the report-only mode. We'll be more clear in the
 documentation.


>
>-  It'd be helpful to reach out to enterprise folks and see what
>their responses may be for this. +Greg Whitworth.
>- This probably 

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

[Charlie Reis]

I believe you're looking for
https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled,
which appears to be supported as of version 100.

Charlie

On Mon, Mar 7, 2022 at 9:07 AM T K  wrote:

> Hi ,
> When will the Enterprise Policy be released, and how it will look like?
> For on premise customers patching the system, it is a long process that
> might take more than M106 (around September)
> Thanks,
> Tuvia.
>
>
> On Monday, February 14, 2022 at 7:28:18 PM UTC+2 Daniel Vogelheim wrote:
>
>> Hi all, just a brief update:
>>
>> - The warning should go live on M100
>> .
>> - Flipping the default is planned for M106 but there'll be a
>> separate intent (and thus additional discussion), as requested.
>> - A deprecation warning for cross-domain access (based on previous
>> document.domain setting) is in the works, and will either make it to M100
>> also, or will land shortly after.
>> - Additional info: Blog post
>> ; plus
>> some technical notes
>> 
>> .
>>
>> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>>
>>> Hi all,
>>> Hi Yoav,
>>>
>>> Thanks for the feedback. I'd like to modify the intent timeline as
>>> follows:
>>>
>>> M99: Start showing a deprecation warning.
>>> M99-105: Watch use counters + outreach to top-N users.
>>> M105: Deprecate the feature by default.
>>>
>>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>>
>>> An enterprise policy is already in place.
>>>
>>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.


>>> Will do. With Lutz' help I just checked the UKM we have on this, and it
>>> seems the usage is quite heavily concentrated on large sites. The
>>> top-quartile of remaining public usage is just 9 sites; top-half is ~35.
>>> We'll try to reach out to them.
>>>
>>>

- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?

 As above, we'll happily go up on this.
>>>
>>> My reasoning why 3 milestones would be reasonable was that there is a
>>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
>>> sure, or just wants to postpone the issue, one can just add
>>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
>>> from e.g. CSP, where adding new CSP headers might require a lot of work and
>>> testing.
>>>
>>>

- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?


>>> We see the deprecation warning - without any behavioural changes - as
>>> effectively being the report-only mode. We'll be more clear in the
>>> documentation.
>>>
>>>

-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.

 I agree, and an enterprise policy is already in place.
>>>
>>>

- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?


>>> There is no plan. The current logic is relatively easy to maintain, so
>>> we have not made any plan to remove the opt-out.
>>>
>>> --
> You received this message because you 

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

[T K]

Hi , 
When will the Enterprise Policy be released, and how it will look like?
For on premise customers patching the system, it is a long process that 
might take more than M106 (around September)  
Thanks, 
Tuvia.


On Monday, February 14, 2022 at 7:28:18 PM UTC+2 Daniel Vogelheim wrote:

> Hi all, just a brief update:
>
> - The warning should go live on M100 
> .
> - Flipping the default is planned for M106 but there'll be a 
> separate intent (and thus additional discussion), as requested.
> - A deprecation warning for cross-domain access (based on previous 
> document.domain setting) is in the works, and will either make it to M100 
> also, or will land shortly after.
> - Additional info: Blog post 
> ; plus some 
> technical 
> notes 
> 
> .
>
> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>
>> Hi all,
>> Hi Yoav,
>>
>> Thanks for the feedback. I'd like to modify the intent timeline as 
>> follows:
>>
>> M99: Start showing a deprecation warning.
>> M99-105: Watch use counters + outreach to top-N users.
>> M105: Deprecate the feature by default.
>>
>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>
>> An enterprise policy is already in place.
>>
>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>
>>> Hey Daniel! 
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe help 
>>>drive the usage down. 
>>>
>>>
>> Will do. With Lutz' help I just checked the UKM we have on this, and it 
>> seems the usage is quite heavily concentrated on large sites. The 
>> top-quartile of remaining public usage is just 9 sites; top-half is ~35. 
>> We'll try to reach out to them.
>>  
>>
>>>
>>>- A deprecation period of 3 milestones feels a bit short here. Is 
>>>the expectation that turning on the opt-out header can be done under 
>>> that 
>>>period? 
>>>
>>> As above, we'll happily go up on this.
>>
>> My reasoning why 3 milestones would be reasonable was that there is a 
>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't 
>> sure, or just wants to postpone the issue, one can just add 
>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different 
>> from e.g. CSP, where adding new CSP headers might require a lot of work and 
>> testing.
>>  
>>
>>>
>>>- A report-only mode could have allowed sites to try and enable 
>>>this, without risking actual breakage for their documents/properties 
>>> that 
>>>use document.domain. This is doubly true for platforms that want to warn 
>>>their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>on their behalf. At the same time, it is true that they could collect 
>>>deprecation reports (thanks for adding those!) instead during the 
>>>deprecation period, which can be considered an on-by-default report-only 
>>>mode. Can y'all add specific guidance on deprecation reports to the 
>>>documentation? 
>>>
>>>
>> We see the deprecation warning - without any behavioural changes - as 
>> effectively being the report-only mode. We'll be more clear in the 
>> documentation.
>>  
>>
>>>
>>>-  It'd be helpful to reach out to enterprise folks and see what 
>>>their responses may be for this. +Greg Whitworth.
>>>- This probably requires an Enterprise Policy, to reduce the risk 
>>>for managed installs. +bheenan@ for opinions on that front. 
>>>
>>> I agree, and an enterprise policy is already in place.
>>  
>>
>>>
>>>- Is there a plan to eventually remove the opt-out option? Or is it 
>>>the plan to have it in place permanently?
>>>
>>>
>> There is no plan. The current logic is relatively easy to maintain, so we 
>> have not made any plan to remove the opt-out.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 

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

['Daniel Vogelheim' via blink-dev]

Hi Noah,

Support for the cross-origin access warning landed this week, but
unfortunately only after the M100 branch cut. So this will first appear in
M101.
If you're willing to build Chromium from tip-of-tree, you should be able to
try it out now.

Daniel

On Fri, Feb 25, 2022 at 5:31 PM Noah Lemen  wrote:

> Any updates on the deprecation warning for cross-domain access? We're now
> looking into setting up the Reporting API to capture this once
> available. Which milestone do you estimate it will ship?
>
> On Monday, February 14, 2022 at 12:28:18 PM UTC-5 Daniel Vogelheim wrote:
>
>> Hi all, just a brief update:
>>
>> - The warning should go live on M100
>> .
>> - Flipping the default is planned for M106 but there'll be a
>> separate intent (and thus additional discussion), as requested.
>> - A deprecation warning for cross-domain access (based on previous
>> document.domain setting) is in the works, and will either make it to M100
>> also, or will land shortly after.
>> - Additional info: Blog post
>> ; plus
>> some technical notes
>> 
>> .
>>
>> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>>
>>> Hi all,
>>> Hi Yoav,
>>>
>>> Thanks for the feedback. I'd like to modify the intent timeline as
>>> follows:
>>>
>>> M99: Start showing a deprecation warning.
>>> M99-105: Watch use counters + outreach to top-N users.
>>> M105: Deprecate the feature by default.
>>>
>>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>>
>>> An enterprise policy is already in place.
>>>
>>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.


>>> Will do. With Lutz' help I just checked the UKM we have on this, and it
>>> seems the usage is quite heavily concentrated on large sites. The
>>> top-quartile of remaining public usage is just 9 sites; top-half is ~35.
>>> We'll try to reach out to them.
>>>
>>>

- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?

 As above, we'll happily go up on this.
>>>
>>> My reasoning why 3 milestones would be reasonable was that there is a
>>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
>>> sure, or just wants to postpone the issue, one can just add
>>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
>>> from e.g. CSP, where adding new CSP headers might require a lot of work and
>>> testing.
>>>
>>>

- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?


>>> We see the deprecation warning - without any behavioural changes - as
>>> effectively being the report-only mode. We'll be more clear in the
>>> documentation.
>>>
>>>

-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.

 I agree, and an enterprise policy is already in place.
>>>
>>>

- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?


>>> There is no plan. The current logic is relatively easy to maintain, so
>>> we have not made any 

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

[Noah Lemen]

Any updates on the deprecation warning for cross-domain access? We're now 
looking into setting up the Reporting API to capture this once 
available. Which milestone do you estimate it will ship?

On Monday, February 14, 2022 at 12:28:18 PM UTC-5 Daniel Vogelheim wrote:

> Hi all, just a brief update:
>
> - The warning should go live on M100 
> .
> - Flipping the default is planned for M106 but there'll be a 
> separate intent (and thus additional discussion), as requested.
> - A deprecation warning for cross-domain access (based on previous 
> document.domain setting) is in the works, and will either make it to M100 
> also, or will land shortly after.
> - Additional info: Blog post 
> ; plus some 
> technical 
> notes 
> 
> .
>
> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>
>> Hi all,
>> Hi Yoav,
>>
>> Thanks for the feedback. I'd like to modify the intent timeline as 
>> follows:
>>
>> M99: Start showing a deprecation warning.
>> M99-105: Watch use counters + outreach to top-N users.
>> M105: Deprecate the feature by default.
>>
>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>
>> An enterprise policy is already in place.
>>
>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>>
>>> Hey Daniel! 
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe help 
>>>drive the usage down. 
>>>
>>>
>> Will do. With Lutz' help I just checked the UKM we have on this, and it 
>> seems the usage is quite heavily concentrated on large sites. The 
>> top-quartile of remaining public usage is just 9 sites; top-half is ~35. 
>> We'll try to reach out to them.
>>  
>>
>>>
>>>- A deprecation period of 3 milestones feels a bit short here. Is 
>>>the expectation that turning on the opt-out header can be done under 
>>> that 
>>>period? 
>>>
>>> As above, we'll happily go up on this.
>>
>> My reasoning why 3 milestones would be reasonable was that there is a 
>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't 
>> sure, or just wants to postpone the issue, one can just add 
>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different 
>> from e.g. CSP, where adding new CSP headers might require a lot of work and 
>> testing.
>>  
>>
>>>
>>>- A report-only mode could have allowed sites to try and enable 
>>>this, without risking actual breakage for their documents/properties 
>>> that 
>>>use document.domain. This is doubly true for platforms that want to warn 
>>>their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>on their behalf. At the same time, it is true that they could collect 
>>>deprecation reports (thanks for adding those!) instead during the 
>>>deprecation period, which can be considered an on-by-default report-only 
>>>mode. Can y'all add specific guidance on deprecation reports to the 
>>>documentation? 
>>>
>>>
>> We see the deprecation warning - without any behavioural changes - as 
>> effectively being the report-only mode. We'll be more clear in the 
>> documentation.
>>  
>>
>>>
>>>-  It'd be helpful to reach out to enterprise folks and see what 
>>>their responses may be for this. +Greg Whitworth.
>>>- This probably requires an Enterprise Policy, to reduce the risk 
>>>for managed installs. +bheenan@ for opinions on that front. 
>>>
>>> I agree, and an enterprise policy is already in place.
>>  
>>
>>>
>>>- Is there a plan to eventually remove the opt-out option? Or is it 
>>>the plan to have it in place permanently?
>>>
>>>
>> There is no plan. The current logic is relatively easy to maintain, so we 
>> have not made any plan to remove the opt-out.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 

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

['Daniel Vogelheim' via blink-dev]

Hi all, just a brief update:

- The warning should go live on M100
.
- Flipping the default is planned for M106 but there'll be a
separate intent (and thus additional discussion), as requested.
- A deprecation warning for cross-domain access (based on previous
document.domain setting) is in the works, and will either make it to M100
also, or will land shortly after.
- Additional info: Blog post
; plus
some technical
notes

.

On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>
> Hi all,
> Hi Yoav,
>
> Thanks for the feedback. I'd like to modify the intent timeline as follows:
>
> M99: Start showing a deprecation warning.
> M99-105: Watch use counters + outreach to top-N users.
> M105: Deprecate the feature by default.
>
> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>
> An enterprise policy is already in place.
>
> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:
>
>> Hey Daniel!
>>
>> While searching for this intent review, I stumbled upon
>> https://developer.chrome.com/blog/immutable-document-domain/
>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>
>> This intent was just discussed at the API owner meeting (where Chris,
>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>> This change seems risky in terms of potential breakage when looking at
>> our stats, and that's even before talking about enterprises, where a lot of
>> the API owners feel the risk is even higher.
>>
>> Given that, here's a few potential next steps to try and reduce that risk:
>>
>>- UKM and outreach to specific large users of the API can maybe help
>>drive the usage down.
>>
>>
> Will do. With Lutz' help I just checked the UKM we have on this, and it
> seems the usage is quite heavily concentrated on large sites. The
> top-quartile of remaining public usage is just 9 sites; top-half is ~35.
> We'll try to reach out to them.
>
>
>>
>>- A deprecation period of 3 milestones feels a bit short here. Is the
>>expectation that turning on the opt-out header can be done under that
>>period?
>>
>> As above, we'll happily go up on this.
>
> My reasoning why 3 milestones would be reasonable was that there is a
> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
> sure, or just wants to postpone the issue, one can just add
> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
> from e.g. CSP, where adding new CSP headers might require a lot of work and
> testing.
>
>
>>
>>- A report-only mode could have allowed sites to try and enable this,
>>without risking actual breakage for their documents/properties that use
>>document.domain. This is doubly true for platforms that want to warn their
>>customers about this upcoming deprecation, but without taking risks on
>>their behalf. At the same time, it is true that they could collect
>>deprecation reports (thanks for adding those!) instead during the
>>deprecation period, which can be considered an on-by-default report-only
>>mode. Can y'all add specific guidance on deprecation reports to the
>>documentation?
>>
>>
> We see the deprecation warning - without any behavioural changes - as
> effectively being the report-only mode. We'll be more clear in the
> documentation.
>
>
>>
>>-  It'd be helpful to reach out to enterprise folks and see what
>>their responses may be for this. +Greg Whitworth.
>>- This probably requires an Enterprise Policy, to reduce the risk for
>>managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, and an enterprise policy is already in place.
>
>
>>
>>- Is there a plan to eventually remove the opt-out option? Or is it
>>the plan to have it in place permanently?
>>
>>
> There is no plan. The current logic is relatively easy to maintain, so we
> have not made any plan to remove the opt-out.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMfJoCfVH27xLARbTyBhgO2ypZLHT%2BQ2Pf4EXvBFdjncA%40mail.gmail.com.

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

[Daniel Bratell]

LGTM3

/Daniel

On 2022-01-14 13:58, Daniel Vogelheim wrote:

Hi all,
Hi Yoav,

Thanks for the feedback. I'd like to modify the intent timeline as 
follows:


M99: Start showing a deprecation warning.
M99-105: Watch use counters + outreach to top-N users.
M105: Deprecate the feature by default.

Enabling/disabling will be via Finch, so we have an emergency shut-off.

An enterprise policy is already in place.

On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:

Hey Daniel!

While searching for this intent review, I stumbled upon
https://developer.chrome.com/blog/immutable-document-domain/
That's a useful piece of documentation! Thanks +Eiji Kitamura!!

This intent was just discussed at the API owner meeting (where
Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
This change seems risky in terms of potential breakage when
looking at our stats, and that's even before talking about
enterprises, where a lot of the API owners feel the risk is even
higher.

Given that, here's a few potential next steps to try and reduce
that risk:

  * UKM and outreach to specific large users of the API can maybe
help drive the usage down.


Will do. With Lutz' help I just checked the UKM we have on this, and 
it seems the usage is quite heavily concentrated on large sites. The 
top-quartile of remaining public usage is just 9 sites; top-half is 
~35. We'll try to reach out to them.


  * A deprecation period of 3 milestones feels a bit short here.
Is the expectation that turning on the opt-out header can be
done under that period?

As above, we'll happily go up on this.

My reasoning why 3 milestones would be reasonable was that there is a 
"safe" opt-out. That is, if one wishes to preserve old behaviour, or 
isn't sure, or just wants to postpone the issue, one can just add 
'Origin-Agent-Cluster: ?0" and deal with it later. This is quite 
different from e.g. CSP, where adding new CSP headers might require a 
lot of work and testing.


  * A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their
documents/properties that use document.domain. This is doubly
true for platforms that want to warn their customers about
this upcoming deprecation, but without taking risks on their
behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during
the deprecation period, which can be considered an
on-by-default report-only mode. Can y'all add specific
guidance on deprecation reports to the documentation?


We see the deprecation warning - without any behavioural changes - as 
effectively being the report-only mode. We'll be more clear in the 
documentation.


  *  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
  * This probably requires an Enterprise Policy, to reduce the
risk for managed installs. +bheenan@ for opinions on that front.

I agree, and an enterprise policy is already in place.

  * Is there a plan to eventually remove the opt-out option? Or is
it the plan to have it in place permanently?


There is no plan. The current logic is relatively easy to maintain, so 
we have not made any plan to remove the opt-out.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adca72c4-1239-a0d8-0c77-bcb034d3ee13%40gmail.com.

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

[Greg Whitworth]

Apologies for forgetting to ask this in my last post: 

> As discussed, a 6 months deprecation period

Can we be explicit, which M release/Month will this be presuming the other 
conditions are met.

Thank you,
Greg

On Monday, January 24, 2022 at 8:36:00 AM UTC-8 Daniel Vogelheim wrote:

> Hi again,
>
> On Mon, Jan 24, 2022 at 5:22 PM Daniel Vogelheim  
> wrote:
>
>> Hi Noah,
>>
>> On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen  wrote:
>>
>>> At Meta (formerly known as Facebook) we have a fair amount of 
>>> dependencies on domain lowering via document.domain. We've discussed this 
>>> internally, and feel that the most difficult aspect of this for us 
>>> currently is identifying where we depend on domain lowering. We feel that 
>>> something that may be helpful for us would be a reporting API not on 
>>> document.domain, but rather on any cross-origin accesses that are only 
>>> working because of domain lowering. Would a reporting API like this be 
>>> possible to add to help us along the deprecation process?
>>
>>
>> This should work as-is. I just tried it out: When warnings are enabled 
>> (i.e., during the 6 milestone warning period), or when 
>> --enable-features=OriginAgentClusterDefaultWarning is used on the current 
>> tip-of-tree build, assigning to document.domain triggers the 
>> deprecation warning (if no other errors interfere). The warning is 
>> delivered through the Reporting API and can be programmatically processed 
>> using ReportingObserver 
>> ,
>>  
>> For example, the first code snippet in this article 
>>  will 
>> successfully report the warning. Is this what you're looking for?
>>
>
> It's been pointed out to me that I've overlooked the "on any accesses that 
> are only working because of domain lowering" bit. That isn't there. I'll 
> see if I can add it. Sorry for misunderstanding.
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ff6b4e8-8f24-4eb5-8d23-3ad3bc927cden%40chromium.org.

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

[Greg Whitworth]

> It's been pointed out to me that I've overlooked the "on any accesses 
that are only working because of domain lowering" bit. That isn't there. 
I'll see if I can add it. Sorry for misunderstanding.

This would be valuable to us as well once it's implemented. Thank you.


On Monday, January 24, 2022 at 8:36:00 AM UTC-8 Daniel Vogelheim wrote:

> Hi again,
>
> On Mon, Jan 24, 2022 at 5:22 PM Daniel Vogelheim  
> wrote:
>
>> Hi Noah,
>>
>> On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen  wrote:
>>
>>> At Meta (formerly known as Facebook) we have a fair amount of 
>>> dependencies on domain lowering via document.domain. We've discussed this 
>>> internally, and feel that the most difficult aspect of this for us 
>>> currently is identifying where we depend on domain lowering. We feel that 
>>> something that may be helpful for us would be a reporting API not on 
>>> document.domain, but rather on any cross-origin accesses that are only 
>>> working because of domain lowering. Would a reporting API like this be 
>>> possible to add to help us along the deprecation process?
>>
>>
>> This should work as-is. I just tried it out: When warnings are enabled 
>> (i.e., during the 6 milestone warning period), or when 
>> --enable-features=OriginAgentClusterDefaultWarning is used on the current 
>> tip-of-tree build, assigning to document.domain triggers the 
>> deprecation warning (if no other errors interfere). The warning is 
>> delivered through the Reporting API and can be programmatically processed 
>> using ReportingObserver 
>> ,
>>  
>> For example, the first code snippet in this article 
>>  will 
>> successfully report the warning. Is this what you're looking for?
>>
>
> It's been pointed out to me that I've overlooked the "on any accesses that 
> are only working because of domain lowering" bit. That isn't there. I'll 
> see if I can add it. Sorry for misunderstanding.
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cd70a75b-1020-47da-973f-7ded1d815e82n%40chromium.org.

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

['Daniel Vogelheim' via blink-dev]

Hi again,

On Mon, Jan 24, 2022 at 5:22 PM Daniel Vogelheim 
wrote:

> Hi Noah,
>
> On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen  wrote:
>
>> At Meta (formerly known as Facebook) we have a fair amount of
>> dependencies on domain lowering via document.domain. We've discussed this
>> internally, and feel that the most difficult aspect of this for us
>> currently is identifying where we depend on domain lowering. We feel that
>> something that may be helpful for us would be a reporting API not on
>> document.domain, but rather on any cross-origin accesses that are only
>> working because of domain lowering. Would a reporting API like this be
>> possible to add to help us along the deprecation process?
>
>
> This should work as-is. I just tried it out: When warnings are enabled
> (i.e., during the 6 milestone warning period), or when
> --enable-features=OriginAgentClusterDefaultWarning is used on the current
> tip-of-tree build, assigning to document.domain triggers the
> deprecation warning (if no other errors interfere). The warning is
> delivered through the Reporting API and can be programmatically processed
> using ReportingObserver
> ,
> For example, the first code snippet in this article
>  will
> successfully report the warning. Is this what you're looking for?
>

It's been pointed out to me that I've overlooked the "on any accesses that
are only working because of domain lowering" bit. That isn't there. I'll
see if I can add it. Sorry for misunderstanding.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOsxjN%3DKza0CwcqEuZ5azMQQus8C32zyp%2BA39eBNLizJA%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

Hi Noah,

On Thu, Jan 20, 2022 at 8:11 PM Noah Lemen  wrote:

> At Meta (formerly known as Facebook) we have a fair amount of dependencies
> on domain lowering via document.domain. We've discussed this internally,
> and feel that the most difficult aspect of this for us currently is
> identifying where we depend on domain lowering. We feel that something that
> may be helpful for us would be a reporting API not on document.domain, but
> rather on any cross-origin accesses that are only working because of domain
> lowering. Would a reporting API like this be possible to add to help us
> along the deprecation process?
>

This should work as-is. I just tried it out: When warnings are enabled
(i.e., during the 6 milestone warning period), or when
--enable-features=OriginAgentClusterDefaultWarning is used on the current
tip-of-tree build, assigning to document.domain triggers the
deprecation warning (if no other errors interfere). The warning is
delivered through the Reporting API and can be programmatically processed
using ReportingObserver
,
For example, the first code snippet in this article
 will
successfully report the warning. Is this what you're looking for?


>
> On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote:
>
>> Hi,
>> Do you know if there is  a way to get a Chrome version with those changes
>> to see how those changes impact my site?
>> Thanks
>>
>> On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org
>> wrote:
>>
>>> Daniel:
>>>
>>> Salesforce use is concentrated in enterprises, and the enterprise opt-in
>>> rates for metrics and crash reporting are very, very, very low. As a
>>> result, I'm not sure we should trust UKM here.
>>>
>>> Greg:
>>>
>>> Thanks so much for looking into your code. I know it might take time for
>>> your larger ecosystem to start sending y'all deprecation reports. How long
>>> after the deprecation API starts reporting do you think it'll be before we
>>> can get solid information from your service?
>>>
>>> Thanks.
>>>
>>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>>>
 On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
 wrote:

> Hey folks,
>
> I'll be spinning up a thread with some internal folks here at
> Salesforce to start doing some scans of code to determine utilization. Has
> this been added to the reporting API for deprecation to possibly capture
> live hits that way as well?
>

 Not yet. That'd be the first step once this intent is approved.

>
> I'll follow up on what I find and that will influence my opinion on
> removal timeline.
>

 Thank you, this would be very helpful.
 If it helps: salesforce.com (or other Salesforce country domains) do
 not show up in our telemetry, so with some likelihood you're among the >99%
 sites that do not even use this mis-feature. :-)
 (Caveat: You might use other domains as well; or maybe your customers
 dis-proportionally disable reporting.)

 If you have a staging environment, you can simulate the deprecation by
 adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables
 clustering by origin. document.domain setting will have no effect, and a
 console message will be printed. (In other words: This is behaviour we'd
 like to be the default.)
 If you do find usage that you cannot easily replace, adding
 "Origin-Agent-Cluster: ?0" will disable this.


> ~Greg
>
> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>
>> Note that Daniel has already landed the enterprise policy for this in
>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
>> (99.0.4759.0).
>>
>> Charlie
>>
>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan 
>> wrote:
>>
>>> > This probably requires an Enterprise Policy, to reduce the risk
>>> for managed installs. +bheenan@ for opinions on that front.
>>>
>>> I agree, this looks like a breaking change according to
>>> go/chrome-enterprise-friendly and therefore needs a policy.
>>> Instructions for implementing a policy are here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>> if you haven't done it before, and the enterprise team is happy to help 
>>> if
>>> anything seems confusing. Having this implemented as a "soft removal" 
>>> with
>>> a temporary policy escape hatch significantly reduces enterprise risk,
>>> since even if we are surprised by a use case hiding behind many
>>> enterprises' tendency to turn off metrics, those users can
>>> break-fix themselves immediately while staying on the latest version.
>>>
>>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 

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

[Chris Harrelson]

LGTM2 under  Yoav's stated conditions, plus adding the mode Noah suggested
and the additional documentation. I recommend a web.dev article about the
why of this change and with the ways developers can plan for it.

On Mon, Jan 24, 2022 at 6:48 AM 'Daniel Vogelheim' via blink-dev <
blink-dev@chromium.org> wrote:

> On Sun, Jan 23, 2022 at 7:47 PM Daniel Bratell 
> wrote:
>
>> Maybe it's wrong to call it "removal" too, since it will still be
>> available for those sites that use site-keyed clusters. It's just making
>> site-keyed clusters opt-in instead of opt-out. It's not going away, but it
>> will require an extra step to use.
>>
>
> This is true, but I'm not sure where to go with this. Since we're
> effectively asking (affected) site owners to change something, it's
> arguably closer to a deprecation than to a "normal" feature which would add
> functionality. To that end, calling it "deprecation" does get the right
> people's attention. I suspect that people would have missed it if we had
> called it "origin cluster opt-in" or something. But of course, technically
> it indeed isn't a deprecation, because the functionality itself remains
> available. Should I change the title?
>
> I think a more comprehensive document that spells out the
> options/consequences more clearly solves most of this problem. :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNueOvzs%2BYKy7qrN5J7jiY2sctYnuxtX-Thvnb0m5SVtQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw88wJ%2BUG89E0%2BcNUS4xe1F%2BDFd9Y%2BD%3DNgRzcRuweFFfoQ%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

On Sun, Jan 23, 2022 at 7:47 PM Daniel Bratell  wrote:

> Maybe it's wrong to call it "removal" too, since it will still be
> available for those sites that use site-keyed clusters. It's just making
> site-keyed clusters opt-in instead of opt-out. It's not going away, but it
> will require an extra step to use.
>

This is true, but I'm not sure where to go with this. Since we're
effectively asking (affected) site owners to change something, it's
arguably closer to a deprecation than to a "normal" feature which would add
functionality. To that end, calling it "deprecation" does get the right
people's attention. I suspect that people would have missed it if we had
called it "origin cluster opt-in" or something. But of course, technically
it indeed isn't a deprecation, because the functionality itself remains
available. Should I change the title?

I think a more comprehensive document that spells out the
options/consequences more clearly solves most of this problem. :)

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNueOvzs%2BYKy7qrN5J7jiY2sctYnuxtX-Thvnb0m5SVtQ%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

On Fri, Jan 21, 2022 at 11:04 PM Chris Harrelson 
wrote:

> On Thu, Jan 20, 2022 at 11:11 AM Noah Lemen  wrote:
>
>> At Meta (formerly known as Facebook) we have a fair amount of
>> dependencies on domain lowering via document.domain. We've discussed this
>> internally, and feel that the most difficult aspect of this for us
>> currently is identifying where we depend on domain lowering. We feel that
>> something that may be helpful for us would be a reporting API not on
>> document.domain, but rather on any cross-origin accesses that are only
>> working because of domain lowering. Would a reporting API like this be
>> possible to add to help us along the deprecation process?
>>
>
> This is an interesting request, and I can see how it would be quite
> useful. @Daniel Vogelheim  do you think it's
> feasible?
>

Yes, that's a super sensible request, and it's very much feasible. In fact,
my understanding was that the deprecation warning mechanism, which we are
using, already supports this. I'll double check. If this isn't possible
with the current code, I'll add it in.

One thing I've learnt here - from this request, but also TK's and Greg's -
is that I have undercommunicated the options available to site owners. I'll
write a seperate doc that is more clear on this, and spells these things
out more clearly.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPN%2BEbUbgf6kx6O3uwFWHPgeM3WUhwsT%3D%3DqMEp48%2BqEaFQ%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

On Fri, Jan 21, 2022 at 9:23 PM Yoav Weiss  wrote:

> LGTM1 to deprecate under the following conditions:
>
>- As discussed, a 6 months deprecation period, as well as broad-scope
>and targeted outreach, that would hopefully bring usage down.
>- A well-crafted deprecation message that indicates the timeline, and
>at the same time indicates that we'll be responsive to community feedback
>(or a link to a blog post/documentation page that indicates the same)
>- Sending a separate intent for the actual removal at the end of the
>deprecation period, once the picture is a bit clearer.
>
> Thanks, will do.



> On Fri, Jan 14, 2022 at 7:07 PM Alex Russell 
> wrote:
>
>> Daniel:
>>
>> Salesforce use is concentrated in enterprises, and the enterprise opt-in
>> rates for metrics and crash reporting are very, very, very low. As a
>> result, I'm not sure we should trust UKM here.
>>
>> Greg:
>>
>> Thanks so much for looking into your code. I know it might take time for
>> your larger ecosystem to start sending y'all deprecation reports. How long
>> after the deprecation API starts reporting do you think it'll be before we
>> can get solid information from your service?
>>
>> Thanks.
>>
>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>>
>>> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
>>> wrote:
>>>
 Hey folks,

 I'll be spinning up a thread with some internal folks here at
 Salesforce to start doing some scans of code to determine utilization. Has
 this been added to the reporting API for deprecation to possibly capture
 live hits that way as well?

>>>
>>> Not yet. That'd be the first step once this intent is approved.
>>>

 I'll follow up on what I find and that will influence my opinion on
 removal timeline.

>>>
>>> Thank you, this would be very helpful.
>>> If it helps: salesforce.com (or other Salesforce country domains) do
>>> not show up in our telemetry, so with some likelihood you're among the >99%
>>> sites that do not even use this mis-feature. :-)
>>> (Caveat: You might use other domains as well; or maybe your customers
>>> dis-proportionally disable reporting.)
>>>
>>> If you have a staging environment, you can simulate the deprecation by
>>> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables
>>> clustering by origin. document.domain setting will have no effect, and a
>>> console message will be printed. (In other words: This is behaviour we'd
>>> like to be the default.)
>>> If you do find usage that you cannot easily replace, adding
>>> "Origin-Agent-Cluster: ?0" will disable this.
>>>
>>>
 ~Greg

 On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:

> Note that Daniel has already landed the enterprise policy for this in
> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
> (99.0.4759.0).
>
> Charlie
>
> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan 
> wrote:
>
>> > This probably requires an Enterprise Policy, to reduce the risk for
>> managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, this looks like a breaking change according to
>> go/chrome-enterprise-friendly and therefore needs a policy.
>> Instructions for implementing a policy are here:
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>> if you haven't done it before, and the enterprise team is happy to help 
>> if
>> anything seems confusing. Having this implemented as a "soft removal" 
>> with
>> a temporary policy escape hatch significantly reduces enterprise risk,
>> since even if we are surprised by a use case hiding behind many
>> enterprises' tendency to turn off metrics, those users can
>> break-fix themselves immediately while staying on the latest version.
>>
>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
>> wrote:
>>
>>> Hey Daniel!
>>>
>>> While searching for this intent review, I stumbled upon
>>> https://developer.chrome.com/blog/immutable-document-domain/
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where
>>> Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking
>>> at our stats, and that's even before talking about enterprises, where a 
>>> lot
>>> of the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe
>>>help drive the usage down.
>>>- A deprecation period of 3 milestones feels a bit short here.
>>>Is the expectation that turning on the opt-out header can be done 
>>> 

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

[Daniel Bratell]

Maybe it's wrong to call it "removal" too, since it will still be 
available for those sites that use site-keyed clusters. It's just making 
site-keyed clusters opt-in instead of opt-out. It's not going away, but 
it will require an extra step to use.


/Daniel

On 2022-01-21 21:22, Yoav Weiss wrote:

LGTM1 to deprecate under the following conditions:

  * As discussed, a 6 months deprecation period, as well as
broad-scope and targeted outreach, that would hopefully bring
usage down.
  * A well-crafted deprecation message that indicates the timeline,
and at the same time indicates that we'll be responsive to
community feedback (or a link to a blog post/documentation page
that indicates the same)
  * Sending a separate intent for the actual removal at the end of the
deprecation period, once the picture is a bit clearer.


On Fri, Jan 14, 2022 at 7:07 PM Alex Russell 
 wrote:


Daniel:

Salesforce use is concentrated in enterprises, and the enterprise
opt-in rates for metrics and crash reporting are very, very, very
low. As a result, I'm not sure we should trust UKM here.

Greg:

Thanks so much for looking into your code. I know it might take
time for your larger ecosystem to start sending y'all deprecation
reports. How long after the deprecation API starts reporting do
you think it'll be before we can get solid information from your
service?

Thanks.

On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim
wrote:

On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth
 wrote:

Hey folks,

I'll be spinning up a thread with some internal folks here
at Salesforce to start doing some scans of code to
determine utilization. Has this been added to the
reporting API for deprecation to possibly capture live
hits that way as well?


Not yet. That'd be the first step once this intent is approved.


I'll follow up on what I find and that will influence my
opinion on removal timeline.


Thank you, this would be very helpful.
If it helps: salesforce.com  (or other
Salesforce country domains) do not show up in our telemetry,
so with some likelihood you're among the >99% sites that do
not even use this mis-feature. :-)
(Caveat: You might use other domains as well; or maybe your
customers dis-proportionally disable reporting.)

If you have a staging environment, you can simulate the
deprecation by adding the "Origin-Agent-Cluster: ?1" header.
This explicitly enables clustering by origin. document.domain
setting will have no effect, and a console message will be
printed. (In other words: This is behaviour we'd like to be
the default.)
If you do find usage that you cannot easily replace, adding
"Origin-Agent-Cluster: ?0" will disable this.


~Greg

On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie
Reis wrote:

Note that Daniel has already landed the enterprise
policy for this in

https://chromium-review.googlesource.com/c/chromium/src/+/3317349
(99.0.4759.0).

Charlie

On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan
 wrote:

> This probably requires an Enterprise Policy, to
reduce the risk for managed installs. +bheenan@
for opinions on that front.

I agree, this looks like a breaking change
according to go/chrome-enterprise-friendly
 and
therefore needs a policy. Instructions for
implementing a policy are here:

https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
if you haven't done it before, and the enterprise
team is happy to help if anything seems confusing.
Having this implemented as a "soft removal" with a
temporary policy escape hatch significantly
reduces enterprise risk, since even if we are
surprised by a use case hiding behind many
enterprises' tendency to turn off metrics, those
users can break-fix themselves immediately while
staying on the latest version.

On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss
 wrote:

Hey Daniel!

While searching for this intent review, I
stumbled upon

https://developer.chrome.com/blog/immutable-document-domain/

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

['Chris Harrelson' via blink-dev]

On Thu, Jan 20, 2022 at 11:11 AM Noah Lemen  wrote:

> At Meta (formerly known as Facebook) we have a fair amount of dependencies
> on domain lowering via document.domain. We've discussed this internally,
> and feel that the most difficult aspect of this for us currently is
> identifying where we depend on domain lowering. We feel that something that
> may be helpful for us would be a reporting API not on document.domain, but
> rather on any cross-origin accesses that are only working because of domain
> lowering. Would a reporting API like this be possible to add to help us
> along the deprecation process?
>

This is an interesting request, and I can see how it would be quite
useful. @Daniel
Vogelheim  do you think it's feasible?


>
> On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote:
>
>> Hi,
>> Do you know if there is  a way to get a Chrome version with those changes
>> to see how those changes impact my site?
>> Thanks
>>
>> On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org
>> wrote:
>>
>>> Daniel:
>>>
>>> Salesforce use is concentrated in enterprises, and the enterprise opt-in
>>> rates for metrics and crash reporting are very, very, very low. As a
>>> result, I'm not sure we should trust UKM here.
>>>
>>> Greg:
>>>
>>> Thanks so much for looking into your code. I know it might take time for
>>> your larger ecosystem to start sending y'all deprecation reports. How long
>>> after the deprecation API starts reporting do you think it'll be before we
>>> can get solid information from your service?
>>>
>>> Thanks.
>>>
>>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>>>
 On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
 wrote:

> Hey folks,
>
> I'll be spinning up a thread with some internal folks here at
> Salesforce to start doing some scans of code to determine utilization. Has
> this been added to the reporting API for deprecation to possibly capture
> live hits that way as well?
>

 Not yet. That'd be the first step once this intent is approved.

>
> I'll follow up on what I find and that will influence my opinion on
> removal timeline.
>

 Thank you, this would be very helpful.
 If it helps: salesforce.com (or other Salesforce country domains) do
 not show up in our telemetry, so with some likelihood you're among the >99%
 sites that do not even use this mis-feature. :-)
 (Caveat: You might use other domains as well; or maybe your customers
 dis-proportionally disable reporting.)

 If you have a staging environment, you can simulate the deprecation by
 adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables
 clustering by origin. document.domain setting will have no effect, and a
 console message will be printed. (In other words: This is behaviour we'd
 like to be the default.)
 If you do find usage that you cannot easily replace, adding
 "Origin-Agent-Cluster: ?0" will disable this.


> ~Greg
>
> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>
>> Note that Daniel has already landed the enterprise policy for this in
>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
>> (99.0.4759.0).
>>
>> Charlie
>>
>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan 
>> wrote:
>>
>>> > This probably requires an Enterprise Policy, to reduce the risk
>>> for managed installs. +bheenan@ for opinions on that front.
>>>
>>> I agree, this looks like a breaking change according to
>>> go/chrome-enterprise-friendly and therefore needs a policy.
>>> Instructions for implementing a policy are here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>> if you haven't done it before, and the enterprise team is happy to help 
>>> if
>>> anything seems confusing. Having this implemented as a "soft removal" 
>>> with
>>> a temporary policy escape hatch significantly reduces enterprise risk,
>>> since even if we are surprised by a use case hiding behind many
>>> enterprises' tendency to turn off metrics, those users can
>>> break-fix themselves immediately while staying on the latest version.
>>>
>>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
>>> wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where
 Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking
 at our stats, and that's even before talking about enterprises, where 
 a lot

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

[Yoav Weiss]

LGTM1 to deprecate under the following conditions:

   - As discussed, a 6 months deprecation period, as well as broad-scope
   and targeted outreach, that would hopefully bring usage down.
   - A well-crafted deprecation message that indicates the timeline, and at
   the same time indicates that we'll be responsive to community feedback (or
   a link to a blog post/documentation page that indicates the same)
   - Sending a separate intent for the actual removal at the end of the
   deprecation period, once the picture is a bit clearer.


On Fri, Jan 14, 2022 at 7:07 PM Alex Russell 
wrote:

> Daniel:
>
> Salesforce use is concentrated in enterprises, and the enterprise opt-in
> rates for metrics and crash reporting are very, very, very low. As a
> result, I'm not sure we should trust UKM here.
>
> Greg:
>
> Thanks so much for looking into your code. I know it might take time for
> your larger ecosystem to start sending y'all deprecation reports. How long
> after the deprecation API starts reporting do you think it'll be before we
> can get solid information from your service?
>
> Thanks.
>
> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>
>> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
>> wrote:
>>
>>> Hey folks,
>>>
>>> I'll be spinning up a thread with some internal folks here at Salesforce
>>> to start doing some scans of code to determine utilization. Has this been
>>> added to the reporting API for deprecation to possibly capture live hits
>>> that way as well?
>>>
>>
>> Not yet. That'd be the first step once this intent is approved.
>>
>>>
>>> I'll follow up on what I find and that will influence my opinion on
>>> removal timeline.
>>>
>>
>> Thank you, this would be very helpful.
>> If it helps: salesforce.com (or other Salesforce country domains) do not
>> show up in our telemetry, so with some likelihood you're among the >99%
>> sites that do not even use this mis-feature. :-)
>> (Caveat: You might use other domains as well; or maybe your customers
>> dis-proportionally disable reporting.)
>>
>> If you have a staging environment, you can simulate the deprecation by
>> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables
>> clustering by origin. document.domain setting will have no effect, and a
>> console message will be printed. (In other words: This is behaviour we'd
>> like to be the default.)
>> If you do find usage that you cannot easily replace, adding
>> "Origin-Agent-Cluster: ?0" will disable this.
>>
>>
>>> ~Greg
>>>
>>> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>>>
 Note that Daniel has already landed the enterprise policy for this in
 https://chromium-review.googlesource.com/c/chromium/src/+/3317349
 (99.0.4759.0).

 Charlie

 On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan 
 wrote:

> > This probably requires an Enterprise Policy, to reduce the risk for
> managed installs. +bheenan@ for opinions on that front.
>
> I agree, this looks like a breaking change according to
> go/chrome-enterprise-friendly and therefore needs a policy.
> Instructions for implementing a policy are here:
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
> if you haven't done it before, and the enterprise team is happy to help if
> anything seems confusing. Having this implemented as a "soft removal" with
> a temporary policy escape hatch significantly reduces enterprise risk,
> since even if we are surprised by a use case hiding behind many
> enterprises' tendency to turn off metrics, those users can
> break-fix themselves immediately while staying on the latest version.
>
> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
> wrote:
>
>> Hey Daniel!
>>
>> While searching for this intent review, I stumbled upon
>> https://developer.chrome.com/blog/immutable-document-domain/
>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>
>> This intent was just discussed at the API owner meeting (where Chris,
>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>> This change seems risky in terms of potential breakage when looking
>> at our stats, and that's even before talking about enterprises, where a 
>> lot
>> of the API owners feel the risk is even higher.
>>
>> Given that, here's a few potential next steps to try and reduce that
>> risk:
>>
>>- UKM and outreach to specific large users of the API can maybe
>>help drive the usage down.
>>- A deprecation period of 3 milestones feels a bit short here. Is
>>the expectation that turning on the opt-out header can be done under 
>> that
>>period?
>>- A report-only mode could have allowed sites to try and enable
>>this, without risking actual breakage for their documents/properties 
>> that
>>use 

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

[Noah Lemen]

At Meta (formerly known as Facebook) we have a fair amount of dependencies 
on domain lowering via document.domain. We've discussed this internally, 
and feel that the most difficult aspect of this for us currently is 
identifying where we depend on domain lowering. We feel that something that 
may be helpful for us would be a reporting API not on document.domain, but 
rather on any cross-origin accesses that are only working because of domain 
lowering. Would a reporting API like this be possible to add to help us 
along the deprecation process?

On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote:

> Hi,
> Do you know if there is  a way to get a Chrome version with those changes 
> to see how those changes impact my site?
> Thanks
>
> On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org 
> wrote:
>
>> Daniel: 
>>
>> Salesforce use is concentrated in enterprises, and the enterprise opt-in 
>> rates for metrics and crash reporting are very, very, very low. As a 
>> result, I'm not sure we should trust UKM here. 
>>
>> Greg: 
>>
>> Thanks so much for looking into your code. I know it might take time for 
>> your larger ecosystem to start sending y'all deprecation reports. How long 
>> after the deprecation API starts reporting do you think it'll be before we 
>> can get solid information from your service?
>>
>> Thanks.
>>
>> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>>
>>> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth  
>>> wrote:
>>>
 Hey folks,

 I'll be spinning up a thread with some internal folks here at 
 Salesforce to start doing some scans of code to determine utilization. Has 
 this been added to the reporting API for deprecation to possibly capture 
 live hits that way as well?

>>>
>>> Not yet. That'd be the first step once this intent is approved. 
>>>

 I'll follow up on what I find and that will influence my opinion on 
 removal timeline.

>>>
>>> Thank you, this would be very helpful.
>>> If it helps: salesforce.com (or other Salesforce country domains) do 
>>> not show up in our telemetry, so with some likelihood you're among the >99% 
>>> sites that do not even use this mis-feature. :-)
>>> (Caveat: You might use other domains as well; or maybe your customers 
>>> dis-proportionally disable reporting.)
>>>
>>> If you have a staging environment, you can simulate the deprecation by 
>>> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables 
>>> clustering by origin. document.domain setting will have no effect, and a 
>>> console message will be printed. (In other words: This is behaviour we'd 
>>> like to be the default.)
>>> If you do find usage that you cannot easily replace, adding 
>>> "Origin-Agent-Cluster: ?0" will disable this.
>>>
>>>
 ~Greg

 On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:

> Note that Daniel has already landed the enterprise policy for this in 
> https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
> (99.0.4759.0).
>
> Charlie
>
> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  
> wrote:
>
>> > This probably requires an Enterprise Policy, to reduce the risk for 
>> managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, this looks like a breaking change according to 
>> go/chrome-enterprise-friendly and therefore needs a policy. 
>> Instructions for implementing a policy are here: 
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>  
>> if you haven't done it before, and the enterprise team is happy to help 
>> if 
>> anything seems confusing. Having this implemented as a "soft removal" 
>> with 
>> a temporary policy escape hatch significantly reduces enterprise risk, 
>> since even if we are surprised by a use case hiding behind many 
>> enterprises' tendency to turn off metrics, those users can 
>> break-fix themselves immediately while staying on the latest version.
>>
>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  
>> wrote:
>>
>>> Hey Daniel!
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where 
>>> Chris, Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking 
>>> at our stats, and that's even before talking about enterprises, where a 
>>> lot 
>>> of the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe 

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

[Alex Russell]

Daniel: 

Salesforce use is concentrated in enterprises, and the enterprise opt-in 
rates for metrics and crash reporting are very, very, very low. As a 
result, I'm not sure we should trust UKM here. 

Greg: 

Thanks so much for looking into your code. I know it might take time for 
your larger ecosystem to start sending y'all deprecation reports. How long 
after the deprecation API starts reporting do you think it'll be before we 
can get solid information from your service?

Thanks.

On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:

> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth  
> wrote:
>
>> Hey folks,
>>
>> I'll be spinning up a thread with some internal folks here at Salesforce 
>> to start doing some scans of code to determine utilization. Has this been 
>> added to the reporting API for deprecation to possibly capture live hits 
>> that way as well?
>>
>
> Not yet. That'd be the first step once this intent is approved. 
>
>>
>> I'll follow up on what I find and that will influence my opinion on 
>> removal timeline.
>>
>
> Thank you, this would be very helpful.
> If it helps: salesforce.com (or other Salesforce country domains) do not 
> show up in our telemetry, so with some likelihood you're among the >99% 
> sites that do not even use this mis-feature. :-)
> (Caveat: You might use other domains as well; or maybe your customers 
> dis-proportionally disable reporting.)
>
> If you have a staging environment, you can simulate the deprecation by 
> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables 
> clustering by origin. document.domain setting will have no effect, and a 
> console message will be printed. (In other words: This is behaviour we'd 
> like to be the default.)
> If you do find usage that you cannot easily replace, adding 
> "Origin-Agent-Cluster: ?0" will disable this.
>
>
>> ~Greg
>>
>> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>>
>>> Note that Daniel has already landed the enterprise policy for this in 
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
>>> (99.0.4759.0).
>>>
>>> Charlie
>>>
>>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  
>>> wrote:
>>>
 > This probably requires an Enterprise Policy, to reduce the risk for 
 managed installs. +bheenan@ for opinions on that front.

 I agree, this looks like a breaking change according to 
 go/chrome-enterprise-friendly and therefore needs a policy. 
 Instructions for implementing a policy are here: 
 https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
  
 if you haven't done it before, and the enterprise team is happy to help if 
 anything seems confusing. Having this implemented as a "soft removal" with 
 a temporary policy escape hatch significantly reduces enterprise risk, 
 since even if we are surprised by a use case hiding behind many 
 enterprises' tendency to turn off metrics, those users can 
 break-fix themselves immediately while staying on the latest version.

 On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  
 wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon 
> https://developer.chrome.com/blog/immutable-document-domain/ 
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris, 
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at 
> our stats, and that's even before talking about enterprises, where a lot 
> of 
> the API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that 
> risk:
>
>- UKM and outreach to specific large users of the API can maybe 
>help drive the usage down.
>- A deprecation period of 3 milestones feels a bit short here. Is 
>the expectation that turning on the opt-out header can be done under 
> that 
>period?
>- A report-only mode could have allowed sites to try and enable 
>this, without risking actual breakage for their documents/properties 
> that 
>use document.domain. This is doubly true for platforms that want to 
> warn 
>their customers about this upcoming deprecation, but without taking 
> risks 
>on their behalf. At the same time, it is true that they could collect 
>deprecation reports (thanks for adding those!) instead during the 
>deprecation period, which can be considered an on-by-default 
> report-only 
>mode. Can y'all add specific guidance on deprecation reports to the 
>documentation?
>-  It'd be helpful to reach out to enterprise folks and see what 
>their responses may be for this. +Greg Whitworth.
>- This 

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

['Daniel Vogelheim' via blink-dev]

On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
wrote:

> Hey folks,
>
> I'll be spinning up a thread with some internal folks here at Salesforce
> to start doing some scans of code to determine utilization. Has this been
> added to the reporting API for deprecation to possibly capture live hits
> that way as well?
>

Not yet. That'd be the first step once this intent is approved.

>
> I'll follow up on what I find and that will influence my opinion on
> removal timeline.
>

Thank you, this would be very helpful.
If it helps: salesforce.com (or other Salesforce country domains) do not
show up in our telemetry, so with some likelihood you're among the >99%
sites that do not even use this mis-feature. :-)
(Caveat: You might use other domains as well; or maybe your customers
dis-proportionally disable reporting.)

If you have a staging environment, you can simulate the deprecation by
adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables
clustering by origin. document.domain setting will have no effect, and a
console message will be printed. (In other words: This is behaviour we'd
like to be the default.)
If you do find usage that you cannot easily replace, adding
"Origin-Agent-Cluster: ?0" will disable this.


> ~Greg
>
> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>
>> Note that Daniel has already landed the enterprise policy for this in
>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
>> (99.0.4759.0).
>>
>> Charlie
>>
>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:
>>
>>> > This probably requires an Enterprise Policy, to reduce the risk for
>>> managed installs. +bheenan@ for opinions on that front.
>>>
>>> I agree, this looks like a breaking change according to
>>> go/chrome-enterprise-friendly and therefore needs a policy.
>>> Instructions for implementing a policy are here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>> if you haven't done it before, and the enterprise team is happy to help if
>>> anything seems confusing. Having this implemented as a "soft removal" with
>>> a temporary policy escape hatch significantly reduces enterprise risk,
>>> since even if we are surprised by a use case hiding behind many
>>> enterprises' tendency to turn off metrics, those users can
>>> break-fix themselves immediately while staying on the latest version.
>>>
>>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
>>> wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.
- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?
- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?
-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.
- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?

 Cheers,
 Yoav


 On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:

> On 12/16/21 5:52 PM, Charlie Reis wrote:
>
>
>
> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
> blin...@chromium.org> wrote:
>
>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>> wrote:
>>
>>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>>
>>> It seems more or less everyone agrees on this being a good thing, so

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

['Daniel Vogelheim' via blink-dev]

On Thu, Jan 13, 2022 at 11:32 PM Brandon Heenan  wrote:

> > This probably requires an Enterprise Policy, to reduce the risk for
> managed installs. +bheenan@ for opinions on that front.
>
> I agree, this looks like a breaking change according to
> go/chrome-enterprise-friendly and therefore needs a policy. Instructions
> for implementing a policy are here:
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
> if you haven't done it before, and the enterprise team is happy to help if
> anything seems confusing. Having this implemented as a "soft removal" with
> a temporary policy escape hatch significantly reduces enterprise risk,
> since even if we are surprised by a use case hiding behind many
> enterprises' tendency to turn off metrics, those users can
> break-fix themselves immediately while staying on the latest version.
>

I agree, and a policy is already in place
.
(I'll have to update it with the new milestones, though.)

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNccT4qX8KEyjMkSg5hgytn_RaUMEAC%2B81Ffd9gYK-X0g%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

Hi all,
Hi Yoav,

Thanks for the feedback. I'd like to modify the intent timeline as follows:

M99: Start showing a deprecation warning.
M99-105: Watch use counters + outreach to top-N users.
M105: Deprecate the feature by default.

Enabling/disabling will be via Finch, so we have an emergency shut-off.

An enterprise policy is already in place.

On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss  wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon
> https://developer.chrome.com/blog/immutable-document-domain/
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris,
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at our
> stats, and that's even before talking about enterprises, where a lot of the
> API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that risk:
>
>- UKM and outreach to specific large users of the API can maybe help
>drive the usage down.
>
>
Will do. With Lutz' help I just checked the UKM we have on this, and it
seems the usage is quite heavily concentrated on large sites. The
top-quartile of remaining public usage is just 9 sites; top-half is ~35.
We'll try to reach out to them.


>
>- A deprecation period of 3 milestones feels a bit short here. Is the
>expectation that turning on the opt-out header can be done under that
>period?
>
> As above, we'll happily go up on this.

My reasoning why 3 milestones would be reasonable was that there is a
"safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't
sure, or just wants to postpone the issue, one can just add
'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different
from e.g. CSP, where adding new CSP headers might require a lot of work and
testing.


>
>- A report-only mode could have allowed sites to try and enable this,
>without risking actual breakage for their documents/properties that use
>document.domain. This is doubly true for platforms that want to warn their
>customers about this upcoming deprecation, but without taking risks on
>their behalf. At the same time, it is true that they could collect
>deprecation reports (thanks for adding those!) instead during the
>deprecation period, which can be considered an on-by-default report-only
>mode. Can y'all add specific guidance on deprecation reports to the
>documentation?
>
>
We see the deprecation warning - without any behavioural changes - as
effectively being the report-only mode. We'll be more clear in the
documentation.


>
>-  It'd be helpful to reach out to enterprise folks and see what their
>responses may be for this. +Greg Whitworth.
>- This probably requires an Enterprise Policy, to reduce the risk for
>managed installs. +bheenan@ for opinions on that front.
>
> I agree, and an enterprise policy is already in place.


>
>- Is there a plan to eventually remove the opt-out option? Or is it
>the plan to have it in place permanently?
>
>
There is no plan. The current logic is relatively easy to maintain, so we
have not made any plan to remove the opt-out.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNs24tap5M0OpdPX%3DLYaXDZmq%2BoB8pEALaTX6g1G1h5Sg%40mail.gmail.com.

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

[Yoav Weiss]

On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth 
wrote:

> Hey folks,
>
> I'll be spinning up a thread with some internal folks here at Salesforce
> to start doing some scans of code to determine utilization. Has this been
> added to the reporting API for deprecation to possibly capture live hits
> that way as well?
>

I believe the intent is asking to add those as part of the deprecation
period, but that hasn't happened yet.


>
> I'll follow up on what I find and that will influence my opinion on
> removal timeline.
>
> ~Greg
>
> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>
>> Note that Daniel has already landed the enterprise policy for this in
>> https://chromium-review.googlesource.com/c/chromium/src/+/3317349
>> (99.0.4759.0).
>>
>> Charlie
>>
>> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:
>>
>>> > This probably requires an Enterprise Policy, to reduce the risk for
>>> managed installs. +bheenan@ for opinions on that front.
>>>
>>> I agree, this looks like a breaking change according to
>>> go/chrome-enterprise-friendly and therefore needs a policy.
>>> Instructions for implementing a policy are here:
>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>> if you haven't done it before, and the enterprise team is happy to help if
>>> anything seems confusing. Having this implemented as a "soft removal" with
>>> a temporary policy escape hatch significantly reduces enterprise risk,
>>> since even if we are surprised by a use case hiding behind many
>>> enterprises' tendency to turn off metrics, those users can
>>> break-fix themselves immediately while staying on the latest version.
>>>
>>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
>>> wrote:
>>>
 Hey Daniel!

 While searching for this intent review, I stumbled upon
 https://developer.chrome.com/blog/immutable-document-domain/
 That's a useful piece of documentation! Thanks +Eiji Kitamura!!

 This intent was just discussed at the API owner meeting (where Chris,
 Rego, Daniel, Philip, Alex, MikeT and myself were present).
 This change seems risky in terms of potential breakage when looking at
 our stats, and that's even before talking about enterprises, where a lot of
 the API owners feel the risk is even higher.

 Given that, here's a few potential next steps to try and reduce that
 risk:

- UKM and outreach to specific large users of the API can maybe
help drive the usage down.
- A deprecation period of 3 milestones feels a bit short here. Is
the expectation that turning on the opt-out header can be done under 
 that
period?
- A report-only mode could have allowed sites to try and enable
this, without risking actual breakage for their documents/properties 
 that
use document.domain. This is doubly true for platforms that want to warn
their customers about this upcoming deprecation, but without taking 
 risks
on their behalf. At the same time, it is true that they could collect
deprecation reports (thanks for adding those!) instead during the
deprecation period, which can be considered an on-by-default report-only
mode. Can y'all add specific guidance on deprecation reports to the
documentation?
-  It'd be helpful to reach out to enterprise folks and see what
their responses may be for this. +Greg Whitworth.
- This probably requires an Enterprise Policy, to reduce the risk
for managed installs. +bheenan@ for opinions on that front.
- Is there a plan to eventually remove the opt-out option? Or is it
the plan to have it in place permanently?

 Cheers,
 Yoav


 On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:

> On 12/16/21 5:52 PM, Charlie Reis wrote:
>
>
>
> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
> blin...@chromium.org> wrote:
>
>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>> wrote:
>>
>>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>>
>>> It seems more or less everyone agrees on this being a good thing, so
>>> it mainly comes down to web compatibility.
>>>
>>> How much of the web will break, and how badly. The numbers
>>> mentioned, 0.5% of sites set document.domain, 0.05% seem to depend on
>>> document.domain, are quite high. One thing I didn't quite pick up is 
>>> what
>>> happens if you try to set document.domain when it's not settable. Will 
>>> it
>>> silently pretend to work, or will that also be a possible break point?
>>>
>>> I would be surprised if it didn't behave the same as setting an
>>> arbitrary expando on `document` - we should be safe there.
>>>
>>
>> Almost. The error handling is mostly the same. But while a foreign
>> attribute 

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

[Greg Whitworth]

Hey folks,

I'll be spinning up a thread with some internal folks here at Salesforce to 
start doing some scans of code to determine utilization. Has this been 
added to the reporting API for deprecation to possibly capture live hits 
that way as well?

I'll follow up on what I find and that will influence my opinion on removal 
timeline.

~Greg

On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:

> Note that Daniel has already landed the enterprise policy for this in 
> https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
> (99.0.4759.0).
>
> Charlie
>
> On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:
>
>> > This probably requires an Enterprise Policy, to reduce the risk for 
>> managed installs. +bheenan@ for opinions on that front.
>>
>> I agree, this looks like a breaking change according to 
>> go/chrome-enterprise-friendly and therefore needs a policy. Instructions 
>> for implementing a policy are here: 
>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>  
>> if you haven't done it before, and the enterprise team is happy to help if 
>> anything seems confusing. Having this implemented as a "soft removal" with 
>> a temporary policy escape hatch significantly reduces enterprise risk, 
>> since even if we are surprised by a use case hiding behind many 
>> enterprises' tendency to turn off metrics, those users can 
>> break-fix themselves immediately while staying on the latest version.
>>
>> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  wrote:
>>
>>> Hey Daniel!
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>- UKM and outreach to specific large users of the API can maybe help 
>>>drive the usage down.
>>>- A deprecation period of 3 milestones feels a bit short here. Is 
>>>the expectation that turning on the opt-out header can be done under 
>>> that 
>>>period?
>>>- A report-only mode could have allowed sites to try and enable 
>>>this, without risking actual breakage for their documents/properties 
>>> that 
>>>use document.domain. This is doubly true for platforms that want to warn 
>>>their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>on their behalf. At the same time, it is true that they could collect 
>>>deprecation reports (thanks for adding those!) instead during the 
>>>deprecation period, which can be considered an on-by-default report-only 
>>>mode. Can y'all add specific guidance on deprecation reports to the 
>>>documentation?
>>>-  It'd be helpful to reach out to enterprise folks and see what 
>>>their responses may be for this. +Greg Whitworth.
>>>- This probably requires an Enterprise Policy, to reduce the risk 
>>>for managed installs. +bheenan@ for opinions on that front.
>>>- Is there a plan to eventually remove the opt-out option? Or is it 
>>>the plan to have it in place permanently?
>>>
>>> Cheers,
>>> Yoav
>>>
>>>
>>> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>>>
 On 12/16/21 5:52 PM, Charlie Reis wrote:



 On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
 blin...@chromium.org> wrote:

> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  
> wrote:
>
>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>
>> It seems more or less everyone agrees on this being a good thing, so 
>> it mainly comes down to web compatibility.
>>
>> How much of the web will break, and how badly. The numbers mentioned, 
>> 0.5% of sites set document.domain, 0.05% seem to depend on 
>> document.domain, 
>> are quite high. One thing I didn't quite pick up is what happens if you 
>> try 
>> to set document.domain when it's not settable. Will it silently pretend 
>> to 
>> work, or will that also be a possible break point?
>>
>> I would be surprised if it didn't behave the same as setting an 
>> arbitrary expando on `document` - we should be safe there.
>>
>
> Almost. The error handling is mostly the same. But while a foreign 
> attribute on document would return the new value, document.domain (when 
> in 
> an origin-keyed agent cluster) does not.
>
> So:
>   document.foo = "bla"
>   document.foo  // Returns "bla".
>
>   document.domain 

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

[Charlie Reis]

Note that Daniel has already landed the enterprise policy for this in
https://chromium-review.googlesource.com/c/chromium/src/+/3317349
(99.0.4759.0).

Charlie

On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  wrote:

> > This probably requires an Enterprise Policy, to reduce the risk for
> managed installs. +bheenan@ for opinions on that front.
>
> I agree, this looks like a breaking change according to
> go/chrome-enterprise-friendly and therefore needs a policy. Instructions
> for implementing a policy are here:
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
> if you haven't done it before, and the enterprise team is happy to help if
> anything seems confusing. Having this implemented as a "soft removal" with
> a temporary policy escape hatch significantly reduces enterprise risk,
> since even if we are surprised by a use case hiding behind many
> enterprises' tendency to turn off metrics, those users can
> break-fix themselves immediately while staying on the latest version.
>
> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss 
> wrote:
>
>> Hey Daniel!
>>
>> While searching for this intent review, I stumbled upon
>> https://developer.chrome.com/blog/immutable-document-domain/
>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>
>> This intent was just discussed at the API owner meeting (where Chris,
>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>> This change seems risky in terms of potential breakage when looking at
>> our stats, and that's even before talking about enterprises, where a lot of
>> the API owners feel the risk is even higher.
>>
>> Given that, here's a few potential next steps to try and reduce that risk:
>>
>>- UKM and outreach to specific large users of the API can maybe help
>>drive the usage down.
>>- A deprecation period of 3 milestones feels a bit short here. Is the
>>expectation that turning on the opt-out header can be done under that
>>period?
>>- A report-only mode could have allowed sites to try and enable this,
>>without risking actual breakage for their documents/properties that use
>>document.domain. This is doubly true for platforms that want to warn their
>>customers about this upcoming deprecation, but without taking risks on
>>their behalf. At the same time, it is true that they could collect
>>deprecation reports (thanks for adding those!) instead during the
>>deprecation period, which can be considered an on-by-default report-only
>>mode. Can y'all add specific guidance on deprecation reports to the
>>documentation?
>>-  It'd be helpful to reach out to enterprise folks and see what
>>their responses may be for this. +Greg Whitworth.
>>- This probably requires an Enterprise Policy, to reduce the risk for
>>managed installs. +bheenan@ for opinions on that front.
>>- Is there a plan to eventually remove the opt-out option? Or is it
>>the plan to have it in place permanently?
>>
>> Cheers,
>> Yoav
>>
>>
>> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>>
>>> On 12/16/21 5:52 PM, Charlie Reis wrote:
>>>
>>>
>>>
>>> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
 wrote:

> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so
> it mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned,
> 0.5% of sites set document.domain, 0.05% seem to depend on 
> document.domain,
> are quite high. One thing I didn't quite pick up is what happens if you 
> try
> to set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
> I would be surprised if it didn't behave the same as setting an
> arbitrary expando on `document` - we should be safe there.
>

 Almost. The error handling is mostly the same. But while a foreign
 attribute on document would return the new value, document.domain (when in
 an origin-keyed agent cluster) does not.

 So:
   document.foo = "bla"
   document.foo  // Returns "bla".

   document.domain = "bla"  // Throws SecurityException.

   // On a domain www.host.com, site-keyed agent cluster (current
 default)
   document.domain = "host.com"  // Succeeds.
   document.domain;  // returns "host.com".

   // On a domain www.host.com, origin-keyed agent cluster (future
 default)
   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
 else either.
   document.domain;  // Still returns www.host.com.

 Risks: Interoperability and Compatibility
>
> * No interoperability risks. *
> Compatibility risk exists, but is 

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

['Brandon Heenan' via blink-dev]

> This probably requires an Enterprise Policy, to reduce the risk for
managed installs. +bheenan@ for opinions on that front.

I agree, this looks like a breaking change according to
go/chrome-enterprise-friendly and therefore needs a policy. Instructions
for implementing a policy are here:
https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
if you haven't done it before, and the enterprise team is happy to help if
anything seems confusing. Having this implemented as a "soft removal" with
a temporary policy escape hatch significantly reduces enterprise risk,
since even if we are surprised by a use case hiding behind many
enterprises' tendency to turn off metrics, those users can
break-fix themselves immediately while staying on the latest version.

On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  wrote:

> Hey Daniel!
>
> While searching for this intent review, I stumbled upon
> https://developer.chrome.com/blog/immutable-document-domain/
> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>
> This intent was just discussed at the API owner meeting (where Chris,
> Rego, Daniel, Philip, Alex, MikeT and myself were present).
> This change seems risky in terms of potential breakage when looking at our
> stats, and that's even before talking about enterprises, where a lot of the
> API owners feel the risk is even higher.
>
> Given that, here's a few potential next steps to try and reduce that risk:
>
>- UKM and outreach to specific large users of the API can maybe help
>drive the usage down.
>- A deprecation period of 3 milestones feels a bit short here. Is the
>expectation that turning on the opt-out header can be done under that
>period?
>- A report-only mode could have allowed sites to try and enable this,
>without risking actual breakage for their documents/properties that use
>document.domain. This is doubly true for platforms that want to warn their
>customers about this upcoming deprecation, but without taking risks on
>their behalf. At the same time, it is true that they could collect
>deprecation reports (thanks for adding those!) instead during the
>deprecation period, which can be considered an on-by-default report-only
>mode. Can y'all add specific guidance on deprecation reports to the
>documentation?
>-  It'd be helpful to reach out to enterprise folks and see what their
>responses may be for this. +Greg Whitworth.
>- This probably requires an Enterprise Policy, to reduce the risk for
>managed installs. +bheenan@ for opinions on that front.
>- Is there a plan to eventually remove the opt-out option? Or is it
>the plan to have it in place permanently?
>
> Cheers,
> Yoav
>
>
> On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:
>
>> On 12/16/21 5:52 PM, Charlie Reis wrote:
>>
>>
>>
>> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
>>> wrote:
>>>
 On 12/14/21 11:35 AM, Daniel Bratell wrote:

 It seems more or less everyone agrees on this being a good thing, so it
 mainly comes down to web compatibility.

 How much of the web will break, and how badly. The numbers mentioned,
 0.5% of sites set document.domain, 0.05% seem to depend on document.domain,
 are quite high. One thing I didn't quite pick up is what happens if you try
 to set document.domain when it's not settable. Will it silently pretend to
 work, or will that also be a possible break point?

 I would be surprised if it didn't behave the same as setting an
 arbitrary expando on `document` - we should be safe there.

>>>
>>> Almost. The error handling is mostly the same. But while a foreign
>>> attribute on document would return the new value, document.domain (when in
>>> an origin-keyed agent cluster) does not.
>>>
>>> So:
>>>   document.foo = "bla"
>>>   document.foo  // Returns "bla".
>>>
>>>   document.domain = "bla"  // Throws SecurityException.
>>>
>>>   // On a domain www.host.com, site-keyed agent cluster (current
>>> default)
>>>   document.domain = "host.com"  // Succeeds.
>>>   document.domain;  // returns "host.com".
>>>
>>>   // On a domain www.host.com, origin-keyed agent cluster (future
>>> default)
>>>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
>>> else either.
>>>   document.domain;  // Still returns www.host.com.
>>>
>>> Risks: Interoperability and Compatibility

 * No interoperability risks. *
 Compatibility risk exists, but is fairly small as document.domain is an
 already deprecated feature. We’ve detailed UKM metrics in place and are
 planning to reach out to top users as soon as we’ve LGTMs for the plan.

 As Daniel mentioned, I think the compat risk should be considered to be
 higher, despite this being deprecated for a long time.

>>>
>>> Yes, 

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

[Yoav Weiss]

Hey Daniel!

While searching for this intent review, I stumbled 
upon https://developer.chrome.com/blog/immutable-document-domain/ 
That's a useful piece of documentation! Thanks +Eiji Kitamura!!

This intent was just discussed at the API owner meeting (where Chris, Rego, 
Daniel, Philip, Alex, MikeT and myself were present).
This change seems risky in terms of potential breakage when looking at our 
stats, and that's even before talking about enterprises, where a lot of the 
API owners feel the risk is even higher.

Given that, here's a few potential next steps to try and reduce that risk:

   - UKM and outreach to specific large users of the API can maybe help 
   drive the usage down.
   - A deprecation period of 3 milestones feels a bit short here. Is the 
   expectation that turning on the opt-out header can be done under that 
   period?
   - A report-only mode could have allowed sites to try and enable this, 
   without risking actual breakage for their documents/properties that use 
   document.domain. This is doubly true for platforms that want to warn their 
   customers about this upcoming deprecation, but without taking risks on 
   their behalf. At the same time, it is true that they could collect 
   deprecation reports (thanks for adding those!) instead during the 
   deprecation period, which can be considered an on-by-default report-only 
   mode. Can y'all add specific guidance on deprecation reports to the 
   documentation?
   -  It'd be helpful to reach out to enterprise folks and see what their 
   responses may be for this. +Greg Whitworth.
   - This probably requires an Enterprise Policy, to reduce the risk for 
   managed installs. +bheenan@ for opinions on that front.
   - Is there a plan to eventually remove the opt-out option? Or is it the 
   plan to have it in place permanently?
   
Cheers,
Yoav


On Saturday, December 18, 2021 at 9:38:33 PM UTC+1 Mike Taylor wrote:

> On 12/16/21 5:52 PM, Charlie Reis wrote:
>
>
>
> On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  
>> wrote:
>>
>>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>>
>>> It seems more or less everyone agrees on this being a good thing, so it 
>>> mainly comes down to web compatibility.
>>>
>>> How much of the web will break, and how badly. The numbers mentioned, 
>>> 0.5% of sites set document.domain, 0.05% seem to depend on document.domain, 
>>> are quite high. One thing I didn't quite pick up is what happens if you try 
>>> to set document.domain when it's not settable. Will it silently pretend to 
>>> work, or will that also be a possible break point?
>>>
>>> I would be surprised if it didn't behave the same as setting an 
>>> arbitrary expando on `document` - we should be safe there.
>>>
>>
>> Almost. The error handling is mostly the same. But while a foreign 
>> attribute on document would return the new value, document.domain (when in 
>> an origin-keyed agent cluster) does not.
>>
>> So:
>>   document.foo = "bla"
>>   document.foo  // Returns "bla".
>>
>>   document.domain = "bla"  // Throws SecurityException.
>>
>>   // On a domain www.host.com, site-keyed agent cluster (current default)
>>   document.domain = "host.com"  // Succeeds.
>>   document.domain;  // returns "host.com".
>>
>>   // On a domain www.host.com, origin-keyed agent cluster (future 
>> default)
>>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything 
>> else either.
>>   document.domain;  // Still returns www.host.com.
>>
>> Risks: Interoperability and Compatibility 
>>>
>>> * No interoperability risks. * 
>>> Compatibility risk exists, but is fairly small as document.domain is an 
>>> already deprecated feature. We’ve detailed UKM metrics in place and are 
>>> planning to reach out to top users as soon as we’ve LGTMs for the plan. 
>>>
>>> As Daniel mentioned, I think the compat risk should be considered to be 
>>> higher, despite this being deprecated for a long time.
>>>
>>
>> Yes, agreed.
>>
>>> Current usage of the document.domain: 0.05% 
>>>  of 
>>> page views rely upon document.domain to enable some cross-origin access 
>>> that wasn't otherwise possible. 0.24% 
>>>  of 
>>> page views block same-origin access because only one side sets 
>>> document.domain. Both counters can be found on 
>>> https://deprecate.it/#document-domain, too.
>>>
>>> (cool site, btw)
>>>
>>> We’ve reached out in advance to 4 of the top current users - TL;DR Most 
>>> of their use cases could be achieved already by different APIs e.g. 
>>> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support 
>>> chat deployed across subdomains.
>>>
>>> Out of curiosity, did any of them mention what couldn't be achieved via 
>>> existing APIs?
>>>
>>
>> I checked back, and nothing particular came 

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

[Mike Taylor]

On 12/16/21 5:52 PM, Charlie Reis wrote:



On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev 
 wrote:


On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor
 wrote:

On 12/14/21 11:35 AM, Daniel Bratell wrote:


It seems more or less everyone agrees on this being a good
thing, so it mainly comes down to web compatibility.

How much of the web will break, and how badly. The numbers
mentioned, 0.5% of sites set document.domain, 0.05% seem to
depend on document.domain, are quite high. One thing I didn't
quite pick up is what happens if you try to set
document.domain when it's not settable. Will it silently
pretend to work, or will that also be a possible break point?


I would be surprised if it didn't behave the same as setting
an arbitrary expando on `document` - we should be safe there.


Almost. The error handling is mostly the same. But while a foreign
attribute on document would return the new value, document.domain
(when in an origin-keyed agent cluster) does not.

So:
  document.foo = "bla"
  document.foo  // Returns "bla".

  document.domain = "bla"  // Throws SecurityException.

  // On a domain www.host.com , site-keyed
agent cluster (current default)
  document.domain = "host.com " // Succeeds.
  document.domain;  // returns "host.com ".

  // On a domain www.host.com , origin-keyed
agent cluster (future default)
  document.domain = "host.com " // Doesn't throw.
Doesn't do anything else either.
  document.domain;  // Still returns www.host.com
.



Risks: Interoperability and Compatibility


*

No interoperability risks.

*


Compatibility risk exists, but is fairly small as
document.domain is an already deprecated feature. We’ve
detailed UKM metrics in place and are planning to reach out
to top users as soon as we’ve LGTMs for the plan.

As Daniel mentioned, I think the compat risk should be
considered to be higher, despite this being deprecated for a
long time.


Yes, agreed.



*

*

Current usage of the document.domain: 0.05%
of
page views rely upon document.domain to enable some
cross-origin access that wasn't otherwise possible. 0.24%
of
page views block same-origin access because only one side
sets document.domain. Both counters can be found
onhttps://deprecate.it/#document-domain
, too.

(cool site, btw)

We’ve reached out in advance to 4 of the top current users -
TL;DR Most of their use cases could be achieved already by
different APIs e.g. Audio/video autoplay in iframes by
adding the ‘autoplay’ attribute, support chat deployed
across subdomains.

Out of curiosity, did any of them mention what couldn't be
achieved via existing APIs?


I checked back, and nothing particular came up. It seems that
migrating off of document.domain isn't blocked by a lack of options.


Activation - Deprecation plan
M98 - Add the devtools issue and warning incl. a web.dev
 blog post to guide adoption


*

M98-M100 - Monitor use counters and reach out to
current users

*


What's the plan if the use counters don't move? Do you have a
minimum page view % in mind you would want before proceeding
to the next step (even if it meant delaying the timeline)?


We don't have a dead-set plan. The primary idea is a combination
of delay-ing until usage is low enough, and outreach to offending
sites to educate about the problem & available alternatives.



*

M101 - Deprecate the feature by default. No
reverse-origin trial is planned as the
‘Origin-Agent-Cluster’ http header can be used to
gain access to the feature.

*


Would this disabled-by-default change ride the trains, or have
you considered finching it out to assess compat risk?


My original plan was to enable it by default in the 101 release,
and have a Finch switch as an emergency-off. Reading the feedback
here, maybe it's better to incrementally enable it via Finch. I'll
be happy to follow whatever path API owners prefer.


In my experience (caveat: I'm not an API owner), it's harder to repro 
and triage compatibility bugs that get filed if a 

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

[Charlie Reis]

On Thu, Dec 16, 2021 at 7:28 AM 'Daniel Vogelheim' via blink-dev <
blink-dev@chromium.org> wrote:

> On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor 
> wrote:
>
>> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>>
>> It seems more or less everyone agrees on this being a good thing, so it
>> mainly comes down to web compatibility.
>>
>> How much of the web will break, and how badly. The numbers mentioned,
>> 0.5% of sites set document.domain, 0.05% seem to depend on document.domain,
>> are quite high. One thing I didn't quite pick up is what happens if you try
>> to set document.domain when it's not settable. Will it silently pretend to
>> work, or will that also be a possible break point?
>>
>> I would be surprised if it didn't behave the same as setting an arbitrary
>> expando on `document` - we should be safe there.
>>
>
> Almost. The error handling is mostly the same. But while a foreign
> attribute on document would return the new value, document.domain (when in
> an origin-keyed agent cluster) does not.
>
> So:
>   document.foo = "bla"
>   document.foo  // Returns "bla".
>
>   document.domain = "bla"  // Throws SecurityException.
>
>   // On a domain www.host.com, site-keyed agent cluster (current default)
>   document.domain = "host.com"  // Succeeds.
>   document.domain;  // returns "host.com".
>
>   // On a domain www.host.com, origin-keyed agent cluster (future default)
>   document.domain = "host.com"  // Doesn't throw. Doesn't do anything
> else either.
>   document.domain;  // Still returns www.host.com.
>
> Risks: Interoperability and Compatibility
>>
>> * No interoperability risks. *
>> Compatibility risk exists, but is fairly small as document.domain is an
>> already deprecated feature. We’ve detailed UKM metrics in place and are
>> planning to reach out to top users as soon as we’ve LGTMs for the plan.
>>
>> As Daniel mentioned, I think the compat risk should be considered to be
>> higher, despite this being deprecated for a long time.
>>
>
> Yes, agreed.
>
>> Current usage of the document.domain: 0.05%
>>  of
>> page views rely upon document.domain to enable some cross-origin access
>> that wasn't otherwise possible. 0.24%
>>  of
>> page views block same-origin access because only one side sets
>> document.domain. Both counters can be found on
>> https://deprecate.it/#document-domain, too.
>>
>> (cool site, btw)
>>
>> We’ve reached out in advance to 4 of the top current users - TL;DR Most
>> of their use cases could be achieved already by different APIs e.g.
>> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support
>> chat deployed across subdomains.
>>
>> Out of curiosity, did any of them mention what couldn't be achieved via
>> existing APIs?
>>
>
> I checked back, and nothing particular came up. It seems that migrating
> off of document.domain isn't blocked by a lack of options.
>
> Activation - Deprecation plan
>> M98 - Add the devtools issue and warning incl. a web.dev blog post to
>> guide adoption
>>
>> * M98-M100 - Monitor use counters and reach out to current users *
>>
>> What's the plan if the use counters don't move? Do you have a minimum
>> page view % in mind you would want before proceeding to the next step (even
>> if it meant delaying the timeline)?
>>
>
> We don't have a dead-set plan. The primary idea is a combination of
> delay-ing until usage is low enough, and outreach to offending sites to
> educate about the problem & available alternatives.
>
>
>
>> * M101 - Deprecate the feature by default. No reverse-origin trial is
>> planned as the ‘Origin-Agent-Cluster’ http header can be used to gain
>> access to the feature. *
>>
>> Would this disabled-by-default change ride the trains, or have you
>> considered finching it out to assess compat risk?
>>
>
> My original plan was to enable it by default in the 101 release, and have
> a Finch switch as an emergency-off. Reading the feedback here, maybe it's
> better to incrementally enable it via Finch. I'll be happy to follow
> whatever path API owners prefer.
>

In my experience (caveat: I'm not an API owner), it's harder to repro and
triage compatibility bugs that get filed if a feature is only enabled for a
percentage of users via Finch.  It tends to be quicker to bisect reports
and get attention on a compat bug if the feature is enabled on trunk
instead, with an easy way to revert if needed.  (Finch is certainly better
when you care about performance issues, which doesn't seem to be the case
here.)

Charlie


> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> 

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

['Daniel Vogelheim' via blink-dev]

On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  wrote:

> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so it
> mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned, 0.5%
> of sites set document.domain, 0.05% seem to depend on document.domain, are
> quite high. One thing I didn't quite pick up is what happens if you try to
> set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
> I would be surprised if it didn't behave the same as setting an arbitrary
> expando on `document` - we should be safe there.
>

Almost. The error handling is mostly the same. But while a foreign
attribute on document would return the new value, document.domain (when in
an origin-keyed agent cluster) does not.

So:
  document.foo = "bla"
  document.foo  // Returns "bla".

  document.domain = "bla"  // Throws SecurityException.

  // On a domain www.host.com, site-keyed agent cluster (current default)
  document.domain = "host.com"  // Succeeds.
  document.domain;  // returns "host.com".

  // On a domain www.host.com, origin-keyed agent cluster (future default)
  document.domain = "host.com"  // Doesn't throw. Doesn't do anything else
either.
  document.domain;  // Still returns www.host.com.

Risks: Interoperability and Compatibility
>
> * No interoperability risks. *
> Compatibility risk exists, but is fairly small as document.domain is an
> already deprecated feature. We’ve detailed UKM metrics in place and are
> planning to reach out to top users as soon as we’ve LGTMs for the plan.
>
> As Daniel mentioned, I think the compat risk should be considered to be
> higher, despite this being deprecated for a long time.
>

Yes, agreed.

> Current usage of the document.domain: 0.05%
>  of
> page views rely upon document.domain to enable some cross-origin access
> that wasn't otherwise possible. 0.24%
>  of
> page views block same-origin access because only one side sets
> document.domain. Both counters can be found on
> https://deprecate.it/#document-domain, too.
>
> (cool site, btw)
>
> We’ve reached out in advance to 4 of the top current users - TL;DR Most of
> their use cases could be achieved already by different APIs e.g.
> Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support
> chat deployed across subdomains.
>
> Out of curiosity, did any of them mention what couldn't be achieved via
> existing APIs?
>

I checked back, and nothing particular came up. It seems that migrating off
of document.domain isn't blocked by a lack of options.

Activation - Deprecation plan
> M98 - Add the devtools issue and warning incl. a web.dev blog post to
> guide adoption
>
> * M98-M100 - Monitor use counters and reach out to current users *
>
> What's the plan if the use counters don't move? Do you have a minimum page
> view % in mind you would want before proceeding to the next step (even if
> it meant delaying the timeline)?
>

We don't have a dead-set plan. The primary idea is a combination of
delay-ing until usage is low enough, and outreach to offending sites to
educate about the problem & available alternatives.



> * M101 - Deprecate the feature by default. No reverse-origin trial is
> planned as the ‘Origin-Agent-Cluster’ http header can be used to gain
> access to the feature. *
>
> Would this disabled-by-default change ride the trains, or have you
> considered finching it out to assess compat risk?
>

My original plan was to enable it by default in the 101 release, and have a
Finch switch as an emergency-off. Reading the feedback here, maybe it's
better to incrementally enable it via Finch. I'll be happy to follow
whatever path API owners prefer.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOOVfCH42eaBeoGCn6KCKjOvoJa1ZY4wY8%3DXHooVytAiA%40mail.gmail.com.

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

[Daniel Vogelheim]

>
> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so it
> mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned, 0.5%
> of sites set document.domain, 0.05% seem to depend on document.domain, are
> quite high. One thing I didn't quite pick up is what happens if you try to
> set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
>
It does nothing, silently. This matches the behaviour when
Origin-Agent-Cluster is explicitly set to true. From a developer's
perspective, the current default matches explicit-false and the future
default is meant to match explicit-true.

Reference: Step 7 of "The domain setter steps are" of
https://html.spec.whatwg.org/multipage/origin.html#dom-document-domain.

There is also the question of reverse origin trial and enterprise flags. If
> Origin-Agent-Cluster can be set with , then I don't
> see any use for an origin trial since that would be activated the same way.
> An enterprise flag might still be needed though, since that covers
> installations where the client can be configured, but applications can not
> be changed.
>
>
An enterprise policy has been implemented

.
We didn't think a reverse origin trial would make sense, since any site can
already opt-out by setting the Origin-Agent-Cluster header.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOae7vcJmfZBJUZFMbLk7qrcxa0ot%2BLnTJF25rqHp2_kg%40mail.gmail.com.

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

[Yoav Weiss]

On Tue, Dec 14, 2021 at 11:51 PM Mike Taylor  wrote:

> On 12/14/21 11:35 AM, Daniel Bratell wrote:
>
> It seems more or less everyone agrees on this being a good thing, so it
> mainly comes down to web compatibility.
>
> How much of the web will break, and how badly. The numbers mentioned, 0.5%
> of sites set document.domain, 0.05% seem to depend on document.domain, are
> quite high. One thing I didn't quite pick up is what happens if you try to
> set document.domain when it's not settable. Will it silently pretend to
> work, or will that also be a possible break point?
>
> I would be surprised if it didn't behave the same as setting an arbitrary
> expando on `document` - we should be safe there.
>

https://github.com/WICG/origin-agent-cluster#no-op-documentdomain-setter-instead-of-throwing
suggests you're right.

Also - TIL https://developer.mozilla.org/en-US/docs/Glossary/Expando

> There is also the question of reverse origin trial and enterprise flags.
> If Origin-Agent-Cluster can be set with , then I
> don't see any use for an origin trial since that would be activated the
> same way. An enterprise flag might still be needed though, since that
> covers installations where the client can be configured, but applications
> can not be changed.
>
> I'd be surprised if meta http-equiv is supported, as IIUC, the decision on
an agent cluster needs to be made before the document is committed, hence
the opt-in can't be made available to markup.
I'm guessing the same would be true for a deprecation trial (as a result,
there's no difference between one and the header based opt-in).


> /Daniel
> On 2021-12-14 15:06, Daniel Vogelheim wrote:
>
> Contact emails
>
>
> * v...@chromium.org , vogelh...@chromium.org
>  * Specification
>
>
> * Explainer: https://github.com/mikewest/deprecating-document-domain
>  HTML Spec draft:
> https://github.com/whatwg/html/compare/main...otherdaniel:dd
>  * API spec
>
>
> * Yes * Summary
>
>
>
>
>
>
>
> * Change the default behavior of the Origin-Agent-Cluster: header /
> document.domain settability. Presently, pages within Chromium have
> site-keyed agent clusters by default, unless the Origin-Agent-Cluster:
> header is explicitly set to true. This accommodates pages or frames which
> want to access each other's state, despite being on different origins (but
> within a site). This is fine for any pages that wish to do so, but because
> a page *might* set document.domain later on, Chromium currently must use
> site-keyed agent clusters for *all* pages by default even though the
> overwhelming majority of pages do not ever make use of this (mis-)feature.
> In turn, this requires Chromium to use sites as the basis for renderer
> process isolation (via Site Isolation), which exposes origins to same-site
> but cross-origin attacks involving compromised renderer processes or the
> "Spectre" family of side-channel attacks. This proposal changes the default
> behaviour of Origin-Agent-Cluster. From a developer's point of view, the
> new default matches "Origin-Agent-Cluster: ?1". The initial implementation
> will use origin-keyed agent clusters for all (non-opted out) origins,
> without changing how many processes Chromium creates. Over time, we can
> then adapt Chromium's isolation strategy towards origin-keyed processes
> without further affecting web-visible behaviour. The developer-visible
> aspect of this is that for pages with origin-keyed agent clusters,
> document.domain is no longer settable. Thus, we have marked this intent as
> a deprecation. Note that this proposal is about the default. Both modes -
> site-keyed or origin-keyed agent clusters - remain available to any site,
> but origin-keyed agent clusters change from opt-in to opt-out. The current
> behaviour remains available by setting "Origin-Agent-Cluster: ?0". * Blink
> component
>
>
> * Blink>SecurityFeature * TAG review
>
>
> * https://github.com/w3ctag/design-reviews/issues/564
>  (The thread is a bit
> unwieldy, but there do not seem to be open issues.) * Risks:
> Interoperability and Compatibility
>
> * No interoperability risks. *
> Compatibility risk exists, but is fairly small as document.domain is an
> already deprecated feature. We’ve detailed UKM metrics in place and are
> planning to reach out to top users as soon as we’ve LGTMs for the plan.
>
> As Daniel mentioned, I think the compat risk should be considered to be
> higher, despite this being deprecated for a long time.
>
> Current usage of the document.domain: 0.05%
>  of
> page views rely upon document.domain to enable some cross-origin access
> that wasn't otherwise possible. 0.24%
>  of
> page views block same-origin access because only one side sets

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

[Mike Taylor]

On 12/14/21 11:35 AM, Daniel Bratell wrote:


It seems more or less everyone agrees on this being a good thing, so 
it mainly comes down to web compatibility.


How much of the web will break, and how badly. The numbers mentioned, 
0.5% of sites set document.domain, 0.05% seem to depend on 
document.domain, are quite high. One thing I didn't quite pick up is 
what happens if you try to set document.domain when it's not settable. 
Will it silently pretend to work, or will that also be a possible 
break point?


I would be surprised if it didn't behave the same as setting an 
arbitrary expando on `document` - we should be safe there.


There is also the question of reverse origin trial and enterprise 
flags. If Origin-Agent-Cluster can be set with http-equiv="">, then I don't see any use for an origin trial since 
that would be activated the same way. An enterprise flag might still 
be needed though, since that covers installations where the client can 
be configured, but applications can not be changed.


/Daniel

On 2021-12-14 15:06, Daniel Vogelheim wrote:



Contact emails


*

v...@chromium.org ,
vogelh...@chromium.org


*


Specification


*

Explainer:
https://github.com/mikewest/deprecating-document-domain

HTML Spec draft:
https://github.com/whatwg/html/compare/main...otherdaniel:dd



*


API spec


*

Yes


*


Summary


*

Change the default behavior of the Origin-Agent-Cluster:
header / document.domain settability.


Presently, pages within Chromium have site-keyed agent
clusters by default, unless the Origin-Agent-Cluster: header
is explicitly set to true. This accommodates pages or frames
which want to access each other's state, despite being on
different origins (but within a site). This is fine for any
pages that wish to do so, but because a page *might* set
document.domain later on, Chromium currently must use
site-keyed agent clusters for *all* pages by default even
though the overwhelming majority of pages do not ever make
use of this (mis-)feature. In turn, this requires Chromium to
use sites as the basis for renderer process isolation (via
Site Isolation), which exposes origins to same-site but
cross-origin attacks involving compromised renderer processes
or the "Spectre" family of side-channel attacks.


This proposal changes the default behaviour of
Origin-Agent-Cluster. From a developer's point of view, the
new default matches "Origin-Agent-Cluster: ?1". The initial
implementation will use origin-keyed agent clusters for all
(non-opted out) origins, without changing how many processes
Chromium creates. Over time, we can then adapt Chromium's
isolation strategy towards origin-keyed processes without
further affecting web-visible behaviour.


The developer-visible aspect of this is that for pages with
origin-keyed agent clusters, document.domain is no longer
settable. Thus, we have marked this intent as a deprecation.


Note that this proposal is about the default. Both modes -
site-keyed or origin-keyed agent clusters - remain available
to any site, but origin-keyed agent clusters change from
opt-in to opt-out. The current behaviour remains available by
setting "Origin-Agent-Cluster: ?0".



*


Blink component


*

Blink>SecurityFeature


*


TAG review


*

https://github.com/w3ctag/design-reviews/issues/564


(The thread is a bit unwieldy, but there do not seem to be
open issues.)


*


Risks: Interoperability and Compatibility


*

No interoperability risks.

*


Compatibility risk exists, but is fairly small as document.domain is 
an already deprecated feature. We’ve detailed UKM metrics in place 
and are planning to reach out to top users as soon as we’ve LGTMs for 
the plan.
As Daniel mentioned, I think the compat risk should be considered to be 
higher, despite this being deprecated for a long time.



*

*

Current usage of the document.domain: 0.05% 
of 
page views rely upon document.domain to enable some cross-origin 
access that wasn't otherwise possible. 0.24% 
of 
page views block same-origin access because only one side sets 
document.domain. Both counters can be found 
onhttps://deprecate.it/#document-domain 

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

[Daniel Bratell]

It seems more or less everyone agrees on this being a good thing, so it 
mainly comes down to web compatibility.


How much of the web will break, and how badly. The numbers mentioned, 
0.5% of sites set document.domain, 0.05% seem to depend on 
document.domain, are quite high. One thing I didn't quite pick up is 
what happens if you try to set document.domain when it's not settable. 
Will it silently pretend to work, or will that also be a possible break 
point?


There is also the question of reverse origin trial and enterprise flags. 
If Origin-Agent-Cluster can be set with , then I 
don't see any use for an origin trial since that would be activated the 
same way. An enterprise flag might still be needed though, since that 
covers installations where the client can be configured, but 
applications can not be changed.


/Daniel

On 2021-12-14 15:06, Daniel Vogelheim wrote:



Contact emails


*

v...@chromium.org ,
vogelh...@chromium.org


*


Specification


*

Explainer: https://github.com/mikewest/deprecating-document-domain

HTML Spec draft:
https://github.com/whatwg/html/compare/main...otherdaniel:dd



*


API spec


*

Yes


*


Summary


*

Change the default behavior of the Origin-Agent-Cluster:
header / document.domain settability.


Presently, pages within Chromium have site-keyed agent
clusters by default, unless the Origin-Agent-Cluster: header
is explicitly set to true. This accommodates pages or frames
which want to access each other's state, despite being on
different origins (but within a site). This is fine for any
pages that wish to do so, but because a page *might* set
document.domain later on, Chromium currently must use
site-keyed agent clusters for *all* pages by default even
though the overwhelming majority of pages do not ever make use
of this (mis-)feature. In turn, this requires Chromium to use
sites as the basis for renderer process isolation (via Site
Isolation), which exposes origins to same-site but
cross-origin attacks involving compromised renderer processes
or the "Spectre" family of side-channel attacks.


This proposal changes the default behaviour of
Origin-Agent-Cluster. From a developer's point of view, the
new default matches "Origin-Agent-Cluster: ?1". The initial
implementation will use origin-keyed agent clusters for all
(non-opted out) origins, without changing how many processes
Chromium creates. Over time, we can then adapt Chromium's
isolation strategy towards origin-keyed processes without
further affecting web-visible behaviour.


The developer-visible aspect of this is that for pages with
origin-keyed agent clusters, document.domain is no longer
settable. Thus, we have marked this intent as a deprecation.


Note that this proposal is about the default. Both modes -
site-keyed or origin-keyed agent clusters - remain available
to any site, but origin-keyed agent clusters change from
opt-in to opt-out. The current behaviour remains available by
setting "Origin-Agent-Cluster: ?0".



*


Blink component


*

Blink>SecurityFeature


*


TAG review


*

https://github.com/w3ctag/design-reviews/issues/564


(The thread is a bit unwieldy, but there do not seem to be
open issues.)


*


Risks: Interoperability and Compatibility


*

No interoperability risks.

*


Compatibility risk exists, but is fairly small as document.domain is 
an already deprecated feature. We’ve detailed UKM metrics in place and 
are planning to reach out to top users as soon as we’ve LGTMs for the 
plan.



*

*

Current usage of the document.domain: 0.05% 
of 
page views rely upon document.domain to enable some cross-origin 
access that wasn't otherwise possible. 0.24% 
of 
page views block same-origin access because only one side sets 
document.domain. Both counters can be found 
onhttps://deprecate.it/#document-domain 
, too.
We’ve reached out in advance to 4 of the top current users - TL;DR 
Most of their use cases could be achieved already by different APIs 
e.g. Audio/video autoplay in iframes by adding the ‘autoplay’ 
attribute, support chat deployed across subdomains.
Gecko: Standards position request 

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

[Daniel Vogelheim]

Contact emails


*v...@chromium.org , vogelh...@chromium.org
*Specification


*Explainer: https://github.com/mikewest/deprecating-document-domain
HTML Spec draft:
https://github.com/whatwg/html/compare/main...otherdaniel:dd
*API spec


*Yes*Summary







*Change the default behavior of the Origin-Agent-Cluster: header /
document.domain settability.Presently, pages within Chromium have
site-keyed agent clusters by default, unless the Origin-Agent-Cluster:
header is explicitly set to true. This accommodates pages or frames which
want to access each other's state, despite being on different origins (but
within a site). This is fine for any pages that wish to do so, but because
a page *might* set document.domain later on, Chromium currently must use
site-keyed agent clusters for *all* pages by default even though the
overwhelming majority of pages do not ever make use of this (mis-)feature.
In turn, this requires Chromium to use sites as the basis for renderer
process isolation (via Site Isolation), which exposes origins to same-site
but cross-origin attacks involving compromised renderer processes or the
"Spectre" family of side-channel attacks.This proposal changes the default
behaviour of Origin-Agent-Cluster. From a developer's point of view, the
new default matches "Origin-Agent-Cluster: ?1". The initial implementation
will use origin-keyed agent clusters for all (non-opted out) origins,
without changing how many processes Chromium creates. Over time, we can
then adapt Chromium's isolation strategy towards origin-keyed processes
without further affecting web-visible behaviour.The developer-visible
aspect of this is that for pages with origin-keyed agent clusters,
document.domain is no longer settable. Thus, we have marked this intent as
a deprecation.Note that this proposal is about the default. Both modes -
site-keyed or origin-keyed agent clusters - remain available to any site,
but origin-keyed agent clusters change from opt-in to opt-out. The current
behaviour remains available by setting "Origin-Agent-Cluster: ?0".*Blink
component


*Blink>SecurityFeature*TAG review


*https://github.com/w3ctag/design-reviews/issues/564
(The thread is a bit
unwieldy, but there do not seem to be open issues.)*Risks: Interoperability
and Compatibility

*No interoperability risks.*

Compatibility risk exists, but is fairly small as document.domain is an
already deprecated feature. We’ve detailed UKM metrics in place and are
planning to reach out to top users as soon as we’ve LGTMs for the plan.


Current usage of the document.domain: 0.05%
 of page
views rely upon document.domain to enable some cross-origin access that
wasn't otherwise possible. 0.24%
 of page
views block same-origin access because only one side sets document.domain.
Both counters can be found on https://deprecate.it/#document-domain, too.

We’ve reached out in advance to 4 of the top current users - TL;DR Most of
their use cases could be achieved already by different APIs e.g.
Audio/video autoplay in iframes by adding the ‘autoplay’ attribute, support
chat deployed across subdomains.


Gecko: Standards position request
. (Provisionally
"worth prototyping", but is open for additional comments/opinions. Mozilla
representatives also participated in the TAG discussion. No concrete
implementation plans were given.

WebKit:
https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html (No
signals.)

Web developers: No signals.

Activation - Deprecation plan
M98 - Add the devtools issue and warning incl. a web.dev blog post to guide
adoption

*M98-M100 - Monitor use counters and reach out to current usersM101 -
Deprecate the feature by default. No reverse-origin trial is planned as the
‘Origin-Agent-Cluster’ http header can be used to gain access to the
feature. SecurityThis change should be security-positive, since setting the
document.domain will not have any impact on the origin of the document any
more.*
Debuggability


*A deprecation warning will be added to DevTools console and to the issues
panel in M98, which will support current users to adopt. This warning will
file a deprecation report as well using the Reporting API, if so
configured.*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


*Yes*Is this feature fully tested by web-platform-tests

?


*Are in place to test the current functionality
, and
will be adjusted within the M101 timeframe to ensure