Re: [blink-dev] Intent to Ship: AudioContext.outputLatency

['Chris Cunningham' via blink-dev]

Re: privacy discussion, Hongchan and I scheduled to meet with Paul Jensen 
next week.

Also, I recently determined that this new WebAudio API (outputLatency) is 
largely redundant with an existing API (getOutputTimestamp()). 
https://github.com/WebAudio/web-audio-api/issues/2461

Chrome has already shipped the latter API, so I believe this new API 
doesn't add potential for additional fingerprinting. Shipping both APIs is 
still a good idea for the sake of inter-op.

On Friday, November 19, 2021 at 8:45:28 AM UTC-8 hongchan wrote:

> Thanks for the clarification, Yoav!
>
> I hope the mitigation approach in the previous comment makes sense from 
> the privacy perspective, but it will hurt the usability/value of this API 
> significantly.
> For the privacy-focused discussion, should I use other venues rather than 
> this I2S thread?
>
> Cheers,
> Hongchan
>
>
> On Thu, Nov 18, 2021 at 10:35 PM Yoav Weiss  wrote:
>
>> Apologies, I misread the discussion. A spec issue is indeed not needed, 
>> as this is already covered.
>>
>> From my perspective, since this exposes active entropy, the fact that it 
>> exposes more data than the (passively exposed) platform is not prohibitive 
>> on its own.
>> At the same time, it'd be good to work with privacy-focused folks to make 
>> sure we expose as little information as needed to maintain the API's 
>> functionality, but not more.
>>
>> On Fri, Nov 19, 2021 at 4:57 AM Chris Cunningham  
>> wrote:
>>
>>> > If the reported value is incorrect, the A/V synchronization won't be 
>>> possible. (Perhaps chcunningham@ can say more about this use case.)
>>>
>>> The typical video player design drives the clock with audio. In short, 
>>> you send buffers of audio to the OS, use the latency value to know when 
>>> those buffers actually reach the user's ears, and choose a video frame 
>>> accordingly. Apps using WebCodecs will design apps this way (example 
>>> here ).
>>>
>>> As Mike notes, the latency value can vary by quite a lot depending on 
>>> the device (huge differences for bluetooth vs wired), so it's critical to 
>>> have the platform tell you when this changes. In terms of precision, we can 
>>> _probably_ do some rounding like to the nearest millisecond. Higher values 
>>> may lead to issues; user studies 
>>> 
>>>  
>>> have shown sensitivity to fairly low values of drift. 
>>>
>>> Aside: we may eventually desire a display latency value for similar 
>>> reasons. 
>>>
>>> On Thu, Nov 18, 2021 at 12:45 PM Hongchan Choi  
>>> wrote:
>>>
 Hi Yoav,

 Could you clarify what needs to be discussed from the spec side? The 
 feature (and its behavior) is properly specified, and its privacy aspect 
 is 
 already reviewed by W3C:
 https://github.com/WebAudio/web-audio-api/issues/1498 (outputLatency)
 https://github.com/WebAudio/web-audio-api/issues/1495 (general 
 security/privacy consideration)

 I thought the request from this thread is to devise a Chrome-specific 
 mitigation, not reopening the spec discussion. Please correct me if I'm 
 mistaken.

 Cheers,
 Hongchan


 On Thu, Nov 18, 2021 at 12:37 PM Yoav Weiss  
 wrote:

> Hey folks!
>
> It seems like there are some things to figure out here before 
> shipping. Could y'all file a spec issue to discuss this with the broader 
> community?
>
> On Tuesday, November 16, 2021 at 6:16:14 PM UTC+1 hongchan wrote:
>
>> Thanks for the feedback, Mike. This is really helpful!
>>
>> Mitigation strategies include adding jitter (dithering) and 
>>> quantization so that the exact skew is incorrectly reported
>>>
>>
>> This bit refers to the randomization mechanism deployed by other 
>> browsers, but this approach defeats the purpose of this specific API and 
>> it 
>> is also argued in the spec:
>>
>> Note however that most audio systems aim for low latency, to 
>>> synchronise the audio generated by WebAudio to other audio or video 
>>> sources 
>>> or to visual cues (for example in a game, or an audio recording or 
>>> music 
>>> making environment). Excessive latency decreases usability and may be 
>>> an 
>>> accessibility issue.
>>
>>  
>> If the reported value is incorrect, the A/V synchronization won't be 
>> possible. (Perhaps chcunningham@ can say more about this use case.)
>>
>> One mitigation idea: we can do some research to collect values 
>> reported by major platforms/devices and devise a reasonable "bucket 
>> system" 
>> for them.
>>
>>
>> On Tue, Nov 16, 2021 at 8:14 AM Mike Taylor  
>> wrote:
>>
>>> I suppose it would be nice to do some testing to verify the idea 
>>> that there's a small number of platform + audio device pairs. 

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

[Rick Byers]

+1 for taking a random sample (eg. 10) of pages from the HTTPArchive
UseCounter list and trying to understand how it's being used and what
breakage would result (especially on a Mac, see below).

I also looked at per-platform breakdowns (Google internal data, sorry) and
found:

   - Android WebView usage is very low (~0.0003%). -webkit-isms sometimes
   feature in Android native apps so I wanted to verify we didn't see high
   usage. This is so low as to likely be irrelevant I think.
   - Mac is much higher than Windows - eg. 0.01-0.02% for Mac vs.
   0.002%-0.004% for Windows
   - There's a pronounced weekday pattern with Mac/Windows usage about
   doubling M-F relative to Sat/Sun
   - Android usage is low (~0.001%) with no weekday pattern

This suggests to me perhaps some enterprise or line-of-business application
may be using it. But if we have evidence that the change in behavior is
almost always subtle (eg. font metrics) not significant (eg. missing text)
then I think this is probably low enough risk to just try.

I wonder if we have metrics about unrenderable characters? I.e. how often
we fail to render some text because the glyph isn't present in the selected
font? If we did, then I think it would be pretty easy to do a finch trial
for changes like this and decide go/no-go based on that data.

Rick

On Mon, Nov 22, 2021 at 4:27 AM Yoav Weiss  wrote:

> Based on +Rick Byers 's HA for webcompat document
> ,
> I just ran the following query:
> ```
> SELECT url FROM `httparchive.latest.pages_mobile`
> WHERE JSON_EXTRACT(payload, "$._blinkFeatureFirstUsed.Features['3987']")
> IS NOT NULL
> ```
> Results are here
> 
> .
> In short, there are 191 pages that touch this usecounter, out of 7655542
> pages in that table. (or ~0.0025% of pages)
>
> This resolves my previous concerns about HA showing an order of magnitude
> more usage than our chromestatus use counter data.
>
> While digging into UKM data could be interesting, it'd take some time to
> gather, so it might be sufficient to take a random sample from the HA list
> and see what the impact on those sites would be.
>
>
> On Mon, Nov 22, 2021 at 9:49 AM Frédéric Wang  wrote:
>
>> Le 18/11/2021 à 21:29, Chris Harrelson a écrit :
>>
>>
>> Would it be possible to get results of top pages hitting the use counter,
>>> so one can analyze them more carefully ? Do we need to do any additional
>>> change in Chromium to make that possible ?
>>>
>>
>> chromestatus.com already has this feature, by combining UseCounter with
>> HTTPArchive. It can take a while for this data to be populated though,
>> because of latency in the indexing.
>>
>>
>>> Hi Chris,
>>
>> Last week Chromestatus was showing wrong results, basically for any
>> feature it was returning matches for all HTTPArchive pages. Now it returns
>> no data at all for -webkit-standard. Not sure if we need to wait more
>> before indexing happens...
>>
>> Otherwise, I was thinking of something we did for scroll position values
>> in non-default writing modes in the past [1] i.e. use UKM to better collect
>> and analyze affected origins and maybe introducing a finch flag to ship
>> this more safely (the code change to disable that is one line [2] so that
>> should be easy). But IIRC we will need help from a Googler for that purpose.
>>
>> [1]
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ
>>
>> [2] https://chromium-review.googlesource.com/c/chromium/src/+/3282157
>>
>> --
>> Frédéric Wang
>>
>> --
>> 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/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.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/CAFUtAY9fqrpWok%3DB_s2qBacf%2BHZzcJYHiWY3e6OHODQ%2BWiVDXw%40mail.gmail.com.

[blink-dev] I would like to test this feature

[Marco Cocco]

Hi Is there a way to make it work in normal chrome?
I've seen the feature first party sets flag and followed the 
When I try launch crome like this:
start chrome 
--use-first-party-set=https://my-test:8443,https://my-other-test:8453

and set a cookie from one of the 2 domains like this:

document.cookie = "username=Billy; Samesite=Lax; SameParty; Secure";

This cookie can't be seen from the other site.

Any hint?

-- 
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/9e41e239-1fc2-4da2-801c-e4f7ba809f85n%40chromium.org.

[blink-dev] Intent to Ship: Sec-CH-UA-Full-Version-List user-agent client hint

[Victor Tan]

Contact emails

victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org


Specification

https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list


Summary

The Sec-CH-UA-Full-Version-List request header field gives a server
information about the full version for each brand in its brands list.


Blink component

Privacy>Fingerprinting



Motivation

As raised in UA-CH Issue 196
,
Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary
brand in the brand list
, especially for
embedders. In order to prevent classes of bugs where a site might think the
fictional “Hamburger” browser is not up to date (because its version scheme
is different, and lower than Chromium’s), we propose to expose the full
version of each brand in the brand list, by requesting this new client hint.

Here’s what that would look like:

Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium";
v="92.0.4515.131", "?Not:A Browser"; v="3.1.2.0"

Eventually, it will make sense to deprecate and remove
Sec-CH-UA-Full-Version
 (assuming
usage allows us to do so). But we do not intend to do that until we ship
its replacement.


Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196

TAG review

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


TAG review status

Pending (there’s a pre-existing review, and this hint came up in the review
process as feedback from other browsers, so the TAG is aware of it).


RisksInteroperability and CompatibilityThis is a new hint, so it should not
create compatibility issues.

  Edge: This hint was added to solve a bug (maybe a feature request?)
 by Edge folks.

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

WebKit: Requested through email


Web developers: No signals
Debuggability

No special DevTools support needed. It should just work™.


Is this feature fully tested by web-platform-tests

?

Yes. https://chromium-review.googlesource.com/c/chromium/src/+/3256910


Flag name

UserAgentClientHintFullVersionList

Requires code in //chrome?

False


Tracking bug

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


Launch bug

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


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5703317813460992

-- 
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/CAJh4P7FdCmHAA-8b1CH_So%3D2Fur2dZO8SKNetWmEetQ1KcP9_A%40mail.gmail.com.

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

[Philip Jägenstedt]

On Mon, Nov 22, 2021 at 3:08 PM Manuel Rego Casasnovas  wrote:
>
>
> On 18/11/2021 22:30, 'Anupam Snigdha' via blink-dev wrote:
> > /WebKit/: Neutral
> > (https://github.com/w3c/editing/issues/334#issuecomment-933939592
> > )
> > Webkit has a custom format implementation which isn't well documented.
>
> I'd say: "No signal", as there's no reply to the mailing list request:
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031855.html
>
> It would be nice to send a new email to notify the intention of shipping
> in Chromium, to see if we can get any feedback there.

Note that there's plenty of engagement on the repo, however. I don't
know how to summarize it, but it's clear there's disagreement on some
aspects at least.

Best regards,
Philip

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

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

[Manuel Rego Casasnovas]

On 18/11/2021 22:30, 'Anupam Snigdha' via blink-dev wrote:
> /WebKit/: Neutral
> (https://github.com/w3c/editing/issues/334#issuecomment-933939592
> )
> Webkit has a custom format implementation which isn't well documented.

I'd say: "No signal", as there's no reply to the mailing list request:
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031855.html

It would be nice to send a new email to notify the intention of shipping
in Chromium, to see if we can get any feedback there.

Cheers,
  Rego

-- 
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/b2c779c3-0361-689c-8285-cf267fd1b229%40igalia.com.

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

[Philip Jägenstedt]

Hi Anupam,

I see that the two pull requests on the spec are still open:
https://github.com/w3c/clipboard-apis/pull/158
https://github.com/w3c/clipboard-apis/pull/162

I see there's a lot of discussion on both, with folks from other vendors
involved, and it looks like some points are contentious. Can you summarize
the state of things as they are, and what you think the remaining steps are
to landing the spec changes?

On the testing front, is
async-custom-formats-write-read.tentative.https.html

the only test for this? This test doesn't seem to cover what happens
writing both text/plain and custom payload, and what then happens if
pasting that with and without opting into the custom format. Can these
tests be made more elaborate?

Best regards,
Philip

On Thu, Nov 18, 2021 at 10:30 PM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> sni...@microsoft.com, m...@chromium.org, pc...@microsoft.com
>
> Explainer
>
>
> https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api
>
> Specification
>
> https://github.com/w3c/clipboard-apis/pull/162
>
> https://github.com/w3c/clipboard-apis/pull/158
> 
> Design docs
>
>
>
> https://docs.google.com/document/d/1afc45MQuwxEWgoUeJCO-sOWRSzs31V4JS-kKXJNMTXw/edit
>
> Summary
>
> Pickle Clipboard API lets websites read and write arbitrary unsanitized
> payloads using a standardized pickling format, as well as read and write a
> limited subset of OS-specific formats (for supporting legacy apps). The
> name of the clipboard format is mangled by the browser in a standardized
> way to indicate that the content is from the web, which allows native
> applications to opt-in to accepting the unsanitized content.
>
>
> Blink component
>
> Blink>DataTransfer
> 
>
> Search tags
>
> pickle , pickling api
> , pickling
> , clipboard custom
> format
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/636
>
> TAG review status
>
> Issues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> Other browsers implement an ability to write custom clipboard data in
> varied shapes. Part of the value of this work is to standardize the names
> of the formats that will be written per platform and to ensure a common
> shape of data on the clipboard so that browsers can read and write from
> this standard set of pickled formats.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/525)
>
> *WebKit*: Neutral (
> https://github.com/w3c/editing/issues/334#issuecomment-933939592) Webkit
> has a custom format implementation which isn't well documented.
>
> *Web developers*: Positive (
> https://github.com/w3ctag/design-reviews/issues/636#issuecomment-854038820)
> Positive signal from Figma & Sketchup. Internal MS office products have
> shown interest in supporting this API.
>
> *Other signals*:
>
> Ergonomics
>
> This feature is part of the existing async clipboard read/write. It
> doesn't affect the well-defined formats that are supported by this API.
>
>
> Activation
>
> The feature uses the existing async clipboard read/write methods which has
> already been shipped.
>
>
> Security
>
> Here is a link to a more detailed security review:
> https://github.com/w3c/editing/issues/315
>
>
> Debuggability
>
> The async clipboard APIs have basic tooling support as described in the
> DevTools support checklist doc.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
>
> https://wpt.fyi/results/clipboard-apis?label=master=experimental=async%20clipboard
>
>
> https://wpt.fyi/results/clipboard-apis/async-custom-formats-write-read.tentative.https.html?label=master=experimental=async%20clipboard
>
> Flag name
>
> ClipboardCustomFormats
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=106449
>
> Sample links
>
> https://glitch.com/edit/#!/sequoia-innovative-date
>
> Estimated milestones
>
> 98
>
>
> Link to entry on the Chrome Platform Status
>
> 

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

[Yoav Weiss]

Based on +Rick Byers 's HA for webcompat document
,
I just ran the following query:
```
SELECT url FROM `httparchive.latest.pages_mobile`
WHERE JSON_EXTRACT(payload, "$._blinkFeatureFirstUsed.Features['3987']") IS
NOT NULL
```
Results are here

.
In short, there are 191 pages that touch this usecounter, out of 7655542
pages in that table. (or ~0.0025% of pages)

This resolves my previous concerns about HA showing an order of magnitude
more usage than our chromestatus use counter data.

While digging into UKM data could be interesting, it'd take some time to
gather, so it might be sufficient to take a random sample from the HA list
and see what the impact on those sites would be.


On Mon, Nov 22, 2021 at 9:49 AM Frédéric Wang  wrote:

> Le 18/11/2021 à 21:29, Chris Harrelson a écrit :
>
>
> Would it be possible to get results of top pages hitting the use counter,
>> so one can analyze them more carefully ? Do we need to do any additional
>> change in Chromium to make that possible ?
>>
>
> chromestatus.com already has this feature, by combining UseCounter with
> HTTPArchive. It can take a while for this data to be populated though,
> because of latency in the indexing.
>
>
>> Hi Chris,
>
> Last week Chromestatus was showing wrong results, basically for any
> feature it was returning matches for all HTTPArchive pages. Now it returns
> no data at all for -webkit-standard. Not sure if we need to wait more
> before indexing happens...
>
> Otherwise, I was thinking of something we did for scroll position values
> in non-default writing modes in the past [1] i.e. use UKM to better collect
> and analyze affected origins and maybe introducing a finch flag to ship
> this more safely (the code change to disable that is one line [2] so that
> should be easy). But IIRC we will need help from a Googler for that purpose.
>
> [1]
> https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ
>
> [2] https://chromium-review.googlesource.com/c/chromium/src/+/3282157
>
> --
> Frédéric Wang
>
> --
> 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/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.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/CAL5BFfWU72RYX4QNF3ztoNoNy1cgnYBQ2YLhkVNbzfxvWx8S-A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove font-family -webkit-standard

[Frédéric Wang]

Le 18/11/2021 à 21:29, Chris Harrelson a écrit :


Would it be possible to get results of top pages hitting the use
counter, so one can analyze them more carefully ? Do we need to do
any additional change in Chromium to make that possible ?


chromestatus.com  already has this feature, 
by combining UseCounter with HTTPArchive. It can take a while for this 
data to be populated though, because of latency in the indexing.



Hi Chris,

Last week Chromestatus was showing wrong results, basically for any 
feature it was returning matches for all HTTPArchive pages. Now it 
returns no data at all for -webkit-standard. Not sure if we need to wait 
more before indexing happens...


Otherwise, I was thinking of something we did for scroll position values 
in non-default writing modes in the past [1] i.e. use UKM to better 
collect and analyze affected origins and maybe introducing a finch flag 
to ship this more safely (the code change to disable that is one line 
[2] so that should be easy). But IIRC we will need help from a Googler 
for that purpose.


[1] 
https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ


[2] https://chromium-review.googlesource.com/c/chromium/src/+/3282157

--
Frédéric Wang

--
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/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.com.

Re: [blink-dev] Intent to Prototype: Dark mode support for web apps

['Thomas Steiner' via blink-dev]

>
> > There are a lot of proposals that were discussed in this Issue. Which
> one are you planning on going with? Do we have consensus on one?
> The current proposal is this one:
> https://github.com/w3c/manifest/issues/975#issuecomment-960222756, it
> matches the current translations proposal
> 
> .


Thanks for the clarification, this is also what Aaron has published on his
blog . I can
certainly live with this solution.

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