Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

2023-09-01 Thread 'Fergal Daly' via blink-dev 
Sorry for the slow reply, I've had to focus on some other things in the
last month. The reply below covers a few overlapping topics that were
brought up in this thread by Yoav Weiss and Daniel Bratell.

On Fri, 28 Jul 2023 at 13:57, Yoav Weiss  wrote:

> Hey Mingyu & Fergal,
>
> Given the fact that getting this heuristic wrong can have *significant*
> negative implications on impacted users, I think we need to be very careful
> here.
> I'd love to see a plan to validate the heuristic we'd pick here such that
> its coverage is as close to 100% as we can in terms of hitting the
> "excessive cache limits" bucket (and missing the "user sensitive data"
> bucket). Alternatively, maybe we could use a mix of outreach and a new API
> (or fix Clear-Site-Data) to help us fish out the "excessive cache limits"
> crowd?
>

> Do we have a way to validate the heuristics y'all came up with and
understand what would be their hit rate vs. miss rate? What makes us
confident that no sensitive data would be caught in those heuristics as
cacheable content?

It's important to clarify something. Our goal is not to avoid restoring
pages containing *any* sensitive data. Our goal is to avoid restoring pages
containing sensitive data that the user no longer has access to. If cookies
have not changed, then the browser's HTTP request will be the same as last
time and our assumption is that the decisions about access will also be the
same. We know this assumption is not entirely correct, resources could be
deleted or access could be changed on the server, hence our shorter
timeout. We can break the problem down as follows

   -

   changes on the client result is loss of access (e.g.
   cookies/access-tokens changed/deleted) - we believe this is covered
   -

   changes on the server results in loss of access - this breaks down
   further
   -

  site has implemented a way to immediately reflect those changes to
  open pages, e.g. using EventSource - this will continue to work either by
  causing them to be evicted or by delivering events as soon as they are
  restored from BFCache
  -

  site has not implemented a way to immediately reflect those changes
  to open pages - in this case users can hold onto this data
indefinitely. We
  are adding an additional window where this data could also reappear from
  BFCache. It would be surprising for a site to be concerned about
the latter
  but not with the former.



XMLHttpRequest, fetch, WebTransport, WebRTC, WebSocket complicate this as
they give a route for sensitive data to appear in the page outside of
navigation-driven requests and that is why we block restoring if we see any
of those (for XHR and fetch we only block if the response is CCNS, for the
others we simply have to assume that all data is sensitive).

Given all that, we don't have any way to estimate how often it would happen
that sensitive content that the user has lost access to would appear from
BFCache. If we had a way to measure it, we would probably use that as a
heuristic to prevent BFCaching. We believe it would only happen if e.g. a
server-side change removed the user's access to the data as discussed above.

Daniel:
> Even if cache-control: no-store is being badly overused, and the numbers
you list seem to indicate that is the case, hasn't there been a promise to
web developers that such a resource will be forever gone once the page is
no longer shown, and is that a promise that can reasonably be broken?

There is no explicit promise that CCNS prevents BFCaching. The CCNS header,
or in general, all the Cache-control directives, are intended to control
the HTTP caching, so the explicit promise is about HTTP cache. BFCache is
not part of the HTTP caching, and developers should not interpret the CCNS
header as a promise that the page will not be BFCached. Indeed, there is a
consensus  about not providing
any explicit way of preventing BFCache to avoid abuse. This web.dev article
 also
touches on the difference between BFCache and HTTP cache with the
Cache-control header.

There is an implicit promise that comes from the fact that CCNS has blocked
BFCache. It’s inevitable that some sites have already set their
expectations on the CCNS header blocking BFCache. Some sites will
malfunction when they start to be restored from BFCache. This was also true
when we launched BFCache for non-CCNS sites.

We believe that BFCache is a huge user benefit. We launched it knowing that
some pages would malfunction. The benefit to users outweighs the cost of
some devs having to update their sites to work with BFCache. We don't think
CCNS sites should get a special pass. The concern with CCNS-sites is that
they often deal with sensitive information and that is why we have put so
much effort into making sure that that kind of information is not
inappropriately resurfaced as a result of BFCache.

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

2023-09-01 Thread 'Fergal Daly' via blink-dev 
Sorry for the slow reply, I've had to focus on some other things in the
last month. The reply below covers a few overlapping topics that were
brought up in this thread by Yoav Weiss and Daniel Bratell.


On Sat, 29 Jul 2023 at 03:03, Mike Taylor  wrote:

> Thanks for the additional analysis. Another question I have, if a site
> sends:
>
> "Cache-Control: no-cache, no-store, must-revalidate" (copypasta from 
> https://stackoverflow.com/a/2068407),
> would it be treated differently as "Cache-Control: no-store"? I'm trying to 
> think of signals that might be useful as
> heuristics for "no seriously don't ever cache this"...
>
>
We would prefer not to do this and other browsers are in agreement
. If we give any kind of simple
header that prevents BFCaching, it will become the wide-spread
stack-exchange-documented way to opt out of BFCache. Any site that truly
cannot tolerate its data entering BFCache and doesn't already fall under
one of our conditions for avoiding BFCache, can erase content in a
`pagehide` handler as they enter BFCache and reload it in a `pageload`
handler if restored. This is pretty simple to do for anyone who truly needs it
(worst case they trigger a reload from JS when leaving BFCache, obviously
not a good user experience but we have to weight that against block BFCache
for many users) but it still provides a little bit of a barrier, so
hopefully people think twice and instead correctly support BFCache rather
than casually opting out,

F

 On 7/27/23 9:04 AM, Mingyu Lei wrote:
>
> Hi Mike,
>
> Following our previous response, we would like to share the usage data
> that we have collected from the beta channel. 18.76% of history navigations
> are not restored from BFCache because of the CCNS header only. The
> following are the breakdowns:
>
>- No RPC containing CCNS response header: 8.63%
>- *No cookie modification: 6.70%*
>   - With non-HttpOnly cookie modifications only: 1.38%
>   - With HttpOnly or non-HttpOnly cookie modifications: 0.55%
>- With RPC containing CCNS response header: 10.13%
>- No cookie modification: 1.01%
>   - With non-HttpOnly cookie modifications only: 7.86%
>   - With HttpOnly or non-HttpOnly cookie modifications: 1.26%
>
> Based on these figures, we will update the proposal to evict the BFCache
> entry with any cookie modification for the current phase. This should give
> us 6.70% improvement in cache hit rate.
>
> We could continue the HttpOnly cookie discussion in the future.
>
> On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei  wrote:
>
>> Hi Mike,
>>
>> Thanks for the comments. We have discussed the concerns you raised before
>> and please find the replies below.
>>
>>
>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies
>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure" cookies.
>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute
>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something else?
>>>
>>
>>
>>> Later in
>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api,
>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only"
>>> cookies have changed. Are these cookies setting only the "HttpOnly"
>>> attribute, or is this intended to say "HTTPS-only" as above?
>>>
>>
>> The short answer is that we will only monitor HttpOnly cookies,
>> regardless of whether they are secure or not. The terms in the explainer
>> were unclear, and we will fix them.
>>
>> I see that
>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477
>>> references this work. Did we learn anything from experimentation in the
>>> wild (not sure if y'all ran an experiment)?
>>>
>>> I'm curious if y'all have looked at stats on the uptake of
>>> secure/httponly cookies vs "non-secure" cookies being set by pages returned
>>> from RPCs sent with an Authorization header (though I wouldn't be surprised
>>> if we don't have UMA for that... perhaps just globally would be useful to
>>> consider).
>>>
>>
>> We are currently conducting a Finch experiment to collect the hit rate on
>> beta, and the data will be available next week. We will share it with you
>> again after we have the data.
>>
>> With that data, we will be able to tell the percentage of page loads that
>> observe HttpOnly cookie changes, any cookie changes, or no cookie changes.
>> There will also be another dimension about whether the page had sent out
>> RPC with CCNS response. There is no pre-existing UMA for this, but we have
>> recorded the reasons why BFCache is not restored.
>>
>> My only concern (which may not be grounded in reality) would be for sites
>>> not following best practices...
>>
>>
>> We expect that there will be cases where pages are restored
>> inappropriately where sites are not following good practice. We don't have
>> an idea of the size of th

Re: [blink-dev] Intent to Prototype: WebDriver commands for triggering Bounce Tracking Mitigations

2023-09-01 Thread 'Mathias Bynens' via blink-dev 
Excited about this getting prototyped! I look forward to discussing the
specifics, such as the exact shape of the WebDriver Classic or BiDi
command(s) / event(s). Please keep me looped in.

On Thu, Aug 31, 2023 at 11:28 PM Joshua Hood  wrote:

> *Please note that the addition of an associated "User Agent Automation**"** 
> section
> to the spec, defining the new WebDriver Extension Command(s)
> , is still in
> progress.*
> Contact emails...@chromium.org, wanderv...@chromium.org,
> rtarp...@chromium.org, b...@chromium.org
>
> ExplainerNone
>
> Specification
> https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations
>
> Summary
>
> Exposes a WebDriver command to allow browser automation, such as the
> automated testing, to force Bounce Tracking Mitigations to run immediately.
> There are currently no web-platform-tests for Bounce Tracking Mitigations.
> Adding this WebDriver command allows web developers to create
> web-platform-tests to test their implementation and verify its adherence to
> the spec.
>
>
> Blink componentPrivacy>NavTracking
> 
>
> Motivation
>
> None
>
>
> Initial public proposalNone
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> Not applicable
>
>
> Security
>
> n/a, this is only exposed through WebDriver.
>
>
> 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
>
> This is a debugging feature.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1474656
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5171591763197952
>
> 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/CAAp0QgekAmLOLMwaRQAGpM_-J_WmsCTBZpK6WurhfyUFi9ii3A%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/CADizRga6cYrN-EiZAt-EcWCr0Sd%2B30ym%3DOr59VgOU%3Dn%3DK8o%2BBg%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: DisplayMediaStreamOptions monitorTypeSurfaces

2023-09-01 Thread 'François Beaufort' via blink-dev 
Contact emails

fbeauf...@google.com

elada...@google.com

Explainer

https://github.com/eladalon1983/screen-share-explainers/blob/main/monitorTypeSurfaces_Explainer.md

Specification

https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamoptions-monitortypesurfaces

Summary

When getDisplayMedia() is called, the browser offers the user a choice of
display surfaces: tabs, windows, or monitors. Using the monitorTypeSurfaces
option, the web application may now hint to the browser if it prefers to
include display surfaces whose type is monitor among the choices offered to
the user.

Blink component

Blink>GetDisplayMedia


TAG review

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

TAG review status

Pending

Risks
Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/876)
Jan-Ivar Bruaroey from Mozilla has reviewed and approved
https://github.com/w3c/mediacapture-screen-share/pull/274.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/248)
Youenn Fablet from Apple has participated in
https://www.w3.org/2023/06/27-webrtc-minutes.html#t04 and
https://github.com/w3c/mediacapture-screen-share/issues/261#issuecomment-1693090386
.

Web developers: Positive Cisco folks have expressed interest in this
feature.
https://github.com/screen-share/meetings/blob/main/minutes/2023-03-21.md?plain=1#L161

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

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

Supported on all platforms that support getDisplayMedia. Namely, all
desktop platforms.

Is this feature fully tested by web-platform-tests

?

Yes. See https://wpt.fyi/results/screen-capture/getdisplaymedia.https.html

Flag name on chrome://flags

None

Finch feature name

MonitorTypeSurfaces

Requires code in //chrome?

Yes. In chrome/browser/media/webrtc/display_media_access_handler.cc

Tracking bug

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

Estimated milestones

Shipping on desktop

119

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

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5558622137876480

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

Re: [blink-dev] Intent to Prototype: form-sizing CSS property

2023-09-01 Thread Mike Taylor 

On 8/31/23 7:52 PM, TAMURA, Kent wrote:



Contact emails

tk...@chromium.org, ikilpatr...@chromium.org


Explainer

https://github.com/tkent-google/explainers/blob/main/form-sizing.md


Specification

https://github.com/w3c/csswg-drafts/pull/9251


Design docs

N/A


Summary

By 'form-sizing' property, web authors can disable fixed default sizes 
of form controls, and make their size depend on their content. It's 
very easy to provide automatically-growing text fields.




Blink component

Blink>Layout 




Motivation

None



Initial public proposal

None


Search tags

css , forms 
, form-sizing 




TAG review

https://github.com/w3ctag/design-reviews/issues/883
https://github.com/w3ctag/design-reviews/issues/890 seems to be the 
correct link.



TAG review status

Issue open


Risks



Interoperability and Compatibility



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/849)


