Re: API to access file system (was Re: Review of May 15 WebRTC 1.0 draft)

On 6/14/2017 3:18 PM, Stefan Håkansson LK wrote:
> My recollection is that this comes from use case 2.3.9. "Simple Video
> Communication Service with File Exchange". At the time (as I remember
> it) Tim Terriberry pushed for this (and even went beyond this saying
> that if you want to transfer all files in a folder, each of them should
> go on a different SCTP stream) if memory serves.

Right - the file picker API may not cover selecting them extremely well 
- and more to the point, when the other side receives them, having to 
pop a file requester API for each file in a directory being transferred 
is untenable.  Also, right now incremental sending and reception for 
large files is painful, since the File API isn't widely supported, and 
merging N blobs into one for writing is also painful (and wastes memory 
temporarily).

> As we considered at the time that existing and APIs defined by other W3C
> groups (such as the Audio API can be used for panning) could be used we
> (I) figured that this is OK since there is the File (picker) API
> already, and most browsers already at the time (remember that this was
> six years ago) supported that.

We may have been thinking about the File API.  There are certainly some 
interesting security and user-notification concerns around that level of 
access to the filesystem, though.

[snip - more below]

> On 14/06/17 20:37, Cullen Jennings (fluffy) wrote:
>>> On Jun 7, 2017, at 7:53 AM, Randell Jesup <randell-ietf@jesup.org>
>>> wrote:
>>>
>>>> A1              The web API must provide means for the
>>>>
>>>> application to ask the browser for permission
>>>>
>>>> to use cameras and microphones as input devices
>>>>
>>>> and to have access to the local file system.
>>>>
>>>> Just a question about this requirement: why does the application
>>>> need access to the file system? Am I misinterpreting this?
>>> Not sure where this came from... archaeology on the archives?
>> The discussion at the time was a privacy consideration. The idea was
>> that if the JS asked for a camera, the browser could allow the user
>> to instead provide video from a pre recorded file on disk instead of
>> a real camera. The JS would not be able to tell that the media was
>> coming from the file and not form the camera.
>>
>> As time went on, the thinking that this was needed or even possible
>> seem to sort of disappear. I can't see any reason a browser could not
>> do this if they wanted to.

Correct, browsers can do this without involving the app.  And 
applications can do similar things (provide a video/image in place of a 
camera) using a filepicker, <video>/<canvas> and captureStream(), 
without needing filesystem access beyond file-picker.

>>
>> I would propose we amend that to just remove the "  and to have
>> access to the local file system."

I'd be fine with that.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam