[blink-dev] Re: Intent to Prototype: Realms Initialization Control

['Eli Grey' via blink-dev]

(You can ignore the confidentiality notice in that last message.)

On Wednesday, August 28, 2024 at 2:49:53 AM UTC-7 Chromestatus wrote:

Contact emails weizm...@gmail.com, yoav@shopify.com 

Explainer https://github.com/WICG/Realms-Initialization-Control 

Specification https://github.com/WICG/Realms-Initialization-Control 

Summary 

Support a new CSP directive which points to a remote (first party) script 
file to be loaded before any other JavaScript code within every child realm 
that shares an origin with the top realm of a website (such as same origin 
iframes and popups). This allows websites to regain control over which 
capabilities such a realm exposes to untrusted entities living within the 
website and thus allow them to tame and control it. 


Blink component Blink 
 

Motivation 

The web is a great platform for creating composable software, but not to do 
so securely - the environment and the APIs available make it extremely 
difficult for applications to contain a program without having to trust it, 
especially when interacting with the DOM. Unfortunately, securing a supply 
chain - telling good code from bad code within the dependencies from which 
an application is composed - is very hard. This is evident by the 
prevalence of services focused on detecting threats both before they get 
baked into an application (at build-time) and while being executed on the 
fly (at runtime). One way to approach this problem at runtime is by 
virtualization - redefining JavaScript capabilities (commonly known as 
monkey patching) to behave similarly while hardening them to limit how they 
can be used. However, due to some characteristics of how the web is 
designed, there are some major blockers in fully unleashing the power of 
virtualization in favor of introducing runtime security. One of those 
blockers is the lack of control web applications have over safe 
introduction of same origin realms into their execution environment at 
runtime. The motivation behind this proposal is to remove this blocker by 
providing developers a way to control the initialization of same origin 
realms to tame access to powerful capabilities those leak.


Initial public proposal 
https://github.com/WICG/Realms-Initialization-Control 

TAG review None 

TAG review status Pending 

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://flags None 

Finch feature name None 

Non-finch justification None 

Requires code in //chrome? True 

Estimated milestones 

No milestones specified


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

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/ad1866a5-6cc3-426c-bf31-a185f018580en%40chromium.org.

[blink-dev] Re: Intent to Prototype: Realms Initialization Control

['Eli Grey' via blink-dev]

It would be great if this API could cover all same-origin realm creation 
sources, including workers and worklets, if possible. That enables much 
more comprehensive use cases with less unexpected behavior for web content 
authors.

On Thursday, August 29, 2024 at 6:53:28 AM UTC-7 Kanaru Sato wrote:

> Hi there,
>
> I'm an independent contributor interested in this feature.
>
> I'm really eager to get involved with the implementation of the feature or 
> contribute in other ways.
> Could you please tell me if it's possible?
> I've just fixed few bugs for Blink, and I might not fully understand all 
> the rules about "Intent to" yet.
>
> If it's not possible at this point, could you please guide me on how I 
> could get involved in the implementation of new features like this in the 
> future?
> Any advice would be greatly appreciated :)
> On Thursday, August 29, 2024 at 1:41:20 AM UTC+9 Gal Weizman wrote:
>
>> Correction: "Requires code in //chrome?" is False, not True (my mistake)
>>
>> On Wednesday 28 August 2024 at 12:49:53 UTC+3 Chromestatus wrote:
>>
>> Contact emails weizm...@gmail.com, yoav@shopify.com 
>>
>> Explainer https://github.com/WICG/Realms-Initialization-Control 
>>
>> Specification https://github.com/WICG/Realms-Initialization-Control 
>>
>> Summary 
>>
>> Support a new CSP directive which points to a remote (first party) script 
>> file to be loaded before any other JavaScript code within every child realm 
>> that shares an origin with the top realm of a website (such as same origin 
>> iframes and popups). This allows websites to regain control over which 
>> capabilities such a realm exposes to untrusted entities living within the 
>> website and thus allow them to tame and control it. 
>>
>>
>> Blink component Blink 
>>  
>>
>> Motivation 
>>
>> The web is a great platform for creating composable software, but not to 
>> do so securely - the environment and the APIs available make it extremely 
>> difficult for applications to contain a program without having to trust it, 
>> especially when interacting with the DOM. Unfortunately, securing a supply 
>> chain - telling good code from bad code within the dependencies from which 
>> an application is composed - is very hard. This is evident by the 
>> prevalence of services focused on detecting threats both before they get 
>> baked into an application (at build-time) and while being executed on the 
>> fly (at runtime). One way to approach this problem at runtime is by 
>> virtualization - redefining JavaScript capabilities (commonly known as 
>> monkey patching) to behave similarly while hardening them to limit how they 
>> can be used. However, due to some characteristics of how the web is 
>> designed, there are some major blockers in fully unleashing the power of 
>> virtualization in favor of introducing runtime security. One of those 
>> blockers is the lack of control web applications have over safe 
>> introduction of same origin realms into their execution environment at 
>> runtime. The motivation behind this proposal is to remove this blocker by 
>> providing developers a way to control the initialization of same origin 
>> realms to tame access to powerful capabilities those leak.
>>
>>
>> Initial public proposal 
>> https://github.com/WICG/Realms-Initialization-Control 
>>
>> TAG review None 
>>
>> TAG review status Pending 
>>
>> 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://flags None 
>>
>> Finch feature name None 
>>
>> Non-finch justification None 
>>
>> Requires code in //chrome? False
>>
>>
>>
>> Estimated milestones 
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status 
>> https://chromestatus.com/feature/5080729822953472?gate=5143912415756288 
>>
>> This intent message was generated by Chrome Platform Status 
>> . 
>>
>>
-- 
This email may be confidential or privileged.  If you received this 
communication by mistake, please don't forward it to anyone else, please 
erase all copies and attachments, and please let me know that it went to 
the wrong person. Thanks.

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

[blink-dev] Re: Intent to Experiment: Reduce Accept-Language

['Eli Grey' via blink-dev]

Restricting accept-language to 'common combinations' is fundamentally at 
odds with personal agency. This can break the web for people with uncommon 
combinations of accepted languages. This change would effectively 
discriminate against these people by denying them access to websites in 
their preferred languages that previously worked just fine.

Language preferences should not be ignored just because they're unique, and 
therefore trackable.

On Wednesday, August 7, 2024 at 8:41:48 AM UTC-7 vict...@chromium.org wrote:

Email Body

Contact emails

vict...@chromium.org, mike...@chromium.org 

Explainer

https://github.com/explainers-by-googlers/reduce-accept-language 

TAG reviewTo be filed.
Summary

In order to reduce the amount of passively available entropy in HTTP 
requests, we want to reduce the amount of information the Accept-Language 
header exposes in HTTP requests and JS interface navigator.languages. 
Instead of sending every user's language preferences via Accept-Language, 
we only send the user’s most preferred language after language negotiation 
in the Accept-Language header. For the HTTP Accept-Language header, we will 
potentially expand a base language based on the language-region pair (e.g., 
if the preferred language is “en-US” we will expand to “en-US, en;q=0.9”). 
The JS getter navigator.languages returns the same value as 
navigator.language. 

We would like to run a Finch 1% experiment from M128 to M131 inclusive.

Blink component

Privacy>Fingerprinting 


Risks

Interoperability and Compatibility

The compatibility risk is relatively low for most users since we're 
planning to reduce the amount of information in the Accept-Language header 
and navigator.languages, rather than remove the header or change value 
format in the header. Most existing Accept-Language detection code should 
continue to work. This experiment should help us validate this assumption 
and identify corner cases.

As for interoperability, for multilingual sites to rely on the 
Accept-Language, developers would need to depend on a user's full 
Accept-Language list for some browsers and a primary user's Accept-Language 
for others. Another signal is that the Chrome incognito model already 
reduced the Accept-Language header and JS interface navigator.languages to 
one language, and Safari ships this behavior for many users today. 

