Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Mike Taylor]

LGTM3

On 6/28/23 2:06 AM, Stephen Mcgruer wrote:
Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, 
here's hoping for #3 :)). I agree with your points on the difficulty 
of making either user activation or capability delegation work across 
navigation (though I still personally think there are reasonable 
use-cases! :D). We're definitely paying attention to potential abuse 
scenarios here, though we do agree with Rick's take that getting user 
activation is unfortunately a fairly weak protection today already.


Wrt the PR status - yes, the WG has now endorsed it, but we will 
definitely be landing the PR before trying to ship this. We've 
re-targeted the launch from M116 to M117.


On Tue, 27 Jun 2023 at 03:52, Yoav Weiss  wrote:

LGTM2 conditional on the PR landing

On Mon, Jun 26, 2023 at 5:02 PM Rick Byers 
wrote:

This makes good sense to me. Obviously there's so much risk
and potential for abuse around payments, getting the user to
click seems like a very weak mitigation anyway (eg. the
prevalence of "click to read more" buttons). +1 to waiting for
the PR to land, but it looks like the WG has now approved it,
so proactive LGTM1 for when the PR actually lands.

It's too bad Apple isn't currently a member of the WG, so
we're not likely to get their thoughts on this in time to
influence our launch decision. But I also don't think it's a
substantial interop risk - Payment Request is already very
different on Apple browsers due to the tight coupling only
with Apple Pay.

Rick

On Tue, Jun 13, 2023 at 2:54 PM Nick Burris
 wrote:


Contact emails

nbur...@chromium.org, smcgr...@chromium.org, i...@chromium.org


Specification

https://github.com/w3c/payment-request/pull/1009


Design docs


https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4


Summary

To help developers reduce friction in Payment Request
flows, we are removing the user activation requirement for
PaymentRequest.show(). Spam and clickjacking mitigations
are put in place to mitigate security and privacy risks
with this change (see design doc

).



Blink component

Blink>Payments




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

/Gecko/: No signal

/WebKit/: No signal

/Web developers/: We've received direct feedback from web
developers that they would be able to reduce friction in
their redirect-based payment flows if
PaymentRequest.show() could be initiated without a user
activation.

/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

Existing debuggability for PaymentRequest; e.g. a specific
SecurityError is thrown when an activationless show() call
is not allowed.


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

--enable-blink-features=PaymentRequestActivationlessShow


Tracking bug

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


Estimated milestones

DevTrial on desktop 117

DevTrial on Android 117



Anticipated spec changes

https://github.com/w3c/payment-request/pull/1009


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4879115349393408


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 

Re: [blink-dev] Re: Intent to Ship: Barcode Detection API

[Reilly Grant]

There is currently no plan to ship this on Windows because the underlying
platform does not provide a barcode detection capability.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Tue, Jun 27, 2023 at 6:36 AM Matt Dean  wrote:

>
> Hi, is there any progress on shipping this to windows?
> Thanks
> Matt
> On Thursday, 9 December 2021 at 19:00:42 UTC Reilly Grant wrote:
>
>> Apologies, I spoke too soon. We'll be holding off shipping this on
>> Windows and Linux for the time being. Android, macOS and Chrome OS continue
>> to support it.
>>
>> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
>> 
>>
>>
>> On Tue, Nov 30, 2021 at 12:07 PM Alex Russell 
>> wrote:
>>
>>> This is great. Thanks for letting us know!
>>>
>>> On Mon, Nov 29, 2021 at 12:03 PM Reilly Grant 
>>> wrote:
>>>
 As of Chrome 98 the Barcode Detection API will be available on Windows
 and Linux as well, making this API available on all supported Chrome
 platforms (including Chrome OS, which shipped support awhile ago without an
 announcement).

 On Tuesday, February 18, 2020 at 11:50:56 AM UTC-8 Reilly Grant wrote:

> An update, since this was delayed by last-minute polish work that took
> way too long to find time for: This will be shipping in Chrome 82.
> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
> 
>
>
> On Thu, Aug 8, 2019 at 3:13 PM Yoav Weiss  wrote:
>
>> Regarding the fingerprinting concerns raised in this thread and after
>> talking to Reilly, my understanding is that the formats exposed clearly 
>> map
>> to data already exposed by the browser (i.e. the OS part of the UA 
>> string).
>>
>> Given that, *LGTM3*
>>
>> At the same time, it would be good to add that to the spec's security
>> and privacy section.
>>
>>
>> On Thu, Aug 8, 2019 at 9:37 PM Chris Harrelson 
>> wrote:
>>
>>> Make that LGTM2, since Alex already LGTM1'ed.
>>>
>>> On Thu, Aug 8, 2019 at 12:20 PM Chris Harrelson <
>>> chri...@chromium.org> wrote:
>>>
 LGTM1

 On Wed, Aug 7, 2019 at 11:03 AM Reilly Grant 
 wrote:

> On Fri, Aug 2, 2019 at 10:55 AM Chris Harrelson <
> chri...@chromium.org> wrote:
>
>>
>>
>> On Fri, Aug 2, 2019 at 10:51 AM Reilly Grant 
>> wrote:
>>
>>> On Thu, Aug 1, 2019 at 12:36 PM Chris Harrelson <
>>> chri...@chromium.org> wrote:
>>>
 One question regarding barcode formats
 :
 it seems like a pretty big list of current and legacy formats. Is 
 there any
 concern about implicitly depending on these side-specs in a 
 web-exposed API?

>>>
>>> The format specifications themselves seem reasonably
>>> well-defined and web-exposed APIs depend on plenty of other
>>> side-specifications through other means, for example encryption 
>>> algorithms
>>> by way of HTTPS and TLS. My primary concern is that we may not be 
>>> referring
>>> to them specifically enough. As an example, what if encoding FOO as
>>> implemented by Chrome on Android only really decodes some variant 
>>> FOO_A.
>>> Would changes to the specification be needed if another platform 
>>> gained
>>> support for FOO but only variant FOO_B?
>>>
>>
>> That's a good question. Do you think this needs more discussion
>> before shipping?
>>
>
> I think we've done all the investigation we can on this. I just
> wanted to mention that it as an inevitable concern when creating an
> enumeration like this.
>
>
>> Second question is regarding origin trial feedback: is there any
 summary of how useful this feature was from the origin trial?

>>>
>> (referring to your response below) This is excellent feedback!
>> Sounds like the origin trial was quite useful.
>>
>>
>>>
>>> Feedback on the Origin Trial was overwhelmingly complaints about
>>> the inconsistency in support across different platforms and how 
>>> that was
>>> communicated in a confusing way, which is why I have been focusing 
>>> on
>>> improving the ability to feature detect this capability.
>>>
>>
>> Feature detecting whether a particular barcode format is
>> supported on a particular platform, you mean?
>>
>
> Yes.
>
> Outside of the Origin Trial I've received feedback from 

RE: [blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

Hi Nicola,
The textformatupdate event does not get fired in response to browser spell 
checking. It's only used for decorations applied by IMEs to give hints to users 
during composition, e.g. thin/thick underlines for "phrase mode" in Japanese 
IME.
Spell checking for an EditContext depends on how the author builds the view of 
their Editor.
If the author builds with "normal" DOM elements -- , , etc -- the 
platform will run the spell-checker on these like any other editable elements, 
drawing the underlines and allowing the user to choose corrections. EditContext 
will not see any of this, and will only be able to tell at the point that the 
user has chosen a suggestion, e.g. by listening for beforeinput with 
event.inputType === "insertReplacementText". So spell-checking will work much 
like a normal contenteditable div today.
If the author uses , the platform's native spellcheck will have no way 
to integrate with the EditContext. By using , the author is taking on 
the responsibility for building out their editor from scratch, including 
spell-checking if needed by their application.
-- Dan

From: Nicola Tommasi 
Sent: Tuesday, June 27, 2023 1:03 AM
To: blink-dev 
Cc: Daniel Clark ; Yoav Weiss ; 
Mike Taylor ; blin...@chromium.org 
; Joshua Bell ; chri...@google.com 
; Anupam Snigdha ; Alex Keng 
; mt...@google.com ; Alex Russell 
; Arthur Sonzogni 
Subject: Re: [blink-dev] Intent to Experiment: EditContext API

Hi, from a privacy perspective we have some concerns regarding the spellchecker 
section: we enforced in the past the concept that websites should not learn 
about the user dictionaries [1] and it seems like the spellcheking API proposal 
could leak those via the textformatupdate event. Was this taken into 
consideration?Do we have any way to prevent this?

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-security

Thanks,
Nicola
On Thursday, June 15, 2023 at 11:31:59 PM UTC 
dan...@microsoft.com wrote:
Thanks Alex!

It looks like 
crbug.com/1263817
 is a good tracking bug for https://github.com/w3c/uievents/issues/202 (which 
is already linked from there). Since EditContext differs in how these events 
will fire I think this issue can be resolved separately, but I’ve tagged some 
folks in on that issue to try to drive some progress.

I’ll investigate what can be done to get the tests moved to WPT.

From: Alex Russell mailto:slightly...@chromium.org>>
Sent: Wednesday, June 14, 2023 8:32 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Yoav Weiss mailto:yoavwe...@chromium.org>>; Mike 
Taylor mailto:miketa...@chromium.org>>; 
blin...@chromium.org 
mailto:blink-dev@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
chri...@google.com 
mailto:chris...@google.com>>; Anupam Snigdha 
mailto:sni...@microsoft.com>>; Alex Keng 
mailto:shih...@microsoft.com>>; Daniel Clark 
mailto:dan...@microsoft.com>>; 
mt...@google.com 
mailto:m...@google.com>>
Subject: Re: [blink-dev] Intent to Experiment: EditContext API

LGTM to experiment assuming WPT caveats are addressed.

On editing event order, perhaps we can track this separately. Is there a crbug 
for it?
On Tuesday, June 13, 2023 at 9:02:34 PM UTC-7 Yoav Weiss wrote:
On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
> Although in the template this is phrased as a yes/no question, can you say 
> more about the WPT coverage and limitations?

We currently do not have tests in web-platform-tests.
There are tests outside the external/wpt folder:
third_party/blink/web_tests/editing/input/edit-context.html
third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html

I’m going to migrate as much of the contents of these as I can to WPT. This 
won’t be possible for a lot of the subtests since they rely on primitives like 
eventSender and textInputController, which aren’t available in WPT.
There is also test coverage that still needs to be written for scenarios 
involving nested editable elements, and I plan to add these as WPTs.

Would it be possible to add WebDriver extensions to enable these tests to move 
over to WPT?

+Mathias Bynens - FYI


There’s been some work 
done around 
adding support for IME testing but my understanding is that more work is needed 
in order to use this in WPTs.

From: Daniel Clark
Sent: Tuesday, June 13, 2023 10:42 AM
To: Mike Taylor mailto:miketa...@chromium.org>>; 
blink-dev@chromium.org
Cc: Chris Harrelson 

[blink-dev] Intent to Deprecate: Remove non-standard appearance keywords

[Di Zhang]

Contact emailsdizha...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-ui-4/#appearance-switching

Summary

Since only standard appearance keywords should be supported, we are
removing the appearance (and -webkit-appearance) keywords that are only
meant to be used internally: * inner-spin-button * media-slider *
media-sliderthumb * media-volume-slider * media-volume-sliderthumb *
push-button * searchfield-cancel-button * slider-horizontal *
sliderthumb-horizontal * sliderthumb-vertical * square-button Note that
value slider-vertical will not be removed as part of this patch it is used
for allowing  vertical. It will be removed once feature
FormControlsVerticalWritingModeSupport is enabled in stable. [1]
https://drafts.csswg.org/css-ui-4/#appearance-switching [2]
https://github.com/w3c/csswg-drafts/issues/8506#issuecomment-1515062326


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This feature only affects the reflection in computed style. Currently,
while it is possible to set an appearance value with one of these
non-standard values, it will not affect the appearance of that element.
Now, if appearance is set to one of these non-standard values, the returned
computed appearance value will be auto. It is unlikely websites depend on
this information: this deprecation should be web compatible.


*Gecko*: Shipped/Shipping

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

Ergonomics

There are no other platform APIS this will be used in tandem with and this
will not make it hard for chrome to maintain good performance.


Activation

There should be no challenge for developers to take advantage of this
feature immediately.


Security

N/A


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

The non-standard appearance values we are removing are already not listed
in the autocomplete in DevTools.


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://flagsRemoveNonStandardAppearanceValue

Finch feature name

Non-finch justificationNone

Requires code in //chrome?False

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

Estimated milestones
DevTrial on desktop 115
DevTrial on Android 115

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

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/CA%2BSS7eB2DLvCJcNDB33aJ-8hgnmER%3DXfM3s_rn_A%2B5LvxE-5nA%40mail.gmail.com.

[blink-dev] Intent to Prototype: Partitioning :visited links history

[Kyra Seevers]

Contact emails

kyraseev...@chromium.org

Explainer

https://github.com/kyraseevers/Partitioning-visited-links-history

Specification

TBD

Summary

To eliminate user browsing history leaks, anchor elements will be styled as
:visited if and only if they have been visited from the same top-level site
and frame origin before. On the browser-side, this means that the
VisitedLinks hashtable will now be partitioned via "triple-keying", or by
storing the following for each visited link: . By only styling links that have been visited from this site
and frame before, the many side-channel attacks that have been developed to
obtain :visited links styling information will be obsolete, as they no
longer provide sites with new information about users.

Blink component

Blink>History>VisitedLinks


Motivation

