Re: [blink-dev] Intent to Experiment: Speculation Rules - Document rules, response header, deliveryType

[Camille Lamy]

Hi Jeremy,

We've been reviewing this intent as part of the S&P review process and had 
a few questions:

   - Does the document rules only apply to same-origin links in the page?
   - Is the delivery type gated behind TAO?

Thanks!
Camille

On Friday, December 16, 2022 at 8:58:14 PM UTC+1 Rick Byers wrote:

> LGTM
>
> On Fri, Dec 16, 2022 at 1:54 PM Jeremy Roman  wrote:
>
>> Contact emails
>>
>>
>> *jbro...@chromium.org , adith...@chromium.org 
>> , isabo...@google.com , 
>> dome...@chromium.org , kenjibah...@chromium.org 
>> *Explainer
>>
>>
>> *https://github.com/WICG/nav-speculation/blob/main/triggers.md 
>> https://github.com/w3c/resource-timing/issues/332
>>  
>> *Specification
>>
>>
>> *https://wicg.github.io/nav-speculation/speculation-rules.html 
>> https://github.com/w3c/resource-timing/pull/343
>>  
>> https://github.com/WICG/nav-speculation/pull/180
>>  
>> *Summary
>>
>>
>>
>>
>>
>>
>> *Three enhancements to preloading, under a combined experiment:An 
>> extension to speculation rules syntax that lets the browser obtain URLs for 
>> speculation from link elements in a page. They may include criteria which 
>> restrict which of these links can be used.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.Expose information about how a resource was delivered. For example, 
>> resources which were delivered from the cache (currently exposed through 
>> transferSize) and navigations which were prefetched by the previous page 
>> are useful to identify.An overview of this experiment is drafted (once 
>> reviewed, this will be merged into 
>> WICG/nav-speculation):https://github.com/jeremyroman/nav-speculation/blob/experiment-summary/chrome-2023q1-experiment-overview.md
>>  
>> Of
>>  
>> particular note is that due to the oddity of needing to enable the origin 
>> trial for a potentially third-party origin serving speculation rules, this 
>> trial will be enabled for third-party use and with a bit of special logic 
>> allowing the OT token to be supplied in the document response headers, 
>> providing its origin matches the origin of the external speculation 
>> rules.*Blink 
>> component
>>
>>
>> *Internals>Preload 
>> *TAG
>>  
>> review
>>
>>
>> *https://github.com/w3ctag/design-reviews/issues/721 
>> *TAG review status
>>
>>
>> *Pending*Risks
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>>
>>
>>
>> *Because authors cannot rely on speculation rules being evaluated (or 
>> preloading generally), applications which use them should function 
>> correctly in other browsers and should continue to function correctly were 
>> the feature to be deprecated. Of course, ideally other browsers do find it 
>> compelling to implement this feature.Gecko: No signal 
>> (https://github.com/mozilla/standards-positions/issues/620 
>> )WebKit: No 
>> signal (https://github.com/WebKit/standards-positions/issues/54 
>> )Web developers: 
>> We built these enhancements specifically upon requests from partners that 
>> found the current speculation rules too hard to integrate into their sites, 
>> and have at least one partner lined up to participate in the origin 
>> trial.Other signals:*Activation
>>
>>
>>
>> *Some developers might not be immediately aware of which URLs they can 
>> preload without side effects. This risk is reduced if they primarily use 
>> the feature for same-origin URL patterns they are familiar with.*Security
>>
>>
>>
>> *See 
>> https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations
>>  
>> .*WebView
>>  
>> application risks
>>
>>
>>
>> *None that are specifically anticipated.*Goals for experimentation
>>
>>
>>
>>
>>
>> *We're hoping to gain experience about the ergonomics and impact of 
>> declarative browser-driven preloading of links in the document, tuning 
>> heuristics to provide useful tradeoffs, and refining the API surface to be 
>> easy to use.We're hoping to confirm that the Speculation-Rules header is a 
>> useful way for servers to deliver speculati

Re: [blink-dev] Intent to Ship: Convert adoptedStyleSheets to use ObservableArray

[Camille Lamy]

Hi Mason,

We reviewed this intent in the S&P review today, and we were not quite 
clear on the scope of the change. In particular, is it possible for 
cross-origin documents to share the adoptedStyelSheets? If so, can a style 
sheet used across cross-origin documents be modified and the modifications 
apply cross-origin as well? If so, this would be a security and privacy 
concern.

Thanks!
Camille

On Wednesday, December 1, 2021 at 7:09:08 PM UTC+1 Mason Freed wrote:

> On Tue, Nov 30, 2021 at 8:40 AM Mason Freed  wrote:
>
>> Was ObservableArray and its use in the web platform reviewed by the TAG? 
>>> If not then I think it should be, as there are plans to use it in more 
>>> places than just this. 
>>>
>>
>> No, it wasn't. This is a good suggestion - I'll open a TAG review for 
>> ObservableArray and this conversion of adoptedStyleSheets. There definitely 
>> are plans to expand its use on the platform. 
>>
>
> TAG review filed . 
>
>  
>
>>  
>>
>>>

 Risks


 Interoperability and Compatibility

 Chromium is the only shipped implementation of adoptedStyleSheets. 
 Gecko would like to ship this feature, but has been waiting for the 
 resolution of this issue (FrozenArray vs. ObservableArray) to ship their 
 implementation. This should unblock Gecko [1]. The Edge team supports this 
 change [2]. WebKit continues to be skeptical [3] of this usefulness of 
 this 
 feature, despite the general agreement of the rest of the web components 
 community [4], and the support of the developer community [5][6][7]. So 
 the 
 interop risk is mainly that WebKit decides not to implement this feature. 
 Compat risks (from the change from FrozenArray to ObservableArray) should 
 be minimal, as the same re-assignment semantics will continue to work. As 
 documentation improves, and usage expands, we expect re-assignment usage 
 to 
 wane, and mutation (e.g. adoptedStyleSheets.push()) to expand. [1] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-834749590
  
 [2] https://github.com/whatwg/webidl/issues/1027#issuecomment-940204556 
 [3] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-826036758
  
 [4] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-825055766
  
 [5] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577941622
  
 [6] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-827229881
  
 [7] 
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-827234689

>>>
>>> I appreciate your extensive efforts to achieve consensus and a good 
>>> design. The result is in a spec and has broad consensus, which is great!
>>>
>>
>> Thanks! It has definitely taken some time.
>>  
>>
>>> Gecko: Positive (
 https://github.com/whatwg/webidl/issues/1027#issuecomment-940204556)

 WebKit: Negative (
 https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-826036758
 )

>>>
>>> While those two links are not signals, I think it's:
>>>
>>> * OK to not ask for a formal Gecko signal on this, if you can point to 
>>> clear evidence they are implementing. Can you provide a link?
>>>
>>> * OK to not ask for a formal webkit signal, given their negative signal 
>>> on the public issues. Another one would be redundant and likely yield the 
>>> same (negative) result.
>>>
>>
>> I appreciate it. For Gecko, the main adoptedStyleSheets bug 
>>  hasn't had any 
>> activity in some time, but I believe that's because the ObservableArray 
>> implementation  is 
>> now blocking it. That bug has had regular recent activity, getting 
>> ObservableArray implemented.
>>
>>  
>>
>>> Web developers: Strongly positive Several large web component 
 developers are strongly positive on this feature and change. See several 
 links in the "Interoperability and Compatibility Risks" section.

 Other signals:


 Debuggability

 This feature should remain debuggable via existing JS/devtools 
 infrastructure. There is good support for adoptedStyleSheets already in 
 devtools.


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

 Flag nameBecause few compat risks are anticipated, and because it is 
 relatively difficult to switch the representation (FrozenArray to 
 ObservableArray) via a feature flag, this feature will be enabled by 
 default. This will be done at the start of a new Chromium milestone (M99), 
 and bugs will be monitored carefully in case any breakages are observed.

 Requires code in //c

Re: [blink-dev] Intent to Ship: Convert adoptedStyleSheets to use ObservableArray

[Camille Lamy]

Thanks Mason! I wasn't sure if it was possible to share it cross-origin, 
hence my question. If you can only get a non-shared copied version, then 
this is fine from a security POV.

On Tuesday, December 14, 2021 at 4:53:52 AM UTC+1 Mason Freed wrote:

> Thanks Alex! I did file a TAG review for ObservableArray and this first 
> use by adoptedStyleSheets 
> <https://github.com/w3ctag/design-reviews/issues/693>. No response yet.
>
> On Mon, Dec 13, 2021 at 4:03 PM Alex Russell  
> wrote:
>
>> Thanks Mason, that matches my understanding of the situation too.
>>
>> Can you please file an FYI with the TAG to let them know this new type is 
>> being put into use? It is often helpful for them to stay informed of new 
>> WebIDL primitives that they can suggest to others to help drive consistency.
>>
>> Sending LGTM1 in the tool.
>>
>> On Wednesday, December 8, 2021 at 3:49:55 PM UTC-8 Mason Freed wrote:
>>
>>> Hi Camille,
>>>
>>> Thanks for the question. I guess I have two points/questions:
>>> 1. That sounds like a general question about adoptedStyleSheets (which 
>>> we shipped a few years ago), and isn't at all particular to the conversion 
>>> from FrozenArray to ObservableArray. But did I miss something relevant 
>>> about this change?
>>> 2. Can you help me understand how you'd go about sharing a single 
>>> CSSStyleSheet between cross-origin documents? If you passed it around via 
>>> postMessage, it'd be a (structured clone) copy, so it would no longer be 
>>> shared. I agree that it'd be a (huge) privacy concern if this were 
>>> possible, but I don't see how it could be done. I'm sure I'm missing 
>>> something - perhaps give me more specifics and I'm happy to dig further.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>> On Tue, Dec 7, 2021 at 8:04 AM Camille Lamy  wrote:
>>>
>>>> Hi Mason,
>>>>
>>>> We reviewed this intent in the S&P review today, and we were not quite 
>>>> clear on the scope of the change. In particular, is it possible for 
>>>> cross-origin documents to share the adoptedStyelSheets? If so, can a style 
>>>> sheet used across cross-origin documents be modified and the modifications 
>>>> apply cross-origin as well? If so, this would be a security and privacy 
>>>> concern.
>>>>
>>>> Thanks!
>>>> Camille
>>>>
>>>> On Wednesday, December 1, 2021 at 7:09:08 PM UTC+1 Mason Freed wrote:
>>>>
>>>>> On Tue, Nov 30, 2021 at 8:40 AM Mason Freed  
>>>>> wrote:
>>>>>
>>>>>> Was ObservableArray and its use in the web platform reviewed by the 
>>>>>>> TAG? If not then I think it should be, as there are plans to use it in 
>>>>>>> more 
>>>>>>> places than just this. 
>>>>>>>
>>>>>>
>>>>>> No, it wasn't. This is a good suggestion - I'll open a TAG review for 
>>>>>> ObservableArray and this conversion of adoptedStyleSheets. There 
>>>>>> definitely 
>>>>>> are plans to expand its use on the platform. 
>>>>>>
>>>>>
>>>>> TAG review filed <https://github.com/w3ctag/design-reviews/issues/693>
>>>>> . 
>>>>>
>>>>>  
>>>>>
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Risks
>>>>>>>>
>>>>>>>>
>>>>>>>> Interoperability and Compatibility
>>>>>>>>
>>>>>>>> Chromium is the only shipped implementation of adoptedStyleSheets. 
>>>>>>>> Gecko would like to ship this feature, but has been waiting for the 
>>>>>>>> resolution of this issue (FrozenArray vs. ObservableArray) to ship 
>>>>>>>> their 
>>>>>>>> implementation. This should unblock Gecko [1]. The Edge team supports 
>>>>>>>> this 
>>>>>>>> change [2]. WebKit continues to be skeptical [3] of this usefulness of 
>>>>>>>> this 
>>>>>>>> feature, despite the general agreement of the rest of the web 
>>>>>>>> components 
>>>>>>>> community [4], and the support of the developer community 

[blink-dev] Re: Intent to Prototype: CSS object-view-box and object-overflow

[Camille Lamy]

Hi!

We looked at this as part of the Security & privacy review process for Web 
Platform intents, and we were wondering about the feature behavior with 
regards to iframes. Specifically, we were concerned about the potential for 
a child frame to draw custom content over its parent using this feature. Is 
something like this possible as part of the overflow mechanism? If so, we 
were concerned about the potential for spoofing.

Thanks!
Camille

On Monday, March 7, 2022 at 6:07:28 PM UTC+1 Khushal Sagar wrote:

> Contact emailskhushalsa...@chromium.org, tabatk...@chromium.org, 
> vmp...@chromium.org
>
> Explainerhttps://github.com/w3c/csswg-drafts/issues/7058
>
> SpecificationIn Progress
>
> Summary
>
> The object-view-box and object-overflow properties allow the content for 
> replaced elements to paint outside its content-box, similar to ink overflow 
> for other elements.
>
> Blink componentBlink>CSS 
> 
>
> Motivation
>
> object-view-box and object-overflow allows the author to specify a subset 
> within an image that should draw within the content box of the target 
> replaced element. This enables an author to create an image with a custom 
> glow or shadow applied, with proper ink-overflow behavior like a CSS shadow 
> would have.
>
>
> The property will also be used to draw ink overflow for snapshots 
> generated for shared element transitions 
>  (issue 
> ).
>
> Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/7058
>
> TAG reviewIn Progress (Will file one with a draft spec)
>
> TAG review statusIn Progress
>
> Risks
>
>
> Interoperability and Compatibility
>
> Risk is minimal. This is a new feature for which support can be detected 
> by developers. 
>
> Gecko: Positive (see comment here 
> ). 
> Will file a request for position with a draft spec (see comment here 
> 
> ).
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals:
>
>
> Debuggability
>
> This is debuggable similar to other CSS object-* properties.
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> Flag nameCSSObjectViewBox
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1303102
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5213032857731072
>
> 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/af5057b2-9d20-45b8-8196-93e12836e54an%40chromium.org.

[blink-dev] Intent to Prototype: Document-Isolation-Policy

[Camille Lamy]

Contact emailscl...@google.com

Explainerhttps://github.com/explainers-by-googlers/document-isolation-policy

SpecificationNone

Summary

Document-Isolation-Policy allows a document to enable crossOriginIsolation
for itself, without having to deploy COOP or COEP, and regardless of the
crossOriginIsolation status of the page. The policy is backed by process
isolation. Additionally, the document non-CORS cross-origin subresources
will either be loaded without credentials or will need to have a CORP
header.


Blink componentBlink>SecurityFeature


Motivation

Developers want to build applications that are fast using
SharedArrayBuffers (SAB), which can improve computation time by ~40%. But
SharedArrayBuffers allow to create high-precision timers that can be
exploited in a Spectre attack, allowing to leak cross-origin user data. To
mitigate the risk, SharedArrayBuffers are gated behind crossOriginIsolation
(COI). CrossOriginIsolation requires to deploy both
Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP).
Both have proven hard to deploy, COOP because it prevents communication
with cross-origin popups, and COEP because it imposes restrictions on
third-party embeds. Finally, the whole COOP + COEP model is focused on
providing access to SharedArrayBuffers to the top-level frame. Cross-origin
embeds can only use SABs if their embedder deploys crossOriginIsolation and
delegates the permission to use COI-gated APIs, making the availability of
SABs in third-party iframes very unreliable. Document-Isolation-Policy, is
proposing to solve these deployment concerns by relying on the browser
Out-of-Process-Iframe capability. It will provide a way to securely build
fast applications using SharedArrayBuffers while maintaining communication
with cross-origin popups and not requiring extra work to embed cross-origin
iframes. Finally, it will be available for embedded widgets.


Initial public proposalhttps://github.com/WICG/proposals/issues/145

TAG reviewNone

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal

*WebKit*: No signal

*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

None


Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5141940204208128?gate=5097535879512064

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/CAMKsNvp7Xcgz%3DcMXJ7%2B%2BBgwhO2wOKEkaMiDk_wUY1nprvPG4HQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Document-Isolation-Policy

[Camille Lamy]

n Thu, Apr 4, 2024 at 8:05 AM Vladimir Levin  
>>> wrote:
>>>
>>>> This does sound a bit unfortunate. My understanding is that at least 
>>>> this behavior is deterministic, right? That is, either the same-origin 
>>>> frames will be able to script each other or they won't and this will 
>>>> happen 
>>>> consistently (based on the agent cluster key).
>>>>
>>>> An observation I had is that it seems that the 
>>>> Document-Isolation-Policy is still at the mercy of the platform having the 
>>>> resources to process-isolate frames. It wasn't clear to me from the 
>>>> explainer whether this is already a limitation with the COOP and COEP 
>>>> approaches, however unwieldy those may be. This basically means that one 
>>>> of 
>>>> the listed use-case of authors maintaining two copies of their widgets -- 
>>>> one with SharedArrayBuffers, one without -- doesn't seem to be addressed. 
>>>> Also I'm not sure if it would be possible for 3p iframes to starve 
>>>> platform 
>>>> of such resources so that the top level frame would no longer be able to 
>>>> create 1p frames that have access to COI-gated APIs
>>>>
>>>> (I also don't know what is the right forum in which to raise these 
>>>> issues)
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> On Wed, Apr 3, 2024 at 1:54 PM Charlie Reis  wrote:
>>>>
>>>>> Thanks for sharing this.  I do think it's worth calling attention to this 
>>>>> paragraph 
>>>>> <https://github.com/explainers-by-googlers/document-isolation-policy?tab=readme-ov-file#browsing-context-group-switch-instead-of-agent-cluster-keying>
>>>>>  
>>>>> of the explainer, for one thing to consider about the proposal:
>>>>>
>>>>> The Document-Isolation-Policy proposal relies on agent cluster keying 
>>>>>> to achieve isolation, instead of browsing context group switches. This 
>>>>>> means that it introduces a situation where two same-origin documents 
>>>>>> might 
>>>>>> find themselves in different agent clusters and be unable to have DOM 
>>>>>> access to each other. This is unprecedented in the HTML spec.
>>>>>>
>>>>>
>>>>> In other words, two same-origin frames within the same page (or 
>>>>> anywhere in the same browsing context group) can end up in different 
>>>>> processes, unable to script each other.  It could be that this is 
>>>>> considered fine and might be outweighed by the benefits of the proposal, 
>>>>> though it does have some implications for web developers and for the 
>>>>> browser's implementation:
>>>>>
>>>>>- Web developers might be confused when some attempts to script a 
>>>>>same-origin frame fail, since this has always been possible within a 
>>>>> given 
>>>>>browsing context group.  Maybe this can be mitigated with a different 
>>>>> type 
>>>>>of error message in the DevTools console?
>>>>>- In Chromium's implementation, both the browser process and 
>>>>>renderer process make assumptions that same-origin frames within the 
>>>>> same 
>>>>>browsing context group (also known as content::BrowsingInstance) must 
>>>>> be in 
>>>>>the same process so that they can script each other.  Dividing that up 
>>>>>based on Document-Isolation-Policy seems like it should be possible, 
>>>>> though 
>>>>>it would add some complexity and might require some auditing of 
>>>>> process 
>>>>>model 
>>>>>
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md>
>>>>>  
>>>>>code.
>>>>>
>>>>> Maybe this is a manageable risk?
>>>>>
>>>>> Thanks,
>>>>> Charlie
>>>>>
>>>>>
>>>>> On Wed, Apr 3, 2024 at 5:41 AM Camille Lamy  
>>>>> wrote:
>>>>>
>>>>>> Contact emailscl...@google.com
>>>>>>
>>>>>> Explainer
>>>>>> https://github.com/explainers-by-googlers/document-isolatio

[blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Camille Lamy]

Contact emails

v...@chromium.org cl...@chromium.org

Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k

Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects

Design docs Including the new security requirements

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

Discussion how and what to gate

https://github.com/whatwg/html/issues/4732

Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
cross-origin isolated environments, matching the behavior we've recently
shipped on Android and Firefox. We've performed that change in Chrome 92. A
reverse OT was started to give developers the option to use SABs in case
they are not able to adopt cross origin isolation yet.

We’ve worked with multiple internal and external users of the OT to
understand their use cases and why they can’t adopt yet. With
COEP:credentialless and iframes credentialless now available, the SAB non
COI usage went further down.

Unfortunately, the cascading requirements of COEP are still a blocker for
COI adoption. Some of the users of the OT rely heavily on credentialled
cross-origin subresources, so credentialless modes are not an option for
them. And their apps are complex enough that they are still blocked on
child iframes supporting COEP.

To address this, we’ve explored ways of enabling COI that would take
advantage of process isolation in order to waive requirements on child
frames to enforce COEP.

We’ve sent out the I2P for Document-Isolation-Policy and are aiming to OT
it starting with M128. Giving developers 3 milestones to verify and provide
feedback, we’re aiming for a release in M131.

As we know the cascading is the final blocker for COI adoption and
therefore SAB usage on Desktop, we’re asking to extend the OT to M131.

Blink component

Blink>JavaScript


Search tags

SharedArrayBuffer 
, SAB 

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/471
TAG review statusClosed
RisksInteroperability and Compatibility

We expect this change to negatively impact developers using
`SharedArrayBuffer` today. Chrome was the only platform where SABs have
been available without COOP/COEP. Therefore we need to give developers the
right capabilities and a clear path forward to ensure they have enough time
to adopt. We aim to mitigate these risks by adopting a longer-than-usual
depreciation period with console warnings/issues and a reverse origin
trial.

Good news is usage is down to ~0.0777%

page loads and that other browsers have or are shipping SABs again gated
behind COOP/COEP. Bad news is that Chromium was the only browser that
supported SABs without COI, therefore we need to provide a migration path
to not break existing sites.

Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)

WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

No - This OT is only for desktop, as this was the only platform where SABs
have been available without COOP/COEP.

Android re-enabled SABs gated behind COOP/COEP:
https://chromestatus.com/feature/5171863141482496

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1144104

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1138860

Blink-dev Thread

Planning isolation requirements (COOP/COEP) for SharedArrayBuffer


I2S


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4570991992766464

-- 
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/CAMKsNvrmoF0hRkDzA3U0pVW-dXHvWZ1Objr4eABsy%2BJOPgmJUg%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Document-Isolation-Policy

[Camille Lamy]

On Monday, April 8, 2024 at 6:12:23 PM UTC+2 thomascli...@gmail.com wrote:

There is a huge demand for protecting data that's shared with users  Any 
help in strong binding data to origin and blocking sharing would a big win.


I believe that is a different problem from the one we're trying to solve 
with this API. Would you happen to have more details about the issue you're 
referring to?
 


thx ..Tom (mobile)

On Mon, Apr 8, 2024, 1:20 AM Yoav Weiss (@Shopify)  
wrote:

This is very interesting!

Do I understand correctly and the main reason this would be easier to 
deploy is because embedded iframes and popups won't need to deploy COEP in 
this model?


Yes. They also wouldn't need to deploy COOP, and so would be able to 
interact with cross-origin popups.
 


On Fri, Apr 5, 2024 at 12:14 PM Camille Lamy  wrote:

Yes the user agent keying is deterministic, and we're adding reporting to 
warn developers if they end up having two same origin documents that could 
normally have DOM access but can't due to Document-Isolation-Policy.


I'm not sure same-origin isolation won't end up being a desired feature 
on its own. I heard developers asking for stronger isolation primitives on 
more than one occasion. I'll talk to folks and think about it some more.
 

Our recommendation would be to adopt the header on all documents of an 
origin, which removes the concerns around script access. As a followup, we 
might resurrect the Origin-Policy work to help with this issue.


Origin-Policy would definitely help avoid mistakes here..
 


For COOP and COEP, you're correct to note that they are not available due 
to the platform limitations on Android WebView. Because of this, the 
crossOriginIsolated spec already has a notion of crossOriginIsolation being 
either logical (ie no API access) or effective (ie API access). We're 
building on this existing notion.

In terms of platform support, our goal is to first release on desktop, in 
order to finally end the ungated SAB reverse Origin Trial. Then we'll 
extend to Android (but not Android WebView). For Android, the situation is 
a bit different from full Site Isolation, because here the isolation and 
resulting increase memory consumption is driven by the website as opposed 
to the platform. We might not implement full functionality on low-end 
Android, but then none of the developers interested in the API want to have 
it run on low-end Android. Basically, this gives access to 
SharedArrayBuffers, which are mostly useful to cut calculation time in 
heavy web apps, that wouldn't run on devices with limited hardware.

Hope that helps!
Camille

On Thursday, April 4, 2024 at 9:45:04 PM UTC+2 Charlie Reis wrote:

I seem to recall that Android Chrome is also limited here, but maybe that 
has changed and my knowledge is outdated.


Correct, we don't usually create out-of-process iframes on Android Chrome 
if the device has less than 2G of RAM.  Otherwise we allow it (e.g., for 
partial 
Site Isolation 
<https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md#Partial-Site-Isolation>).
  
I'm not sure if COOP+COEP has any restrictions on low-end Android devices, 
since that mode requires multiple processes but not out-of-process 
iframes.  For Document-Isolation-Policy, I believe there's some notes about 
low-end Android devices in the explainer, maybe suggesting that it's less 
needed on such devices?  I'll let Camille clarify.

Charlie 

On Thu, Apr 4, 2024 at 12:27 PM Vladimir Levin  wrote:



On Thu, Apr 4, 2024 at 12:11 PM Charlie Reis  wrote:

My understanding is that at least this behavior is deterministic, right? 
That is, either the same-origin frames will be able to script each other or 
they won't and this will happen consistently (based on the agent cluster 
key).


Yes, I think it would be deterministic based on the headers, so hopefully 
education via error messages would help.

An observation I had is that it seems that the Document-Isolation-Policy is 
still at the mercy of the platform having the resources to process-isolate 
frames.


Camille can probably confirm the details, but I believe that's right.  
COOP+COEP depends on the platform being able to open a new window in a 
different process, which I think all platforms but Android WebView can 
support at this point (?).  Document-Isolation-Policy would depend on 
out-of-process iframes, which wouldn't work on Android WebView or iOS, at 
least for the time being.  On platforms that do support out-of-process 
iframes, it would make crossOriginIsolated modes much easier to adopt, 
though.