Gecko: Pending (https://github.com/mozilla/standards-positions/issues/1014) 

WebKit: Shipped (https://github.com/WebKit/standards-positions/issues/338) 
Safari already reduced the Accept-Language to a single language in most 
cases.

Web developers: Some web developers are concerned about the client-side 
language negotiation implications (
https://github.com/Tanych/accept-language/issues/10).

Experiment Goals

The goal of this experiment is to ensure web compatibility with our 
proposed changes. Developers can also test how reducing the Accept-Language 
request header and the JS getter navigator.languages will affect their 
systems via the  chrome://flags/#reduce-accept-language flag, especially to 
understand the impact on client side language negotiation via 
navigator.languages. We will be relying heavily on user and developer 
feedback to identify where breakage occurs,  or where use cases are not 
accounted for, especially for multilingual sites depending on the 
Accept-Language header, and navigator.languages.

Experiment Risks

There are some risks, as many multilingual sites have come to rely on the 
value in Accept-Language header and JS interfaces navigator.languages to 
send the right representation pages to the user.  Site breakage can take 
many forms, both obvious and non-obvious - which is the point of running 
this experiment. If we are confident the design is largely web-compatible, 
we will request a Deprecation Trial for sites to be able to have time to 
migrate or modify how their sites work.

Debuggability

Both of these settings and the resulting network requests are visible in 
DevTools.

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

No (All but WebView)

Is this feature fully tested by web-platform-tests 

?

No (We fully test in browser_tests, WPT has limits to cover all the test 
cases in the Accept-Language header).

Flag name on chrome://flags

#reduce-accept-language

Finch Flag name

kReduceAcceptLanguage
Tracking bug

https://issues.chromium.org/issues/40218547 
Launch bug

https://launch.corp.google.com/launch/4317282
Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5188040623390720 
 

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this gro

[blink-dev] Re: Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Eli Grey' via blink-dev]

This change would impact the ability of first parties to regulate and 
prevent reportEvent beacons. Although this requires mutual opt-in, I expect 
scenarios to eventually come up where a site owner wants to allow 
cross-origin reportEvent only for certain origins.

On Wednesday, May 8, 2024 at 8:30:58 AM UTC-7 lbr...@google.com wrote:

> Contact emails
>
> lbr...@google.com, shiva...@chromium.org, jka...@chromium.org
>
> Explainer(s)
>
> https://github.com/WICG/turtledove/pull/1134
>
> Spec(s)
>
> https://github.com/WICG/fenced-frame/pull/152
>
> Summary
>
> Ad frames (both fenced frames and urn-iframes) created through a Protected 
> Audience auction, as well as their same-origin nested iframes, are allowed 
> to call reportEvent() API 
> 
>  
> to send event-level reports. It's also important for third-parties on 
> Protected Audience-created ads to have the same measurement and reporting 
> capabilities for spam detection, brand safety, and measurement 
> verification. However, the API as it exists currently has a same-origin 
> child iframe restriction which poses a complication as described below.
>
> If an ad buyer wins an ad auction and its ad frame is displayed on a page, 
> it might choose to embed a subframe that points to a third-party server 
> that hosts the actual ad instead. With this use case, and with the current 
> state of the reportEvent() API, the actual ad's document cannot directly 
> call reportEvent() the way that its embedder can since the document is in a 
> cross-origin nested iframe. Instead, it has to get its embedder to actually 
> send the beacon by letting the embedder know via a postMessage. This will 
> not be an ergonomic solution for this use case.
>
> With this change, a cross-origin subframe can opt in to sending 
> reportEvent() beacons using its ancestor's reporting metadata by calling 
> reportEvent() with the parameter crossOriginExposed=true. This is the same 
> syntax as is currently used by the main render URL frame to opt in to 
> sending cross-origin automatic beacons with data (this means the FenceEvent 
> IDL will stay the same).
>
> The main ad render URL frame will opt in with a new 
> "Allow-Cross-Origin-Event-Reporting" response header. Its valid values will 
> be true and false, and will default to false when omitted. This will not be 
> required for documents that are same-origin to the FencedFrameConfig's 
> mapped url.
>
> This is a convenience change (not privacy impacting), as it's already 
> possible (but cumbersome) for the third-party to postMessage the parent 
> frame to send the report on their behalf. For security reasons, the 
> proposal requires opt-ins from both the main ad frame and the cross-origin 
> iframe.
>
> Blink component
>
> Blink>FencedFrames 
> 
>
> TAG reviews and status
>
> Fenced frames existing TAG review appended with these spec changes 
> https://github.com/w3ctag/design-reviews/issues/838# 
> 
>
> Link to Origin Trial feedback summary
>
> No Origin Trial performed
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
> Chrome OS, Android, and Android WebView)?
>
> Supported on all the above platforms except Android WebView.
>
> Debuggability
>
> Additional debugging capabilities are not necessary for these feature 
> changes.
>
> Risks
>
> Compatibility
>
> This is an added functionality and is backward compatible.
>
> Interoperability
>
> There are no interoperability risks as no other browsers have decided to 
> implement these features yet. We have not received any standards positions 
> from Mozilla  
> or Webkit .
>
> Is this feature fully tested by web-platform-tests 
> ?
>  
> Link to test suite results from wpt.fyi. 
>
> Yes. New reportEvent() beacon tests have been added to test cross-origin 
> beacons.
>
> fence-report-event-cross-origin-content-initiated.https.html (test 
> )
>  
> (results 
> 
> )
>
> fence-report-event-cross-origin-nested-urn-iframe.https.html (test 
> )
>  
> (results 
> 
> )
>
> fence-report-event-cross-origin-nested.https.html (test 
>

Re: [blink-dev] Intent to Ship: requestStorageAccessFor (for First-Party Sets)

['Eli Grey' via blink-dev]

Are you planning to ship both the plural and singular APIs or just one of 
the two?

On Thursday, April 6, 2023 at 9:26:28 AM UTC-7 mike...@chromium.org wrote:

> LGTM2
> On 3/29/23 10:45 AM, Johann Hofmann wrote:
>
> Thanks Yoav! 
>
> One minor note to the group that we successfully renamed the repository 
> and so the explainer and spec can now be found at 
> https://github.com/privacycg/requestStorageAccessFor and 
> https://privacycg.github.io/requestStorageAccessFor/, respectively. 
> (apologies to those who hit a 404 on the spec link)
>
> On Wed, Mar 29, 2023 at 11:39 AM Yoav Weiss  wrote:
>
>> LGTM1 
>>
>> I appreciate the reliance on this API on FPS as an internal concept 
>> (equivalent to the reliance of other browsers on entities.json) to 
>> significantly reduce its user friction as well as the risk that other 
>> vendors are concerned with (e.g. reputation concerns).
>>
>> I think we've made significant strides towards eventual interoperability 
>> with this, without compromising on the use cases we care about, and without 
>> unnecessarily burdening users with privacy labour.
>>
>> On Mon, Mar 20, 2023 at 10:35 PM Johann Hofmann  
>> wrote:
>>
>>> Contact emails 
>>>
>>> joha...@chromium.org, mreic...@chromium.org, kaust...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/privacycg/requestStorageAccessForOrigin
>>>
>>> (note that we recently updated the name to remove “origin”, but not yet 
>>> the repository name)
>>>
>>> Specification 
>>>
>>> https://privacycg.github.io/requestStorageAccessForOrigin
>>>
>>> Summary 
>>>
>>> An extension to the Storage Access API that allows a top-level site to 
>>> request access to unpartitioned ("first-party") cookies on behalf of 
>>> embedded sites. Browsers will have discretion to grant or deny access, with 
>>> mechanisms like First-Party Set membership as a potential signal. This 
>>> allows for use of the Storage Access API by top-level sites.
>>>
>>> For now, we intend to ship requestStorageAccessFor without user-facing 
>>> prompts, instead relying on information from First-Party Sets to determine 
>>> which sites should be granted storage access.
>>>
>>> Blink component 
>>>
>>> Blink>StorageAccessAPI 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/808
>>>
>>> TAG review status 
>>>
>>> Pending
>>>
>>> Risks 
>>>
>>> Interoperability and Compatibility 
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/736)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/125)
>>>
>>> This has been discussed with other browser vendors outside of the 
>>> standards-positions repositories. These browsers ship this functionality as 
>>> a version that is only accessible to internal code (as an 
>>> anti-cross-site-cookie-breakage measure), but haven’t exposed it to 
>>> developers, primarily out of prompt relevance concerns. There have been 
>>> mixed reactions to our proposal, with the primary feedback being on 
>>> reputation 
>>> concerns with potential prompts 
>>> , 
>>> and a desire to maintain the security benefits from cross-site cookie 
>>> blocking to an even larger extent 
>>> . 
>>> We intend to work on these concerns in collaboration with other browsers 
>>> (if possible).
>>>
>>> Edge: No public signal. However, we’ve discussed this with Edge and 
>>> they are supportive of this additional API surface and will work on 
>>> enabling it (i.e. providing the prompts or FPS mechanisms to gate it) on 
>>> Edge as well.
>>>
>>> Web developers:
>>>
>>> Positive. There has been developer 
>>> 
>>>  
>>> feedback  on SAA 
>>> asking for this or similar functionality, as well as communication with 
>>> partners that are trying out the API to utilize FPS.
>>>
>>> Ergonomics 
>>>
>>> Like requestStorageAccess, this API requires additional work from the 
>>> developer compared to the old state of "passive" cross-site cookie access. 
>>> This is an inherent, intentional property of the design.
>>>
>>> For security reasons, this feature requires developers to use either 
>>> CORS headers (for non-iframe subresources) or requestStorageAccess in 
>>> iframes to be able to access cross-site cookies after a 
>>> requestStorageAccessFor call.
>>>
>>>
>>> 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 
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)? 

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