Since 2010, the number of side-channel attacks to leak the user’s browsing
history by abusing :visited links styling has grown, including user
interaction attacks, timing attacks, pixel color attacks, and process-level
attacks
.
While these attack vectors are slowed down by the 2010 mitigations
,
they are not eliminated; browsers are still actively leaking user browsing
history today.

Triple-keyed history partitioning only styles links have been visited from
the same top-level site and frame origin before. As a result, the many
side-channel attacks that have been developed to obtain the global :visited
links state will now be obsolete, as they will no longer provide sites with
new information about users.

This feature will improve user privacy and security. The resulting
implementation will be relevant to users who will see slight changes to
which links appear styled on their screens, and to bad actors who will no
longer be able to use side-channel attacks to reveal user browsing history.

Initial public proposal

https://github.com/WICG/proposals/issues/100

Search tags

visited links ,
:visited
selector ,
partitioning
history 

TAG review

TBD

TAG review status

Not Started

Risks

Interoperability and Compatibility

Gecko: Positive initial signals from presentation at WebAppSec


WebKit: Positive initial signals from presentation at WebAppSec


Web developers: Feedback from UX that CSS extensibility is in-demand from
developers right now, and this work would pave the way for less restricted
CSS on anchor elements. In addition, support from various developers who
believe that taking care of this long-standing privacy leak will allow
their own security and privacy solutions to advance once history sniffing
is no longer an issue.

Other signals: N/a

WebView application risks

No - this feature deals with platform-specific code, and Android WebView
does style :visited links based on user browsing history, but we do not
expect significant challenges for WebView users.


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

?

No

Flag name

(Tentatively) base::features::PartitionVisitedLinks

Requires code in //chrome?

False

Tracking bug

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

Launch bug

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

Estimated milestones

No milestones specified yet

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5101991698628608

-- 
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/CA%2BmmbXbbLWwmRYH5SWx0%2BMWkfB2UY2miOAq4r0MZc34i_sWqBw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship (I2S): Protected Audience

[Paul Jensen]

Yoav,

Protected Audiences has been fortunate to have a ton of design
contributions and feedback, but consequently has a lot of issues filed.  We
try to respond to all issues, as you can see by the discussion comments on
nearly all issues.  I went through and triaged all the issues recently.  I
closed many of them, created some labels and labeled many of them.  Here’s
where I think the open issues stand:

   -

   65
   
   I labeled “Non-breaking Feature Request”, meaning they’re requesting new
   functionality that is unlikely to cause backwards compatibility issues.
   -

   29  are spec related.
   As Dominic said above, most of these changes are unlikely to break web
   content.
   -

   8 
   are seeking feedback rather than pointing to a problem.
   -

   4  could
   potentially break compatibility.  I think for all of these we’ve decided to
   not adopt the proposed changes or we’ve decided to adopt the proposed
   changes but as part of our longer-term plans in the future.  I should note
   that recently we adopted many breaking changes to our API, but did so in a
   way that supports backwards compatibility, so we can wean developers off of
   the old APIs without causing immediate significant breakage.  If we chose
   to adopt some of these changes, I imagine we could do so in a similar
   non-breaking way.
   -

   86
   

   didn’t fit well into a particular category:
   -

  Some were questions seeking to clarify details of our timeline or the
  explainer or design.
  -

  Some were discussions that are mostly addressed but left open so we
  don’t forget about remaining pieces.
  -

  Some are open discussions or examples.

I think it’s worth noting that our usage of the issue system differs from
those of many other folks who ship features:  We tend to use the issues as
open forums as opposed to only leaving open issues that need to have
decisions made.  Many of the issues predate the FLEDGE explainer and
represent design discussions that culminated in FLEDGE’s design.

I hope the labels I added make it clearer which are future enhancements and
not likely to break backwards compatibility.  I honestly think over the
years before our Origin Trial and over the course of our lengthy Origin
Trial we’ve addressed all the feedback for core functionality in Protected
Audience and don’t anticipate breaking backwards compatibility in
significant ways.

On Thu, Jun 22, 2023 at 3:56 AM Yoav Weiss  wrote:

> Glancing at the open issues, I see 291 of them
> .. Would it
> be possible to go over the issues and label them so that it's clearer which
> are about future enhancements, which are editorial and which may have an
> impact on the processing model or API shape in ways that can impact future
> compatibility?
>
> On Wed, Jun 21, 2023 at 8:00 PM Dominic Farolino  wrote:
>
>> As the spec mentor for this feature I'll offer a spec maturity summary
>> .
>> @Jeffrey Yasskin  and I reviewed the spec in
>> detail recently and were pleased with the improvements that the team worked
>> with us to make recently, especially with regards to:
>>
>>-
>>
>>Formalizing the interaction with times and dates
>>-
>>
>>Adding rigor to the in parallel work (and its interaction with the
>>main thread and the Script Runner realms)
>>-
>>
>>Fetch integration
>>-
>>
>>Specifying the conversions from internal spec data to JS objects when
>>calling into the Script Runners
>>, mostly by
>>increasing the use of WebIDL
>>
>> In a few of these points there is still work to be done, and we've been 
>> filing
>> bugs  against the
>> specification for individual tasks that the team has committed to making
>> progress on in the very near future. The spec overall is not yet very
>> readable , which means
>> external reviewers will have to spend time to understand the flow before
>> they can give substantive feedback. From a completeness perspective, the
>> spec still has over a dozen "TODOs" (I expect that they’ll be finished soon

Re: [blink-dev] Intent to Ship: Attribution Reporting API

[John Delaney]

Thanks, Yoav and Rick for the questions/discussion. See responses below.

Can you expand (or point to existing docs) about the differences between
> this and PCM? What's the likelihood of future convergence? What are
> developers expected to do in the meantime?
>

Unfortunately, while we were able to converge with the PCM authors on
nomenclature
, the
Attribution Reporting API differs substantially from PCM in quite a few
ways. We don’t have a detailed write-up of all the differences, but if it
seems useful we can draft a document in our repo outlining detailed
differences (tracking issue here
). Here is a
short summary:


   -

   ARA has support for "viewed" impressions, where PCM only supports clicks
   -

   The ability for attribution to be scoped to, and reports sent to, third
   parties (issue
   )
   -

   Registration is performed via different mechanisms, HTTP headers for
   ARA, PCM uses a combination of html attributes and .well-known request
   parsing (see this issue
    as an
   example of divergence)
   -

   Reports contain different types of information, for example a 64-bit
   identifier in event-level ARA, and an 8 bit identifier PCM
   -

   Different limitations on the number and timing of reports which are sent
   (issue 
   )


There is some documentation on high-level design dimensions within PATCG
here

.

Future convergence right now is not entirely clear, but it's something we
are actively working on in the PATCG.

We expect that developers will develop for these measurement APIs when they
are providing value for their use-cases and customers, and that this will
require multiple different implementations switched on UA currently. It's
worth noting that, at present, the API surfaces for these two APIs do not
conflict with each other (PCM won't cause any issues in Chrome and vice
versa).

 +1. I spent 30 min looking over open issues, and while many didn't have
> responses yet they largely all felt like possible future extensions. Here's
> a couple which seemed to me to be worthy of at least a response or
> follow-up (if not a resolution) before I'd be comfortable approving the
> I2S. There may be others though, so I'd appreciate at least a quick triage
> pass by experts on the team to focus API owner attention on the issues
> which may cause future compat problems or otherwise inhibit an
> interoperable implementation.


We went through and added a "compat" label for issues that we feel have
compat risk. For the issues linked here, we are following up on those
individually and will provide an update soon.

On Mon, Jun 26, 2023 at 12:08 PM Rick Byers  wrote:

> There's clearly a lot of interop risk around all the different proposals
> in this space. At the same time, it's clear this is one of the most
> important aspects to the ads industry and so the huge amount of
> collaborative experimentation and open sharing of information on pros/cons
> seems net beneficial to the industry to me. I'm optimistic that we'll see
> convergence over time.
>
> On Mon, Jun 26, 2023 at 6:01 AM Yoav Weiss  wrote:
>
>> A few words with my spec-mentor hat on:
>> * I reviewed the specification, and I believe it is well-integrated with
>> other web platform specifications.
>> * There's one case where I think the algorithm can be more precise
>> , but I
>> wouldn't consider this a blocker.
>> * The choice of JSON header values is non-orthodox, but I was convinced
>> that Structured Fields cannot support the API's use case. (due to nesting)
>> * There are 85 open issues. It'd probably be good to give them labels
>> that'd enable reviewers to see how many of them may impact compat.
>>
>
> +1. I spent 30 min looking over open issues, and while many didn't have
> responses yet they largely all felt like possible future extensions. Here's
> a couple which seemed to me to be worthy of at least a response or
> follow-up (if not a resolution) before I'd be comfortable approving the
> I2S. There may be others though, so I'd appreciate at least a quick triage
> pass by experts on the team to focus API owner attention on the issues
> which may cause future compat problems or otherwise inhibit an
> interoperable implementation.
>
> https://github.com/WICG/attribution-reporting-api/issues/488
> https://github.com/WICG/attribution-reporting-api/issues/221
> https://github.com/WICG/attribution-reporting-api/issues/220
> https://github.com/WICG/attribution-reporting-api/issues/358
>
> * One thing I just now realized (apologies for not catching this sooner),
>> 

Re: [blink-dev] Intent to Ship: Make CaptureController derive from the EventTarget interface

[Frédéric Wang]

Hello,

To elaborate a bit more on this, it's a small IDL change to make the 
CaptureController interface derive from the EventTarget interface:


https://github.com/w3c/mediacapture-screen-share/issues/268
https://docs.google.com/presentation/d/1lti3-GFsJ1iU2pXFjfSzeK8xyKj6Ohng9D6HndPNPLc/edit#slide=id.g2547a9cc7f2_1_15

The main use case is to implement CapturedMouseEvent, but that extra 
inheritance cannot be controlled by a runtime flag.


https://groups.google.com/a/chromium.org/g/blink-dev/c/DYb5fXICJvo

This change was discussed in today's WebRTC WG meeting (with other 
potential use cases mentioned) and approved, with PR pending to be merged:

https://docs.google.com/presentation/d/1lti3-GFsJ1iU2pXFjfSzeK8xyKj6Ohng9D6HndPNPLc/edit#slide=id.g2547a9cc7f2_1_15
https://github.com/w3c/mediacapture-screen-share/pull/269
https://github.com/w3c/mediacapture-screen-share/issues/268

In general Web developers from the Screen Capture CG are supportive of 
this and interested in related future applications. Some members of 
Mozilla and Apple were also present in W3C meetings where this was 
discussed and they OK'ed the change. However, since I didn't open a 
Mozilla/Apple position to get official stance for such a small feature, 
I left "No Signal".


Chromium's CL is 
https://chromium-review.googlesource.com/c/chromium/src/+/4542243/12


Thanks,


On 27/06/2023 19:19, Frédéric Wang wrote:



Contact emails

fw...@chromium.org


Explainer

None


Specification

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


Summary

The CaptureController interface enables further manipulation of a 
screen capture session. In the future, it is expected that the events 
related to a capture session are dispatched on that controller. To be 
able to manage listeners for such events, the EventTarget methods are 
made available on CaptureController.




Blink component

Blink>GetDisplayMedia 
GetDisplayMedia> 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: Positive 
(https://github.com/screen-share/mouse-events/issues/1)


/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?




Debuggability



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags



Finch feature name



Non-finch justification

Small IDL change that don't affect existing use cases of 
CaptureController.




Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117

Shipping on WebView 117



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


Links to previous Intent discussions



This intent message was generated by Chrome Platform Status 
.

--
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/b6bbda72-2f28-b04c-dbed-a02da71b7cb5%40igalia.com 
.



--
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/54acfe11-0e0c-e416-8970-30a4ae7e6f67%40igalia.com.

[blink-dev] Intent to Ship: Make CaptureController derive from the EventTarget interface

[Frédéric Wang]

   Contact emails

fw...@chromium.org


   Explainer

None


   Specification

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


   Summary

The CaptureController interface enables further manipulation of a screen 
capture session. In the future, it is expected that the events related 
to a capture session are dispatched on that controller. To be able to 
manage listeners for such events, the EventTarget methods are made 
available on CaptureController.




   Blink component

Blink>GetDisplayMedia 
GetDisplayMedia> 




   TAG review

None


   TAG review status

Not applicable


   Risks



   Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: Positive 
(https://github.com/screen-share/mouse-events/issues/1)


/Other signals/:


   WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?




   Debuggability



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

Yes


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

Yes


   Flag name on chrome://flags



   Finch feature name



   Non-finch justification

Small IDL change that don't affect existing use cases of CaptureController.



   Requires code in //chrome?

False


   Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117

Shipping on WebView 117



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


   Links to previous Intent discussions



This intent message was generated by Chrome Platform Status 
.


--
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/b6bbda72-2f28-b04c-dbed-a02da71b7cb5%40igalia.com.

Re: [blink-dev] Re: Intent to Ship: Barcode Detection API

[Matt Dean]

Hi, is there any progress on shipping this to windows?
Thanks
Matt
On Thursday, 9 December 2021 at 19:00:42 UTC Reilly Grant wrote:

> Apologies, I spoke too soon. We'll be holding off shipping this on Windows 
> and Linux for the time being. Android, macOS and Chrome OS continue to 
> support it.
>
> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
> 
>
>
> On Tue, Nov 30, 2021 at 12:07 PM Alex Russell  
> wrote:
>
>> This is great. Thanks for letting us know!
>>
>> On Mon, Nov 29, 2021 at 12:03 PM Reilly Grant  
>> wrote:
>>
>>> As of Chrome 98 the Barcode Detection API will be available on Windows 
>>> and Linux as well, making this API available on all supported Chrome 
>>> platforms (including Chrome OS, which shipped support awhile ago without an 
>>> announcement).
>>>
>>> On Tuesday, February 18, 2020 at 11:50:56 AM UTC-8 Reilly Grant wrote:
>>>
 An update, since this was delayed by last-minute polish work that took 
 way too long to find time for: This will be shipping in Chrome 82.
 Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
 


 On Thu, Aug 8, 2019 at 3:13 PM Yoav Weiss  wrote:

> Regarding the fingerprinting concerns raised in this thread and after 
> talking to Reilly, my understanding is that the formats exposed clearly 
> map 
> to data already exposed by the browser (i.e. the OS part of the UA 
> string).
>
> Given that, *LGTM3*
>
> At the same time, it would be good to add that to the spec's security 
> and privacy section.
>  
>
> On Thu, Aug 8, 2019 at 9:37 PM Chris Harrelson  
> wrote:
>
>> Make that LGTM2, since Alex already LGTM1'ed.
>>
>> On Thu, Aug 8, 2019 at 12:20 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM1
>>>
>>> On Wed, Aug 7, 2019 at 11:03 AM Reilly Grant  
>>> wrote:
>>>
 On Fri, Aug 2, 2019 at 10:55 AM Chris Harrelson <
 chri...@chromium.org> wrote:

>
>
> On Fri, Aug 2, 2019 at 10:51 AM Reilly Grant  
> wrote:
>
>> On Thu, Aug 1, 2019 at 12:36 PM Chris Harrelson <
>> chri...@chromium.org> wrote:
>>
>>> One question regarding barcode formats 
>>> :
>>>  
>>> it seems like a pretty big list of current and legacy formats. Is 
>>> there any 
>>> concern about implicitly depending on these side-specs in a 
>>> web-exposed API?
>>>
>>
>> The format specifications themselves seem reasonably well-defined 
>> and web-exposed APIs depend on plenty of other side-specifications 
>> through 
>> other means, for example encryption algorithms by way of HTTPS and 
>> TLS. My 
>> primary concern is that we may not be referring to them specifically 
>> enough. As an example, what if encoding FOO as implemented by Chrome 
>> on 
>> Android only really decodes some variant FOO_A. Would changes to the 
>> specification be needed if another platform gained support for FOO 
>> but 
>> only variant FOO_B?
>>
>
> That's a good question. Do you think this needs more discussion 
> before shipping?
>

 I think we've done all the investigation we can on this. I just 
 wanted to mention that it as an inevitable concern when creating an 
 enumeration like this.
  

> Second question is regarding origin trial feedback: is there any 
>>> summary of how useful this feature was from the origin trial?
>>>
>>
> (referring to your response below) This is excellent feedback! 
> Sounds like the origin trial was quite useful.
>  
>
>>
>> Feedback on the Origin Trial was overwhelmingly complaints about 
>> the inconsistency in support across different platforms and how that 
>> was 
>> communicated in a confusing way, which is why I have been focusing 
>> on 
>> improving the ability to feature detect this capability.
>>
>
> Feature detecting whether a particular barcode format is supported 
> on a particular platform, you mean?
>

 Yes.

 Outside of the Origin Trial I've received feedback from developers 
>> in the commercial and industrial space who are interested in the 
>> performance advantage of this API over JS/WASM solutions. The API 
>> also gets 
>> a mention in eBay's recent blog post 
>> 
>>  about 
>> implementing a barcode scanner 

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Stephen Mcgruer]

Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's
hoping for #3 :)). I agree with your points on the difficulty of making
either user activation or capability delegation work across navigation
(though I still personally think there are reasonable use-cases! :D). We're
definitely paying attention to potential abuse scenarios here, though we do
agree with Rick's take that getting user activation is unfortunately a
fairly weak protection today already.

Wrt the PR status - yes, the WG has now endorsed it, but we will definitely
be landing the PR before trying to ship this. We've re-targeted the launch
from M116 to M117.

On Tue, 27 Jun 2023 at 03:52, Yoav Weiss  wrote:

> LGTM2 conditional on the PR landing
>
> On Mon, Jun 26, 2023 at 5:02 PM Rick Byers  wrote:
>
>> This makes good sense to me. Obviously there's so much risk and potential
>> for abuse around payments, getting the user to click seems like a very weak
>> mitigation anyway (eg. the prevalence of "click to read more" buttons). +1
>> to waiting for the PR to land, but it looks like the WG has now approved
>> it, so proactive LGTM1 for when the PR actually lands.
>>
>> It's too bad Apple isn't currently a member of the WG, so we're not
>> likely to get their thoughts on this in time to influence our launch
>> decision. But I also don't think it's a substantial interop risk - Payment
>> Request is already very different on Apple browsers due to the tight
>> coupling only with Apple Pay.
>>
>> Rick
>>
>> On Tue, Jun 13, 2023 at 2:54 PM Nick Burris  wrote:
>>
>>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org,
>>> i...@chromium.org
>>>
>>> Specificationhttps://github.com/w3c/payment-request/pull/1009
>>>
>>> Design docs
>>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4
>>>
>>> Summary
>>>
>>> To help developers reduce friction in Payment Request flows, we are
>>> removing the user activation requirement for PaymentRequest.show(). Spam
>>> and clickjacking mitigations are put in place to mitigate security and
>>> privacy risks with this change (see design doc
>>> 
>>> ).
>>>
>>>
>>> Blink componentBlink>Payments
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility*Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: We've received direct feedback from web developers
>>> that they would be able to reduce friction in their redirect-based payment
>>> flows if PaymentRequest.show() could be initiated without a user activation.
>>>
>>> *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
>>>
>>> Existing debuggability for PaymentRequest; e.g. a specific SecurityError
>>> is thrown when an activationless show() call is not allowed.
>>>
>>> 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--enable-blink-features=PaymentRequestActivationlessShow
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1454204
>>>
>>> Estimated milestones
>>> DevTrial on desktop 117
>>> DevTrial on Android 117
>>>
>>> Anticipated spec changes
>>> https://github.com/w3c/payment-request/pull/1009
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/4879115349393408
>>>
>>>
>>> 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/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%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
>> 

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

[Torne (Richard Coles)]

On Tue, 27 Jun 2023 at 11:42, Adam Rice  wrote:

> Our mitigations if a serious compatibility issue should occur are more
> effective with Chrome. If we discovered we needed to urgently disable zstd
> we could do it with a config push. However, in the case of WebView every
> app would have to start at least once in the broken configuration before
> the config push would take effect.
>

This applies to every finch experiment in WebView, whether it's a
killswitch or a launch. Rolling it out later in WebView just means we'll
get any feedback about issues in WebVIew later.


> For this reason, I feel it is safer to enable it in Chrome first to
> achieve confidence that there aren't going to be any issues. However, there
> is nothing technically stopping us from enabling it in WebView at the same
> time if that is the consensus.
>
> On Tue, 27 Jun 2023 at 23:37, Torne (Richard Coles) 
> wrote:
>
>> Unless you have specific reasons to believe that there are going to be
>> compatibility issues that are specific to WebView and a plan for how
>> they're going to be addressed, we would strongly prefer that the rollout
>> happens at the same time for WebView.
>>
>> On Tue, 27 Jun 2023 at 08:10, Mihai Cîrlănaru  wrote:
>>
>>> Thank you for the clarification, Nidhi!
>>>
>>> Could you expand on the compatibility issues that might come up here?
>>> Given the overlap WebView has with Chrome in terms of source code, these
>>> might apply to both. Nevertheless, having WebView in the experiments from
>>> the start will help uncover WebView specific issues early and ensure a
>>> timely release (as opposed to Brotli support
>>> ) and a unified
>>> narrative, i.e. "*Zstd content-encoding support available for Android
>>> (Chrome and WebView)*".
>>>
>>> On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote:
>>>
 Thank you for reaching out, Mihai and Peter!
 Our plan is to support this feature in WebView as well, but most likely
 a few milestones after M117 so that we can deal with any compatibility
 issues separately. I'll share further updates when we have more information
 on the WebView rollout plan.

 Thanks,
 Nidhi

 On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo 
 wrote:

> Thank you for sharing the I2P Nidhi! What are your plans regarding
> supporting this feature in Android WebView? We're just rolling out support
> for Brotli there and we should aim for it to be on par with the browser
> regarding supported compression algorithms.
>
> Thanks,
> Peter
>
>
> On Thu, Jun 22, 2023 at 7:05 PM PhistucK  wrote:
>
>> If/when shipping, just remember to add this to the list of "Accepted
>> Content-Encodings" that shows up on the developer tools, under the 
>> "Network
>> conditions" panel. :)
>> [image: image.png]
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis 
>> wrote:
>>
>>> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice 
>>> wrote:
>>>
 Drive by question: Given that the codec is going to be in the
> browser, are there plans to surface this up to CompressionStreams? 
> (same
> question applies for Brotli, I suppose)


 For the zstd Content-Encoding, we will only be linking in the
 decompression part of the zstd library. But for CompressionStreams,
 supporting a format only for decompression and not for compression is
 likely to confuse and frustrate developers.

>>>
>>> FWIW, asymmetric codec capabilities are quite common in media and
>>> developers have adapted just fine. E.g., we may only have 
>>> hevc/aac/theora
>>> decoding, but not encoding.
>>>
>>>

 So while I'd like to add Zstd to CompressionStreams, we'll need a
 good justification for the extra binary size increase caused by 
 linking in
 the compression code. The same applies to Brotli.

 Thanks for the question!

 On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon 
 wrote:

>
>
> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote:
>
>
>
> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju <
>> nidhij...@chromium.org> wrote:
>>
>>> Contact emailsnidhij...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>>> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878
>>>
>>> Design docs
>>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing
>>>
>>> Summary
>>>

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

[Adam Rice]

Our mitigations if a serious compatibility issue should occur are more
effective with Chrome. If we discovered we needed to urgently disable zstd
we could do it with a config push. However, in the case of WebView every
app would have to start at least once in the broken configuration before
the config push would take effect.

For this reason, I feel it is safer to enable it in Chrome first to achieve
confidence that there aren't going to be any issues. However, there is
nothing technically stopping us from enabling it in WebView at the same
time if that is the consensus.

On Tue, 27 Jun 2023 at 23:37, Torne (Richard Coles) 
wrote:

> Unless you have specific reasons to believe that there are going to be
> compatibility issues that are specific to WebView and a plan for how
> they're going to be addressed, we would strongly prefer that the rollout
> happens at the same time for WebView.
>
> On Tue, 27 Jun 2023 at 08:10, Mihai Cîrlănaru  wrote:
>
>> Thank you for the clarification, Nidhi!
>>
>> Could you expand on the compatibility issues that might come up here?
>> Given the overlap WebView has with Chrome in terms of source code, these
>> might apply to both. Nevertheless, having WebView in the experiments from
>> the start will help uncover WebView specific issues early and ensure a
>> timely release (as opposed to Brotli support
>> ) and a unified
>> narrative, i.e. "*Zstd content-encoding support available for Android
>> (Chrome and WebView)*".
>>
>> On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote:
>>
>>> Thank you for reaching out, Mihai and Peter!
>>> Our plan is to support this feature in WebView as well, but most likely
>>> a few milestones after M117 so that we can deal with any compatibility
>>> issues separately. I'll share further updates when we have more information
>>> on the WebView rollout plan.
>>>
>>> Thanks,
>>> Nidhi
>>>
>>> On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo 
>>> wrote:
>>>
 Thank you for sharing the I2P Nidhi! What are your plans regarding
 supporting this feature in Android WebView? We're just rolling out support
 for Brotli there and we should aim for it to be on par with the browser
 regarding supported compression algorithms.

 Thanks,
 Peter


 On Thu, Jun 22, 2023 at 7:05 PM PhistucK  wrote:

> If/when shipping, just remember to add this to the list of "Accepted
> Content-Encodings" that shows up on the developer tools, under the 
> "Network
> conditions" panel. :)
> [image: image.png]
>
> ☆*PhistucK*
>
>
> On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis 
> wrote:
>
>> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice  wrote:
>>
>>> Drive by question: Given that the codec is going to be in the
 browser, are there plans to surface this up to CompressionStreams? 
 (same
 question applies for Brotli, I suppose)
>>>
>>>
>>> For the zstd Content-Encoding, we will only be linking in the
>>> decompression part of the zstd library. But for CompressionStreams,
>>> supporting a format only for decompression and not for compression is
>>> likely to confuse and frustrate developers.
>>>
>>
>> FWIW, asymmetric codec capabilities are quite common in media and
>> developers have adapted just fine. E.g., we may only have hevc/aac/theora
>> decoding, but not encoding.
>>
>>
>>>
>>> So while I'd like to add Zstd to CompressionStreams, we'll need a
>>> good justification for the extra binary size increase caused by linking 
>>> in
>>> the compression code. The same applies to Brotli.
>>>
>>> Thanks for the question!
>>>
>>> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon 
>>> wrote:
>>>


 On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote:



 On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss 
 wrote:

>
>
> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju 
> wrote:
>
>> Contact emailsnidhij...@chromium.org
>>
>> Explainer
>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878
>>
>> Design docs
>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing
>>
>> Summary
>>
>> Zstandard, or “zstd”, is a data compression mechanism described
>> in RFC8878. It is a fast lossless compression algorithm, targeting
>> real-time compression scenarios at zlib-level and better compression
>> ratios. The "zstd" token was added as an IANA-registered 
>> Content-Encoding
>> token as per
>> 

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

[Torne (Richard Coles)]

Unless you have specific reasons to believe that there are going to be
compatibility issues that are specific to WebView and a plan for how
they're going to be addressed, we would strongly prefer that the rollout
happens at the same time for WebView.

On Tue, 27 Jun 2023 at 08:10, Mihai Cîrlănaru  wrote:

> Thank you for the clarification, Nidhi!
>
> Could you expand on the compatibility issues that might come up here?
> Given the overlap WebView has with Chrome in terms of source code, these
> might apply to both. Nevertheless, having WebView in the experiments from
> the start will help uncover WebView specific issues early and ensure a
> timely release (as opposed to Brotli support
> ) and a unified
> narrative, i.e. "*Zstd content-encoding support available for Android
> (Chrome and WebView)*".
>
> On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote:
>
>> Thank you for reaching out, Mihai and Peter!
>> Our plan is to support this feature in WebView as well, but most likely a
>> few milestones after M117 so that we can deal with any compatibility issues
>> separately. I'll share further updates when we have more information on the
>> WebView rollout plan.
>>
>> Thanks,
>> Nidhi
>>
>> On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo 
>> wrote:
>>
>>> Thank you for sharing the I2P Nidhi! What are your plans regarding
>>> supporting this feature in Android WebView? We're just rolling out support
>>> for Brotli there and we should aim for it to be on par with the browser
>>> regarding supported compression algorithms.
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> On Thu, Jun 22, 2023 at 7:05 PM PhistucK  wrote:
>>>
 If/when shipping, just remember to add this to the list of "Accepted
 Content-Encodings" that shows up on the developer tools, under the "Network
 conditions" panel. :)
 [image: image.png]

 ☆*PhistucK*


 On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis 
 wrote:

> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice  wrote:
>
>> Drive by question: Given that the codec is going to be in the
>>> browser, are there plans to surface this up to CompressionStreams? (same
>>> question applies for Brotli, I suppose)
>>
>>
>> For the zstd Content-Encoding, we will only be linking in the
>> decompression part of the zstd library. But for CompressionStreams,
>> supporting a format only for decompression and not for compression is
>> likely to confuse and frustrate developers.
>>
>
> FWIW, asymmetric codec capabilities are quite common in media and
> developers have adapted just fine. E.g., we may only have hevc/aac/theora
> decoding, but not encoding.
>
>
>>
>> So while I'd like to add Zstd to CompressionStreams, we'll need a
>> good justification for the extra binary size increase caused by linking 
>> in
>> the compression code. The same applies to Brotli.
>>
>> Thanks for the question!
>>
>> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon  wrote:
>>
>>>
>>>
>>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote:
>>>
>>>
>>>
>>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss 
>>> wrote:
>>>


 On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju 
 wrote:

> Contact emailsnidhij...@chromium.org
>
> Explainer
> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878
>
> Design docs
> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing
>
> Summary
>
> Zstandard, or “zstd”, is a data compression mechanism described in
> RFC8878. It is a fast lossless compression algorithm, targeting 
> real-time
> compression scenarios at zlib-level and better compression ratios. The
> "zstd" token was added as an IANA-registered Content-Encoding token 
> as per
> https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding.
> Adding support for "zstd" as a Content-Encoding will help load pages 
> faster
> and use less bandwidth.
>
> Blink componentInternals>Network
> 
>
> Motivation
>
> Supporting zstd content-encoding in the browser would allow sites
> to spend less time and CPU/power on compression on their servers, 
> resulting
> in reduced server costs. There are several published benchmarks[i.e.
> 1 , 2
> ]
> and existing research showing promising 

Re: [blink-dev] Intent to Prototype: Zstd Content-Encoding

[Mihai Cîrlănaru]

Thank you for the clarification, Nidhi!

Could you expand on the compatibility issues that might come up here? Given 
the overlap WebView has with Chrome in terms of source code, these might 
apply to both. Nevertheless, having WebView in the experiments from the 
start will help uncover WebView specific issues early and ensure a timely 
release (as opposed to Brotli support 
) and a unified 
narrative, i.e. "*Zstd content-encoding support available for Android 
(Chrome and WebView)*".

On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote:

> Thank you for reaching out, Mihai and Peter!
> Our plan is to support this feature in WebView as well, but most likely a 
> few milestones after M117 so that we can deal with any compatibility issues 
> separately. I'll share further updates when we have more information on the 
> WebView rollout plan.
>
> Thanks,
> Nidhi
>
> On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo  wrote:
>
>> Thank you for sharing the I2P Nidhi! What are your plans regarding 
>> supporting this feature in Android WebView? We're just rolling out support 
>> for Brotli there and we should aim for it to be on par with the browser 
>> regarding supported compression algorithms.
>>
>> Thanks,
>> Peter
>>
>>
>> On Thu, Jun 22, 2023 at 7:05 PM PhistucK  wrote:
>>
>>> If/when shipping, just remember to add this to the list of "Accepted 
>>> Content-Encodings" that shows up on the developer tools, under the "Network 
>>> conditions" panel. :)
>>> [image: image.png]
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis  
>>> wrote:
>>>
 On Wed, Jun 21, 2023 at 3:18 AM Adam Rice  wrote:

> Drive by question: Given that the codec is going to be in the browser, 
>> are there plans to surface this up to CompressionStreams? (same question 
>> applies for Brotli, I suppose)
>
>
> For the zstd Content-Encoding, we will only be linking in the 
> decompression part of the zstd library. But for CompressionStreams, 
> supporting a format only for decompression and not for compression is 
> likely to confuse and frustrate developers.
>

 FWIW, asymmetric codec capabilities are quite common in media and 
 developers have adapted just fine. E.g., we may only have hevc/aac/theora 
 decoding, but not encoding.
  

>
> So while I'd like to add Zstd to CompressionStreams, we'll need a good 
> justification for the extra binary size increase caused by linking in the 
> compression code. The same applies to Brotli.
>
> Thanks for the question!
>
> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon  wrote:
>
>>
>>
>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote:
>>
>>
>>
>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju  
>>> wrote:
>>>
 Contact emailsnidhij...@chromium.org

 Explainer
 https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
 Specificationhttps://datatracker.ietf.org/doc/html/rfc8878

 Design docs
 https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing

 Summary

 Zstandard, or “zstd”, is a data compression mechanism described in 
 RFC8878. It is a fast lossless compression algorithm, targeting 
 real-time 
 compression scenarios at zlib-level and better compression ratios. The 
 "zstd" token was added as an IANA-registered Content-Encoding token as 
 per 
 https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. 
 Adding support for "zstd" as a Content-Encoding will help load pages 
 faster 
 and use less bandwidth.

 Blink componentInternals>Network 
 

 Motivation

 Supporting zstd content-encoding in the browser would allow sites 
 to spend less time and CPU/power on compression on their servers, 
 resulting 
 in reduced server costs. There are several published benchmarks[i.e. 
 1 , 2 
 ]
  
 and existing research showing promising potential wins. Zstd is 
 roughly 
 three times faster than Brotli for decompression. Combined with zstd 
 being 
 faster at compression, this will result in faster page load times. 
 Initial public proposalNone

 TAG reviewNone

>>>
>> Drive by question: Given that the codec is going to be in the 
>> browser, are there plans 

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

[Nicola Tommasi]

Hi, from a privacy perspective we have some concerns regarding the 
spellchecker section: we enforced in the past the concept that websites 
should not learn about the user dictionaries [1] and it seems like the 
spellcheking API proposal could leak those via the *textformatupdate *event. 
Was this taken into consideration?Do we have any way to prevent this?

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-security

Thanks,
Nicola
On Thursday, June 15, 2023 at 11:31:59 PM UTC dan...@microsoft.com wrote:

> Thanks Alex!
>
>  
>
> It looks like crbug.com/1263817 
>  is a good 
> tracking bug for https://github.com/w3c/uievents/issues/202 (which is 
> already linked from there). Since EditContext differs in how these events 
> will fire I think this issue can be resolved separately, but I’ve tagged 
> some folks in on that issue to try to drive some progress.
>
>  
>
> I’ll investigate what can be done to get the tests moved to WPT.
>
>  
>
> *From:* Alex Russell  
> *Sent:* Wednesday, June 14, 2023 8:32 AM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Mike Taylor <
> miketa...@chromium.org>; blin...@chromium.org ; 
> Joshua Bell ; chri...@google.com ; 
> Anupam Snigdha ; Alex Keng ; 
> Daniel Clark ; mt...@google.com 
> *Subject:* Re: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> LGTM to experiment assuming WPT caveats are addressed.
>
>  
>
> On editing event order, perhaps we can track this separately. Is there a 
> crbug for it?
>
> On Tuesday, June 13, 2023 at 9:02:34 PM UTC-7 Yoav Weiss wrote:
>
> On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> *> Although in the template this is phrased as a yes/no question, can you 
> say more about the WPT coverage and limitations?*
>
>  
>
> We currently do not have tests in web-platform-tests. 
>
> There are tests outside the external/wpt folder:
>
> third_party/blink/web_tests/editing/input/edit-context.html 
> 
>
> third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html 
> 
>
>  
>
> I’m going to migrate as much of the contents of these as I can to WPT. 
> This won’t be possible for a lot of the subtests since they rely on 
> primitives like eventSender and textInputController, which aren’t available 
> in WPT.
>
> There is also test coverage that still needs to be written for scenarios 
> involving nested editable elements, and I plan to add these as WPTs.
>
>  
>
> Would it be possible to add WebDriver extensions to enable these tests to 
> move over to WPT?
>
>  
>
> +Mathias Bynens  - FYI
>
>  
>
>  
>
> There’s been some work done 
>  
> around adding support for IME testing but my understanding is that more 
> work is needed in order to use this in WPTs.
>
>  
>
> *From:* Daniel Clark 
> *Sent:* Tuesday, June 13, 2023 10:42 AM
> *To:* Mike Taylor ; blink-dev@chromium.org
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Alex Keng 
> *Subject:* RE: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> Tentatively M116 - M120 for the trial.
>
>  
>
> *From:* Mike Taylor  
> *Sent:* Tuesday, June 13, 2023 9:24 AM
> *To:* Daniel Clark ; blink-dev@chromium.org
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Alex Keng 
> *Subject:* Re: [blink-dev] Intent to Experiment: EditContext API
>
>  
>
> Do you all have a timeline in mind for experimentation?
>
> On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:
>
> Contact emails 
>
> sni...@microsoft.com, shih...@microsoft.com, bemat...@microsoft.com, 
> dan...@microsoft.com
>
> Explainer 
>
> https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
>
> Specification 
>
> https://w3c.github.io/edit-context
>
> Design docs 
>
>
> https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
>
> Summary 
>
> The EditContext API simplifies the process of integrating a web app with 
> advanced text input methods such as VK shape-writing, Handwriting panels, 
> speech recognition, IME Compositions etc., improves accessibility and 
> performance, and unlocks new capabilities for web-based editors.
>
>
>
> Blink component 
>
> Blink>Editing 
> 
>
> Search tags 
>
> editing , contenteditable 
> , input 
> , rawinput 
> , ime 
> 
>
> TAG review 
>
> https://github.com/w3ctag/design-reviews/issues/416
>
> 

