RE: [blink-dev] Intent to Deprecate and Freeze: The User-Agent string

['James Rosewell' via blink-dev]

Dear Google,

Adding Matthew Hancox and David Verroken in their role as Monitoring 
Trustee
 of Google’s commitments with the CMA.

Google make the following statements in their May 2022 
report
 in relation to this Intent to Deprecate and Freeze notice.

API / Technology
 Feedback Theme
 (Ranked by
 Prevalence)
 Questions and
 Concerns
 Summary
 Chrome Response
User Agent Reduction
Performance
There are concerns about the latency of getting hints via Critical-CH (on the 
first page load).
Chrome is investigating ways to improve performance.
User-Agent
Reduction /
User-Agent Client
Hints
Anti-Fraud / Anti-Abuse concerns
Having as much information as possible is
important when debugging certain types of attacks, including Denial of Service. 
Losing some info from the UA string may pose challenges.
Chrome is in discussions and evaluating ways to maintain privacy while 
providing sufficient information that will be useful for debugging.
User Agent Reduction
Confusion around OT setup
Multiple Origin Trial participants recommended improving documentation with 
examples of how to enroll in the Origin Trial.
The Reduced UA Origin Trial is ending, but Chrome intends to improve the 
instructions for 
the 

Deprecation 
Trial
  (including making the example demo more prominent).
User Agent Reduction
Concern about values of specific hint
Questions around
if the
Sec-CH-UA-Model
is the same as < deviceModel> in the User-Agent string.
Sec-CH-UA-Model is the same as  in the User-Agent string. Chrome 
will try to make this more clear in future documentation.
User-Agent Reduction
Concern about
enrolling in Deprecation
Trial
Questions around h ow to enroll a large number of domains into the
Deprecation Trial.
Chrome has considered centralized approaches when designing the Deprecation 
Trial, but Chrome believes the existing Origin Trial is the best option as it 
gives all control to developers ( since they can choose to s end the header or 
not).
User-Agent Client
Hints
Concerns around
prescriptive nature of
UA-CH
There is a concern that UA-CH is
overly prescriptive when compared to the flexibility the
User-Agent header offers, as de ned by rfc7231.
Chrome sees the prescriptive nature of UA-CH headers as an
important improvement
over the flexibility of the UA string, both from the point of view of eventual 
cross-browser interoperability and user privacy protection (by preventing 
arbitrary additions of high-entropy identifiers).
However the issue remains open in case others also share this concern and would 
like to provide feedback.
User-Agent Client
Hints
Concerns that the API is being used to block certain browsers
Concern that a site is using the API to look for “Google Chrome” or “Microsoft 
Edge” and blocking all other browsers.
The concept of a brand list was designed to handle this case - a browser can 
send “Google Chrome” in addition to their own brands.
User-Agent Client
Hints
Request for a method
to enumerate all supported hints
Interest in having a
programmatic way to know all supported hints for a browser.
Chrome is evaluating the feature request.
User-Agent
Reduction /
User-Agent Client
Hints
Anti-Fraud / Anti-Abuse concerns
Client hints are not available on first load for HTTP1
One of the Client Hints
Reliability APIs
(ACCEPT_CH) is only available over HTTP2 and H TTP3. For servers who are still 
served over HTTP1, they will need to rely solely on Critical-CH.
User-Agent Reduction
Impact on Chrome for Android
Questions on how this impacts Chrome on Android in particular.
UA Reduction as well as UA-CH will ship on Chrome on Android, in addition to 
Desktop. For Chrome on Android, the changes will only take place in “Phase 6”, 
currently scheduled for Chrome 110.
Gnatcatcher +
User-Agent
Reduction
Reducing signals for anti-fraud
Anti-fraud impact of  concurrently reducing IP  and U A access.
Expecting Willful IP
Blindness anti-fraud policy stipulations (to allow use of I P for anti-fraud 
use cases) will resolve defensibility concerns around IP proxying.

Latency

Google acknowledged Privacy Sandbox is part of their “Ad Systems” in the 
commitments to the CMA. User Agent Reduction and User Agent Client Hints are 
part of Privacy Sandbox.

Any delay in retrieving the UACH values will delay the population of the Open 
RTB Structured User 
Agent 
(SUA) data thus delaying the request for advertising. Those websites that are 
bundled with the web browser via defaults, or are well-kno

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[Josh Karlin]

The unified origin trial is also now at 50% of Chrome Beta for the Topics
API as of May 27th.


