W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2014

[html-media-capture] Save to the file system update: review - testing and new Last Call?

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Wed, 5 Nov 2014 12:15:47 -0500
Cc: Frederick Hirsch <w3c@fjhirsch.com>, Device APIs Working Group <public-device-apis@w3.org>, Emmanuel Toledo <emmanuel.toledo@assertus.com>
Message-Id: <5CD0FB6D-4759-4DAD-A7D7-16A2409742A6@fjhirsch.com>
To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
All

Earlier Anssi updated the HTML Media Capture specification to add a normative requirement (see full details in mail below)

> [[
> 
> When the capture attribute is specified, the user agent MUST NOT save the captured media to any data storage, local or remote.
> 
> NOTE
> 
> When scripts gain access to the files selected from the file picker (represented by a FileList object), they can use various mechanisms to store the captured media. These mechanisms are out of scope for this specification.
> 
> ]]

Is this a testable requirement and do we have a test case for it? How will we test this with implementations given that storage may not be obvious?

Although the concern related to privacy is real, should this be left to implementations rather than added as a requirement to the specification?

If we decide to retain this change, it might make sense to see if we can complete the tests for it and then return to Last Call for review since it is a normative change.

Please share thoughts on this to the list, especially regarding the testing. I expect the next step will be a CfC to return to Last Call from CR.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch



On Oct 14, 2014, at 9:07 AM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:

> Hi All,
> 
> On 13 Oct 2014, at 16:36, Emmanuel Toledo <emmanuel.toledo@assertus.com> wrote:
> 
>> You are right :), I appreciate your help , thanks for your time.
> 
> [...]
> 
>>> This could help on the issue when a device has file synchronization 
>>> with a cloud service(i.e. ICloud, Google drive, One drive, etc.) and the developer does not want to make the user's capture image shareable and potentially making that image public.  In example on Windows Phone the captured image gets saved on the device, there could be more devices with this potential problem.
>> 
>> Wouldn't this problem be addressed by simply requiring that a conformant implementation must not save the captured media anywhere?
> 
> Given this addresses Emmanuel’s concern, I added the following to the spec:
> 
> [[
> 
> When the capture attribute is specified, the user agent MUST NOT save the captured media to any data storage, local or remote.
> 
> NOTE
> 
> When scripts gain access to the files selected from the file picker (represented by a FileList object), they can use various mechanisms to store the captured media. These mechanisms are out of scope for this specification.
> 
> ]]
> 
> See the ED [1] and diff [2].
> 
> A note regarding testability: this assertion must be manually tested.
> 
> All - please let me know if you have concerns with the suggested change.
> 
> Thanks,
> 
> -Anssi
> 
> [1] http://dev.w3.org/2009/dap/camera/
> [2] http://dev.w3.org/cvsweb/2009/dap/camera/Overview.src.html.diff?r1=1.13;r2=1.14;f=h
Received on Wednesday, 5 November 2014 17:17:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC