- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Wed, 11 Dec 2013 18:35:19 -0500
- To: public-media-capture@w3.org
+1 on all of Eric's points. Gili On 11/12/2013 5:27 AM, Eric Rescorla wrote: > On Wed, Dec 11, 2013 at 6:16 PM, Adam Bergkvist > <adam.bergkvist@ericsson.com> wrote: >> On 2013-12-10 02:26, Eric Rescorla wrote: >>> For the record, I am opposed to this entire piece of Jan-Ivar's proposal. >>> >>> As has been observed many times, there are plenty of opportunities >>> for fingerprinting and so going through these gyrations to make >>> it fractionally more difficult is silly. >> >> I think there's more to this than only protecting against fingerprinting. > Perhaps, but the only argument I have heard for why this needs to > be a specification requirement is fingerprinting. > > >> IMO, prompting for the getUserMedia() *request* itself, not only if some >> devices survived the exclusion process have benefits. >> >> * More consistent behavior when no devices pass the constraints. When this >> happens in our current model, the user can be presented with anything from >> nothing, the app just halts, to a detailed explanation of what went wrong; >> depending on how the app is programmed to handle this case. You could argue >> that the app that does nothing is badly written (and I agree), but if we can >> make users lives better even in these cases I think we should. > I totally disagree. This is a programming environment and it's not > the browser's job to displace the programmer. > > > >> * We could offer alternative actions when no devices pass the constrains. >> >> - Ask the user to connect a new device. >> >> - Offer the user to select a media file that will act as a device (This has >> been a use-case from very early on). >> >> - Give the user the option to report, to the app, what went wrong so it can >> explain in detail why you don't have the hardware required. > These are all fine things, but they are exactly the kind of fine things that > the app knows better than the browser manufacturer to offer > > -Ekr >
Received on Wednesday, 11 December 2013 23:36:06 UTC