On Mon, May 23, 2022 at 6:23 PM John Delaney  wrote:

> The unified origin trial for the Privacy Sandbox Ads APIs is now at 50% of
> Chrome Beta population for FLEDGE and Attribution Reporting.  A stability
> issue was identified and fixed in Topics code, and we expect the API to be
> available to 50% of Chrome Canary and Chrome Dev by the end of today, and
> 50% of Beta users within a few days.  Reports from early testers help us
> identify and address such technical issues. This is to be expected in the
> early days of origin trials and the reason we proceed gradually.
>
> We expect the origin trial to remain in Beta for at least a few more weeks
> to help us identify and address any additional issues.  Once we’re
> confident we’ve fixed any major open issues, we will provide an update with
> a timeline for moving the origin trial to Chrome Stable for expanded
> testing with a larger volume of traffic.  To get support, report issues, or
> provide feedback please see the resources for Topics
> 
> , FLEDGE
> 
>  and Attribution Reporting
> 
> .
> On Thursday, April 28, 2022 at 4:18:05 PM UTC-4 John Delaney wrote:
>
>> The unified origin trial for the Privacy Sandbox relevance and
>> measurement APIs (Topics, FLEDGE and Attribution Reporting) is available in
>> Chrome Beta.  We plan to ramp up to approximately 50% of the Chrome Beta
>> population within the next two weeks.  We will continue to run the origin
>> trial in Chrome Beta to evaluate the functionality of the APIs and the
>> accompanying user controls.   Technical testing is an important first step
>> in the origin trial process;  developers are encouraged to provide feedback
>> on API functionality, documentation and ease of integration.  To get
>> support, report issues, or provide feedback please see these resources for
>> Topics
>> ,
>> FLEDGE
>> 
>> and Attribution Reporting
>> .
>>
>>
>> We will provide updates soon on when we expect to advance the origin
>> trial to Chrome Stable, with increased traffic volume to support additional
>> testing.
>>
>> On Friday, April 8, 2022 at 4:17:12 PM UTC-4 John Delaney wrote:
>>
>>> Hi blink-dev,
>>>
>>> This is a heads-up that there will be a shared origin trial for three
>>> new APIs.
>>>
>>> The "Privacy Sandbox Ads APIs" origin trial will include:
>>>
>>>- Attribution Reporting API:
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ
>>>- FLEDGE:
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/_0T5qleqCgAJ
>>>- Topics API:
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/jPkW3T-mCgAJ
>>>
>>>
>>> Please see each API’s Intent to Experiment for additional details.
>>>
>>> We have published separate guidance on how this shared origin trial will
>>> work, and how developers can participate once available here:
>>>
>>> https://developer.chrome.com/blog/privacy-sandbox-unified-origin-trial/
>>>
>>> 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.com/a/chromium.org/d/msgid/blink-dev/ae4f48db-f42f-4fc5-9de6-635e3a8c0fc5n%40chromium.org
> 
> .
>

-- 
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/CAANMuaPFu03zU2%3DcEjSqJKo96kazbxGg8VEDrzOObPAr%2BugJBw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Topics API

[Josh Karlin]

The Topics API experiment is ramped up to 50% of the beta population as
well now. This ramp-up began on May 27th. Remember that it takes a week or
more after usage of the API for a user to start returning topics.

Josh

On Mon, May 23, 2022 at 3:24 PM Josh Karlin  wrote:

> Hi all. The Topics API experiment is back up and running. 50% of canary &
> dev users are now in the experiment group. We'll add 50% of beta within the
> next couple of days. While I have your attention I'd like to also point you
> to our new chrome://topics-internals page (available on canary and dev for
> M103) that will provide handy developer information about the topics that
> have been selected in each epoch and it also allows you to query the site
> classifier to understand the mapping of sites to topics. More improvements
> to the internals page are in consideration as well.
>
> Sorry about the delay,
>
> Josh
>
> On Mon, May 2, 2022 at 3:42 PM Josh Karlin  wrote:
>
>> Update: we've discovered a stability issue with the Topics API and fixed
>> the code, but the Topics API has been disabled in the Privacy Sandbox Ads
>> APIs Origin Trial for users that aren't running a version of Chrome with
>> the fix applied. It will take a couple of weeks for the updated
>> canary/dev/beta releases to propagate to the majority of users.
>>
>> Best,
>>
>> Josh
>>
>> On Wed, Mar 30, 2022 at 11:58 AM Philip Jägenstedt 
>> wrote:
>>
>>> I was not clear about the connection between this intent and 2 other
>>> intents that are under review now.
>>>
>>> While my LGTM stands, please make sure that the total package of 3 make
>>> sense :)
>>>
>>> On Wed, Mar 30, 2022 at 5:49 PM Philip Jägenstedt 
>>> wrote:
>>>
 LGTM to experiment

 On Fri, Mar 25, 2022 at 10:31 PM Josh Karlin 
 wrote:

> Contact emails
>
> yao...@chromium.org, jkar...@chromium.org
>
> Developers interested in the Topics API can also join the Topics API
> announcements
> 
> group for updates and announcements.
>
> Explainer
>
> https://github.com/jkarlin/topics
>
> Specification
>
> TBD
>
> Summary
>
> The intent of the Topics API is to provide callers (including
> third-party ad-tech or advertising providers on the page that run script)
> with coarse-grained advertising topics that the page visitor might
> currently be interested in. These topics will supplement the contextual
> signals from the current page and can be combined to help find an
> appropriate advertisement for the visitor.
>
>
> Blink component
>
> Blink>InterestCohort
> 
>
> Search tags
>
> Topics , browsingTopics
> , FLoC
> 
>
> TAG request
>
> https://github.com/w3ctag/design-reviews/issues/726
>
> Risks
> Interoperability and Compatibility
>
> Gecko: issue
>  –
> requested March 17th 2022
>
> WebKit: webkit-dev thread
> 
> – requested March 17th 2022
>
> Web developers: Lots of interest in issues in the explainer. Concerns
> center around utility. Balancing privacy/utility and making tweaks to the
> algorithms so that we get this right is what the OT is all about.
>
> 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
>
>
> Goals for experimentation
>
> The intent is for experimenters to try Topics out and see how it
> performs for them. We expect there to be bumps along the road toward
> optimizing privacy and utility trade-offs. We also expect it may be
> necessary to change parameters and algorithms along the way (e.g., we’re
> already having discussions around adding Topics in request headers and
> weighting topics by frequency). So please experiment and provide feedback
> on the issue tracker  to
> help us improve it.
>
> Experiment Configuration
>
> The origin trial for this experiment will be shared among various
> Privacy Sandbox APIs. Our goal is to allow for coordinated experiments to
> be run by multiple different sites, across multiple APIs in one OT.
>
> This shared origin trial, Privacy Sandbox Ads APIs, will be a
> third-party origin trial. To ensure that developers can run coordinated
> experiments without concern for exceeding page l

Re: [blink-dev] Intent to Ship: Default SVG cursor size set from OS settings

[Chris Harrelson]

LGTM3. Please also file an issue tracking implementation on other
platforms, if there is not one already.

On Thu, Jun 2, 2022 at 11:42 PM Yoav Weiss  wrote:

> LGTM2
>
> On Thu, Jun 2, 2022 at 9:37 PM Daniel Bratell  wrote:
>
>> LGTM1.
>>
>> It would be better if it was more cross-platform, but I accept that this
>> is the best we can do right now. And I agree that this is close to a bug
>> fix.
>>
>> /Daniel
>> On 2022-06-01 19:00, Sahir Vellani wrote:
>>
>>
>>
>> On Tuesday, May 31, 2022 at 9:31:01 AM UTC-7 mike...@chromium.org wrote:
>>
>>> Hi Sahir,
>>>
>>> On 5/26/22 4:44 PM, 'Sahir Vellani' via blink-dev wrote:
>>>
>>> Contact emails
>>> sahir@microsoft.com, gerc...@microsoft.com, bema...@microsoft.com
>>>
>>> Specification
>>> https://drafts.csswg.org/css-ui-3/#cursor
>>>
>>> Summary
>>>
>>> Platform cursor size used as default for custom SVG cursors if no
>>> specified size. SVG cursors can scale based on the platform
>>> accessibility/cursor settings. This can be overridden if the cursor has any
>>> specified dimensions. This feature is initially available on Windows only.
>>>
>>> It's not 100% clear to me what you're proposing shipping here (this may
>>> be due to my lack of expertise in this area), and the spec link doesn't
>>> help much I'm afraid. A short explainer with use cases and mockups or
>>> screenshots would be helpful, if you could post one. Or is this just a
>>> bugfix, rather than a new feature?
>>>
>> *This is basically a bug fix that will slightly change CSS cursor API
>> behavior. The main change here is that web developers that specify an SVG
>> to the CSS Cursor property with no specified size will see it rendered with
>> the size being what Chromium gets from the platform. The spec states:
>> "The default object size
>>  for cursor images
>> is a UA-defined size that should be based on the size of a typical cursor
>> on the UA’s operating system". With this change, this statement will be
>> honored, as previously Chromium would not know the "typical" size of the
>> cursor and just render a default cursor.*
>>
>>>
>>> Blink component
>>> Blink>SVG
>>> 
>>>
>>> TAG review
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Web developers will need to reexamine the way they handle SVG cursors
>>> with no specified sizes. A custom cursor may be rendered where it was
>>> previously just the default cursor image.
>>>
>>> Could you explain why a different (presumably fallback) cursor would be
>>> rendered?
>>>
>> *The scenario where a different cursor is rendered is as follows: Web
>> developer sets an SVG image as the cursor but with no specified size.
>> Without this change, the actual rendered cursor is the default for that
>> cursor type (i.e. I beam, pointer). With this change, the actual rendered
>> cursor will be the SVG image with a size being what the OS provides
>> Chromium. *
>>
>>>
>>> *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?
>>>
>>>
>>> Debuggability
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>> No
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>> No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=737459
>>>
>>> Estimated milestones
>>>
>>> 105
>>>
>>>
>>> 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/5112911184789504
>>>
>>> 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+...@chromium.org.
>>>
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b87b0ab4-836d-45f0-af04-2ce26b3e718an%40chromium.org
>>> 