['Eli Grey' via blink-dev]

Hi Mike,

By not coordinating Privacy Sandbox timeline with the unpartitioned storage 
deprecation timeline, Chrome is pushing us to use cookies due having to 
balance user privacy with customer demands to use all available browser 
capabilities. We currently support cross-site sync in Chrome/Edge only 
using unpartitioned storage, and by killing this feature without aligning 
deprecation timelines, Chrome is going to make us leak user consent data 
over the network with cookies. This results in an effective net privacy 
decrease for the users of Transcend Consent.

I vote that either unpartitioned storage timeline is pushed back or the 3P 
cookie deprecation timeline is moved up (the latter seems more difficult 
given the existing public commitments I've seen from Google). Anything less 
than the full deprecation of *all* unpartitioned storage (including 
cookies) is harmful to users' interests, as a partial deprecation just 
pushes sites to use other still-unpartitioned storage mechanisms with 
potentially worse privacy characteristics.

> which safer APIs you're referring to - some more info would be useful

APIs like requestStorageAccessFor 
 (FPS-scoped) or 
something 
else extending the storage API 
 could serve this 
purpose.

> Can I ask how you handle users on Firefox and Safari? This change moves 
us to align with their storage model.

We don't attempt to do cross-site sync in Firefox and Safari. For browsers 
with partitioned storage our sync endpoints are only used to propagate 
consent & quarantine data cross-(sub)domain on one site (eTLD+1) as we 
don't currently rely on cookies.

As an aside: Google is has been severely dropping the ball lately when it 
comes to coordination of Privacy Sandbox initiatives with other browser 
privacy features. For example, Chrome ignores its own Do Not Track feature 
when auto-enabling Privacy Sandbox trials 
. Please 
work on improving cross-team coordination to prevent these sort of issues 
from happening.

Regards,
Eli

On Wednesday, April 5, 2023 at 5:17:40 PM UTC-7 mike...@chromium.org wrote:

> Hi Eli,
>
> Correct, we're not deprecating third-party cookies with this change - you 
> can learn more about the timeline for that here 
> . I 
> don't understand the setup of your use case, or which safer APIs you're 
> referring to - some more info would be useful (also feel free to email me 
> and the folks in cc directly, if you prefer). 
>
> Can I ask how you handle users on Firefox and Safari? This change moves us 
> to align with their storage model.
>
> thanks,
> Mike
> On 4/5/23 2:28 PM, Eli Grey wrote:
>
> I'm not sure if I'm reading this right. Is partitioned storage being 
> shipped without deprecating legacy third-party cookies at the same time? If 
> this change doesn't also deprecate third party cookies, it effectively 
> pushes some websites to use third-party cookies instead of safer APIs 
> scoped by FPS (which aren't ready yet). I maintain a consent manager that 
> uses localStorage and postMessage/MessageChannel to locally synchronize 
> cross domain consent and quarantine data. It is not a best practice to use 
> third party cookies for this as I would rather not leak data over the 
> network unnecessarily. I am now forced to leak consent data over the 
> network unnecessarily because the actual effective privacy boundaries have 
> not changed due to the lack of third-party cookie deprecation. 
>
> As far as I can tell, this will only result in a degradation of privacy 
> for my users if I need to switch to third party cookies. Currently 
> quarantine data never touches the network but with this change we can no 
> longer privately and securely synchronize quarantined events, so we will 
> have to reduce our functionality in Chrome.
> On Tuesday, April 4, 2023 at 3:44:52 PM UTC-7 mike...@chromium.org wrote:
>
>> *Contact emails*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * wande...@chromium.org, m...@chromium.org, mike...@chromium.org 
>> Explainer 
>> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
>>  
>> 
>>   
>> Specification Partitioned Storage is roughly specified at 
>> https://privacycg.github.io/storage-partitioning/ 
>> . As part of this work, 
>> we have started to codify the necessary concepts in HTML, DOM, and Storage 
>> in the following PRs: https://github.com/whatwg/storage/pull/144 
>>  
>> https://github.com/whatwg/dom/pull/1142 
>>  
>> https://github.com/whatwg/h

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

['Eli Grey' via blink-dev]

I'm not sure if I'm reading this right. Is partitioned storage being 
shipped without deprecating legacy third-party cookies at the same time? If 
this change doesn't also deprecate third party cookies, it effectively 
pushes some websites to use third-party cookies instead of safer APIs 
scoped by FPS (which aren't ready yet). I maintain a consent manager that 
uses localStorage and postMessage/MessageChannel to locally synchronize 
cross domain consent and quarantine data. It is not a best practice to use 
third party cookies for this as I would rather not leak data over the 
network unnecessarily. I am now forced to leak consent data over the 
network unnecessarily because the actual effective privacy boundaries have 
not changed due to the lack of third-party cookie deprecation.

As far as I can tell, this will only result in a degradation of privacy for 
my users if I need to switch to third party cookies. Currently quarantine 
data never touches the network but with this change we can no longer 
privately and securely synchronize quarantined events, so we will have to 
reduce our functionality in Chrome.
On Tuesday, April 4, 2023 at 3:44:52 PM UTC-7 mike...@chromium.org wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * Contact emails wande...@chromium.org, m...@chromium.org, 
> mike...@chromium.org Explainer 
> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
>  
> 
>   
> Specification Partitioned Storage is roughly specified at 
> https://privacycg.github.io/storage-partitioning/ 
> . As part of this work, 
> we have started to codify the necessary concepts in HTML, DOM, and Storage 
> in the following PRs: https://github.com/whatwg/storage/pull/144 
>  
> https://github.com/whatwg/dom/pull/1142 
>  
> https://github.com/whatwg/html/pull/8447 
>   We have also updated other APIs 
> to use StorageKey (ServiceWorker [1 
> ],
>  
> BroadcastChannel [1 ], 
> SharedWorker[1 ]), and landed 
> necessary additions to Storage itself ([1 
> ][2
>  
> ]).
>  
> What we thought to be a straightforward set of changes has evolved to be a 
> more complex refactoring, per the request of HTML editors. We propose to 
> ship with a WIP spec spread out across the PRs above (noting that Firefox 
> and Safari have already shipped partitioned storage). That said, we intend 
> to finish this work. Summary We intend to partition a number of APIs in 
> third-party contexts. This effort is focused on partitioning APIs above the 
> network stack. This includes quota-managed storage, service workers, and 
> communication APIs (like BroadcastChannel). See the explainer for more 
> details: 
> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
>  
> 
>   
> Blink component Blink>Storage TAG review 
> https://github.com/w3ctag/design-reviews/issues/629 
>   TAG review status 
> Resolution: Satisfied Risks Interoperability and Compatibility Given that 
> Firefox and Safari have already shipped this feature, we expect our 
> implementation to be interoperable. We are aware of breakage 
> 
>  
> for sites that use Firebase for authentication (because it relies on being 
> able to access unpartitioned sessionStorage). Firebase has blogged on how 
> sites can mitigate this issue 
> . We 
> built a deprecation trial specifically for the sessionStorage redirect use 
> case, which should work for Firebase users. In addition, we have a general 
> deprecation trial available and enterprise policies in place. See below for 
> more info on the deprecation trials. We’ve made storage partitioning 
> available for local testing in Chrome for the past 6 months 
> . 
> Apart from Firebase, we’re not aware of any existing compatibility issues 
> that can’t be solved by the deprecation trials 
> . 
> There may be unforeseen contexts and use cases that rely on unpartitioned 
> storage and as such, we propose to roll this feature out carefully via 
> Fin

Re: [blink-dev] Intent to Ship: Forbidden and escaped host characters compliant with the URL standard

['Eli Grey' via blink-dev]

I've updated my isValidHost() util to support this change. Could someone 
please have another look and let me know if my implementation now aligns 
well with the spec?



On Monday, March 13, 2023 at 6:26:18 PM UTC-7 dom...@chromium.org wrote:

> On Mon, Mar 13, 2023 at 6:46 PM Philip Jägenstedt  
> wrote:
>
>> To simplify and keep this moving, I've filed 
>> https://github.com/mozilla/standards-positions/issues/759 as an umbrella 
>> issue for anything URL in Interop 2023.
>>
>> My view is that we can't improve our risk assessment of this by much with 
>> metrics, because we can't distinguish between harmless and serious 
>> breakage. Instead what we should do is take some comfort in the fact that 
>> the behavior is already shipping in Safari, try to ship it and revert at 
>> the first sign of trouble to evaluate. In other words, I'll happily LGTM 
>> this, but I'll send this round of feedback first, in case Yoav disagrees 
>> with that.
>>
>> Some additional replies inline:
>>
>> On Mon, Mar 13, 2023 at 5:30 AM Yoav Weiss  wrote:
>>
>>> Thanks for working on interop! :)
>>>
>>
>> Indeed, I'm very grateful and happy to see this work!
>>
>> Can you please explain what would be the impact of this change and 
>>> provide examples of cases that are currently working and would stop working 
>>> after this change is landed?
>>> Web developers are asking questions on this thread, and it'd be good to 
>>> have an explainer that answers such questions.
>>>
>>
>> I've replied to Eli.
>>
>> More generally, since this is a change in the nitty gritty details, my 
>> concrete advice for web developers would be to test what Safari currently 
>> does and assume that's what Chrome is going to start doing. If one doesn't 
>> have access to Safari, then https://www.browserstack.com/screenshots can 
>> be used for one-off tests, as long as the test result appears on the page.
>>
>> The other difference to Safari that's easy to test for is when exceptions 
>> are thrown. `new URL('https://example|.com')` returns a URL escaped as "
>> https://example%7C.com"; in Chrome, but throws TypeError in Safari.
>>
>
> Developers can also use the whatwg-url Node.js package 
> , including the live URL viewer 
> . It is kept 1:1 with the URL 
> Standard and so reflects the behavior that all browsers will be aiming 
> toward as part of Interop 2023 (and that Safari is already compliant with). 
> Examples:
>
>- Parsing https://example|.com 
>
> 
>- Testing Eli's isValidHost usage of the host setter 
>
>
>  
>
>>
>> Do we have use counters for content that would start throwing once this 
>>> change lands?
>>>
>>
>> I'll let Jiacheng answer, but if the answer is no, I'm skeptical that 
>> adding use counters will meaningfully help us judge the risk of this. 
>> Breaking it down:
>>
>>- Many invalid URLs already throw exceptions, which may be caught. 
>>Knowing that new exceptions will be thrown in X% of page views will not 
>>help know how often those are caught and the web app still behaves 
>>correctly.
>>- Changes in serialization are akin to changing a return value. We 
>>can't instrument the downstream effects of that and determine if the 
>>difference led to a different outcome.
>>
>> Can you provide a link to the tests? 
>>>
>>
>>
>> https://wpt.fyi/results/url?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-url
>>
>> There's no way to link to exactly the subtests that will be affected, but 
>> "Parsing:  against " 
>> in url-constructor.any.html is one of them.
>>
>> Best regards,
>> Philip
>>
>> -- 
>>
> 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/CAARdPYdKrtMS10VJxvzKntoXMBOEaA1doTYqpQ1W4%2BX1q40-bg%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/8a74ea7a-d80b-4300-8bbb-337df9cad022n%40chromium.org.

[blink-dev] Re: Intent to Ship: Forbidden and escaped host characters compliant with the URL standard

['Eli Grey' via blink-dev]

Will this affect the behavior of the URL.prototype.host accessor at all? I 
rely on the automatic escaping to detect 'invalid' hosts with this utility: 
https://gist.github.com/eligrey/6549ad0a635fa07749238911b42923da
On Friday, March 10, 2023 at 7:07:38 AM UTC-8 g...@google.com wrote:

> Contact emailsg...@google.com, gotlo...@gmail.com, blink-net...@google.com
>
> ExplainerAs a part of the URL interop 2023, the forbidden character table 
> of hostnames will be updated as described in the URL spec. The characters 
> in hostnames will be no longer percent escaped since it's not required by 
> the URL spec.
>
> Specificationhttps://url.spec.whatwg.org/#host-writing
>
> Summary
>
> The writing and parsing rule of the URL host characters are updated to be 
> compliant with the URL standard. The following characters characters will 
> become forbidden in the hostnames as described in 
> https://url.spec.whatwg.org/#forbidden-host-code-point: ' ' (space), '<', 
> '>' and '|'. '[' and ']' are still allowed as a part of IPv6 addresses but 
> will be forbidden in any other hostnames. The following characters will no 
> longer be percent escaped in hostnames: '!', '"', '$', '&', ''' (the ' 
> character itself), '(', ')', '*', ';', '=', '`', '{', '}' and '~'
>
>
> Blink componentBlink>Network 
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The URL standard is a well established standard and the effort is a part 
> of the URL interop 2023. We expect the risk to be minimal.
>
>
> *Gecko*: Positive The forbidden characters are partially followed in 
> firefox. '*' is considered as an invalid character in hostnames. The 
> characters are not percent escaped in the hostnames.
>
> *WebKit*: Shipped/Shipping Safari strictly follows the forbidden 
> character list and never percent escape the characters in the hostnames.
>
> *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?
>
>
>
> Debuggability
>
> The forbidden characters will throw TypeErrors where developers can find 
> in the console.
>
>
> 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 name
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1398117
>
> Sample links
> https://chromium-review.googlesource.com/c/chromium/src/+/4199790
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> No spec change
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5074885224693760
>
> 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/2aa38a46-b491-44bb-9f06-166c0505187en%40chromium.org.