- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Thu, 15 Jun 2017 12:40:10 -0400
- To: public-webrtc@w3.org
- Message-ID: <326e7ec9-1cb9-501a-fb68-eddf1562b4a3@jesup.org>
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
Received on Thursday, 15 June 2017 16:41:12 UTC