search

w3c / mediacapture-main

Media Capture and Streams specification (aka getUserMedia)
https://w3c.github.io/mediacapture-main/
Other
125 stars 61 forks source link

Spec should document anticipated differences from v2.0 #831

Closed pes10k closed 2 years ago

pes10k commented 2 years ago

The outcome of many of the conversations between PING and the working group have been (understandably) the “current approach is too constrained by compat concerns to be fundamentally fixed privacy wise, but the 2.0 version of the spec will solve by being fundamentally different by emphasizing in browser-mediated selection.”.

I think it would be useful (both to document the concerns raised and planned to be addressed by follow up work, and to prevent the current approach from being used as a model for other specs) it would be ideal to add a non-normative section in the current document discussing choices in the current document that are no longer considered ideal, and the different approaches that are planned for the future versions (whether inline or as links to other documents).

cc @dontcallmedom

alvestrand commented 2 years ago

This question assumes that a 2.0 version would go along with deprecating the current functions that allow in-app device selection. I don't think we can assume that this is the case.

The "browser-mediated selection" proposal is outlined in https://w3c.github.io/mediacapture-extensions/#camera%20and%20microphone%20picker - so far this has been written up, but I don't know if it has been implemented by anyone, or if product owners (aka web developers) have stated that they would be willing to switch from in-app browser pickers to this kind of API and UI.

pes10k commented 2 years ago

This question assumes that a 2.0 version would go along with deprecating the current functions that allow in-app device selection

I'm surprised to heard this. IIRC, several times when PING was reviewing the spec last year, PING was told that the current "in page selection / JS device enumeration" approach was known to be privacy-harming, but that the WG was locked in due to webcompat concerns, and that the next version of the spec would take a browser-mediated approach. This is why we dropped some of our issues / concerns / objections with the current version of the spec.

I'm not (in this issue) requesting the group only and exclusively purse browser mediated approaches; i appreciate that none of this has been implemented and its early days and things can change etc. The request is to include text that accomplishes the following:

  1. that the current approach is not ideal but still in the spec bc of legacy / compat reasons
  2. that other specs should not use the current approach as a model to build off
  3. describe why the current version is not ideal (privacy wise) and the general approach the current authors think would be better

Would the group object to including a non-normative section in the spec accomplishing the above?

youennf commented 2 years ago

I think it would be worth adding a note about this. Probably linking to the document presenting the various approaches to ensure data minimisation. I cannot find it right now. @pes10k, do you have this link?

dontcallmedom commented 2 years ago

https://w3ctag.github.io/design-principles/#device-enumeration ?

youennf commented 2 years ago

Yep, that is the document I was thinking about.

pes10k commented 2 years ago

Sounds good. Yes adding a note mentioning why the current approach is sub-optimal and shouldn't be modeled for new specs going forward, with an explanatory link to the TAG doc describing what approaches spec authors should pursue instead would address the concern. Thanks!