Re: [blink-dev] Ready for Developer Testing: Media Previews opt-out

['Philipp Hancke' via blink-dev]

Interesting, this goes in the direction of
  https://github.com/w3c/mediacapture-extensions/issues/2
which I had considered "that ship has sailed". The spec landed

https://w3c.github.io/mediacapture-extensions/#camera%20and%20microphone%20picker
but I don't recall any implementations.
Will this be wired up to the "semantics" field?

It seems that choosing the output device is missing, that is a quite common
feature.

Am Di., 9. Apr. 2024 um 17:07 Uhr schrieb mark a. foltz :

> Contact emailsmfo...@chromium.org, bryantchand...@chromium.org
>
> ExplainerNone
>
> Specification
> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>
> Design docs
>
> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>
> Summary
>
> Allow coordination between sites using Page Embedded Permissions Controls
> and concurrent experiments with the camera and microphone permissions UI in
> Chrome.
>
>
> Blink componentBlink>MediaStream
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None as this feature concerns the functionality of Chrome's permissions
> UI, and does not change the behavior of the APIs that are gated by it:
> navigator.mediaDevices.enumerateDevices and
> navigator.mediaDevices.getUserMedia Other browsers implement their own
> permissions UIs independently of Chrome.
>
>
> *Gecko*: N/A
>
> *WebKit*: N/A
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> 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
>
>
> Goals for experimentation
>
>
>
> Ongoing technical constraints
>
> There are no plans to add media previews to Chrome on platforms other than
> Windows/Mac/Linux.
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> There are currently no plans to launch previews outside of
> Windows/Mac/Linux.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> N/A
>
>
> DevTrial instructionshttps://tinyurl.com/yc6mvth8
>
> Flag name on chrome://flags--enable-features=camera-mic-preview
>
> Finch feature nameCameraMicPreview
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/330762482
>
> Launch bughttps://launch.corp.google.com/launch/4304480
>
> Estimated milestones
> Origin trial desktop first 125
> Origin trial desktop last 136
> DevTrial on desktop 122
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5100528783851520
>
> 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/CALgg%2BHEQFdnM53Q0wxGhRmsW%3D8A0%2Ba43MXs5nGaP4eujexSOOQ%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/CADxkKiLNEw%3D%2BzmhjZedWyeLPiQrsbf6fRzj%2BYVPvq9YcpAPL2g%40mail.gmail.com.

[blink-dev] Ready for Developer Testing: Media Previews opt-out

[mark a. foltz]

Contact emailsmfo...@chromium.org, bryantchand...@chromium.org

ExplainerNone

Specification
https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit

Design docs
https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit

Summary

Allow coordination between sites using Page Embedded Permissions Controls
and concurrent experiments with the camera and microphone permissions UI in
Chrome.


Blink componentBlink>MediaStream


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None as this feature concerns the functionality of Chrome's permissions UI,
and does not change the behavior of the APIs that are gated by it:
navigator.mediaDevices.enumerateDevices and
navigator.mediaDevices.getUserMedia Other browsers implement their own
permissions UIs independently of Chrome.


*Gecko*: N/A

*WebKit*: N/A

*Web developers*: No signals

*Other signals*:

Ergonomics

N/A


Activation

N/A


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


Goals for experimentation



Ongoing technical constraints

There are no plans to add media previews to Chrome on platforms other than
Windows/Mac/Linux.


Debuggability

N/A


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

There are currently no plans to launch previews outside of
Windows/Mac/Linux.


Is this feature fully tested by web-platform-tests

?No

N/A


DevTrial instructionshttps://tinyurl.com/yc6mvth8

Flag name on chrome://flags--enable-features=camera-mic-preview

Finch feature nameCameraMicPreview

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/330762482

Launch bughttps://launch.corp.google.com/launch/4304480

Estimated milestones
Origin trial desktop first 125
Origin trial desktop last 136
DevTrial on desktop 122

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

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/CALgg%2BHEQFdnM53Q0wxGhRmsW%3D8A0%2Ba43MXs5nGaP4eujexSOOQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Protected Audience Bidding & Auction Services

['Russ Hamilton' via blink-dev]

Specification
We are just beginning writing the spec. We're drafting a WICG spec for the
browser components and an IETF spec for the server interface.

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723.


TAG review status

Completed for Protected Audience, resolved unsatisfied.


Interoperability and Compatibility


Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in
the Mozilla forum here
, and in the
Webkit forum here 
.


*WPT Tests*


We have not started on WPT tests for this feature.


On Mon, Apr 8, 2024 at 11:40 AM Mike Taylor  wrote:

> Hi Russ,
>
> Could you summarize progress on the following, per the extension process:
>
> Draft spec (early draft is ok, but must be spec-like and associated with
> the appropriate standardization venue, or WICG)
> TAG review
> bit.ly/blink-signals requests
> Outreach for feedback from the spec community
> WPT tests
>
> I recognize some of this is touched on in your email - but having it
> explicitly in one spot would be helpful, thanks.
> On 4/4/24 12:19 PM, 'Russ Hamilton' via blink-dev wrote:
>
> Contact emails
>
> pauljen...@chromium.org, behamil...@google.com
>
> Explainer
>
> Chrome:
> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>
> Services:
> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>
> Note that this explainer has a helpful onboarding section
> 
> for setting up the services.
>
> Specification
>
> Influenced by Origin Trial feedback, so work has just started.  Protected
> Audience auctions running on Bidding & Auction Services provide
> functionality very similar to existing on-device auctions so much of the
> existing spec  applies.
>
> Summary
>
> We propose extending the Bidding and Auction Services origin trial
> currently operating on 1% stable. We have decided to extend the experiment
> given developers need more time to onboard and to keep experimenting with
> new features. We would like to request extending the end milestone from
> M124 to M127.
>
> Blink component
>
> Blink>InterestGroups
> 
>
> TAG review
>
> For Protected Audience:
> https://github.com/w3ctag/design-reviews/issues/723
>
> TAG review status
>
> Completed for Protected Audience, resolved unsatisfied.
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4649601971257344
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com
>
> Intent to Experiment:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2bwMHd3Yz7I
> 
> --
> 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/CAAG-DU2FmKivx3FF%3Dn0BZge_0n10ihizanpgrZVkPaeWtzaCbA%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/CAAG-DU2nS16Me8DK_p8oaA900244DxEVNrDmbcZXEyRExMxZdw%40mail.gmail.com.

Re: [blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Stefan Peter]

Hi, I think it would help to extend the Open Trial to Windows and Mac as 
well. We're really like that feature it fits perfectly our strategy and the 
behaviour of or App (having mutliple remote session to computers active in 
different tabs)

I have only minor problems with it, like that there are no favicons in the 
tabs or that the visible split between inactive tabs is not so well 
visible. But otherwise can't wait to have it as a non experimental feature. 
:)

Domenic Denicola schrieb am Mittwoch, 13. März 2024 um 03:45:58 UTC+1:

> LGTM to extend. The recent spec progress looks significant, and other 
> areas are in good shape.
>
> On Wed, Mar 13, 2024 at 11:36 AM Matt Giuca  wrote:
>
>> The original trial was from 118 to 123, inclusive.
>>
>> We want to extend it so it continues running from 124 to 126, inclusive.
>>
>> On Fri, 8 Mar 2024 at 16:52, Domenic Denicola  
>> wrote:
>>
>>> For what milestones do you want to extend the experiment for?
>>>
>>> On Thu, Mar 7, 2024 at 3:39 PM Matt Giuca  wrote:
>>>
 Contact emailsloub...@google.com, gle...@chromium.org, 
 mgi...@chromium.org, bre...@chromium.org

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

 Specificationhttps://github.com/WICG/manifest-incubations/pull/95
  (draft)

 Summary

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

 Following a 6-milestone origin trial, we would like to continue 
 experimenting as the feature team is not ready to commit to shipping, and 
 gathered very little data from the initial experiment (as partners we have 
 lined up have not yet started their experiment).

 Per the Blink policy, we have made substantial progress in these five 
 areas:

- Draft spec: https://github.com/WICG/manifest-incubations/pull/95
- TAG review: https://github.com/w3ctag/design-reviews/issues/841 
(closed with "unsatisfied"; I have sent a follow-up comment).
- Signals requests:
   - WebKit: 
   https://github.com/WebKit/standards-positions/issues/195 
   (ignored)
   - Mozilla: 
   https://github.com/mozilla/standards-positions/issues/811 
   (closed as not interested in any of "these sorts of features")
- Outreach for feedback from spec community: 
https://developer.chrome.com/docs/capabilities/tabbed-application-mode
- WPT tests: 

 https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html

 Blink componentBlink>AppManifest 
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841

 TAG review statusClosed ("Unsatisfied")

 Chromium Trial NameWebAppTabStrip

 Origin trial feedback summary
 Only a small number of signups, most look like individuals wanting to 
 experiment. A handful of small PWAs are using it. A few large sites signed 
 up for the trial but do not appear to be using it.

 That said, we think this is a useful feature and want to keep exploring 
 possible customers of the API.

 I was unable to see any qualitative feedback from registrants.

 Origin Trial documentation link
 https://developer.chrome.com/docs/capabilities/tabbed-application-mode

 Risks


 Interoperability and Compatibility



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

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

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

 *Other signals*:

 WebView application risks

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

 N/A



 Goals for experimentation

 Roll out one major client and get developer and user feedback.

 Ongoing technical constraints

 Reuses browser tab strip code, adding further dependency between the 
 browser tab strip and PWA windows.

 Debuggability

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


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

 The origin trial is available on ChromeOS only. Support for other 
 desktop platforms is planned but low priority.


 Is this feature fully tested by web-platform-tests 
 

Re: [blink-dev] Intent to Ship: WebAuthn: Large blob storage extension (largeBlob)

[Carlos Cabada]

Hello, 

What would it mean to have support of Large Blob in Android devices?  

> Play Services does not support CTAP 2.1, which is required for this 
feature

Is this the only constraint? Do Android devices in general have support of 
CTAP 2.1?
El viernes, 13 de octubre de 2023 a las 9:20:29 UTC-6, polyset escribió:

> Would it be possible to show the uncompressed data in the modal before a 
> read or write returns? 
>
> There are a few reasons for this:
>
> 1) I want to know what the window is storing on my credential 
>
> 2) this opens up development use cases not yet available
>
> On Thursday, March 9, 2023 at 2:53:42 PM UTC-4 nsat...@chromium.org wrote:
>
>> On Fri, Mar 3, 2023 at 8:08 AM Rick Byers  wrote:
>>
>>> LGTM3
>>>
>>> On Wed, Mar 1, 2023 at 7:35 PM Nina Satragno  
>>> wrote:
>>>
 Hey Rick!

 On Mon, Feb 27, 2023 at 6:14 PM Rick Byers  wrote:

> Hi Nina,
> Seems pretty solid to me, just a few questions inline.
>
> On Wed, Feb 22, 2023 at 5:15 PM Nina Satragno  
> wrote:
>
>> *Contact emails*
>> nsat...@chromium.org, identi...@chromium.org
>>
>> *Explainer*
>>
>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Large-Blob-Extension
>>
>
> *Specification*
>> https://www.w3.org/TR/webauthn-2/#sctn-large-blob-extension
>>
>> *Summary*
>> The WebAuthn large blob extension allows relying parties to store 
>> opaque data associated with a credential. This is useful for 
>> authentication 
>> schemes involving storing certificates on authenticators.
>>
>
> Sorry if it should be obvious, but can you say a little more about 
> the utility? How are such certificates expected to be used? The explainer 
> doesn't describe the developer/user benefits of this feature.
>

 It's not obvious at all! I added an example use cases 
 
  section 
 with two I could conjure: offline SSH authentication in the context of 
 SSO, 
 and E2E messaging.

>>>
>>> Makes sense, thank you! 
>>>
  

> Do you know of any specific RPs who are looking to deploy such 
> features? What value does it bring them or their users?
>
>
 During the prototype period, we had a handful of developers reach out 
 to ask for availability & file bugs (e.g. crbug.com/1282491, 
 crbug.com/1312802, crbug.com/1312788). We also had a couple large RPs 
 express interest privately.

>>>
>>> Perfect, thanks.
>>>  
>>>
 When we're the first engine to ship, the API owners are tasked with 
> making an risk vs. moving the web forward tradeoff evaluation and it's 
> not 
> clear to me from the explainer exactly how this "moves the web forward". 
> Maybe worth adding a few sentences to the explainer?
>
> *Blink component*
>> Blink>WebAuthentication
>>
>> *Search tags*
>> webauthn, large blob, blobs
>>
>> *TAG review*
>> https://github.com/w3ctag/design-reviews/issues/820
>>
>> *TAG review status*
>> Pending
>>
>> *Risks*
>>
>> *Interoperability and Compatibility*
>> Low. This feature has long been part of the WebAuthn L2 recommended 
>> standard 
>> . It is 
>> supported by production CTAP 2.1 security keys as well as recent enough 
>> versions of the Windows WebAuthn API.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/750)
>>
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/139)
>>
>
> Looks like that's in-development now (though Ricky does say they want 
> to study the privacy and security properties a little more).
>
> Web developers: Positive. We had a few developers reach out about 
>> availability, e.g. crbug.com/1282491.
>>
>> Other signals: Microsoft has shipped the OS-level large blob API, see 
>> https://github.com/microsoft/webauthn/blob/master/webauthn.h
>>
>> *Ergonomics*
>> WebAuthn is already an asynchronous API with a "long" time to get a 
>> response (in the order of seconds) since it needs user interaction. 
>> Adding 
>> this feature will not impact the "normal" webauthn flow. For relying 
>> parties (i.e. websites) using it, it won't significantly affect 
>> performance.
>>
>
> Can you say a little bit about storage limits? This is to be stored on 
> the authenticator itself, right? Is there a max size per credential or 
> RP? 
>

 We are limiting the pre-compression size of each blob to 2kb.

 The storage capacity depends on the authenticator. Phones will 
 essentially have "unlimited" storage, while security keys will have 
 comparatively little. The key I have