/WebKit/: Positive 
(https://github.com/WebKit/standards-positions/issues/231)


/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

?

Yes, it should be.


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5176596826161152

This intent message was generated by Chrome Platform Status 
.


--
TAMURA Kent
Software Engineer, Google


--
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/CAGH7WqF9x271V96TMM3YNumzawv%3DC9i30BeW2trNO_%2Bk7O4%2BAg%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/01012c98-0a82-4806-b238-2a0984dd9a3e%40chromium.org.

Re: [blink-dev] Intent to Experiment: Tabbed web apps

2023-09-01 Thread Mike Taylor 

No issues, thanks for the update.

On 8/31/23 11:16 PM, 'Louise Brett' via blink-dev wrote:
We aren't ready to start the origin trial in M117 so we are going to 
run it from M118-123 (inclusive).


On Wednesday, July 26, 2023 at 1:19:33 PM UTC+10 Matt Giuca wrote:

@Šime: Yes, the feature as currently implemented is exposed as a
media query: "(display-mode: tabbed)" works.

We flagged additionally the need to be able to detect
whether you're in the special home tab. I'm not sure how you do
that (whether it's a media query or some other way) and it isn't
mentioned in the explainer

.
Perhaps Louise can explain (out until next week) if there is a way
to do it. However, I checked the basic detection of "am I in
tabbed mode" works with a media query.

On Mon, 24 Jul 2023 at 20:25, Thomas Steiner  wrote:

On Mon, Jul 24, 2023 at 01:04 Šime Vidas 
wrote:

Is it available in CSS media queries?

@media (display-mode: tabbed) { ... }


I have opened https://github.com/w3c/manifest/issues/952 where
the same request is made for all overrides.



On Wednesday, July 19, 2023 at 9:50:44 AM UTC+2
yoav...@chromium.org wrote:

LGTM to experiment M116-122 (inclusive)

On Wed, Jul 19, 2023 at 8:14 AM 'Louise Brett' via
blink-dev  wrote:


Contact emails

loub...@google.com, alanc...@chromium.org,
gle...@chromium.org, mgi...@chromium.org



Explainer


https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md


Specification

None


Summary

Allow web app windows to have a tab strip. This
adds a new display mode "tabbed" and a new
manifest field to allow customizations to the tab
strip.



Blink component

Blink>AppManifest




TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility



/Gecko/: Defer
(https://github.com/mozilla/standards-positions/issues/811)

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

/Web developers/: Positive
(https://github.com/w3c/manifest/issues/737)

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

N/A. This feature is not supported on WebView so
we will fallback to a supported display mode.



Goals for experimentation

Gather feedback on the API design.


Ongoing technical constraints



Debuggability

chrome://web-app-internals can be used for
debugging, and the new manifest field could also
be added to the DevTools Application pane.



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

No. Initially this will only be available on
ChromeOS, but will be expanded to other desktop
platforms in the future.


Is this feature fully tested by
web-platform-tests

?

No


Flag name on chrome://flags

chrome://flags/#enable-desktop-pwas-tab-strip
chrome://flags/#enable-desktop-pwas-tab-strip-customizations


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

https://bugs.chro

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

2023-09-01 Thread Mike Taylor 

On 9/1/23 12:59 AM, Koji Ishii wrote:



Contact emails

ko...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-text-4/#valdef-word-break-auto-phrase


Design docs


https://docs.google.com/document/d/1QyPza8XS4aaYD-yA1MHYx56Hy7DZuEm9cAH-A6lTu8c/edit?usp=sharing


Summary

Changes the line breaking rules for Japanese to keep natural phrases 
(of multiple words) together. In Japanese, this boundary is called 
"Bunsetu". Japanese doesn't use spaces to delimit words, and usually 
prefers to break at any characters, but short paragraphs such as 
headlines prefer breaking at natural phrase boundaries. In CSS, this 
feature adds a new value to the `word-break` property: `auto-phrase`. 
The implementation uses a C++ port of the BudouX 
, the AdaBoost ML technology to 
determine the natural phrase boundaries.




Blink component

Blink>Layout>Inline 




TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


/WebKit/: In development 
(https://bugs.webkit.org/show_bug.cgi?id=258668) 
https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1586696215


/Web developers/: Positive (https://github.com/google/budoux) The 
original JS/Python implementation has 970 stars and is already used by 
several sites  A demo tweet 
 and its 
retweets  has 
100 likes.


/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



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 on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://github.com/google/budoux
https://google.github.io/budoux
https://twitter.com/kojiishi/status/1687688315896733696


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



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


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJBouY10zVrouYbpGnokj65Jz4Qjuh3UMcS477u2Q9uqw%40mail.gmail.com


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/CAHe_1dKEQhh-Fa7WG_RWed8-ST74Oy_6KvwLnkKpwyau54fRAQ%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/1a675bf6-81e9-4b29-be81-3eb3a2567e38%40chromium.org.

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

2023-09-01 Thread Mike Taylor 

On 9/1/23 9:53 AM, Mike Taylor wrote:


On 9/1/23 12:59 AM, Koji Ishii wrote:



Contact emails

ko...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-text-4/#valdef-word-break-auto-phrase


Design docs


https://docs.google.com/document/d/1QyPza8XS4aaYD-yA1MHYx56Hy7DZuEm9cAH-A6lTu8c/edit?usp=sharing


Summary

Changes the line breaking rules for Japanese to keep natural phrases 
(of multiple words) together. In Japanese, this boundary is called 
"Bunsetu". Japanese doesn't use spaces to delimit words, and usually 
prefers to break at any characters, but short paragraphs such as 
headlines prefer breaking at natural phrase boundaries. In CSS, this 
feature adds a new value to the `word-break` property: `auto-phrase`. 
The implementation uses a C++ port of the BudouX 
, the AdaBoost ML technology to 
determine the natural phrase boundaries.




Blink component

Blink>Layout>Inline 




TAG review

None


TAG review status

Not applicable

Any reason to not request a TAG review?

Ah, it's at https://github.com/w3ctag/design-reviews/issues/891. :)



Risks



Interoperability and Compatibility



/Gecko/: No signal

Can we request one?


/WebKit/: In development 
(https://bugs.webkit.org/show_bug.cgi?id=258668) 
https://github.com/w3c/csswg-drafts/issues/7193#issuecomment-1586696215


/Web developers/: Positive (https://github.com/google/budoux) The 
original JS/Python implementation has 970 stars and is already used 
by several sites  A demo tweet 
 and its 
retweets  
has 100 likes.


/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



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 on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://github.com/google/budoux
https://google.github.io/budoux
https://twitter.com/kojiishi/status/1687688315896733696


Estimated milestones

Shipping on desktop 119

Shipping on Android 119

Shipping on WebView 119



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


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJBouY10zVrouYbpGnokj65Jz4Qjuh3UMcS477u2Q9uqw%40mail.gmail.com


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/CAHe_1dKEQhh-Fa7WG_RWed8-ST74Oy_6KvwLnkKpwyau54fRAQ%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/0370c424-2c15-4045-84fb-d7025781b446%40chromium.org.

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

2023-09-01 Thread Koji Ishii 
On Fri, Sep 1, 2023 at 11:53 PM Mike Taylor  wrote:

> *Gecko*: No signal
>
> Can we request one?
>

Done, https://github.com/mozilla/standards-positions/issues/877

-- 
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/CAHe_1dJmbVodgZLXs%2BY43R%3DGKMKqWGWcadP3K-XOA0Mg%3DM%3DsvA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

2023-09-01 Thread Mike Taylor 

Hi Shivani,

In general I think this is a pretty interesting idea, just a few minor 
questions below:


On 8/30/23 8:16 AM, Shivani Sharma wrote:



Contact emails

shivani...@chromium.org , 
georg...@google.com 



Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md 




A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any more 
info on this? Does a renewal mean incrementing attestation_version?


2) attestation_version states "This allows the maintenance of a 
historical record of attestations." Is that something you plan on 
exposing to the public somewhere? Or would you expect a site to maintain 
previous versions somewhere?


Also, how does unenrollment happen?



Design document

https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing 




Specification

While the enrollment process itself is not intended to be 
standardized, the impacted API specifications allow for a user agent 
defined gating mechanism such as enrollment and attestation. The spec 
changes for the gated APIs are linked below:



Private aggregation (section with note on enrollment 
) 



Shared Storage (pull request 
)


Topics (pull request 
)


Attribution reporting API (pull request 
)


Protected Audience (pull requests: 1 
, 2 
)



Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start ramping up 
for general availability, we want to make sure these technologies are 
used as intended and with transparency. The APIs include Attribution 
Reporting, the Protected Audience API, Topics, Private Aggregation and 
Shared Storage. As announced in a blog post 
, 
a new Developer Enrollment process for Privacy Sandbox relevance and 
measurement APIs is being introduced across Chrome and Android. This 
I2S refers to Chrome’s implementation of fetching the enrolled-sites 
list from the enrollment server (via component updater 
) 
and using it to gate access to the Privacy Sandbox APIs.



Blink component

Blink>PrivateAggregation 



Blink>Storage>SharedStorage 



Blink>TopicsAPI 



Internals > AttributionReporting 



Blink>InterestGroups 




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.

In the initial version, no gated APIs are supported on WebView , with 
the caveat that the Attribution Reporting API delegates from WebView 
to Android and would be gated as part of Android’s attestation based 
gating.



Debuggability


Console errors: The API surfaces gated on enrollment and
attestation will output relevant console error messages if a
given site is not allowed to participate/invoke those API
surfaces. (Private Aggregation API-related console messages
are output during its consumer API enrollment checks e.g.
Shared Storage, but could be made more specific in the future).


Is integration with the Reporting API also planned?


Local override: For local testing, we are providing developer 
overrides with a Chrome flag and CLI switch:


Flag: chrome://flags/#privacy-sandbox-enrollment-overrides

CLI: 
--privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...



Initial public proposal

https://github.com/privacysandbox/attestation/blob/main/README.md 




TAG review

Private Aggregation (comment 
)


Shared Storage (comment

[blink-dev] Re: Intent to Prototype: Isolated Web Apps

2023-09-01 Thread Daniel Herr 


 approach to how these apps are discovered and installed by users given the 
different user expectations on mobile vs. desktop.


What exactly are the these differing expectations?

-- 
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/7a32ced1-b204-46a0-8ada-02f32931146an%40chromium.org.

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

2023-09-01 Thread Shivani Sharma 
Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor  wrote:

> Hi Shivani,
>
> In general I think this is a pretty interesting idea, just a few minor
> questions below:
> On 8/30/23 8:16 AM, Shivani Sharma wrote:
>
> Contact emails
>
> shivani...@chromium.org, georg...@google.com
>
>
> Explainer
>
> https://github.com/privacysandbox/attestation/blob/main/README.md
>
> A few questions about the attestation format:
>
> 1) expiry_seconds_since_epoch implies this expires. Is there any more info
> on this? Does a renewal mean incrementing attestation_version?
>
> 2) attestation_version states "This allows the maintenance of a historical
> record of attestations." Is that something you plan on exposing to the
> public somewhere? Or would you expect a site to maintain previous versions
> somewhere?
>
> Also, how does unenrollment happen?
>
1. Yes the plan is to have attestations expire, and have adtechs step
through re-attestation process which would increment the version.
2. The attestation file hosted on the .well-known will include all their
historical attestations. We could also consider maintaining a historical
record on the transparency server.

Unenrollment would be either when the original attestation expires or the
entity explicitly requests to unenroll (via the form asking to cancel
existing enrollment). When that happens, their data will be removed from
the enrollment records and the updated list pushed to Chrome will not have
their site.


> Design document
>
>
> https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing
>
> Specification
>
> While the enrollment process itself is not intended to be standardized,
> the impacted API specifications allow for a user agent defined gating
> mechanism such as enrollment and attestation. The spec changes for the
> gated APIs are linked below:
>
> Private aggregation (section with note on enrollment
> 
> )
>
> Shared Storage (pull request
> )
>
> Topics (pull request
> )
>
> Attribution reporting API (pull request
> )
>
> Protected Audience (pull requests: 1
> , 2
> )
>
>
> Summary and Motivation
>
> As the Privacy Sandbox relevance and measurement APIs start ramping up for
> general availability, we want to make sure these technologies are used as
> intended and with transparency. The APIs include Attribution Reporting, the
> Protected Audience API, Topics, Private Aggregation and Shared Storage. As
> announced in a blog post
> ,
> a new Developer Enrollment process for Privacy Sandbox relevance and
> measurement APIs is being introduced across Chrome and Android. This I2S
> refers to Chrome’s implementation of fetching the enrolled-sites list from
> the enrollment server (via component updater
> )
> and using it to gate access to the Privacy Sandbox APIs.
>
> Blink component
>
> Blink>PrivateAggregation
> 
>
> Blink>Storage>SharedStorage
> 
>
> Blink>TopicsAPI
> 
>
> Internals > AttributionReporting
> 
>
> Blink>InterestGroups
> 
>
> 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.
>
> In the initial version, no gated APIs are supported on WebView , with the
> caveat that the Attribution Reporting API delegates from WebView to Android
> and would be gated as part of Android’s attestation based gating.
>
> Debuggability
> Console errors: The API surfaces gated on enrollment and attestation will
> output relevant console error messages if a given site is not allowed to
> participate/invoke those API surfaces. (Private Aggregation API-related
> console messages are output during its consumer API enrollment checks e.g.
> Shared Storage, but could be made more specific in the future).
>
> Is integration with the Reporting API also planned?
>

The error reporting currently follows what happens in the gated APIs for
their existing failure paths. Looking at their specs, it seems none of the
gated APIs

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

2023-09-01 Thread Mike Taylor 
I also had an offline discussion with Daniel to confirm shipping as-is 
in M117, and sanitizing in 118 is acceptable from a security POV (trust 
but verify, etc).


LGTM1 to ship.

On 8/31/23 7:55 AM, 'Garrett Tanzer' via blink-dev wrote:
After some discussion offline, we're going to sanitize the macro keys 
and values with EscapeQueryParamValue 
 so 
that macro substitution always stays within the original query 
parameter field. This should prevent XSS-y substitutions while keeping 
the API surface exactly the same for regular use.


This fix will be implemented in M118, and we've decided that it need 
not block launch in M117 due to the low severity (especially because 
the existing reportEvent surface grants the buyer reporting worklet 
complete control over the destination URL, so the ad creative is 
already known to trust the buyer wrt where its reports get sent).


On Monday, August 28, 2023 at 11:55:39 AM UTC-4 Garrett Tanzer wrote:

Hi Daniel,

  * There are a few relevant call sites in the overall reporting
flow:
  o Declare allowlist of reporting destination origins
  + This happens in navigator.joinAdInterestGroup(), by an
ad auction buyer
  o Declare macros (key:value correspondences)
  + This happens in the buyer reporting worklet, by the
same ad auction buyer that declared the reporting
destination origins
  o Perform report to custom url
  + This happens under the auction's winning ad creative's
origin, which isn't necessarily the same as the ad
auction buyer, but it is chosen by the ad auction buyer
  * Here is the sequence of events:

1.
 1. The browser ingests and validates the allowlist when the
interest group is declared.
 2. The browser ingests the macro key:value mapping when the
auction happens. The key/value strings have no structure
that is validated. The browser adds "${" and "}" around
the user-provided keys in the macro mapping.
 3. In the ad that results from the auction:
 1. The ad sends a URL to the browser, including macros
like ${KEY}. The URL has to be a valid HTTPS url even
with the macros unsubstituted. (See impl:

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_host_impl.cc;l=8644?q=content%2Fbrowser%2Frenderer_host%2Frender_frame_host_impl.cc%20-f:out)
 2. The browser performs a simple string substitution to
replace the keys with the values. The implementation
is reused from navigator.deprecatedReplaceInURN,
another part of Protected Audience. It doesn't
substitute macros recursively, so you can't get an
infinite loop. deprecatedReplaceInURN has apparently
not been spec'd, which is was unable to quickly reuse
that spec and left it as a TODO for now.
 3. The origin of the resulting URL is checked against the
allowlist. If it doesn't match any of them, no action
is performed. If the URL is invalid, this will create
an opaque origin and therefore always fail the check.
(See impl:

https://source.chromium.org/chromium/chromium/src/+/main:content/browser/fenced_frame/fenced_frame_reporter.cc;l=454?q=fenced_frame_reporter.cc%20-f:out)
We may add an explicit URL valid/HTTPS check after
substitution for neatness/to be robust to any future
changes to the allowlist checking.
 4. If the URL does pass the check, a GET fetch will be
performed on it (the result is unused). There's no
other parsing/usage of the URL other than performing a
fetch.

So in summary, we were not very concerned about XSS because the
entity choosing the macro pairings is the one we want to protect,
and the entity providing the base URLs is semi-trusted. The less
trusted entity is the site of the destination URL, which just
receives a GET and doesn't get to control anything. Since the URL
has to be valid both before and after the macro substitution, this
limits how wacky the substitutions can get even if you don't trust
one of those entities. The weirdest stuff you could do would be
like "FOO}&key=value1&${BAR" -> "key=value2", so that it becomes
"${FOO}&key=value1&${BAR}" -> "key=value2". We can add a check to
exclude $,{,} characters in the macro key so even this isn't possible.

Hope this answers your questions,
Garrett

On Monday, August 28, 2023 at 9:35:34 AM UTC-4 Daniel V

Re: [blink-dev] Intent to Experiment: X25519Kyber768 key encapsulation for TLS

2023-09-01 Thread Mike Taylor 

Hi David,

LGTM to experiment from M117 - M118 inclusive. I think that's what 
you're asking for - please let me know if I'm reading this incorrectly. 
Good luck!


thanks,
Mike

On 8/28/23 9:18 AM, 'David Adrian' via blink-dev wrote:



Contact emails

dadr...@google.com


Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Summary

Protect current Chrome TLS traffic against future quantum 
cryptanalysis by deploying the Kyber768 quantum-resistant key 
agreement algorithm. This is a hybrid X25519 + Kyber768 key agreement 
based on an IETF standard. This specification and launch is outside 
the scope of W3C. This key agreement will be launched as a TLS cipher, 
and should be transparent to users. 
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html




Blink component

Internals>Network>SSL 




Search tags

tls , kem 
, kyber 
, postquantum 




TAG review



TAG review status

Pending


Risks



Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers. This 
may cause compatibility issues with middleboxes.



Any pointers to learn more about this possible compat problem?



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/874) Firefox is 
also in the process of rolling this out.


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


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




Goals for experimentation

This is a Finch experiment, not site opt-in.

We are aiming to shake out bugs and incompatibilities with buggy TLS 
stacks that do not correctly handle large TLS ClientHellos. Announcing 
a public timeline for experimenting on stable provides the necessary 
justification for teams at companies who have buggy TLS stacks to 
prioritize fixing the bugs.



Ongoing technical constraints



Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

enable-tls13-kyber


Finch feature name

PostQuantumKyber


Requires code in //chrome?

False


Tracking bug

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


Launch bug

https://launch.corp.google.com/launch/4252981


Estimated milestones

Shipping on desktop 119
OriginTrial desktop last118
OriginTrial desktop first   117
DevTrial on desktop 115

Shipping on Android 119
OriginTrial Android last118
OriginTrial Android first   117
DevTrial on Android 115

Shipping on WebView 119



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com


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/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%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/b18bb8c1-e6bb-4592-b6c4-c8a3dcbee74e%40chromium.org.

Re: [blink-dev] Intent to Ship: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

2023-09-01 Thread Mike Taylor 

On 8/30/23 3:55 PM, Luke wrote:



Contact emails

lukewarlow...@gmail.com, l...@warlow.dev


Explainer

https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md


Specification

https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency


Summary

User Preference Media Features Client Hints Header defines a set of 
HTTP Client Hints headers around user preference media features as 
defined by Media Queries Level 5. If used as Critical Client Hints, 
these headers allow servers to make smart choices regarding, e.g., CSS 
inlining. Sec-CH-Prefers-Reduced-Transparency reflects the user's 
prefers-reduced-transparency preference.




Blink component

Blink>CSS 




Search tags

client hints , 
sec-ch-prefers-reduced-transparency 
, 
prefers-reduced-transparency 




TAG review


Anything relevant to link here?



TAG review status

Pending


Risks



Interoperability and Compatibility



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/526)


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


/Web developers/: Positive (WICG proposal Issue: 
https://github.com/WICG/proposals/issues/30 with feedback from 
developers working for Facebook and Magento. Twitter: 
https://twitter.com/kilianvalkhof/status/1392404416335056896. The 
proposal was initially discussed in 
https://github.com/w3c/csswg-drafts/issues/4162 and received positive 
feedback via 18 Likes)


/Other signals/:


Activation

Developers will include Sec-CH-Prefers-Reduced-Transparency in the 
response headers Accept-CH and Critical-CH to let the browser know 
that they’re interested in the user's transparency preferences. If 
supported, the request header Sec-CH-Prefers-Reduced-Transparency will 
be populated with the appropriate value. This follows the same pattern 
as existing Preference Client Hints and as such should be easy for 
developers to make use of.




Security

This feature could be used for fingerprinting as it exposes a user 
preference. However, this is already exposed to CSS/JS by the 
`prefers-reduced-transparency` media query.




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

Developers can change this client hint header value by emulating 
prefers-reduced-transparency via Devtools in the Rendering Panel.




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

Yes

The feature will be supported on all platforms, but whether the user 
will be able to signal a reduced transparency preference depends on 
the OS.




Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

#enable-experimental-web-platform-features


Finch feature name

ClientHintsPrefersReducedTransparency


Requires code in //chrome?

False


Tracking bug

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


Sample links


https://sec-ch-prefers-reduced-transparency.glitch.me


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118



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


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.com


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/6B4E754E-49E5-47DE-B473-4AC40FC0C599%40gmail.com

Re: [blink-dev] Intent to Ship: Enrollment for Privacy Sandbox

2023-09-01 Thread Mike Taylor 

On 9/1/23 2:46 PM, Shivani Sharma wrote:


Thanks Mike! Responses inline.

On Fri, Sep 1, 2023 at 1:09 PM Mike Taylor  wrote:

Hi Shivani,

In general I think this is a pretty interesting idea, just a few
minor questions below:

On 8/30/23 8:16 AM, Shivani Sharma wrote:



Contact emails

shivani...@chromium.org ,
georg...@google.com 


Explainer

https://github.com/privacysandbox/attestation/blob/main/README.md



A few questions about the attestation format:

1) expiry_seconds_since_epoch implies this expires. Is there any
more info on this? Does a renewal mean incrementing
attestation_version?

2) attestation_version states "This allows the maintenance of a
historical record of attestations." Is that something you plan on
exposing to the public somewhere? Or would you expect a site to
maintain previous versions somewhere?

Also, how does unenrollment happen?

1. Yes the plan is to have attestations expire, and have adtechs step 
through re-attestation process which would increment the version.
2. The attestation file hosted on the .well-known will include all 
their historical attestations. We could also consider maintaining a 
historical record on the transparency server.
Cool - makes sense. The explainer (or blog post) could probably be 
updated to make this more clear.
Unenrollment would be either when the original attestation expires or 
the entity explicitly requests to unenroll (via the form asking to 
cancel existing enrollment). When that happens, their data will be 
removed from the enrollment records and the updated list pushed to 
Chrome will not have their site.
Thanks - it would be nice to document this in the explainer again (and 
the form, if it's not already documented).




Design document


https://docs.google.com/document/d/16PYa6wBBGBbV4YMujkFzBab8s4a7N4PcvpY0Js1qN1k/edit?usp=sharing




Specification

While the enrollment process itself is not intended to be
standardized, the impacted API specifications allow for a user
agent defined gating mechanism such as enrollment and
attestation. The spec changes for the gated APIs are linked below:


Private aggregation (section with note on enrollment

)


Shared Storage (pull request
)

Topics (pull request
)

Attribution reporting API (pull request
)

Protected Audience (pull requests: 1
, 2
)


Summary and Motivation

As the Privacy Sandbox relevance and measurement APIs start
ramping up for general availability, we want to make sure these
technologies are used as intended and with transparency. The APIs
include Attribution Reporting, the Protected Audience API,
Topics, Private Aggregation and Shared Storage. As announced in a
blog post
,
a new Developer Enrollment process for Privacy Sandbox relevance
and measurement APIs is being introduced across Chrome and
Android. This I2S refers to Chrome’s implementation of fetching
the enrolled-sites list from the enrollment server (via component
updater

)
and using it to gate access to the Privacy Sandbox APIs.


Blink component

Blink>PrivateAggregation



Blink>Storage>SharedStorage



Blink>TopicsAPI



Internals > AttributionReporting



Blink>InterestGroups




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.

In the initial version, no gated APIs are supported on WebView ,
with the caveat that the Attribution Reporting API delegates from
WebView to Android

Re: [blink-dev] Intent to Ship: Sec-CH-Prefers-Reduced-Transparency User Preference Media Features Client Hints Header

2023-09-01 Thread Luke 
Apologies, https://github.com/w3ctag/design-reviews/issues/632 would be the 
relevant link. Will update in Chromestatus too.

On Friday, 1 September 2023 at 23:10:25 UTC+1 mike...@chromium.org wrote:

> On 8/30/23 3:55 PM, Luke wrote:
>
> Contact emails lukewa...@gmail.com, lu...@warlow.dev
>
> Explainer 
> https://github.com/wicg/user-preference-media-features-headers/blob/main/README.md
>
> Specification 
> https://wicg.github.io/user-preference-media-features-headers/#sec-ch-prefers-reduced-transparency
>
> Summary 
>
> User Preference Media Features Client Hints Header defines a set of HTTP 
> Client Hints headers around user preference media features as defined by 
> Media Queries Level 5. If used as Critical Client Hints, these headers 
> allow servers to make smart choices regarding, e.g., CSS inlining. 
> Sec-CH-Prefers-Reduced-Transparency reflects the user's 
> prefers-reduced-transparency preference.
>
>
> Blink component Blink>CSS 
> 
>
> Search tags client hints 
> , 
> sec-ch-prefers-reduced-transparency 
> 
> , prefers-reduced-transparency 
> 
>
> TAG review 
>
> Anything relevant to link here?
>
>
>
> TAG review status Pending
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/526)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/15)
>
> *Web developers*: Positive (WICG proposal Issue: 
> https://github.com/WICG/proposals/issues/30 with feedback from developers 
> working for Facebook and Magento. Twitter: 
> https://twitter.com/kilianvalkhof/status/1392404416335056896. The 
> proposal was initially discussed in 
> https://github.com/w3c/csswg-drafts/issues/4162 and received positive 
> feedback via 18 Likes)
>
> *Other signals*:
>
> Activation 
>
> Developers will include Sec-CH-Prefers-Reduced-Transparency in the 
> response headers Accept-CH and Critical-CH to let the browser know that 
> they’re interested in the user's transparency preferences. If supported, 
> the request header Sec-CH-Prefers-Reduced-Transparency will be populated 
> with the appropriate value. This follows the same pattern as existing 
> Preference Client Hints and as such should be easy for developers to make 
> use of.
>
>
> Security 
>
> This feature could be used for fingerprinting as it exposes a user 
> preference. However, this is already exposed to CSS/JS by the 
> `prefers-reduced-transparency` media query.
>
>
> 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 
>
> Developers can change this client hint header value by emulating 
> prefers-reduced-transparency via Devtools in the Rendering Panel.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)? Yes 
>
> The feature will be supported on all platforms, but whether the user will 
> be able to signal a reduced transparency preference depends on the OS.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ? Yes
>
> Flag name on chrome://flags #enable-experimental-web-platform-features
>
> Finch feature name ClientHintsPrefersReducedTransparency
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1466423
>
> Sample links 
> https://sec-ch-prefers-reduced-transparency.glitch.me
>
> Estimated milestones 
> Shipping on desktop 118 
> DevTrial on desktop 118 
> Shipping on Android 118 
> DevTrial on Android 118 
>
> 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/6242983812268032
>
> Links to previous Intent discussions Intent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/B1ED49A6-31BF-4D28-89B3-D2973F9F12DA%40gmail.com
>
> 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 visi