I seem to recall that Android Chrome is also limited here, but maybe that 
has changed and my knowledge is outdated.
 


Also I'm not sure if it would be possible for 3p iframes to starve platform 
of such resources so that the top level frame would no longe

[blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Camille Lamy]

Contact emails

v...@chromium.org cl...@chromium.org

Explainer

https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k

Specification

https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects

Design docs Including the new security requirements

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

Discussion how and what to gate

https://github.com/whatwg/html/issues/4732

Summary

‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
cross-origin isolated environments, matching the behavior we've recently
shipped on Android and Firefox. We've performed that change in Chrome 92. A
reverse OT was started to give developers the option to use SABs in case
they are not able to adopt cross origin isolation yet.

We’ve worked with multiple internal and external users of the OT to
understand their use cases and why they can’t adopt yet. With
COEP:credentialless and iframes credentialless now available, the SAB non
COI usage went further down.

Unfortunately, the cascading requirements of COEP are still a blocker for
COI adoption. Some of the users of the OT rely heavily on credentialled
cross-origin subresources, so credentialless modes are not an option for
them. And their apps are complex enough that they are still blocked on
child iframes supporting COEP.

To address this, we’re exploring ways of enabling COI that would take
advantage of process isolation in order to waive requirements on child
frames to enforce COEP. However, this is still at an exploratory stage. So
we would like to request a 3 milestones extension (until M124) to this
deprecation trial. This will give us enough time to propose a solution and
discuss it with the standards community and users of the reverse OT. We
will then come back with a proposed solution to finally end the OT and get
the remaining users of the reverse OT, as well as a timeline for the OT
ending.
Blink component

Blink>JavaScript


Search tags

SharedArrayBuffer 
, SAB 

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/471
TAG review statusClosed
RisksInteroperability and Compatibility

We expect this change to negatively impact developers using
`SharedArrayBuffer` today. Chrome was the only platform where SABs have
been available without COOP/COEP. Therefore we need to give developers the
right capabilities and a clear path forward to ensure they’ve enough time
to adopt. We aim to mitigate these risks by adopting a longer-than-usual
depreciation period with console warnings/issues and a reverse origin
trial.

Good news is usage is down to ~0.0209%

page loads and that other browsers have or are shipping SABs again gated
behind COOP/COEP. Bad news is that Chromium was the only browser that
supported SABs without COI, therefore we need to provide a migration path
to not break existing sites.

Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)

WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

No - This OT is only for desktop, as this was the only platform where SABs
have been available without COOP/COEP.

Android re-enabled SABs gated behind COOP/COEP:
https://chromestatus.com/feature/5171863141482496

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1144104

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1138860

Blink-dev Thread

Planning isolation requirements (COOP/COEP) for SharedArrayBuffer


I2S


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4570991992766464

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

Re: [blink-dev] Intent to Experiment: Keep strong references to resources in Blink memory cache

[Camille Lamy]

In the S&P review, we were wondering if the memory pressure case event was 
an event exposed to the web page or an internal Chrome event? In the latter 
case, there may be a potential for XS-Leaks.

Thanks!
On Monday, March 20, 2023 at 3:57:24 PM UTC+1 Mike Taylor wrote:

> LGTM to experiment in canary/dev. For clarity, how long do you plan to 
> experiment?
>
> (I don't think you need an LGTM in this case, 
> https://www.chromium.org/blink/launching-features/#origin-trials mentions 
> needing an LGTM to experiment on beta or stable - but thanks for sending 
> the intent!).
> On 3/20/23 10:16 AM, Jiacheng Guo wrote:
>
> The spec says:
> User agents may copy entries from one Document 
>  object's list 
> of available images 
>  
> to 
> another at any time
> I believe the change is in line with the spec. It makes this behavior more 
> frequent. The spec does not define behavior for other resources for now. 
> The other involved resource types are stylesheet, fonts and scripts. It 
> would be desirable to add a description about MemoryCache for these 
> resources in the spec and allow cross-document reusing. For now I believe 
> it is acceptable to launch the experiment in dev and canary.
>
> We plan to launch the experiment in dev and canary in April. There are 
> concerns about the memory footprint increase introduced by the change so we 
> decide to hold the experiment in beta or stable. The experiment will 
> provide data for the tradeoff between memory consumption and load speed. If 
> the experiments in dev and canary show a positive impact on page loading 
> metrics, we plan to refine the resource saving strategy and launch with the 
> new implementation.
>
> On Mon, Mar 20, 2023 at 10:49 PM Mike Taylor  
> wrote:
>
>> What are the desired timelines for the experiments?
>>
>> The design doc mentions only testing in dev and canary - do you plan to 
>> eventually experiment in beta or stable?
>> On 3/17/23 2:08 PM, 'Jiacheng Guo' via blink-dev wrote:
>>
>> Contact emails g...@google.com
>>
>> Explainer 
>> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>>
>> Specification The feature is not web-spec related.
>>
>> Design docs 
>>
>> https://docs.google.com/document/d/1jcdXkoFBbdxmp_EYIrrOJvEgYd0hGBAr4Nbno7KWnIs/edit?usp=sharing
>>
>> Summary 
>>
>> To measure the impact of garbage collection on Blink memory cache and 
>> potential performance boost, we plan to keep strong references to loaded 
>> resources in the Blink memory cache. The change will serve as an estimation 
>> only project to collect data about the maximal cache hit rate with all 
>> resources available.
>>
>>
>> Blink component Blink>Loader 
>> 
>>
>> TAG review 
>> TAG review is not required since the experiment changes the internal 
>> behavior of renderer and is transparent to the websites and web developers.
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> Resource reference lifetime does not affect the behavior of the browser. 
>> We do not expect there to be interoperability or compatibility issues.
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks 
>>
>> The change does not modify the behavior of web APIs
>>
>> Goals for experimentation 
>>
>> The four configurations will be launched on dev/canary. The combinations 
>> are: * The control group. No strong reference to resources. * Save strong 
>> references for all resources of all types for all the pages. * Save strong 
>> references for only script, fonts and stylesheets for all pages. * Save 
>> strong references for all resources for only one page. * Save strong 
>> references for only script, fonts and stylesheets for only one page. We 
>> will evaluate the following metrics under different configurations * Core 
>> web browsing metric (FCP/LCP etc) * Cache hit rate: 
>> Blink.MemoryCache.RevalidationPolicy * Memory footprint * Crash Rate 
>>
>>
>> Reason this experiment is being extended 
>>
>> Ongoing technical constraints 
>>
>> 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 
>> 
>> ? No, resource reference lifetime in blink is invisible to the websites.
>>
>> Flag name MemoryCacheStrongReference for the overall configuration. 
>> MemoryCacheStrongReferenceSingleUnload and 
>> MemoryCacheStrongReferenceFilterImages for sub configurations
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1409349
>>
>> Estimated milestones 
>>
>> The feature i

Re: [blink-dev] Intent to Prototype: Document Render-Blocking

[Camille Lamy]

Hi Khushal,

I am reviewing this for security as part of the OWP S&P review process. I
had a few questions regarding the API to make sure we're assessing
it correctly.

   1. Is the render blocking attribute something that only applies to one
   particular document, and does not block rendering of other documents (e.g.
   child iframes, parent iframes?)?
   2. Can the render blocking attribute only be set by the document that
   will be render blocked?

Thanks!
Camille

On Wed, Aug 9, 2023 at 11:08 PM 'Khushal Sagar' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailskhushalsa...@google.com
>
> Explainer
> https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md
>
> SpecificationNone
>
> Summary
>
> This feature enables authors to block rendering of a Document until the
> critical content has been parsed, ensuring a consistent first paint across
> all browsers. Without this feature, the first paint's state depends on the
> heuristics for parser yielding which can vary across browsers. This is
> particularly important for View Transitions where the parsed DOM state on
> the first frame can drastically change the transition created.
>
>
> Blink componentBlink>ViewTransitions>MPA
> 
>
> Motivation
>
> The Web is designed with a model for incremental rendering. When a
> Document is loading, the browser can render its intermediate states before
> fetching all the requisite sub-resources, executing all script or
> fetching/parsing the complete Document. While this is great to reduce the
> time for first paint, there is a tradeoff between showing a jarring flash
> of intermediate Document state (which could be unstyled or have more CLS)
> vs blocking rendering on high priority sub-resources within a reasonable
> timeout. The render-blocking concept helps browsers in making this
> tradeoff. It lets authors specify the set of stylesheets and script
> elements which should block rendering. For example, a stylesheet with the
> rules necessary to ensure a stable layout. But authors can’t specify which
> nodes should be added to the DOM before first render. This proposal aims to
> fill this gap.
>
>
> Initial public proposalhttps://github.com/whatwg/html/issues/9332
>
> TAG reviewNone
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *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
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5113053598711808
>
> 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/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com
> 
> .
>

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