Re: [blink-dev] Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Yoav Weiss]

LGTM2 conditional on the PR landing

On Mon, Jun 26, 2023 at 5:02 PM Rick Byers  wrote:

> This makes good sense to me. Obviously there's so much risk and potential
> for abuse around payments, getting the user to click seems like a very weak
> mitigation anyway (eg. the prevalence of "click to read more" buttons). +1
> to waiting for the PR to land, but it looks like the WG has now approved
> it, so proactive LGTM1 for when the PR actually lands.
>
> It's too bad Apple isn't currently a member of the WG, so we're not likely
> to get their thoughts on this in time to influence our launch decision. But
> I also don't think it's a substantial interop risk - Payment Request is
> already very different on Apple browsers due to the tight coupling only
> with Apple Pay.
>
> Rick
>
> On Tue, Jun 13, 2023 at 2:54 PM Nick Burris  wrote:
>
>> Contact emailsnbur...@chromium.org, smcgr...@chromium.org,
>> i...@chromium.org
>>
>> Specificationhttps://github.com/w3c/payment-request/pull/1009
>>
>> Design docs
>> https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4
>>
>> Summary
>>
>> To help developers reduce friction in Payment Request flows, we are
>> removing the user activation requirement for PaymentRequest.show(). Spam
>> and clickjacking mitigations are put in place to mitigate security and
>> privacy risks with this change (see design doc
>> 
>> ).
>>
>>
>> Blink componentBlink>Payments
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility*Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: We've received direct feedback from web developers
>> that they would be able to reduce friction in their redirect-based payment
>> flows if PaymentRequest.show() could be initiated without a user activation.
>>
>> *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
>>
>> Existing debuggability for PaymentRequest; e.g. a specific SecurityError
>> is thrown when an activationless show() call is not allowed.
>>
>> 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--enable-blink-features=PaymentRequestActivationlessShow
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1454204
>>
>> Estimated milestones
>> DevTrial on desktop 117
>> DevTrial on Android 117
>>
>> Anticipated spec changes
>> https://github.com/w3c/payment-request/pull/1009
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/4879115349393408
>>
>>
>> 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/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%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/CAFUtAY_7ZCW3f-uEv%3DcsRY_qtmOzJGujoXVcXfvC7BiCusUfhg%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/CAL5BFfWAGL9umrh%2Bt%3DKLm_OyxcFTLKGZTPxs7nXUQ%3D6NYnXosw%40mail.gmail.com.