Re: [blink-dev] Intent to Deprecate and Remove: navigation to filesystem: URLs in iframes

[Rick Byers]

I checked the WebView-specific UseCounter too and it's half that of the
Android one. So yeah, it seems extremely unlikely to me that anyone will
notice this - more like a bug-fix than a deprecation. LGTM3

On Fri, Jun 3, 2022 at 3:23 AM Yoav Weiss  wrote:

> LGTM2
>
> On Thu, Jun 2, 2022 at 8:20 PM Daniel Bratell  wrote:
>
>> Well below our customary threshold level, and unlikely to be used in our
>> blind spots (WebView, enterprise). I think it's safe to remove directly.
>>
>> LGTM1
>>
>> /Daniel
>> On 2022-06-02 19:40, Mike Taylor wrote:
>>
>> *Contact emails*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * miketa...@chromium.org , m...@chromium.org
>>  Summary We propose to remove support for navigating to
>> filesystem:// URLs in iframes. Blink component Blink>Storage>FileSystem
>> 
>> Motivation Render-initiated navigations to filesystem:// URLs are blocked
>> in top-level frames, but are currently allowed in iframes. As part of the
>> storage partitioning efforts, we propose to remove support for navigation
>> to filesystem:// URLs in iframes. Preventing navigation in third-party
>> contexts would be sufficient for our privacy goals, but as usage is almost
>> non-existent, we believe removing support for navigation in iframes
>> altogether is the better approach.
>> (https://miketaylr.com/misc/filesystem-navigation.html
>>  may be useful to
>> grok what any of this means.) TAG review N/A. This intent refers to a
>> Chromium-only feature (which we’re trying to remove). Risks
>> Interoperability and Compatibility No other engine supports filesystem://
>> URLs, so we do not expect interoperability issues. As for compatibility,
>> usage is very, very low. Currently just above 0.008%
>> . For
>> this reason we would like to just remove it, without any deprecation
>> period. Gecko: N/A (not supported) WebKit: N/A (not supported) 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? No.
>> Debuggability We currently send an error message to the console if you try
>> to open a window to a filesystem:// URL - we will do something similar for
>> iframes. Is this feature fully tested by web-platform-tests
>> ?
>> No Flag name FileSystemUrlNavigation Requires code in //chrome? False
>> Estimated milestones M105 Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5816343679991808
>>  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/84b7af7f-66fb-4874-0290-f0b22f51cb52%40chromium.org
>> 
>> .
>>
>> --
>> 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/b9ca44ab-0655-8e86-a714-aad7ea463b25%40gmail.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/CAL5BFfW5x6mzXJXAngGT1m82jEr3hTM_WPShKi4tnJLvGXgWKQ%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/CAFUtAY86K2rAaOUzqCF31Q8itB

Re: [blink-dev] Developer pain as a result of "introducing blink_wpt_tests"

[Dominic Farolino]

