Re: Direction: Constraints

On May 17, 2012, at 9:03 PM, Cullen Jennings <fluffy@iii.ca> wrote:

> On May 15, 2012, at 3:46 AM, Rich Tibbett wrote:
> 
>> Opera cannot integrate this in to our current products since we are not yet pursuing a trusted environment model for the web on which this proposal heavily relies.
> 
> First - this makes no sense to me in two different ways - the constraints proposal does not rely on a trusted environment. Second, we might mean different things by a trusted environment but I read this to say you are going to allow access to the camera with no user authorization. I seriously doubt this is what you mean so I suspect what we should be  talking about is what sort of trust we are is needed for a minimal implementation.

We will of course be providing user opt-in to camera access [1].

It is not my understanding that providing user authorisation for a web page to access the camera is the same thing as handing over the ability to leak fingerprinting information or give developers the nightmare task of working out a meaningful subset of complex constraints to target their applications at. User authorisation to access the camera should not come with the need to hand over my 'identity' or give sites the ability to track me across sessions. Accessing the camera should not require deep internal knowledge of codecs or their parameters (not to mention ensuring I'm using the right combinations, names, units and scales). 

As a simple thought experiment: I could be identified in a private tab despite not being logged in had I previously logged in to the service in a non private tab at any prior point based on the unique combination of constraints created by my current hardware, OS, webcam type, drivers installed and user preferences. This group just doesn't seem to have evaluated those aspects of the proposal.

As a secondary example: as a developer I set my web app to only work with cameras capable of providing a resolution above 1024x768 that provide 60+ frames per second. I have just excluded ~90% of users from even trying to use my web app. Why did I choose these values? What about the developing world with inferior hardware and software that didn't even cross my mind? Do I _really_ need these constraints for my web app to work or could we just try to work with what the users have actually got? In reality lesser values would have worked just fine but I didn't add them because I couldn't possibly begin to imagine where to begin with that or where to set the threshold. Instead I just wish the user agent would give me a video stream that will work everywhere or just give me the 'best stream you've got' and we'll go from there. If my e.g. Image recognition doesn't work at the point of actually trying it then I can honestly say that it wasn't because we accidentally excluded 90% of the web before they even got to try it.

> 
>> The upshot of this is that we will not be able to claim conformance to the getUserMedia specification if this is added.
> 
>> This and the fact that there is a lot of hidden complexity and a lot of unresolved issues in this proposal
> 
> Really? more complex than what? This is the problem: many of us can not figure out what it is you want - all we know if you don't like anything that is proposed. So what is it exactly that you think this is more complex than. And what requirements do you think we need to meet - for example, most the people I have talked to think that we need to be able to indicate some hints about the desired resolution of image capture. 

This is more complex than _nothing at all at the point of media stream acquisition_ which has proved capable of handling all of our tried and tested use cases to date. In the course of prototyping on our implementation of this over the last 15 months, not a single developer has requested the features proposed by constraints. Not a single use case purporting to its need has yet to stand up to much scrutiny either. _If someone has a use case for constraints *at getUserMedia acquisition* that stands up to scrutiny then it would be very helpful.

My point is (and has been) that this is the wrong point to be asking about resolutions or frame rates or the like. Those characteristics imply a secondary usage such as recording or streaming and should be requested independently at those points. Constraints should live at those points (if anywhere). An acquired media stream will give you whatever the platform is capable of providing which you can further manipulate downstream.

On the contrary at the point you obtain a media stream there are some (very few) meta characteristics that you _do_ want to request but nothing to do with the current proposal. Right now we're looking for a simple way for a page to request the front or back-facing camera. That is not a mandatory request since either camera will work but in some cases while a developer may know best which camera type is best suited for their application, and a user agent will do it's best to suggest the user to authorise the requested camera, a user may want to, and should be able to, choose the other camera.

> 
>> is likely to significantly delay delivery of the core getUserMedia specification in the standards process.
>> 
>> It would be preferable if trusted environment features are pursued in a separate specifcation for now and the open issues on this proposal, of which there are many, are pursued orthogonally to the main task of nailing down the core features of the getUserMedia specification.

[1] http://dev.opera.com/articles/view/getusermedia-access-camera-privacy-ui/

Received on Thursday, 17 May 2012 20:26:54 UTC