Re: [blink-dev] Intent to Prototype: Web Translation API

['Daniel Vogelheim' via blink-dev]

Hi Domenic, et al.,

This intent came up in the OWP sec review today. We wonder whether there's
XSS potential, and how input with plain text interspersed with tags is
meant to be handled:

Several of the use cases seem to hint at the input being HTML strings (e.g.
"pages with complicated DOM"). If the intended input would indeed be HTML
strings, and the output is intended to be parsed & inserted into the DOM,
then this basically implements a new XSS factory. In addition to the
existing re-parsing risks, it would add new ones based on translation (e.g.
"" turning into "

Re: [blink-dev] Intent to Ship: Document rules, response header, eagerness

['Daniel Vogelheim' via blink-dev]

Hi Jeremy,

On Thu, Nov 16, 2023 at 12:33 AM Jeremy Roman  wrote:

> (3) Currently developers can only specify speculation rules using inline
> script tags.  The proposed feature provides an alternative through the
> "Speculation-Rules" header. Its value must be a URL to a text resource with
> "application/speculationrules+json" MIME type. The resource's rules will be
> added to the document's rule set.
>

Is the URL from the speculation rules header restricted to same-origin
resources?

The examples seem to assume so; but I couldn't find any definite statement.
The header parsing code reads to me like it would allow arbitrary URLs
(cross-origin; or mixed http/https). Is this the intent?

-- 
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/CALG6KPOmdn2FiQKjHfCahooU_sARXz_gwGdw8-X8LQ%2B2%2BMFzhg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Deprecate: Remove "Sanitizer API MVP"

['Daniel Vogelheim' via blink-dev]

nteroperable implementation quickly and am
>>>> more supportive than Alex is of the idea that API shapes sometimes need to
>>>> change to get to consensus. Our compat principles
>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.enldekz90vw>
>>>> also say "Sometimes Blink chooses explicitly to ship despite higher interop
>>>> risk, and we accept responsibility for that risk by being more willing to
>>>> take on compat risk in the future if the consensus of the web platform
>>>> community is that the API should change.".
>>>>
>>>> But, like Alex, I also don't like the precedent of unshipping an
>>>> imperfect API while the replacement is still under design debate and also
>>>> not shipped in any other engine. Typically the above principle is used to
>>>> apply after some other engine has shipped an API they feel is better, and
>>>> we move to it in the name of interop. How quickly do we think we could ship
>>>> the new API and Frederik, do you have a timeline for when you think Firefox
>>>> might be able to ship it too? To what extent would it increase the
>>>> engineering costs for your team Daniel to have both forms shipping
>>>> simultaneously vs. removing the old one prior to shipping the new one?
>>>>
>>>> Is this
>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3814>
>>>> the right graph for the Sanitizer API UseCounter? Other than a temporary
>>>> bump (one popular site perhaps?) it doesn't seem to be growing too quickly
>>>> despite being in Chrome for a year. If we're actually on a near-term path
>>>> to consensus and multi-engine support, would a couple more months of the
>>>> old API existing really add much risk? If usage is non-zero (regardless how
>>>> small) I always think it's a more defensible position with web developers
>>>> to say we're removing something because a better alternative has shipped in
>>>> Chrome for at least one milestone (even if "better" is mostly limited to
>>>> "likely to also have support in Firefox").
>>>>
>>>> Rick
>>>>
>>>> On Tue, Aug 22, 2023 at 6:54 AM Yoav Weiss 
>>>> wrote:
>>>>
>>> LGTM2
>>>>>
>>>>> On Mon, Aug 21, 2023 at 6:17 PM Chris Harrelson 
>>>>> wrote:
>>>>>
>>>> LGTM1 to remove in favor of a revised, interoperable AIP in the future.
>>>>>>
>>>>>> On Mon, Aug 21, 2023 at 6:38 AM 'Daniel Vogelheim' via blink-dev <
>>>>>> blin...@chromium.org> wrote:
>>>>>>
>>>>> Hi Luke & Thomas,
>>>>>>>
>>>>>>> On Wed, Aug 16, 2023 at 12:49 PM Thomas Steiner 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Adding in Jack as the author of the mentioned article at
>>>>>>>> https://web.dev/sanitizer/. It might be worthwhile to add a big
>>>>>>>> red warning aside.
>>>>>>>>
>>>>>>>> On Tue, Aug 15, 2023, 23:37 Luke  wrote:
>>>>>>>>
>>>>>>>>> Just to chime in here. If there's a chance this API is going to be
>>>>>>>>> removed or even heavily changed its potentially worth making an 
>>>>>>>>> effort to
>>>>>>>>> take down any documentation regarding it to try to prevent any chance 
>>>>>>>>> of
>>>>>>>>> its usage going up. For example the mdn page on it seems an easy one 
>>>>>>>>> to
>>>>>>>>> remove. Likewise the web.dev article. This may not be as
>>>>>>>>> important if the usage is far below any thresholds.
>>>>>>>>>
>>>>>>>>
>>>>>>> Yes, noted and agreed. Adjusting or even removing the docs has come
>>>>>>> up before, and I hesitated to act on it because we didn't yet have 
>>>>>>> clarity
>>>>>>> on how to proceed with the Sanitizer API. The reason for writing this
>>>>>>> intent-to-deprecate is to get agreement on how to proceed, and to decide
>>>>>>> whether we'll keep supporting the current API in 

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

Hello all, it's been a while.

On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson 
wrote:

> LGTM1 to turn it on in M118 beta and report back to this group about use
> counter results/bugs reported on beta before it reaches stable.
>

As requested, I have added use counters to measure ORB-blocked resources on
elements (script and img/video/media) with event handlers. On current
stable, I get this: (source
<https://uma.googleplex.com/p/chrome/timeline_v2?sid=064bd3472f5dfd2a92f8d34049e5848e>
)

-  0.006% of page loads have a script or media element with an event
handler (and thus potential compatibility impact from this change; although
we don't know what the impact would be)
- 0.0075 % of page loads have a script or media element without any event
handlers (and thus guaranteed without compatibility impact from this change)
- The majority of pages with any event handler seem to have both handlers -
onload and onerror - set.

I'll note that the sum of those (with any + without any) are much lower
than the numbers I previously reported in this thread. I believe that's
because of 1, here we only count specific HTML elements (but not e.g. the
ping attribute on links), and 2, the carveout for fetch()-initiated
requests. The previously reported metric counted ORB-related blocks across
all page-initiated responses, regardless of whether it might be
script-visible or not.

Daniel


On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss 
>> wrote:
>>
>>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
>>> wrote:
>>>
>>>> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>>>>> wrote:
>>>>>
>>>>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim <
>>>>>>> vogelh...@google.com> wrote:
>>>>>>>
>>>>>>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> Contact emailsvogelh...@chromium.org
>>>>>>>>>>
>>>>>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>>>>>>>>
>>>>>>>>>> Summary
>>>>>>>>>>
>>>>>>>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin
>>>>>>>>>> Read Blocking (CORB -
>>>>>>>>>> https://chromestatus.com/feature/5629709824032768). CORB and ORB
>>>>>>>>>> are both heuristics that attempt to prevent cross-origin disclosure 
>>>>>>>>>> of
>>>>>>>>>> “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's 
>>>>>>>>>> second
>>>>>>>>>> step towards a full ORB implementation. ORB specifies error handling 
>>>>>>>>>> for
>>>>>>>>>> blocked resources differently from CORB: ORB raises network errors, 
>>>>>>>>>> while
>>>>>>>>>> CORB injects an empty response. ORB "v0.1" still used CORB-style 
>>>>>>>>>> response
>>>>>>>>>> injection. This change brings our implementation more in line with 
>>>>>>>>>> the ORB
>>>>>>>>>> proposal, by changing the error handling of all fetches (except when
>>>>>>>>>> initiated by a script) to be compliant with ORB. We've made a 
>>>>>>>>>> carve-out for
>>>>>>>>>> script-initiated fetches (where we retain CORB behaviour for now) to 
>>>>>>>>>> limit
>>>>>>>>>> compatibility risk.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Blink componentInternals>Sandbox>SiteIsolation
>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%

Re: [blink-dev] Intent to Ship: Fenced Frames - Functionality Updates

['Daniel Vogelheim' via blink-dev]

Hi Liam,

This intent has come up in the OWP security triage, and I'm trying to
figure out whether there's XSS potential in the 3rd sub-feature, "Creative
macros in FFAR". This looks like a string-based pattern replacement where
the result string will then be parsed by the browser. Similar things have
lent themselves to XSS, e.g. when a string value contains meta characters
that code downstream will then parse in unexpected ways. Unfortunately, I
can't seem to find enough information about how exactly the replacement &
subsequent usage works to make up my mind whether there's a concern or not.
Could you help me out with a bit more information?

What I've found is this:
- In "send a beacon": "TODO: Substitute macros from |macro map|
into |destination url|." (source
)
- In "asynchronously finish reporting" I find where macro map
being set, but then it says: "TODO: Pass |macroMap| and
|allowedReportingOrigins| to [=Finalize a reporting destination=] when it
is updated to take the parameters." (source
) I can't find that
usage.

Questions I have:
- Am I reading the right docs? Where else should I look?
- Is this meant as a simple string-based substitution? Is there any
filtering of allowed characters, or so?
- What happens with the result values?
- Is the entity that sets the macro values always the same that has set the
patterns the values are being used for, or could those be different
entities?

Thanks!


On Fri, Aug 25, 2023 at 9:34 PM 'Liam Brady' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> shivani...@chromium.org, d...@chromium.org, jkar...@chromium.org,
> lbr...@google.com
> Explainer(s)
>
> Send Automatic Beacons Once
>
> https://github.com/WICG/turtledove/pull/718
>
> Serializable Fenced Frames Configs - Minor Change, No explainer available.
>
> Note: With this change, FencedFrameConfig objects will be serializable and
> can be sent through "postMessage()" and other similar calls.
>
> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>
> https://github.com/WICG/turtledove/pull/763
>
> Spec(s)
>
> Send Automatic Beacons Once
>
> https://github.com/WICG/fenced-frame/pull/109
>
> Serializable Fenced Frames Configs
>
> https://github.com/WICG/fenced-frame/pull/111
>
> Creative Macros in Fenced Frames Ads Reporting (FFAR)
>
> Protected Audience: https://github.com/WICG/turtledove/pull/762/files
>
> Fenced Frames: https://github.com/WICG/fenced-frame/pull/113
>
>
>
> Summary
>
> We launched Fenced Frames as a part of Chrome 115. We would like to add
> the following three functionalities to Fenced Frames.
>
> 1. Send Automatic Beacons Once
>
> A common feature in ad frames is the "why this ad?" link. Since that link
> is separate from the ad itself, clicking "why this ad?", and its subsequent
> navigation, should be considered different from clicking directly on the
> advertisement itself. With our current automatic beacon design, however,
> once an automatic beacon is set (usually in the click handler for the ad
> link), that beacon will send out for any subsequent top-level navigations,
> including if "why this ad?" is clicked. This can result in erroneous
> impressions being sent out.
>
> As a solution, this feature introduces a new "once" member to the
> FenceEvent 
> dictionary passed into
> "window.fence.setReportEventDataForAutomaticBeacons()". If set to true, the
> saved automatic beacon data will be cleared out after the next beacon is
> sent, ensuring that automatic beacons with that data are only sent once.
> This means that further clicks to non-ad parts of the frame that result in
> top-level navigations will not send out erroneous beacons.
>
> (This feature already shipped in M116. That was our mistake. At the time,
> we thought we would only need a PSA for it, and shipped it without it being
> behind a flag. We apologize for the mistake.)
>
> 2. Serializable FencedFramesConfigs
>
> With this change, FencedFrameConfig objects will be serializable and can
> be sent through "postMessage()" and other similar calls. Serialization
> allows for a case where the frame that runs an ad auction is not the same
> frame that ends up embedding the winning ad in a fenced frame.
> FencedFrameConfigs cannot be serialized to storage, nor can they be sent in
> a message that crosses a fenced frame boundary. A FencedFrameConfig object
> is only valid in the traversable navigable
>  it was
> originally created in, and, if sent outside to a different context, will
> not be able to navigate, since the new traversable navigable
> 's fenced
> frame config mapping
> 
> will not contain the internal config needed to do the navi

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Aug 22, 2023 at 5:02 PM Dominic Farolino  wrote:

> It looks like the spec PR here has been dormant for something like ~9
>> months. Are there any plans to help drive it to the finish line,
>> especially given the TODOs listed in the OP? How should we all think about
>> whatever work might remain there, and possibly deviate from what Chrome
>> plans on shipping?
>>
>
> Hello, I'm still a little curious if there are plans to advance the spec
> PR anymore, so that it matches what we're attempting to ship? Or is there
> something new that has superseded that work, making it (and my question)
> obsolete?
>

The spec PR is still the latest.

We had settled on a gradual CORB -> ORB transition, where this is the 2nd
step. We initially had quite a few carveouts due to compat concerns, and
we're working through them with this series of changes. I still hope that
in the end we'll have a pretty good approximation of ORB and won't actually
have many change requests to the current proposal. The thing is that right
now, I wouldn't know what to ask for. So my plan is to keep implementing
the proposed spec until I hit roadblocks, and then go back to the proposal.

One new thing that may change this dynamic a bit is that FF is also working
on it (see Olli's post). But the info I've got so far is that their
carve-outs are similar to ours, except they've implemented the
JS/JSON-distinguisher step. Which I'd like to be our next step, "v0.3". The
end goal is certainly that the two implementations & the spec should match
exactly.

-- 
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/CALG6KPNVCdsRpi4KP1CXkK-R75YrCU%2Bxb2NP%2BoYSzizU7spwew%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Deprecate: Remove "Sanitizer API MVP"

['Daniel Vogelheim' via blink-dev]

Hi Luke & Thomas,

On Wed, Aug 16, 2023 at 12:49 PM Thomas Steiner  wrote:

> Adding in Jack as the author of the mentioned article at
> https://web.dev/sanitizer/. It might be worthwhile to add a big red
> warning aside.
>
> On Tue, Aug 15, 2023, 23:37 Luke  wrote:
>
>> Just to chime in here. If there's a chance this API is going to be
>> removed or even heavily changed its potentially worth making an effort to
>> take down any documentation regarding it to try to prevent any chance of
>> its usage going up. For example the mdn page on it seems an easy one to
>> remove. Likewise the web.dev article. This may not be as important if
>> the usage is far below any thresholds.
>>
>
Yes, noted and agreed. Adjusting or even removing the docs has come up
before, and I hesitated to act on it because we didn't yet have clarity on
how to proceed with the Sanitizer API. The reason for writing this
intent-to-deprecate is to get agreement on how to proceed, and to decide
whether we'll keep supporting the current API in the future or not. If it's
okay with you, I'd like to let this discussion run its course, and then
adjust the docs depending on how api owners have decided here.

-- 
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/CALG6KPMrdkH5Br_useiWyt3b8gXVWkzYi9tdL2DSJ9MTwefTjA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Deprecate: Remove "Sanitizer API MVP"

['Daniel Vogelheim' via blink-dev]

Hi Chris,

On Mon, Aug 14, 2023 at 5:38 PM Chris Harrelson 
wrote:

> I think it's fine to consider removing the current API given usage is
> extremely low, and if there is a more plausible path to interoperability
> via a new version.
>
> Is there consensus on a new API shape yet, or is that an open discussion?
>

It's in active discussion. The new design is being circulated to a wider
audience, including the HTML WG (1
<https://github.com/whatwg/html/issues/8942#issuecomment-1462965265>),
where this is meant to land eventually. Every PR that defines the new API
shape (1 <https://github.com/WICG/sanitizer-api/pull/193>, 2
<https://github.com/WICG/sanitizer-api/pull/194>) has been reviewed by
engineers from other browser engines. We are certainly trying to get
consensus here. That said, I can't speak for other people or projects.

Daniel


>
> On Fri, Aug 11, 2023 at 7:45 AM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Alex,
>>
>> On Mon, Aug 7, 2023 at 8:13 PM Alex Russell 
>> wrote:
>>
>>> Hey Daniel,
>>>
>>> Hrm, this isn't how things are supposed to work.
>>>
>>> The API OWNERS set a high bar to ship exactly to prevent this sort of
>>> bikeshedding after shipping. Is it possible to make compatible additions
>>> instead?
>>>
>>
>> I agree that this isn't how things are supposed to work, and I certainly
>> didn't plan it this way. The Sanitizer launch in 105 was based on the
>> then-current spec. The feedback we have gotten since is that there are
>> blocking concerns with that API. We worked through them and landed on a
>> different API shape, which other engines now seem committed to. They're
>> unwilling to support the old API.
>>
>> It would be possible for Blink to add the new APIs in addition to the
>> old, and to retain backwards compatibility. However, given that no other
>> engine is likely to support the old APIs as well, it was recommended to me
>> to not do that. The main argument is the impact on the developer community:
>> Are we helping developers by supporting an API shape that has little
>> current usage and is highly unlikely to see a second implementation?
>>
>> I'm happy to follow whatever API Owners recommend: What I'm asking for
>> here is to retire the current API before adding the new one. The
>> alternative would be to retain the existing API and implement the new one
>> on top of it. Either way can work.
>>
>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Monday, August 7, 2023 at 6:35:16 AM UTC-7 Daniel Vogelheim wrote:
>>>
>>>> Contact emailsvogelh...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>>- Old explainer, API as implemented in "MVP" since M105:
>>>>
>>>> https://github.com/WICG/sanitizer-api/blob/e72b56b361a31b722b4e14491a83e2d25943ba58/explainer.md
>>>>- New explainer, still in progress, API that we expect to implement
>>>>eventually:
>>>>https://github.com/WICG/sanitizer-api/blob/main/explainer.md
>>>>
>>>>
>>>> Specificationhttps://github.com/WICG/sanitizer-api
>>>>
>>>> Summary
>>>>
>>>> The Sanitizer API (https://chromestatus.com/feature/5786893650231296)
>>>> aims to build an easy-to-use, always secure, browser-maintained HTML
>>>> sanitizer into the platform. It is a cross-browser standardization effort
>>>> starting in Q2/2020. We shipped an initial version of the Sanitizer API in
>>>> M105, based on the then-current specification draft. However, the
>>>> discussion has meanwhile moved on and the proposed API shape has changed
>>>> substantially. In order to prevent the current API from becoming entrenched
>>>> we would like to remove the current implementation. We expect to
>>>> re-implement the Sanitizer API when the proposed specification stabilizes
>>>> again.
>>>>
>>>>
>>>> Blink componentBlink>SecurityFeature>SanitizerAPI
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ESanitizerAPI>
>>>>
>>>> Motivation
>>>>
>>>> Since the final version of the standard will look different from our
>>>> initial implementation, the goal is to prevent an API from becoming
>>>> entrenched. According to use counters, the Sanitizer API is currently used
>>>&g

[blink-dev] Re: Intent to Deprecate: Remove "Sanitizer API MVP"

['Daniel Vogelheim' via blink-dev]

Hi Alex,

On Mon, Aug 7, 2023 at 8:13 PM Alex Russell 
wrote:

> Hey Daniel,
>
> Hrm, this isn't how things are supposed to work.
>
> The API OWNERS set a high bar to ship exactly to prevent this sort of
> bikeshedding after shipping. Is it possible to make compatible additions
> instead?
>

I agree that this isn't how things are supposed to work, and I certainly
didn't plan it this way. The Sanitizer launch in 105 was based on the
then-current spec. The feedback we have gotten since is that there are
blocking concerns with that API. We worked through them and landed on a
different API shape, which other engines now seem committed to. They're
unwilling to support the old API.

It would be possible for Blink to add the new APIs in addition to the old,
and to retain backwards compatibility. However, given that no other engine
is likely to support the old APIs as well, it was recommended to me to not
do that. The main argument is the impact on the developer community: Are we
helping developers by supporting an API shape that has little current usage
and is highly unlikely to see a second implementation?

I'm happy to follow whatever API Owners recommend: What I'm asking for here
is to retire the current API before adding the new one. The alternative
would be to retain the existing API and implement the new one on top of it.
Either way can work.


> Best,
>
> Alex
>
> On Monday, August 7, 2023 at 6:35:16 AM UTC-7 Daniel Vogelheim wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Explainer
>>
>>- Old explainer, API as implemented in "MVP" since M105:
>>
>> https://github.com/WICG/sanitizer-api/blob/e72b56b361a31b722b4e14491a83e2d25943ba58/explainer.md
>>- New explainer, still in progress, API that we expect to implement
>>eventually:
>>https://github.com/WICG/sanitizer-api/blob/main/explainer.md
>>
>>
>> Specificationhttps://github.com/WICG/sanitizer-api
>>
>> Summary
>>
>> The Sanitizer API (https://chromestatus.com/feature/5786893650231296)
>> aims to build an easy-to-use, always secure, browser-maintained HTML
>> sanitizer into the platform. It is a cross-browser standardization effort
>> starting in Q2/2020. We shipped an initial version of the Sanitizer API in
>> M105, based on the then-current specification draft. However, the
>> discussion has meanwhile moved on and the proposed API shape has changed
>> substantially. In order to prevent the current API from becoming entrenched
>> we would like to remove the current implementation. We expect to
>> re-implement the Sanitizer API when the proposed specification stabilizes
>> again.
>>
>>
>> Blink componentBlink>SecurityFeature>SanitizerAPI
>> 
>>
>> Motivation
>>
>> Since the final version of the standard will look different from our
>> initial implementation, the goal is to prevent an API from becoming
>> entrenched. According to use counters, the Sanitizer API is currently used
>> on 0.00492 % of page visits.
>>
>> Initial public proposalNone
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Sanitizer API is currently used on 0.00492% of page visits. Since
>> presently no other browser supports this API (in any release version) we
>> expect the compatibility impact to be negligible.
>>
>>
>> *Gecko*: Positive (
>> https://mozilla.github.io/standards-positions/#sanitizer-api) (Note that
>> the Firefox position presumably applies to the eventual result of the
>> standards effort, not to our current implementation.)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/86)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsCurrently none. Would be happy to
>> re-implement the chrome://flags flag if it helps.
>>
>> Finch feature nameSanitizerAPI
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1428276
>>
>> Estimated milestones
>> Shipping on desktop 118
>> Shipping on Android 118
>> Shipping on WebView 118
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5115076981293056
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

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

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss  wrote:

> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim 
> wrote:
>
>> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>>> wrote:
>>>
>>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>>>>> wrote:
>>>>>
>>>>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>
>>>>>>>> Contact emailsvogelh...@chromium.org
>>>>>>>>
>>>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin
>>>>>>>> Read Blocking (CORB -
>>>>>>>> https://chromestatus.com/feature/5629709824032768). CORB and ORB
>>>>>>>> are both heuristics that attempt to prevent cross-origin disclosure of
>>>>>>>> “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's 
>>>>>>>> second
>>>>>>>> step towards a full ORB implementation. ORB specifies error handling 
>>>>>>>> for
>>>>>>>> blocked resources differently from CORB: ORB raises network errors, 
>>>>>>>> while
>>>>>>>> CORB injects an empty response. ORB "v0.1" still used CORB-style 
>>>>>>>> response
>>>>>>>> injection. This change brings our implementation more in line with the 
>>>>>>>> ORB
>>>>>>>> proposal, by changing the error handling of all fetches (except when
>>>>>>>> initiated by a script) to be compliant with ORB. We've made a 
>>>>>>>> carve-out for
>>>>>>>> script-initiated fetches (where we retain CORB behaviour for now) to 
>>>>>>>> limit
>>>>>>>> compatibility risk.
>>>>>>>>
>>>>>>>>
>>>>>>>> Blink componentInternals>Sandbox>SiteIsolation
>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation>
>>>>>>>>
>>>>>>>> TAG reviewNone
>>>>>>>> (A TAG review of a particular aspect happened in:
>>>>>>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>>>>>>
>>>>>>>> TAG review statusNot applicable
>>>>>>>>
>>>>>>>> Risks
>>>>>>>>
>>>>>>>> Interoperability and Compatibility
>>>>>>>>
>>>>>>>> This release does not modify blocking behaviour, but only how a
>>>>>>>> blocked resource is represented. Ideally, this change shouldn't break 
>>>>>>>> any
>>>>>>>> existing code since any resource that loads (or gets blocked) before 
>>>>>>>> will
>>>>>>>> continue to do so after. However, it is possible to distinguish 
>>>>>>>> between the
>>>>>>>> different types of error handling, and it may well happen that an
>>>>>>>> application inadvertently relies on blocked resources "succeeding". In 
>>>>>>>> our
>>>>>>>> examinations so far, this chiefly concerns fetches using the `fetch()` 
>>>>>>>> API,
>>>>>>>> where blocking with a network error results in a failed promise 
>>>>>>>> (instead of
>>>>>>>> a success with an empty response). For this reason, we have carved out
>>>>>>>> script-initiated fetches from "v0.2" and intend to handle them at a 
>>>>>>>> later
>>>>>>>> date.
>>>>>>>>
>>>>>>>
>>>>>>> OK, so how would this change

[blink-dev] Intent to Deprecate: Remove "Sanitizer API MVP"

['Daniel Vogelheim' via blink-dev]

Contact emailsvogelh...@chromium.org

Explainer

   - Old explainer, API as implemented in "MVP" since M105:
   
https://github.com/WICG/sanitizer-api/blob/e72b56b361a31b722b4e14491a83e2d25943ba58/explainer.md
   - New explainer, still in progress, API that we expect to implement
   eventually: https://github.com/WICG/sanitizer-api/blob/main/explainer.md


Specificationhttps://github.com/WICG/sanitizer-api

Summary

The Sanitizer API (https://chromestatus.com/feature/5786893650231296) aims
to build an easy-to-use, always secure, browser-maintained HTML sanitizer
into the platform. It is a cross-browser standardization effort starting in
Q2/2020. We shipped an initial version of the Sanitizer API in M105, based
on the then-current specification draft. However, the discussion has
meanwhile moved on and the proposed API shape has changed substantially. In
order to prevent the current API from becoming entrenched we would like to
remove the current implementation. We expect to re-implement the Sanitizer
API when the proposed specification stabilizes again.


Blink componentBlink>SecurityFeature>SanitizerAPI


Motivation

Since the final version of the standard will look different from our
initial implementation, the goal is to prevent an API from becoming
entrenched. According to use counters, the Sanitizer API is currently used
on 0.00492 % of page visits.

Initial public proposalNone

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Sanitizer API is currently used on 0.00492% of page visits. Since
presently no other browser supports this API (in any release version) we
expect the compatibility impact to be negligible.


*Gecko*: Positive (
https://mozilla.github.io/standards-positions/#sanitizer-api) (Note that
the Firefox position presumably applies to the eventual result of the
standards effort, not to our current implementation.)

*WebKit*: No signal (https://github.com/WebKit/standards-positions/issues/86
)

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability



Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsCurrently none. Would be happy to re-implement
the chrome://flags flag if it helps.

Finch feature nameSanitizerAPI

Requires code in //chrome?False

Tracking bughttps://crbug.com/1428276

Estimated milestones
Shipping on desktop 118
Shipping on Android 118
Shipping on WebView 118

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5115076981293056

This intent message was generated by Chrome Platform Status
.

-- 
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/CALG6KPPDHMN6e5C-KBGwkNWo2WiZ6Tq_8vy1Xp7%3DDXyQObV5Mw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Jul 25, 2023 at 6:00 PM Olli Pettay  wrote:

> Gecko has a variant of ORB enabled currently in early beta and earlier
> https://bugzilla.mozilla.org/show_bug.cgi?id=1821682
> We had full ORB, but had to relax the rules a bit similarly to what Blink
> has done, if I understood correctly.
> And there is also an experiment ongoing.
>
> But I can't recall the details whether Gecko's implementation matches
> Blink v0.2 exactly (and some folks are on vacation atm so I can't ask right
> now).
>

Thanks for the update!

I don't think it's an exact match; for example, we don't deal with JS/JSON
yet. (That should be the next step for us.)

On Tue, Jul 25, 2023 at 6:16 PM Dominic Farolino  wrote:
>
>> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642)
>>> In implementation.
>>
>>
>> "In implementation" and "No signal" sound a little conflicting. Is the
>> feature *definitely* being implemented in Firefox? Can we file for a
>> proper standards signal to be sure?
>>
>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>
>>
>> It looks like the spec PR here has been dormant for something like ~9
>> months. Are there any plans to help drive it to the finish line,
>> especially given the TODOs listed in the OP? How should we all think about
>> whatever work might remain there, and possibly deviate from what Chrome
>> plans on shipping?
>>
>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?Yes (https://wpt.fyi/results/fetch/orb)
>>>
>>
>> Just to double check, are we confident that the tests in that directory
>> assert what the spec PR currently requires? I only ask because the spec has
>> seemed quiet for a while (as mentioned above) and that makes it easy for
>> things to accidentally get out of sync.
>>
>> On Tue, Jul 25, 2023 at 3:10 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>>> wrote:
>>>
>>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>>>>> wrote:
>>>>>
>>>>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>>>>> wrote:
>>>>>>
>>>>>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>
>>>>>>>> Contact emailsvogelh...@chromium.org
>>>>>>>>
>>>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin
>>>>>>>> Read Blocking (CORB -
>>>>>>>> https://chromestatus.com/feature/5629709824032768). CORB and ORB
>>>>>>>> are both heuristics that attempt to prevent cross-origin disclosure of
>>>>>>>> “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's 
>>>>>>>> second
>>>>>>>> step towards a full ORB implementation. ORB specifies error handling 
>>>>>>>> for
>>>>>>>> blocked resources differently from CORB: ORB raises network errors, 
>>>>>>>> while
>>>>>>>> CORB injects an empty response. ORB "v0.1" still used CORB-style 
>>>>>>>> response
>>>>>>>> injection. This change brings our implementation more in line with the 
>>>>>>>> ORB
>>>>>>>> proposal, by changing the error handling of all fetches (except when
>>>>>>>> initiated by a script) to be compliant with ORB. We've made a 
>>>>>>>> carve-out for
>>>>>>>> script-initiated fetches (where we retain CORB behaviour for now) to 
>>>>>>>> limit
>>>>>>>> compatibility risk.
>>>>>>>>
>>>>>>>>
>>>>>>>> Blink componentInternals>Sandbox>SiteIsolation
>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation>
>>&

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss  wrote:

> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
>>> wrote:
>>>
>>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>>>> wrote:
>>>>
>>>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> Contact emailsvogelh...@chromium.org
>>>>>>
>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
>>>>>> Blocking (CORB - https://chromestatus.com/feature/5629709824032768).
>>>>>> CORB and ORB are both heuristics that attempt to prevent cross-origin
>>>>>> disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB -
>>>>>> Chrome's second step towards a full ORB implementation. ORB specifies 
>>>>>> error
>>>>>> handling for blocked resources differently from CORB: ORB raises network
>>>>>> errors, while CORB injects an empty response. ORB "v0.1" still used
>>>>>> CORB-style response injection. This change brings our implementation more
>>>>>> in line with the ORB proposal, by changing the error handling of all
>>>>>> fetches (except when initiated by a script) to be compliant with ORB. 
>>>>>> We've
>>>>>> made a carve-out for script-initiated fetches (where we retain CORB
>>>>>> behaviour for now) to limit compatibility risk.
>>>>>>
>>>>>>
>>>>>> Blink componentInternals>Sandbox>SiteIsolation
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation>
>>>>>>
>>>>>> TAG reviewNone
>>>>>> (A TAG review of a particular aspect happened in:
>>>>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> This release does not modify blocking behaviour, but only how a
>>>>>> blocked resource is represented. Ideally, this change shouldn't break any
>>>>>> existing code since any resource that loads (or gets blocked) before will
>>>>>> continue to do so after. However, it is possible to distinguish between 
>>>>>> the
>>>>>> different types of error handling, and it may well happen that an
>>>>>> application inadvertently relies on blocked resources "succeeding". In 
>>>>>> our
>>>>>> examinations so far, this chiefly concerns fetches using the `fetch()` 
>>>>>> API,
>>>>>> where blocking with a network error results in a failed promise (instead 
>>>>>> of
>>>>>> a success with an empty response). For this reason, we have carved out
>>>>>> script-initiated fetches from "v0.2" and intend to handle them at a later
>>>>>> date.
>>>>>>
>>>>>
>>>>> OK, so how would this change be web exposed? Are there scenarios where
>>>>> an "error" event would now fire instead of a "load" event?
>>>>>
>>>>
>>>> Yes, exactly. If a site is waiting for an onload event - despite not
>>>> really caring about whether the load is actually meaningful, since it
>>>> currently already loads empty - then it would see a behavioural change.
>>>>
>>>>
>>> Do we have stats on how often that would happen? (e.g. how often an
>>> onload event fires on an ORB empty resource?)
>>>
>>
>> No. I didn't realize I could measure onload events firing specifically
>> for ORB-blocked resources. So I unfortunately don't have that data.
>>
>> The number of page views with any CORB/ORB-blocked resource in it hovers
>> around 0.35% of page loads. That should provide an upper bound, but doesn

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss  wrote:

> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
> wrote:
>
>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
>> wrote:
>>
>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Contact emailsvogelh...@chromium.org
>>>>
>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>>
>>>> Summary
>>>>
>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
>>>> Blocking (CORB - https://chromestatus.com/feature/5629709824032768).
>>>> CORB and ORB are both heuristics that attempt to prevent cross-origin
>>>> disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB -
>>>> Chrome's second step towards a full ORB implementation. ORB specifies error
>>>> handling for blocked resources differently from CORB: ORB raises network
>>>> errors, while CORB injects an empty response. ORB "v0.1" still used
>>>> CORB-style response injection. This change brings our implementation more
>>>> in line with the ORB proposal, by changing the error handling of all
>>>> fetches (except when initiated by a script) to be compliant with ORB. We've
>>>> made a carve-out for script-initiated fetches (where we retain CORB
>>>> behaviour for now) to limit compatibility risk.
>>>>
>>>>
>>>> Blink componentInternals>Sandbox>SiteIsolation
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation>
>>>>
>>>> TAG reviewNone
>>>> (A TAG review of a particular aspect happened in:
>>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> This release does not modify blocking behaviour, but only how a blocked
>>>> resource is represented. Ideally, this change shouldn't break any existing
>>>> code since any resource that loads (or gets blocked) before will continue
>>>> to do so after. However, it is possible to distinguish between the
>>>> different types of error handling, and it may well happen that an
>>>> application inadvertently relies on blocked resources "succeeding". In our
>>>> examinations so far, this chiefly concerns fetches using the `fetch()` API,
>>>> where blocking with a network error results in a failed promise (instead of
>>>> a success with an empty response). For this reason, we have carved out
>>>> script-initiated fetches from "v0.2" and intend to handle them at a later
>>>> date.
>>>>
>>>
>>> OK, so how would this change be web exposed? Are there scenarios where
>>> an "error" event would now fire instead of a "load" event?
>>>
>>
>> Yes, exactly. If a site is waiting for an onload event - despite not
>> really caring about whether the load is actually meaningful, since it
>> currently already loads empty - then it would see a behavioural change.
>>
>>
> Do we have stats on how often that would happen? (e.g. how often an onload
> event fires on an ORB empty resource?)
>

No. I didn't realize I could measure onload events firing specifically for
ORB-blocked resources. So I unfortunately don't have that data.

The number of page views with any CORB/ORB-blocked resource in it hovers
around 0.35% of page loads. That should provide an upper bound, but doesn't
tell us how many of them care about the onload/onerror events.


>
>>>>
>>>> *Gecko*: No signal (
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) In
>>>> implementation.
>>>>
>>>> *WebKit*: No signal (
>>>> https://github.com/WebKit/standards-positions/issues/64)
>>>>
>>>> *Web developers*: No signals
>>>>
>>>> *Other signals*: https://github.com/w3ctag/design-reviews/issues/618
>>>>
>>>> WebView application risks
>>>>
>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>> that it has potentially high risk for Android WebView-based applications?
>>>>
>>>> None
>>>>
>>>>
>>>> Debuggability
>>>>
&

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss  wrote:

> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvogelh...@chromium.org
>>
>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>
>> Summary
>>
>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
>> Blocking (CORB - https://chromestatus.com/feature/5629709824032768).
>> CORB and ORB are both heuristics that attempt to prevent cross-origin
>> disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB -
>> Chrome's second step towards a full ORB implementation. ORB specifies error
>> handling for blocked resources differently from CORB: ORB raises network
>> errors, while CORB injects an empty response. ORB "v0.1" still used
>> CORB-style response injection. This change brings our implementation more
>> in line with the ORB proposal, by changing the error handling of all
>> fetches (except when initiated by a script) to be compliant with ORB. We've
>> made a carve-out for script-initiated fetches (where we retain CORB
>> behaviour for now) to limit compatibility risk.
>>
>>
>> Blink componentInternals>Sandbox>SiteIsolation
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation>
>>
>> TAG reviewNone
>> (A TAG review of a particular aspect happened in:
>> https://github.com/w3ctag/design-reviews/issues/618)
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This release does not modify blocking behaviour, but only how a blocked
>> resource is represented. Ideally, this change shouldn't break any existing
>> code since any resource that loads (or gets blocked) before will continue
>> to do so after. However, it is possible to distinguish between the
>> different types of error handling, and it may well happen that an
>> application inadvertently relies on blocked resources "succeeding". In our
>> examinations so far, this chiefly concerns fetches using the `fetch()` API,
>> where blocking with a network error results in a failed promise (instead of
>> a success with an empty response). For this reason, we have carved out
>> script-initiated fetches from "v0.2" and intend to handle them at a later
>> date.
>>
>
> OK, so how would this change be web exposed? Are there scenarios where an
> "error" event would now fire instead of a "load" event?
>

Yes, exactly. If a site is waiting for an onload event - despite not really
caring about whether the load is actually meaningful, since it currently
already loads empty - then it would see a behavioural change.




>
>
>>
>>
>> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642)
>> In implementation.
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/64)
>>
>> *Web developers*: No signals
>>
>> *Other signals*: https://github.com/w3ctag/design-reviews/issues/618
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>>
>>
>> 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
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes (https://wpt.fyi/results/fetch/orb)
>>
>> Flag name on chrome://flags
>>
>> Finch feature nameOpaqueResponseBlockingV02
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463725
>>
>> Estimated milestones
>> Shipping on desktop 117
>> DevTrial on desktop 115
>> Shipping on Android 117
>> DevTrial on Android 115
>> Shipping on WebView 117
>>
>> Anticipated spec changesNone
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5166834424217600
>>
>> Links to previous Intent discussions
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ScjhKz3Z6U4
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>>
>> --
>> 

[blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

['Daniel Vogelheim' via blink-dev]

Contact emailsvogelh...@chromium.org

Specificationhttps://github.com/whatwg/fetch/pull/1442

Summary

Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read
Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB
and ORB are both heuristics that attempt to prevent cross-origin disclosure
of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's
second step towards a full ORB implementation. ORB specifies error handling
for blocked resources differently from CORB: ORB raises network errors,
while CORB injects an empty response. ORB "v0.1" still used CORB-style
response injection. This change brings our implementation more in line with
the ORB proposal, by changing the error handling of all fetches (except
when initiated by a script) to be compliant with ORB. We've made a
carve-out for script-initiated fetches (where we retain CORB behaviour for
now) to limit compatibility risk.


Blink componentInternals>Sandbox>SiteIsolation


TAG reviewNone
(A TAG review of a particular aspect happened in:
https://github.com/w3ctag/design-reviews/issues/618)

TAG review statusNot applicable

Risks

Interoperability and Compatibility

This release does not modify blocking behaviour, but only how a blocked
resource is represented. Ideally, this change shouldn't break any existing
code since any resource that loads (or gets blocked) before will continue
to do so after. However, it is possible to distinguish between the
different types of error handling, and it may well happen that an
application inadvertently relies on blocked resources "succeeding". In our
examinations so far, this chiefly concerns fetches using the `fetch()` API,
where blocking with a network error results in a failed promise (instead of
a success with an empty response). For this reason, we have carved out
script-initiated fetches from "v0.2" and intend to handle them at a later
date.


*Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642)
In implementation.

*WebKit*: No signal (https://github.com/WebKit/standards-positions/issues/64
)

*Web developers*: No signals

*Other signals*: https://github.com/w3ctag/design-reviews/issues/618

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability



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

?Yes (https://wpt.fyi/results/fetch/orb)

Flag name on chrome://flags

Finch feature nameOpaqueResponseBlockingV02

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463725

Estimated milestones
Shipping on desktop 117
DevTrial on desktop 115
Shipping on Android 117
DevTrial on Android 115
Shipping on WebView 117

Anticipated spec changesNone

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5166834424217600

Links to previous Intent discussions
https://groups.google.com/a/chromium.org/g/blink-dev/c/ScjhKz3Z6U4

This intent message was generated by Chrome Platform Status
.

-- 
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/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com.

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
>>>>> <https://developer.chrome.com/blog/immutable-document-domain/> 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
>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. One
>>>>>> critical thing it doesn't mention, but probably should, is that the 
>>>>>> OriginAgentClusterDefaultEnabled
>>>>>> enterprise policy
>>>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled>
>>>>>> 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 ev

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
>>>> <https://developer.chrome.com/blog/immutable-document-domain/> 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
>>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. One
>>>>> critical thing it doesn't mention, but probably should, is that the 
>>>>> OriginAgentClusterDefaultEnabled
>>>>> enterprise policy
>>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled>
>>>>> 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
>>>>&

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
>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>
>>>>> asks for a separate intent for the actual default change
>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/Ybgtf3JfAQAJ>.
>>>>> 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
>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/policy/resources/templates/policy_definitions/Miscellaneous/OriginAgentClusterDefaultEnabled.yaml>
>>>>
>>>>
>>>>> - 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/m

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

['Daniel Vogelheim' via blink-dev]

Hello Yaseen,

Sorry for not betting back earlier.

On Mon, Dec 5, 2022 at 10:05 AM Yaseen Khan  wrote:

> Activation - Deprecation plan
> M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on
> beta, dev, and canary.
> --- As a developer, do I need to set  "Origin-Agent-Cluster: ?1" as a
> header for 50% of page visits or chromium enforcing for 50% of page
> visits from browser(Means 50% ( "Origin-Agent-Cluster: ?1")  and another
> 50% ( "Origin-Agent-Cluster: ?0")?.
>

No, you should always set the header (or remove document.domain usage).
Setting the header means you instruct the browser to cluster pages by
origin ("?1") (or not, "?0"), and thus the change of the default will not
affect you, since you're no longer relying on the default.

Note that origin-agent clustering has been implemented for quite a while.
What changes now is how the default is handled: Pages that do not
explicitly request clustering to be on or off used to get the off behaviour
("?0"), and will soon get the on behaviour ("?1"). In other words, it turns
from an opt-in feature into an opt-out feature. By setting the header to
off ("?0"), you request "off" behaviour - which in the past you got
automatically. It's safe to always do that, since it retains current
behaviour.

I have installed M109 beta and I have not set orginAgentCluster in my site
> and I can see in console "*window.originAgentCluster*" always return
> false for all sites/pages. Could you clarify on this?. How do I know
> whether Origin-Agent-Cluster enabled or not in M109?
>

M109 beta: Your observation is correct. Because of a bug found at the last
minute, I have not actually enabled the feature. Unfortunately I have to
delay the rollout.


> On Thursday, 27 October 2022 at 20:19:44 UTC+5:30 Daniel Vogelheim 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.
>>
>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>>
>>
>> 
>>
>> Contact emailsva...@chromium.org, voge...@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 we

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
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>
>>>> asks for a separate intent for the actual default change
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/Ybgtf3JfAQAJ>.
>>>> 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
>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/policy/resources/templates/policy_definitions/Miscellaneous/OriginAgentClusterDefaultEnabled.yaml>
>>>
>>>
>>>> - 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
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>. 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

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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>
> asks for a separate intent for the actual default change
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/Ybgtf3JfAQAJ>.
> 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
<https://source.chromium.org/chromium/chromium/src/+/main:components/policy/resources/templates/policy_definitions/Miscellaneous/OriginAgentClusterDefaultEnabled.yaml>


> - 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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>. 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 launc

[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

['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&scope=&q=%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 Implement and Ship: Trusted Types fromLiteral

['Daniel Vogelheim' via blink-dev]

Update: I pushed the release target out to 109, so we'll have more time to
sort this out.

On Tue, Oct 25, 2022 at 1:38 PM Daniel Vogelheim 
wrote:

> On Tue, Oct 25, 2022 at 11:03 AM Yoav Weiss 
> wrote:
>
>> Thanks!!
>>
>> On Friday, October 21, 2022 at 11:30:22 AM UTC+2 Daniel Vogelheim wrote:
>>
>>> Apologies this took a while, but the explainer bit has now landed here:
>>> https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals
>>>
>>>
>>
>> I'm guessing that "const value = TrustedHTML.fromLiteral`Hello there
>> ${user_provided_name}`;" will throw as well, right?
>>
>
> Yes. (spec, §3.3 #2
> <https://w3c.github.io/trusted-types/dist/spec/#create-a-trusted-type-from-literal-algorithm>
> )
>
> I proposed improved wording
> <https://github.com/w3c/trusted-types/pull/377> for the explainer, but
> kept it very brief to keep it within the spirit of an explainer.
>
> On Wed, Oct 19, 2022 at 5:34 PM Yoav Weiss  wrote:
>>>
>>>> Friendly ping on an explainer update :)
>>>>
>>>> On Thursday, October 6, 2022 at 7:19:20 PM UTC+2 Jun Kokatsu wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wednesday, October 5, 2022 at 2:52:59 AM UTC-7 yoav...@chromium.org
>>>>> wrote:
>>>>>
>>>>>> On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev <
>>>>>> blin...@chromium.org> wrote:
>>>>>>
>>>>>>> Contact emailsvoge...@chromium.org
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Specification
>>>>>>> https://w3c.github.io/trusted-types/dist/spec/#trusted-html
>>>>>>>
>>>>>>> Summary
>>>>>>>
>>>>>>> Add a function to each "Trusted Type" to create an instance from a
>>>>>>> JavaScript template literal (but not from a dynamically computed 
>>>>>>> string).
>>>>>>> This makes it easy to mark literals in the JavaScript source text as
>>>>>>> "trusted". Example:
>>>>>>>
>>>>>>> const html = TrustedHTML.fromLiteral`Literal Text`;
>>>>>>>
>>>>>>> Blink componentBlink>SecurityFeature>TrustedTypes
>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ETrustedTypes>
>>>>>>>
>>>>>>> TAG reviewn/a
>>>>>>>
>>>>>>> TAG review statusNot applicable
>>>>>>>
>>>>>>> Risks
>>>>>>>
>>>>>>> Interoperability and Compatibility
>>>>>>>
>>>>>>>
>>>>>>> *Gecko*: No signal. (Gecko has not implemented Trusted Types.)
>>>>>>>
>>>>>>> *WebKit*: No signal. (WebKit has not implemented Trusted Types.)
>>>>>>>
>>>>>>> *Web developers*: Positive (
>>>>>>> https://github.com/w3c/trusted-types/issues/347)
>>>>>>>
>>>>>> Can you point out specific signals in that thread that should be
>>>>>> counted as web developer ones?
>>>>>>
>>>>> It's little hard to tell, but that issue was a feature request from a
>>>>> developer (i.e. me).
>>>>> At the time, I was working in Microsoft where I worked with Bing team
>>>>> to deploy Trusted Types in some of their products, and that was a request
>>>>> that I made.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> *Other signals*:
>>>>>>>
>>>>>>> WebView application risks
>>>>>>>
>>>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>>>> that it has potentially high risk for Android WebView-based 
>>>>>>> applications?
>>>>>>> No.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Debuggability
>>>>>>>
>>>>>>> It's a new method. Its use can be readily debugged in DevTools.
>>>>>>>
>>>>>>>
>>

Re: [blink-dev] Intent to Implement and Ship: Trusted Types fromLiteral

['Daniel Vogelheim' via blink-dev]

On Tue, Oct 25, 2022 at 11:03 AM Yoav Weiss  wrote:

> Thanks!!
>
> On Friday, October 21, 2022 at 11:30:22 AM UTC+2 Daniel Vogelheim wrote:
>
>> Apologies this took a while, but the explainer bit has now landed here:
>> https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals
>>
>>
>
> I'm guessing that "const value = TrustedHTML.fromLiteral`Hello there
> ${user_provided_name}`;" will throw as well, right?
>

Yes. (spec, §3.3 #2
<https://w3c.github.io/trusted-types/dist/spec/#create-a-trusted-type-from-literal-algorithm>
)

I proposed improved wording <https://github.com/w3c/trusted-types/pull/377>
for the explainer, but kept it very brief to keep it within the spirit of
an explainer.

On Wed, Oct 19, 2022 at 5:34 PM Yoav Weiss  wrote:
>>
>>> Friendly ping on an explainer update :)
>>>
>>> On Thursday, October 6, 2022 at 7:19:20 PM UTC+2 Jun Kokatsu wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, October 5, 2022 at 2:52:59 AM UTC-7 yoav...@chromium.org
>>>> wrote:
>>>>
>>>>> On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev <
>>>>> blin...@chromium.org> wrote:
>>>>>
>>>>>> Contact emailsvoge...@chromium.org
>>>>>>
>>>>>
>>>>>>
>>>>>> Specification
>>>>>> https://w3c.github.io/trusted-types/dist/spec/#trusted-html
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Add a function to each "Trusted Type" to create an instance from a
>>>>>> JavaScript template literal (but not from a dynamically computed string).
>>>>>> This makes it easy to mark literals in the JavaScript source text as
>>>>>> "trusted". Example:
>>>>>>
>>>>>> const html = TrustedHTML.fromLiteral`Literal Text`;
>>>>>>
>>>>>> Blink componentBlink>SecurityFeature>TrustedTypes
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ETrustedTypes>
>>>>>>
>>>>>> TAG reviewn/a
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>>
>>>>>> *Gecko*: No signal. (Gecko has not implemented Trusted Types.)
>>>>>>
>>>>>> *WebKit*: No signal. (WebKit has not implemented Trusted Types.)
>>>>>>
>>>>>> *Web developers*: Positive (
>>>>>> https://github.com/w3c/trusted-types/issues/347)
>>>>>>
>>>>> Can you point out specific signals in that thread that should be
>>>>> counted as web developer ones?
>>>>>
>>>> It's little hard to tell, but that issue was a feature request from a
>>>> developer (i.e. me).
>>>> At the time, I was working in Microsoft where I worked with Bing team
>>>> to deploy Trusted Types in some of their products, and that was a request
>>>> that I made.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> *Other signals*:
>>>>>>
>>>>>> WebView application risks
>>>>>>
>>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>> No.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Debuggability
>>>>>>
>>>>>> It's a new method. Its use can be readily debugged in DevTools.
>>>>>>
>>>>>>
>>>>>> 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
>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>> ?Yes
>>>>>>
>>>>>> Flag nameTrustedTypesFromLiteral
>>>>>>
>>>>>> Requires code in //chrome?False
>>>>>>
>>>>>

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 content.

Re: [blink-dev] Intent to Implement and Ship: Trusted Types fromLiteral

['Daniel Vogelheim' via blink-dev]

Apologies this took a while, but the explainer bit has now landed here:
https://github.com/w3c/trusted-types/blob/main/explainer.md#source-literals

On Wed, Oct 19, 2022 at 5:34 PM Yoav Weiss  wrote:

> Friendly ping on an explainer update :)
>
> On Thursday, October 6, 2022 at 7:19:20 PM UTC+2 Jun Kokatsu wrote:
>
>>
>>
>> On Wednesday, October 5, 2022 at 2:52:59 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>>> Contact emailsvoge...@chromium.org
>>>>
>>>
>>>>
>>>> Specification
>>>> https://w3c.github.io/trusted-types/dist/spec/#trusted-html
>>>>
>>>> Summary
>>>>
>>>> Add a function to each "Trusted Type" to create an instance from a
>>>> JavaScript template literal (but not from a dynamically computed string).
>>>> This makes it easy to mark literals in the JavaScript source text as
>>>> "trusted". Example:
>>>>
>>>> const html = TrustedHTML.fromLiteral`Literal Text`;
>>>>
>>>> Blink componentBlink>SecurityFeature>TrustedTypes
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ETrustedTypes>
>>>>
>>>> TAG reviewn/a
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>>
>>>> *Gecko*: No signal. (Gecko has not implemented Trusted Types.)
>>>>
>>>> *WebKit*: No signal. (WebKit has not implemented Trusted Types.)
>>>>
>>>> *Web developers*: Positive (
>>>> https://github.com/w3c/trusted-types/issues/347)
>>>>
>>> Can you point out specific signals in that thread that should be counted
>>> as web developer ones?
>>>
>> It's little hard to tell, but that issue was a feature request from a
>> developer (i.e. me).
>> At the time, I was working in Microsoft where I worked with Bing team to
>> deploy Trusted Types in some of their products, and that was a request that
>> I made.
>>
>>
>>
>>>
>>>
>>>>
>>>> *Other signals*:
>>>>
>>>> WebView application risks
>>>>
>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>> that it has potentially high risk for Android WebView-based applications?
>>>> No.
>>>>
>>>>
>>>>
>>>> Debuggability
>>>>
>>>> It's a new method. Its use can be readily debugged in DevTools.
>>>>
>>>>
>>>> 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
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?Yes
>>>>
>>>> Flag nameTrustedTypesFromLiteral
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Tracking bug
>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1271149
>>>>
>>>> Estimated milestones
>>>>
>>>> 108
>>>>
>>>>
>>>> Anticipated spec changes
>>>>
>>>> Open questions about a feature may be a source of future web compat or
>>>> interop issues. Please list open issues (e.g. links to known github issues
>>>> in the project for the feature specification) whose resolution may
>>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>>> the API in a non-backward-compatible way).
>>>>
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://chromestatus.com/feature/6551852775112704
>>>>
>>>> --
>>>>
>>> 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+...@chromium.org.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMW%2BtvbM8eAxv5HJC0JW192EWSX_VmE7Yugta5Z5G-nXg%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMW%2BtvbM8eAxv5HJC0JW192EWSX_VmE7Yugta5Z5G-nXg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
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/CALG6KPMX%3Db4Lg1EPgumnpfpmrahvhjjWU35f8gKYBvgOzKrw5g%40mail.gmail.com.

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.
To

Re: [blink-dev] Re: Intent to Implement and Ship: Trusted Types fromLiteral

['Daniel Vogelheim' via blink-dev]

Hi Rick,

On Tue, Oct 4, 2022 at 5:40 PM Rick Byers  wrote:

> This seems like a pretty minor and uncontroversial extension to trusted
> types to me. But it also seems like a good time to just check-in on the
> state of discussion around TrustedTypes with other vendors.
>

Our most recent check-ins are a March 2022 WebAppSec meeting
,
where Facebook, Microsoft, and Google reported about their Trusted Types
deployments & result, and a mid-2021 Trusted Types "state of the union"
report
,
also shared and discussed
 with
the W3C WebAppSec community group. These also discuss results, e.g. the
former: "[Number] of XSS [reported at Google] halved in 2020 and 2021. 0
DOM XSS in all TT applications".

I certainly think we should keep these discussions going, but I'm a bit
afraid of over-doing it. Also, we don't really have new results since those
meetings.

Also, can you please share the wpt.fyi link for the tests for this feature?
>

The change is a single CL, and I didn't want to land it before having lgtm
for shipping. Thus the tests aren't in wpt.fyi yet. The tests in the CL are
here

(plus a few modifications to other tests.)

If it's important that the tests are in wpt.fyi for the API owners' review,
I'll be happy to use a feature flag to land this default-off, wait for API
owners' lgtm, and then enable it separately.

-- 
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/CALG6KPMKw7tGwzw--%2BccfE5dvJ6emzND5otZRZA9-sz1A_HcJg%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: Trusted Types fromLiteral

['Daniel Vogelheim' via blink-dev]

Contact emailsvogelh...@chromium.org

Specificationhttps://w3c.github.io/trusted-types/dist/spec/#trusted-html

Summary

Add a function to each "Trusted Type" to create an instance from a
JavaScript template literal (but not from a dynamically computed string).
This makes it easy to mark literals in the JavaScript source text as
"trusted". Example:

const html = TrustedHTML.fromLiteral`Literal Text`;

Blink componentBlink>SecurityFeature>TrustedTypes


TAG reviewn/a

TAG review statusNot applicable

Risks

Interoperability and Compatibility


*Gecko*: No signal. (Gecko has not implemented Trusted Types.)

*WebKit*: No signal. (WebKit has not implemented Trusted Types.)

*Web developers*: Positive (https://github.com/w3c/trusted-types/issues/347)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications? No.



Debuggability

It's a new method. Its use can be readily debugged in DevTools.


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

?Yes

Flag nameTrustedTypesFromLiteral

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1271149

Estimated milestones

108


Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6551852775112704

-- 
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/CALG6KPMW%2BtvbM8eAxv5HJC0JW192EWSX_VmE7Yugta5Z5G-nXg%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

Hello Yaseen,

On Thu, Jul 14, 2022 at 8:13 AM Yaseen Khan  wrote:

> Hi Daniel,
>
> Thanks for your quick update. Here is the below different deprecated
> warning message in M100 to M102 and M103.
>
> *M100/M101/M102:*
> Relaxing the same-origin policy by setting "document.domain" is
> deprecated, and will be disabled by default* in M106, around September
> 2022*. To continue using this feature, please opt-out of origin-keyed
> agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the
> HTTP response for the document and frames.
>
> *Latest M103:*
> Relaxing the same-origin policy by setting document.domain is deprecated,
> and will be disabled by default. To continue using this feature, please
> opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster:
> ?0 header along with the HTTP response for the document and frames.
>

This is due to a general change in the issues panel in DevTools, which has
occured around the same time. The target milestone should be displayed
separately. In my version, M103, there's a link "Learn more: This change
will go into effect with milestone 106."

Thanks to your feedback, however, I noticed that I had forgotten to update
that milestone when making the other changes. I've now submitted a CL to
mark the 'document.domain' issue as scheduled for M109 (rather than M106).
So from the next version on - should be M105 -  this should correctly state
109.


Thanks,
Daniel



> Regards,
>
> Yaseen
>
> On Wednesday, 13 July 2022 at 21:21:10 UTC+5:30 Daniel Vogelheim wrote:
>
>> Hello Yaseen,
>>
>> On Wed, Jul 13, 2022 at 2:47 PM Yaseen Khan  wrote:
>>
>>> Hi Team,
>>>
>>> Earliar chromium browser was displaying an error message as
>>> *document.domain* is going to deperecated in *M106*. Now I can not see
>>> this message and in some blogs postpone to *M109*. Could you confirm on
>>> this - when does this actually would enabled and in which version. It would
>>> be great if you could share dates for better planning to mitigate this very
>>> high risk in our platform.
>>>
>>
>> As written earlier in this thread, the deprecation of document.domain,
>> aka defaulting origin-agent-cluster: to ?1, is scheduled for M109. This is
>> slightly postponed from the original plan at M106.
>> https://chromiumdash.appspot.com/schedule provides a schedule that maps
>> versions to planned release dates.
>>
>> The warning/"issue" in the DevTools issues panel should be active. I'm
>> surprised the message would have disappeared. It should occur whenever
>> document.domain is set, as well as when an access based on a modified
>> document.domain is made. If you have any reproducible case that shows the
>> warning isn't shown even though it should be, I'll gladly investigate.
>>
>> This is scheduled for M109, but note that API owners will have the final
>> call of whether and when to launch this.
>>
>

-- 
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/CALG6KPMbfz0gU%2B5_eD8Jh93_BpH4xEnYBNjXyGYW1tpn24BtcA%40mail.gmail.com.

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

['Daniel Vogelheim' via blink-dev]

Hello Yaseen,

On Wed, Jul 13, 2022 at 2:47 PM Yaseen Khan  wrote:

> Hi Team,
>
> Earliar chromium browser was displaying an error message as
> *document.domain* is going to deperecated in *M106*. Now I can not see
> this message and in some blogs postpone to *M109*. Could you confirm on
> this - when does this actually would enabled and in which version. It would
> be great if you could share dates for better planning to mitigate this very
> high risk in our platform.
>

As written earlier in this thread, the deprecation of document.domain, aka
defaulting origin-agent-cluster: to ?1, is scheduled for M109. This is
slightly postponed from the original plan at M106.
https://chromiumdash.appspot.com/schedule provides a schedule that maps
versions to planned release dates.

The warning/"issue" in the DevTools issues panel should be active. I'm
surprised the message would have disappeared. It should occur whenever
document.domain is set, as well as when an access based on a modified
document.domain is made. If you have any reproducible case that shows the
warning isn't shown even though it should be, I'll gladly investigate.

This is scheduled for M109, but note that API owners will have the final
call of whether and when to launch this.

-- 
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/CALG6KPP_1A4fYbvKQ-1%3DBQJBm0bX6xojAWNWnGV7D7fgrssdng%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.1

['Daniel Vogelheim' via blink-dev]

On Wed, Jun 8, 2022 at 9:45 AM Yoav Weiss  wrote:

> I talked to Daniel Vogelheim about this and we agreed that the best way to
> document this intermediary, Chromium-only state is with in-tree
> documentation, which Daniel is working on.


It landed here: services/network/public/cpp/corb/README.md
.
Please note the appendix about ORB/ORB "v0.1" differences.

Thanks all for your patience.

-- 
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/CALG6KPOSBVAExSn00CWX4tfzLwQ2yWbKmzeaDrcOAi4w0B6Oug%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Sanitizer API MVP

['Daniel Vogelheim' via blink-dev]

On Wed, Jun 1, 2022 at 11:47 AM Yoav Weiss  wrote:

>
>
> On Wed, Jun 1, 2022 at 11:09 AM Daniel Vogelheim 
> wrote:
>
>> Contact emailsvogelh...@chromium.org, mk...@chromium.org,
>> l...@chromium.org
>>
>> Explainerhttps://github.com/WICG/sanitizer-api
>> https://web.dev/sanitizer
>>
>> Specificationhttps://wicg.github.io/sanitizer-api
>>
>> Docshttps://web.dev/sanitizer
>> https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API
>>
>> Summary
>>
>> The Sanitizer API offers an easy to use and safe by default HTML
>> Sanitizer API, which developers can use to remove content that may execute
>> script from arbitrary, user-supplied HTML content. The goal is to make it
>> easier to build XSS-free web applications. The intended contributions of
>> the Sanitizer API are: Making a sanitizer more easily accessible to web
>> developers; be easy to use and safe by default; and shift part of the
>> maintenance burden to the platform. This is the initial "MVP". This
>> implements the current spec except for two features, the .sanitize and
>> .sanitizeFor methods on the Sanitizer object, in order to leave room for
>> more discussion. Our intent is to add the missing features once the
>> discussion has run its course. In all other aspects, this launch faithfully
>> implements the spec as currently written. We feel the current
>> implementation already adds substantial value to the web platform as-is.
>>
>
> So will this only support the `setHTML()` option initially?
>

Yes, exactly.


>>
>> Blink componentBlink>SecurityFeature>SanitizerAPI
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/619
>>
>> TAG review statusIssues addressed
>>
>> Risks
>> Interoperability and Compatibility
>>
>> This is a new API that does not modify existing behaviour. A
>> comprehensive WPT test suite ensures cross-browser compatibility.
>>
>> *Gecko*: In development (
>> https://github.com/mozilla/standards-positions/issues/106)
>> Standards Position:
>> https://github.com/mozilla/standards-positions/issues/106
>> A prototype is In development:
>> https://groups.google.com/g/mozilla.dev.platform/c/C4EHeQlaMbU/m/C8hNg9ehBwAJ
>>
>> *WebKit*: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-March/031731.html,
>> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032155.html) A
>> position statement has been requested. The answer received to date
>> (2021-03-18) avoids giving a definite answer one way or another. Please
>> follow the links for details.
>>
>> *Web developers*: Positive. There have been several articles or blog
>> posts about the Sanitizer API, with a generally positive undertone.
>> Examples:
>> https://portswigger.net/daily-swig/google-mozilla-close-to-finalizing-sanitizer-api-for-chrome-and-firefox-browsers
>>
>> https://blog.bitsrc.io/javascript-sanitizer-api-the-modern-way-to-safe-dom-manipulation-828d5ea7dca6
>>  https://css-tricks.com/html-sanitizer-api/
>>
>>
>> Security
>>
>> The goal of this feature is to make security more accessible. We
>> generally consider this feature low risk, since it's an additive feature
>> that does not extend or interact with existing platform security
>> mechanisms. The specification lists several security risks that are being
>> considered during development of the feature:
>> https://wicg.github.io/sanitizer-api/#security-considerations
>>
>>
>> WebView application risks
>>
>> n/a
>>
>>
>>
>> Debuggability
>>
>> Sanitizer API can be readily debugged with existing DevTools. It does not
>> have hidden state (or other "special" integration) that would warrant
>> customized DevTools support.
>>
>>
>> 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
>> 
>> ?Yes
>>
>> Flag nameSanitizerAPIv0
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1101982
>>
>> Launch bughttps://crbug.com/1306863
>>
>> MeasurementSeveral counters for API calls are defined. (E.g.
>> https://source.chromium.org/search?q=MeasureAs%3DSanitizerAPI%20file:%5C.idl$
>> 
>>  )
>>
>> Estimated milestones
>>
>> 105
>>
>> Anticipated spec changes
>>
>> The plan of record is to migrate the current WICG spec to HTML proper: *
>> https://github.com/WICG/sanitizer-api/issues/114
>>
>> * https://github.com/whatwg/html/issues/7197
>>
>>
>> Two apparently contentious API choices were removed from this launch,
>> which is what makes this an MVP. By making sure the MVP only contains
>> agreed upon APIs we allow for the future evolution of the API in any
>> direction.
>>
>> * https://github.com/WICG/sanitizer-api/issues/129
>>
>> * https://github.com/WICG/sanitizer-a

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

['Daniel Vogelheim' via blink-dev]

On Mon, May 2, 2022 at 8:38 PM Jerilyn D.  wrote:

> Are there any future plans on eventually not honoring the 
> Origin-Agent-Cluster:
> ?0 to allow setting document.domain ? Or will this header always be honored
> ?
>

There is no plan for dropping the Origin-Agent-Cluster header, or the
Origin-Agent-Cluster: ?0 value in particular.


> I read on another site that this Origin-Agent-Cluster: ?0 will only be
> honored in secure context (example: https://) Is this true ? Will it also
> work in http:// ?
>

That's a rather excellent question, and since the point is to preserve
existing behaviour it should also work in a non-secure context. I double
checked, and the current implementation correctly works for insecure
contexts. Please let me know if you find a bug here.

However, I didn't find any unit tests for behaviour specifically in
insecure contexts. I'll add those to ensure that the legacy behaviour will
continue to work correctly.

The information that O-A-C will only be honored in secure contexts is
partially true: Enabling per-origin clustering is indeed bound to a secure
context. But disabling - the legacy behaviour - isn't.

On Tuesday, December 14, 2021 at 6:09:07 AM UTC-8 voge...@chromium.org
> wrote:
>
>> Contact emails
>>
>>
>> *va...@chromium.org, voge...@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 

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

['Daniel Vogelheim' via blink-dev]

Thanks all for the feedback. Update(s):
- The warnings are live, for about two weeks now. Usage is trending down,
but slowly.
- I'd like to postpone flipping the default to M109, as requested (here,
and offline). The existing caveats - particularly a new intent, as
requested by Yoav upthread - still apply.

On Tue, Apr 26, 2022 at 10:13 PM 'tuvia.kaha...@gtempaccount.com' via
blink-dev  wrote:

> We also have a fair amount of dependencies on domain lowering via
> document.domain, which affects millions of users. We are in the process of
> providing solutions for that, but we need more time than M106.
>
> Thanks
>
> On Tuesday, December 14, 2021 at 4:09:07 PM UTC+2 voge...@chromium.org
> wrote:
>
>> Contact emails
>>
>>
>> *va...@chromium.org, voge...@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

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

['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

['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 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]

gt;>
>>>>>>> > 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:
>>>>>

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]

t;>>> 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 
>>>>&g

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.
>>>>- Thi

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

['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.