>
> For the long term, we can definitely move this back once we have separate
> legacy tests and wpt into different folders. I can also reach out to you
> guys to better understand your needs.
>
> For the folders Dom mentioned, I can check to see if any of that can be
> removed. I understand the README is needed for virtual test suites.
>

Can you define "long term" here? Is there a timeline? I was really hoping
that we'd go back to how things were almost immediately. Still the need for
the delay does not quite make sense to me, and I'm really hoping that for
Blink developer experience we can revert this back to the previous setup
ASAP.

Under "web_tests/virtual" we have baselines for wpt and pure virtual legacy
> tests, we can list the folders under "virtual/prefix" for each virtual test
> suite, which will make the dependency very large(yes), and we need make
> such change each time when we add new virtual suites. I don't think this is
> something blink devs want to do.
>

I'm sorry, but like Domenic I am not sure what to make of much of this.
What I do know is that Blink developers also don't want the current WPT
writing experience where expectation files are positioned far away from the
source test. I think this experience matters a lot.

On Thu, Jun 2, 2022 at 4:25 PM Weizhong Xia  wrote:

> Previously you don't need to specify anything in BUILD.gn is because we
> are downloading the whole "web_tests" folder. Now we want to run legacy
> tests and wpt in different steps. Under "web_tests/virtual" we have
> baselines for wpt and pure virtual legacy tests, we can list the folders
> under "virtual/prefix" for each virtual test suite, which will make the
> dependency very large(yes), and we need make such change each time when we
> add new virtual suites. I don't think this is something blink devs want to
> do.
>
> The discussion is at the beginning of the crbug. So pls scroll back to
> #c1, and read from there.
>
> thanks, Weizhong
>
> On Thu, Jun 2, 2022 at 12:29 PM Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Jun 2, 2022 at 3:21 PM Weizhong Xia  wrote:
>>
>>> Folks
>>>
>>> I'm sorry to see this has caused inconvenience, and sorry for being late
>>> in response to this, due to the same reason Dom had.
>>>
>>
>> Thanks for responding and listening to our concerns!
>>
>>
>>>
>>> The reason to move baselines to one central place at this point is to
>>> make it possible to specify dependency in BUILD.gn.
>>>
>>
>> I don't quite understand this. I've had to work with WPTs and WPT
>> expectations my entire time working on Chromium. I've never had to "specify
>> dependency in BUILD.gn"; I don't really know what that means. I'd love to
>> hear more (or be referred to a doc explaining the issue), so that I
>> understand why we're making the sacrifice we're making. (The linked bug
>> isn't very understandable for me, unfortunately. I can't even understand
>> enough to find the part you mentioned where you discussed different
>> approaches.)
>>
>> I'm also unsure how the decision was weighed. Is the population of people
>> specifying dependency in BUILD.gn very large, so that their needs are
>> outweighing those of the Chromium developers working with web platform
>> tests?
>>
>>
>>> This is part of the work to use upstream wptrunner to run wpt tests. In
>>> crbug/1299834  we have tried to discuss some
>>> different approaches. I would say this is the least disruptive way. For
>>> blink engprod, I think to make blink devs happy is our top priority.
>>>
>>> For the long term, we can definitely move this back once we have
>>> separate legacy tests and wpt into different folders. I can also reach out
>>> to you guys to better understand your needs.
>>>
>>> For the folders Dom mentioned, I can check to see if any of that can be
>>> removed. I understand the README is needed for virtual test suites.
>>>
>>> Cheers, Weizhong
>>>
>>> On Wednesday, June 1, 2022 at 6:06:56 AM UTC-7 yoav...@chromium.org
>>> wrote:
>>>
 +1 from me as well. I was similarly caught by surprise by this change
 (during reviews for webexposed changes), and am similarly not seeing the
 upside for this.

 While I'm sure this is a change that was meant to be a positive one,
 I'd love to better understand the reasoning, and whether the current
 situation is a temporary one, or one that is planned to be permanent even
 after the move to blink_wpt_tests is done.

 On Fri, May 27, 2022 at 6:10 PM Domenic Denicola 
 wrote:

> +1. This was really unpleasantly surprising. When I first saw the
> original blink-dev email, I thought "generic baselines" meant something
> like "non-web platform test baselines", not "WPT expectation files that 
> are
> platform-agnostic".
>
> In addition to the context-switching cost, it's just much harder to
> navigate between tests and their expectations, which is something I do
> quite often. E.g., they are no longer 

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

