Re: [blink-dev] Re: Intent to Prototype: requestStorageAccessForSite

2022-08-17 Thread 'Matt Reichhoff' via blink-dev 
Hello Brandon,

We have documented our stance on the relationship of this proposal with the
forward declaration model in the explainer
<https://github.com/mreichhoff/requestStorageAccessForSite#forward-declaration>,
and I agree that it is an open question we should collaborate on.

I also agree about discussing the proposal via an issue on the storage
access repo, which I've now filed
<https://github.com/privacycg/storage-access/issues/107>. Feedback is
welcome!

Thanks!

On Tue, Aug 16, 2022 at 5:14 PM 'Brandon Maslen' via blink-dev <
blink-dev@chromium.org> wrote:

> Nice to see further extension of the SAA for specific scenarios the
> existing API doesn't fully cover. I had a couple of questions about the
> extension and how it ties into the existing SAA:
>
> What is the intended interaction with declarative SAA as being discussed
> in  Allow forward-declaration of storage access need · Issue #83 ·
> privacycg/storage-access · GitHub
> <https://github.com/privacycg/storage-access/issues/83> ?
>
> Rather than a separate explainer/repo for discussion, would it be possible
> to discuss in https://github.com/privacycg/storage-access/  perhaps open
> an issue to discuss this modification/extension. If there are any specific
> parts all implementors don't agree on some things could be spec'd in a way
> to allow implementors to make a decision; we already do that with respect
> to how/when prompts show up for requested access. It would be great to
> start there and align early.
>
> On Tuesday, August 9, 2022 at 10:04:20 AM UTC-7 Matt Reichhoff wrote:
>
>> Contact emails
>>
>> mreic...@chromium.org, kaust...@chromium.org, joha...@chromium.org
>> Explainer
>>
>> https://github.com/mreichhoff/requestStorageAccessForSite
>> Specification
>>
>> We do not have a draft specification yet, but we hope to further incubate
>> and develop the API, and specify it as an extension of the existing
>> Storage Access API <https://privacycg.github.io/storage-access/>.
>> TAG review
>>
>> Not yet filed.
>> Blink component
>>
>> Blink>StorageAccessAPI
>> Summary
>>
>> This intent proposes an extension to the Storage Access API
>> <https://privacycg.github.io/storage-access/> (which was previously
>> implemented
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/e5fu5Q06ntA/m/1KF5oNEXAgAJ>
>> in Chromium by the Microsoft Edge team). The extension allows a top-level
>> site to request access to unpartitioned ("first-party") cookies on behalf
>> of embedded sites. We intend for sites to utilize this API as one of the
>> replacements for third-party cookies, which are being phased out
>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>
>> in Chrome. This extension of the Storage Access API inverts the direction
>> of the `requestStorageAccess` request, which is called by the embedded site
>> once it receives a user interaction. Browsers will have discretion to grant
>> or deny access. See the explainer
>> <https://github.com/mreichhoff/requestStorageAccessForSite> for much
>> more information, including about the elevated trust requirement
>> <https://github.com/mreichhoff/requestStorageAccessForSite#elevated-trust-requirement>
>> .
>> Motivation
>>
>> Multiple browsers supporting the Storage Access API have implemented an
>> internal API similar to requestStorageAccessForSite, indicating it is
>> useful for websites that depend on authenticated/personalized content
>> served from cross-site origins. We intend it to aid in unblocking certain
>> cross-site, same-First-Party Set
>> <https://github.com/krgovind/first-party-sets/> use cases previously
>> addressed by the now-archived SameParty cookie attribute
>> <https://github.com/cfredric/sameparty>.
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The new API is in the process of being specified. Because it is additive,
>> it does not present a significant risk to existing code (with the only risk
>> being sites that would have added an identically named method to the
>> document object).
>>
>> Feedback is currently being sought; these are TODOs but need not block
>> prototyping.
>>
>> Firefox: TODO
>>
>> Edge: TODO
>>
>> Safari: TODO
>>
>> Web developers: TODO
>>
>> Ergonomics
>>
>> See the key scenarios
>> <https://github.com/mreichhoff/requestStorageAccessForSite#key-scenarios>
>> and design discussions
>> <https://github.com/mreich

[blink-dev] Intent to Prototype: requestStorageAccessForSite

2022-08-09 Thread Matt Reichhoff 
Contact emails

mreichh...@chromium.org, kaustub...@chromium.org, johann...@chromium.org
Explainer

https://github.com/mreichhoff/requestStorageAccessForSite
Specification

We do not have a draft specification yet, but we hope to further incubate
and develop the API, and specify it as an extension of the existing Storage
Access API .
TAG review

Not yet filed.
Blink component

Blink>StorageAccessAPI
Summary

This intent proposes an extension to the Storage Access API
 (which was previously
implemented

in Chromium by the Microsoft Edge team). The extension allows a top-level
site to request access to unpartitioned ("first-party") cookies on behalf
of embedded sites. We intend for sites to utilize this API as one of the
replacements for third-party cookies, which are being phased out

in Chrome. This extension of the Storage Access API inverts the direction
of the `requestStorageAccess` request, which is called by the embedded site
once it receives a user interaction. Browsers will have discretion to grant
or deny access. See the explainer
 for much more
information, including about the elevated trust requirement

.
Motivation

Multiple browsers supporting the Storage Access API have implemented an
internal API similar to requestStorageAccessForSite, indicating it is
useful for websites that depend on authenticated/personalized content
served from cross-site origins. We intend it to aid in unblocking certain
cross-site, same-First-Party Set
 use cases previously
addressed by the now-archived SameParty cookie attribute
.
Risks

Interoperability and Compatibility

The new API is in the process of being specified. Because it is additive,
it does not present a significant risk to existing code (with the only risk
being sites that would have added an identically named method to the
document object).

Feedback is currently being sought; these are TODOs but need not block
prototyping.

Firefox: TODO

Edge: TODO

Safari: TODO

Web developers: TODO

Ergonomics

See the key scenarios

and design discussions

on the explainer. Note that some details, like origin vs site scoping, are
still being determined.

Security

Please see the security and privacy considerations section of the explainer
.
There are some details, like potential CORS requirements, that are still
being considered.

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

Yes, all blink platforms are in scope.

Is this feature fully tested by web-platform-tests

?

web-platform-test coverage will be added as part of this effort, once the
spec is sufficiently defined.

Feature flag (until launch)

--enable-features=StorageAccessAPI-rsaFor

(note that the larger StorageAccessAPI is behind the flag:
StorageAccessAPI; the new flag name is subject to change)

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

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

[blink-dev] Re: Intent to Ship: User Agent Client Hints GREASE Update

2022-07-06 Thread Matt Reichhoff 
As a small update, we recently encountered a few instances of leading
special characters causing issues (1
<https://bugs.chromium.org/p/chromium/issues/detail?id=1260889#c2>,2
<https://bugs.chromium.org/p/chromium/issues/detail?id=1334304>) with
sites. Accordingly, we slightly modified the spec
<https://github.com/WICG/ua-client-hints/commit/accfc3e207f5c4ca84009a98f69521e5bd1dac56>
to
disallow leading GREASE characters. We don't believe a separate Intent to
[Prototype|Experiment|Ship] is needed, because all new strings would be
valid under the prior spec as well. Please let us know of any disagreement;
otherwise, we will make the corresponding code change in m105.

On Tue, May 3, 2022 at 10:17 AM Matt Reichhoff 
wrote:

> Contact emails
>
> mreichh...@chromium.org, miketa...@chromium.org
>
> Explainer
>
> https://github.com/WICG/ua-client-hints#user-agent-client-hints
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#grease
>
> Summary
>
> We seek to align our implementation of GREASE in User Agent Client Hints
> with the current spec, which includes additional GREASE characters beyond
> the current semicolon and space, and which recommends varying the arbitrary
> version. This is to help prevent bad assumptions from being built on top of
> User-Agent strings.
>
> After experimentation over the course of several releases, we propose to
> make the updated algorithm the default behavior starting with M103. See
> below for potential risks and their mitigation.
>
> Blink component
>
> Privacy>Fingerprinting
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>
> TAG review
>
> N/A. This is a small change to a feature that was already reviewed by the
> TAG <https://github.com/w3ctag/design-reviews/issues/640>.
>
> TAG review status
>
> Not applicable
>
> Risks
> Interoperability and Compatibility
>
> A prior implementation including escaped ASCII 0x22 (double quote) and
> 0x5C (backslash) proved to be web incompatible and was rolled back.
>
> We do not anticipate similar issues with the updated algorithm, because
> experimentation was run in M98 and M99 (during February and March, 2022),
> and did not uncover statistically significant shifts in response codes,
> with the worst finding showing a potential effect size of an additional 2-3
> requests per 100k returning 502 responses; it was marked low-to-medium
> statistical confidence and did not show up consistently across timeframes
> and platforms, leading us to believe it was noisy. We have also not been
> able to find bug reports tied to the changes.
>
> However, because there are hundreds of permutations of the GREASE string,
> we also performed the following set of safety checks:
>
>-
>
>Ran a multi-group experiment where each of the new characters was
>checked in the canary and dev channels; we again did not get statistically
>significant results for response codes.
>-
>
>Ran a fuzzer against the top 10,000 sites (per Tranco
><https://tranco-list.eu/>) with each of the new characters and did not
>observe breakage.
>-
>
>   Per experimental results, special attention was paid to 502
>   responses; none seen with the fuzzer were reproducible in canary with 
> the
>   updated algorithm, reinforcing our belief that the 502 metric was just
>   occasionally noisy.
>   -
>
>Implemented and will maintain for at least an additional 1 year an
>enterprise escape hatch to opt out of the new behavior; that timeframe will
>ensure sufficient coverage of permutations.
>-
>
>Implemented and will maintain for the same timeframe the ability to
>override the behavior via Finch if problems are uncovered.
>-
>
>Implemented once-per-version rotation of the string, meaning we would
>have the full release cycle to uncover any issues with a given permutation,
>much like we do with any other change to chromium.
>
>
> Gecko: Non-harmful (
> https://mozilla.github.io/standards-positions/#ua-client-hints)
>
> WebKit: No signal on this particular change. But unofficially mildly
> positive
> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031201.html> on
> UA-CH as a whole.
>
> Web developers: No 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; Android WebView is not affected.
>
>
> Debuggability
>
> N/A; no change required
>
>
> Is this feature fully tested by web-platform-tests
> <https:

Re: [blink-dev] Re: Intent to Ship: Update User-Agent Client Hints GREASE implementation

2022-05-04 Thread &#x27;Matt Reichhoff' via blink-dev 
M103.

I will be sure to let you know if that changes for some reason.

Thanks!

On Wed, May 4, 2022 at 12:08 PM 'Joe Medley' via blink-dev <
blink-dev@chromium.org> wrote:

> In which version are you wanting to ship?
>
> On Wednesday, May 4, 2022 at 6:06:30 AM UTC-7 mkwst via Chromestatus wrote:
>
>> LGTM3.
>>
> --
> 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/3108ff66-551a-4e36-adeb-cdac929cdee5n%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/CAGBTsisgZaX50LQUyF8To%2BONOsvC%3D5dS-PGJfa3r4XEXjqxMSg%40mail.gmail.com.

[blink-dev] Intent to Ship: User Agent Client Hints GREASE Update

2022-05-03 Thread Matt Reichhoff 
Contact emails

mreichh...@chromium.org, miketa...@chromium.org

Explainer

https://github.com/WICG/ua-client-hints#user-agent-client-hints

Specification

https://wicg.github.io/ua-client-hints/#grease

Summary

We seek to align our implementation of GREASE in User Agent Client Hints
with the current spec, which includes additional GREASE characters beyond
the current semicolon and space, and which recommends varying the arbitrary
version. This is to help prevent bad assumptions from being built on top of
User-Agent strings.

After experimentation over the course of several releases, we propose to
make the updated algorithm the default behavior starting with M103. See
below for potential risks and their mitigation.

Blink component

Privacy>Fingerprinting


TAG review

N/A. This is a small change to a feature that was already reviewed by the
TAG .

TAG review status

Not applicable

Risks
Interoperability and Compatibility

A prior implementation including escaped ASCII 0x22 (double quote) and 0x5C
(backslash) proved to be web incompatible and was rolled back.

We do not anticipate similar issues with the updated algorithm, because
experimentation was run in M98 and M99 (during February and March, 2022),
and did not uncover statistically significant shifts in response codes,
with the worst finding showing a potential effect size of an additional 2-3
requests per 100k returning 502 responses; it was marked low-to-medium
statistical confidence and did not show up consistently across timeframes
and platforms, leading us to believe it was noisy. We have also not been
able to find bug reports tied to the changes.

However, because there are hundreds of permutations of the GREASE string,
we also performed the following set of safety checks:

   -

   Ran a multi-group experiment where each of the new characters was
   checked in the canary and dev channels; we again did not get statistically
   significant results for response codes.
   -

   Ran a fuzzer against the top 10,000 sites (per Tranco
   ) with each of the new characters and did not
   observe breakage.
   -

  Per experimental results, special attention was paid to 502
  responses; none seen with the fuzzer were reproducible in canary with the
  updated algorithm, reinforcing our belief that the 502 metric was just
  occasionally noisy.
  -

   Implemented and will maintain for at least an additional 1 year an
   enterprise escape hatch to opt out of the new behavior; that timeframe will
   ensure sufficient coverage of permutations.
   -

   Implemented and will maintain for the same timeframe the ability to
   override the behavior via Finch if problems are uncovered.
   -

   Implemented once-per-version rotation of the string, meaning we would
   have the full release cycle to uncover any issues with a given permutation,
   much like we do with any other change to chromium.


Gecko: Non-harmful (
https://mozilla.github.io/standards-positions/#ua-client-hints)

WebKit: No signal on this particular change. But unofficially mildly
positive
 on
UA-CH as a whole.

Web developers: No 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; Android WebView is not affected.


Debuggability

N/A; no change required


Is this feature fully tested by web-platform-tests

?

Yes

Flag name

--enable-features="GreaseUACH:updated_algorithm/true"

Requires code in //chrome?

False

Tracking bug

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



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5630916006248448

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/ueudFsZzT1M
Intent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGg35ayyQVGYm%2BE7LreK50L0drNSuBJGHhrcqEK00pqefJ8fPQ%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/CAGg35ax2ckar8632L81A4-Yo%3DFumAKr3AP_iwGnpZXvH%3DYePmg%40mail.gmail.com.

[blink-dev] Re: Intent To Experiment: User-Agent Client Hints GREASE Update

2022-02-01 Thread Matt Reichhoff 
Thanks for the response! Yes, we will be keeping an eye on metrics and bug
reports.

In terms of the character set, it is defined here:
https://wicg.github.io/ua-client-hints/#create-arbitrary-brands-section
It includes: 0x20 (SP), 0x28 (left parenthesis), 0x29 (right parenthesis),
0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D (=), 0x3F (?), 0x5F
(_). The prior implementation included only space (0x20) and semicolon
(0x3B).



On Tue, Feb 1, 2022 at 4:45 AM Mike West  wrote:

> LGTM to experiment with this change on a small percentage of stable in M98
> and M99. Presumably you'll be keeping an eye on metrics and bug reports to
> roll it back in case unexpected incompatibility is discovered.
>
> Out of curiosity, what is the new character set with which you'll be
> working? The spec link was fairly generic, describing a strategy rather
> than an algorithm.
>
> -mike
>
> On Wednesday, January 26, 2022 at 11:18:56 PM UTC+1 Matt Reichhoff wrote:
>
>> Contact emails
>>
>> mreichh...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/ua-client-hints#user-agent-client-hints
>>
>> Specification
>>
>> https://wicg.github.io/ua-client-hints/#grease
>>
>> Summary
>>
>> We seek to align our implementation of GREASE in User Agent Client Hints
>> with the current spec, which includes additional GREASE characters beyond
>> the current semicolon and space, and which recommends varying the arbitrary
>> version. This is to help prevent bad assumptions from being built on top of
>> User-Agent strings.
>>
>> This intent seeks approval to begin an experiment on stable at 1% with
>> the m98 release. Due to a clerical error, the experiment is already running
>> on m98 in beta. The goal is to determine whether the new spec is web
>> compatible via a controlled experiment before we ship to stable.
>>
>>
>> Blink component
>>
>> Privacy>Fingerprinting
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/640
>>
>> TAG review status
>>
>> In progress, but all raised issues addressed.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The prior inclusion (in 2020) of escaped ASCII 0x22 (double quote) and
>> 0x5C (backslash) proved to be web incompatible and was rolled back. While
>> we do not anticipate similar problems with the updated character list, we
>> have taken (or will take) the following actions to validate this assumption:
>>
>>-
>>
>>Pre-launch testing of the new characters against known-common sites,
>>which will include tests against the components known to have been
>>incompatible with the prior implementation [COMPLETED].
>>-
>>
>>Addition of an enterprise policy escape hatch [COMPLETE].
>>-
>>
>>A phased rollout along with monitoring of HTTP 4XX response rates
>>[PROPOSED HERE].
>>
>>
>> Gecko: Non-harmful (
>> https://mozilla.github.io/standards-positions/#ua-client-hints)
>>
>> WebKit: No signal
>>
>> Web developers: No signals
>>
>> Other signals: N/A
>>
>>
>> Goals for experimentation
>>
>> A phased rollout is desired to ensure the changes to the spec are
>> web-compatible. To that end, we will begin with 1% of users on stable, with
>> monitoring of HTTP response codes to ensure the change is non-breaking.
>>
>>
>> Debuggability
>>
>> N/A; no change required
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No (not on WebView or iOS)
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?
>>
>> Yes
>> <https://chromium-review.googlesource.com/c/chromium/src/+/3225903/6/third_party/blink/web_tests/external/wpt/html/webappapis/system-state-and-capabilities/the-navigator-object/navigator_user_agent.https.html>
>>
>> Flag name
>>
>> --enable-features="GreaseUACH:updated_algorithm/true"
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1164423
>>
>> Estimated milestones
>>
>> We anticipate this experiment starting in M98 and running for 2
>> milestones, but it could extend if

[blink-dev] Intent To Experiment: User-Agent Client Hints GREASE Update

2022-01-26 Thread Matt Reichhoff 
Contact emails

mreichh...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org

Explainer

https://github.com/WICG/ua-client-hints#user-agent-client-hints

Specification

https://wicg.github.io/ua-client-hints/#grease

Summary

We seek to align our implementation of GREASE in User Agent Client Hints
with the current spec, which includes additional GREASE characters beyond
the current semicolon and space, and which recommends varying the arbitrary
version. This is to help prevent bad assumptions from being built on top of
User-Agent strings.

This intent seeks approval to begin an experiment on stable at 1% with the
m98 release. Due to a clerical error, the experiment is already running on
m98 in beta. The goal is to determine whether the new spec is web
compatible via a controlled experiment before we ship to stable.


Blink component

Privacy>Fingerprinting


TAG review

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

TAG review status

In progress, but all raised issues addressed.

Risks
Interoperability and Compatibility

The prior inclusion (in 2020) of escaped ASCII 0x22 (double quote) and 0x5C
(backslash) proved to be web incompatible and was rolled back. While we do
not anticipate similar problems with the updated character list, we have
taken (or will take) the following actions to validate this assumption:

   -

   Pre-launch testing of the new characters against known-common sites,
   which will include tests against the components known to have been
   incompatible with the prior implementation [COMPLETED].
   -

   Addition of an enterprise policy escape hatch [COMPLETE].
   -

   A phased rollout along with monitoring of HTTP 4XX response rates
   [PROPOSED HERE].


Gecko: Non-harmful (
https://mozilla.github.io/standards-positions/#ua-client-hints)

WebKit: No signal

Web developers: No signals

Other signals: N/A


Goals for experimentation

A phased rollout is desired to ensure the changes to the spec are
web-compatible. To that end, we will begin with 1% of users on stable, with
monitoring of HTTP response codes to ensure the change is non-breaking.


Debuggability

N/A; no change required


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

No (not on WebView or iOS)

Is this feature fully tested by web-platform-tests

?

Yes


Flag name

--enable-features="GreaseUACH:updated_algorithm/true"

Tracking bug

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

Estimated milestones

We anticipate this experiment starting in M98 and running for 2 milestones,
but it could extend if the data is inconclusive. We are most concerned
about website tail behavior with this change, which can make data gathering
slower than we’d like.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5630916006248448

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/ueudFsZzT1M

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

[blink-dev] Re: Intent to Prototype: User-Agent Client Hints GREASE Update

2021-10-18 Thread Matt Reichhoff 
A small update:
The correct feature link is:
https://www.chromestatus.com/feature/5630916006248448
(also updated below)

On Thu, Oct 14, 2021 at 5:43 PM Matt Reichhoff 
wrote:

> Contact emails
>
> mreichh...@chromium.org, b...@chromium.org, miketa...@chromium.org,
> jadekess...@chromium.org
>
> Explainer
>
> https://github.com/WICG/ua-client-hints#user-agent-client-hints
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#create-arbitrary-brands-section
>
> https://wicg.github.io/ua-client-hints/#grease
>
> API spec
>
> Yes
>
> Summary
>
> This proposal seeks to align our implementation of GREASE in User Agent
> Client Hints with the current spec, which includes additional GREASE
> characters beyond the current semicolon and space, and which recommends
> varying the arbitrary version.
>
> Blink component
>
> Privacy>Fingerprinting
> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3APrivacy%3EFingerprinting>
>
> Motivation
>
> User-Agent GREASE is intended to discourage arbitrary user agent
> blocklists and other assumptions being built on top of the User-Agent
> header. A similar concept exists in TLS
> <https://tools.ietf.org/html/draft-ietf-tls-grease>. This practice is
> currently implemented in Chromium, but today’s implementation differs
> slightly from the current spec. If implemented, this proposal would enable
> additional GREASE characters (the full list includes the following ASCII
> characters: 0x20 (SP), 0x28 (left parenthesis), 0x29 (right parenthesis),
> 0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D (=), 0x3F (?), 0x5F
> (_)) and vary the arbitrary version over time. Note that the GREASE portion
> of the header would remain constant per major version, in accordance with
> the spec.
>
> TAG review
>
> UA-CH is currently in review
> <https://github.com/w3ctag/design-reviews/issues/640>.
>
> Risks
>
> The prior inclusion of escaped ASCII 0x22 (double quote) and 0x5C
> (backslash) proved to be web incompatible
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1091285> and was
> rolled back
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1149575>. While we
> do not anticipate similar problems with the updated character list, we will
> take the following actions to validate this assumption:
>
>-
>
>Pre-launch testing of the new characters against known-common sites,
>which will include tests against the components known to have been
>incompatible with the prior implementation.
>-
>
>A phased rollout along with monitoring of HTTP 4XX response rates.
>
>
> Interoperability and Compatibility
>
> WebKit: No official position; mild positive signals.
> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031198.html>
>
> Firefox: UA Client hints considered non-harmful
> <https://mozilla.github.io/standards-positions/#ua-client-hints>
>
>
>
> Is this feature fully tested by web-platform-tests?
>
> We will be adding web-platform-tests to validate this functionality.
>
> Tracking bug
>
> https://crbug.com/1164423
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5630916006248448
>

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

[blink-dev] Intent to Prototype: User-Agent Client Hints GREASE Update

2021-10-14 Thread Matt Reichhoff 
Contact emails

mreichh...@chromium.org, b...@chromium.org, miketa...@chromium.org,
jadekess...@chromium.org

Explainer

https://github.com/WICG/ua-client-hints#user-agent-client-hints

Specification

https://wicg.github.io/ua-client-hints/#create-arbitrary-brands-section

https://wicg.github.io/ua-client-hints/#grease

API spec

Yes

Summary

This proposal seeks to align our implementation of GREASE in User Agent
Client Hints with the current spec, which includes additional GREASE
characters beyond the current semicolon and space, and which recommends
varying the arbitrary version.

Blink component

Privacy>Fingerprinting


Motivation

User-Agent GREASE is intended to discourage arbitrary user agent blocklists
and other assumptions being built on top of the User-Agent header. A
similar concept exists in TLS
. This practice is
currently implemented in Chromium, but today’s implementation differs
slightly from the current spec. If implemented, this proposal would enable
additional GREASE characters (the full list includes the following ASCII
characters: 0x20 (SP), 0x28 (left parenthesis), 0x29 (right parenthesis),
0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D (=), 0x3F (?), 0x5F
(_)) and vary the arbitrary version over time. Note that the GREASE portion
of the header would remain constant per major version, in accordance with
the spec.

TAG review

UA-CH is currently in review
.

Risks

The prior inclusion of escaped ASCII 0x22 (double quote) and 0x5C
(backslash) proved to be web incompatible
 and was
rolled back .
While we do not anticipate similar problems with the updated character
list, we will take the following actions to validate this assumption:

   -

   Pre-launch testing of the new characters against known-common sites,
   which will include tests against the components known to have been
   incompatible with the prior implementation.
   -

   A phased rollout along with monitoring of HTTP 4XX response rates.


Interoperability and Compatibility

WebKit: No official position; mild positive signals.


Firefox: UA Client hints considered non-harmful




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

We will be adding web-platform-tests to validate this functionality.

Tracking bug

https://crbug.com/1164423

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5995832180473856

-- 
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/CAGg35aw1Ddy-STGWMqHhDmONxp4aM%3DMaeoRYwi-sVmijUnH8gg%40mail.gmail.com.