[Mike Taylor]

On 6/3/22 6:42 AM, Yoav Weiss wrote:

What's the deprecation period you had in mind?

Also, from a technical perspective, it might be worthwhile to talk to 
folks that did past cookie related deprecations, to make sure you're 
reusing the same path for reporting them to the devtools. Also also, 
it'd be great if that deprecation would result in Deprecation Reports, 
if at all feasible.


On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
 wrote:



Contact emails

johann...@chromium.org


Explainer

None


Specification


https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5


Summary

To align with the latest specification in RFC 6265bis, Chromium
will reject cookies with a "Domain" attribute that contains a
non-ASCII character (e.g. Domain=éxample.com
).



Blink component

Blink>Network




Motivation

Support for IDN domain attributes in cookies has been long
unspecified, with Chromium, Safari and Firefox all behaving
differently. https://github.com/httpwg/http-extensions/issues/1707
fixes this issue by standardizing Firefox's behavior of rejecting
cookies with non-ASCII domain attributes. Since Chromium has
previously accepted non-ASCII characters and tried to convert them
to normalized punycode for storage, we will now apply stricter
rules and require valid ASCII (punycode if applicable) domain
attributes.



Initial public proposal



TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium
versions from rejecting previously accepted cookies, but UMA
measurements show the percentage of cookies with non-ASCII
characters (including potentially invalid cookies) to be below
0.0001%.


Any public use counters you could share?
Or is that something we couldn't add due to cookies being processed 
outside the renderer?
Usage is quite low, but it would be good to know if there are any 
patterns that might affect certain locales more than others. Is there 
any way we can get a sample list of domains to spot check?


This change improves interoperability by aligning with what
Firefox is shipping and what Safari aims to ship as well.



/Gecko/: Positive
(https://github.com/httpwg/http-extensions/issues/1707)

/WebKit/: Positive
(https://github.com/httpwg/http-extensions/issues/1707)


Our typical process for getting such signals is 
https://bit.ly/blink-signals
At the same time, as you said above, Mozilla is already shipping 
 
the behavior you want to align on here.
Can you send a request to webkit-dev, letting them know that we're 
moving on that front?



/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

TBD



Is this feature fully tested by web-platform-tests

?

Yes


Flag name



Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5534966262792192

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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%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/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com 

Re: [blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

[Yoav Weiss]

What's the deprecation period you had in mind?

Also, from a technical perspective, it might be worthwhile to talk to folks
that did past cookie related deprecations, to make sure you're reusing the
same path for reporting them to the devtools. Also also, it'd be great if
that deprecation would result in Deprecation Reports, if at all feasible.

On Fri, Jun 3, 2022 at 12:21 PM Johann Hofmann 
wrote:

> Contact emailsjohann...@chromium.org
>
> ExplainerNone
>
> Specification
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5
>
> Summary
>
> To align with the latest specification in RFC 6265bis, Chromium will
> reject cookies with a "Domain" attribute that contains a non-ASCII
> character (e.g. Domain=éxample.com ).
>
>
> Blink componentBlink>Network
> 
>
> Motivation
>
> Support for IDN domain attributes in cookies has been long unspecified,
> with Chromium, Safari and Firefox all behaving differently.
> https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by
> standardizing Firefox's behavior of rejecting cookies with non-ASCII domain
> attributes. Since Chromium has previously accepted non-ASCII characters and
> tried to convert them to normalized punycode for storage, we will now apply
> stricter rules and require valid ASCII (punycode if applicable) domain
> attributes.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> There is a general risk of breakage compared to past Chromium versions
> from rejecting previously accepted cookies, but UMA measurements show the
> percentage of cookies with non-ASCII characters (including potentially
> invalid cookies) to be below 0.0001%.
>

Any public use counters you could share?
Or is that something we couldn't add due to cookies being processed outside
the renderer?


> This change improves interoperability by aligning with what Firefox is
> shipping and what Safari aims to ship as well.
>
>
> *Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>
> *WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707)
>

Our typical process for getting such signals is https://bit.ly/blink-signals
At the same time, as you said above, Mozilla is already shipping

the behavior you want to align on here.
Can you send a request to webkit-dev, letting them know that we're moving
on that front?


> *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
>
> TBD
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1296537
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5534966262792192
>
> 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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%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/CAL5BFfUdCoWru_bd826snHc24eHk7uUYW_HJF-ox0ihaqanX9g%40mail.gmail.com.

[blink-dev] Intent to Deprecate and Remove: Non-ASCII characters in cookie domain attributes

[Johann Hofmann]

Contact emailsjohann...@chromium.org

ExplainerNone

Specification
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#section-5.5

Summary

To align with the latest specification in RFC 6265bis, Chromium will reject
cookies with a "Domain" attribute that contains a non-ASCII character (e.g.
Domain=éxample.com ).


Blink componentBlink>Network


Motivation

Support for IDN domain attributes in cookies has been long unspecified,
with Chromium, Safari and Firefox all behaving differently.
https://github.com/httpwg/http-extensions/issues/1707 fixes this issue by
standardizing Firefox's behavior of rejecting cookies with non-ASCII domain
attributes. Since Chromium has previously accepted non-ASCII characters and
tried to convert them to normalized punycode for storage, we will now apply
stricter rules and require valid ASCII (punycode if applicable) domain
attributes.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is a general risk of breakage compared to past Chromium versions from
rejecting previously accepted cookies, but UMA measurements show the
percentage of cookies with non-ASCII characters (including potentially
invalid cookies) to be below 0.0001%. This change improves interoperability
by aligning with what Firefox is shipping and what Safari aims to ship as
well.


*Gecko*: Positive (https://github.com/httpwg/http-extensions/issues/1707)

*WebKit*: Positive (https://github.com/httpwg/http-extensions/issues/1707)

*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

TBD


Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAD_OO4hVsjFA06ytmbNvn-bfUXDGur0ESSMxEO-o-96sCNAiOQ%40mail.gmail.com.

Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

[Yoav Weiss]

LGTM2

Thanks for working with other vendors and significantly reducing the
interop risk here! :)

On Wed, Jun 1, 2022 at 6:19 PM Alex Russell 
wrote:

> It's great to see all of this progress and the updated explainer is very
> clear.
>
> LGTM1
>
> On Wednesday, May 25, 2022 at 9:37:19 AM UTC-7 snianu wrote:
>
>> Reviving this thread and restarting the I2S process for this API….
>>
>> Sorry for the delay here. We’ve been discussing the new proposal
>>  with EditingWG
>> members and with our partners. We agree with Firefox’s proposal to use “web
>> “ prefix for web custom formats instead of the unsanitized option. It makes
>> the API more ergonomic and helps in interop across apps which is one of the
>> benefits of using web custom formats.
>>
>> We have support from other browser vendors as well(
>> https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047065265,
>> https://github.com/w3c/clipboard-apis/issues/165#issue-1117218251).
>>
>> I’ll try to summarize the changes here.
>>
>>- We removed the `unsanitized` option from ClipboardItem constructor
>>and read() method call.
>>- We’re adding support to read/write MIME types that have “web
>>“(“web” followed by U+0020 SPACE) prefix. These special formats would be
>>read/written unsanitized from/to the system clipboard. It will follow the
>>platform specific clipboard format naming convention that we previously
>>proposed for pickling:
>>
>> https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#os-interaction-format-naming
>>.
>>- Web authors have access to both web custom format(which is
>>unsanitized) and well-known formats(which is sanitized for text/html)
>>during read(). In the previous proposal, unsanitized option controlled
>>access to pickled formats, so if web authors provided well-known MIME 
>> types
>>in the unsanitized list, then they only get access to custom unsanitized
>>formats for the well-known mime types, and not the sanitized(for 
>> text/html)
>>version for these mime types.
>>- We’re adding transient user activation as a requirement for
>>reading/writing all supported formats in the async clipboard API. The
>>transient user activation requirement is something that affects the
>>existing formats. We’ve added histograms to check if site is calling the
>>async API without transient user activation. We don’t anticipate any 
>> issues
>>with this extra check because we don’t expect the site to read clipboard
>>data without any user interaction as that would be a severe
>>security/privacy issue. We discussed this in the EditingWG meeting and
>>everyone agrees that this check should be a strict requirement to access
>>system clipboard. Here is the relevant issue and EditingWG meeting notes:
>>https://github.com/w3c/clipboard-apis/issues/75#issuecomment-1088932790
>>&
>>https://github.com/w3c/clipboard-apis/issues/75#issuecomment-1125148793
>>.
>>- We’ve updated the spec, explainer and the current implementation.
>>Spec: https://github.com/w3c/clipboard-apis/pull/175, Explainer:
>>
>> https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#web-custom-formats-for-async-clipboard-api,
>>CL: https://chromium-review.googlesource.com/c/chromium/src/+/3650952
>>
>>
>>
>> Please let us know if you have any questions/concerns.
>>
>>
>>
>> Thanks,
>>
>> Anupam
>>
>>
>>
>> *From:* Anupam Snigdha
>> *Sent:* Thursday, February 3, 2022 9:06 AM
>> *To:* 'Yoav Weiss' ; blink-dev <
>> blink-dev@chromium.org>
>> *Cc:* Philip Jägenstedt ; Domenic Denicola <
>> dome...@chromium.org>; Chris Harrelson ; Daniel
>> Bratell ; blink-dev ; Alex
>> Russell ; Abhishek Rathi ;
>> svo...@gmail.com ; Ajay Rahatekar <
>> ajayrahate...@google.com>; Bo Cupp ; Marijn
>> Kruisselbrink ; Joshua Bell ;
>> Victor Costan ; Scott Low 
>> *Subject:* RE: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling
>> for Async Clipboard API
>>
>>
>>
>> Discussed offline. Sorry for the delay in response. We are reviewing 
>> Mozilla’s
>> feedback on the proposal
>>  so I think we can put
>> this intent on hold for now.
>>
>>
>>
>> Thanks,
>>
>> Anupam
>>
>>
>>
>> *From:* Yoav Weiss 
>> *Sent:* Wednesday, February 2, 2022 2:26 AM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; Philip Jägenstedt <
>> foo...@chromium.org>; Domenic Denicola ; Chris
>> Harrelson ; Daniel Bratell ;
>> blink-dev ; Alex Russell <
>> slightly...@chromium.org>; Abhishek Rathi ;
>> svo...@gmail.com ; Ajay Rahatekar <
>> ajayrahate...@google.com>; Bo Cupp ; Marijn
>> Kruisselbrink ; Joshua Bell ;
>> Victor Costan ; Scott Low ;
>> Anupam Snigdha 
>> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling
>> for Async Clipboard API
>>
>>
>>
>> Friendly ping! :) Also happy to discuss off-thread in case it's helpful.
>>

Re: [blink-dev] Intent to Deprecate and Remove: navigation to filesystem: URLs in iframes

[Yoav Weiss]

LGTM2

On Thu, Jun 2, 2022 at 8:20 PM Daniel Bratell  wrote:

> Well below our customary threshold level, and unlikely to be used in our
> blind spots (WebView, enterprise). I think it's safe to remove directly.
>
> LGTM1
>
> /Daniel
> On 2022-06-02 19:40, Mike Taylor wrote:
>
> *Contact emails*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * miketa...@chromium.org , m...@chromium.org
>  Summary We propose to remove support for navigating to
> filesystem:// URLs in iframes. Blink component Blink>Storage>FileSystem
> 
> Motivation Render-initiated navigations to filesystem:// URLs are blocked
> in top-level frames, but are currently allowed in iframes. As part of the
> storage partitioning efforts, we propose to remove support for navigation
> to filesystem:// URLs in iframes. Preventing navigation in third-party
> contexts would be sufficient for our privacy goals, but as usage is almost
> non-existent, we believe removing support for navigation in iframes
> altogether is the better approach.
> (https://miketaylr.com/misc/filesystem-navigation.html
>  may be useful to
> grok what any of this means.) TAG review N/A. This intent refers to a
> Chromium-only feature (which we’re trying to remove). Risks
> Interoperability and Compatibility No other engine supports filesystem://
> URLs, so we do not expect interoperability issues. As for compatibility,
> usage is very, very low. Currently just above 0.008%
> . For
> this reason we would like to just remove it, without any deprecation
> period. Gecko: N/A (not supported) WebKit: N/A (not supported) 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? No.
> Debuggability We currently send an error message to the console if you try
> to open a window to a filesystem:// URL - we will do something similar for
> iframes. Is this feature fully tested by web-platform-tests
> ?
> No Flag name FileSystemUrlNavigation Requires code in //chrome? False
> Estimated milestones M105 Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5816343679991808
>  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/84b7af7f-66fb-4874-0290-f0b22f51cb52%40chromium.org
> 
> .
>
> --
> 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/b9ca44ab-0655-8e86-a714-aad7ea463b25%40gmail.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/CAL5BFfW5x6mzXJXAngGT1m82jEr3hTM_WPShKi4tnJLvGXgWKQ%40mail.gmail.com.