W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2015

Re: Re ACTION-723 user denial of captured file leading to no capture

From: Nick Doty <npdoty@w3.org>
Date: Tue, 13 Jan 2015 16:10:00 -0800
Cc: chaals@yandex-team.ru, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "Zhang, Zhiqiang" <zhiqiang.zhang@intel.com>, W3C Device APIs WG <public-device-apis@w3.org>
Message-Id: <FBC069C1-B77B-4135-AAB5-B74952A5494B@w3.org>
To: Frederick Hirsch <w3c@fjhirsch.com>
Apologies, I haven’t been following the test efforts on this spec closely, but I didn’t understand the following.

On Jan 13, 2015, at 11:29 AM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> I agree with Chaals that we don’t want to lose this consideration completely, while at the same time recognizing that we want testable MUST assertions.

I don’t see how "MUST NOT save the captured media to any data storage” is not a testable assertion. Storage is a clear side effect and should be verifiable. It might be more difficult to test this in an automated fashion through the existing test runner, but it still seems testable: either manually, or through automated tests that can check storage media mechanisms that a particular user agent uses.

The “MUST” normative requirement improves interoperability in making it clear to developers and to users that all user agents who implement this spec will not capture the media to storage. (I’m not familiar with all the details of the previous conversation, but it seems like the WG saw some advantage in not having this vary by implementation.)

Nick

> Perhaps we can achieve this by restating the text as follows:
> 
> Change from
> 
> [[
> 
> When the <code><a>capture</a></code> attribute is specified, the
> 	         <a>user agent</a> MUST NOT save the captured media to any data storage,
> 	         local or remote.
> ]]
> 
> to
> 
> [[
> 
> 
> When the <code><a>capture</a></code> attribute is specified, the  <a>user agent</a> is expected to NOT save the captured media to any data storage,
> 	         local or remote.
> 
> ]]
> 
> In other words, use English to capture expectations that matter but are not testable assertions.
> 
> regards, Frederick
> 
> Frederick Hirsch
> @fjhirsch
> 
> On Jan 13, 2015, at 10:11 AM, chaals@yandex-team.ru wrote:
> 
>> Hi,
>> 
>> 13.01.2015, 17:29, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>:
>>> Hi All,
>>>> On 13 Jan 2015, at 07:15, Zhang, Zhiqiang <zhiqiang.zhang@intel.com> wrote:
>>>> 
>>>> I tried to create some tests to check the "user denial of captured file leading to no capture" (ACTION-723) and the spec update "When the capture attribute is specified, the user agent MUST NOT save the captured media to any data storage, local or remote"; but found it is difficult to figure out a good pass/fail criteria for these tests; so I haven't submitted them to the w-p-t repo.
>> [...]
>>> 
>>> Given it appears this assertion (see above) is hard to test reliably (thanks Zhiqiang for experimenting with test cases), I plan to revert the following change I made to the spec in the coming weeks unless I hear otherwise:
>>> 
>>>  http://dev.w3.org/cvsweb/2009/dap/camera/Overview.src.html.diff?r1=1.13;r2=1.14;f=h
>>> 
>>> The change was done in an attempt to address this concern raised on the mailing list some time ago (see the thread for details):
>>> 
>>>  http://lists.w3.org/Archives/Public/public-device-apis/2014Oct/0022.html
>> 
>> I don't think the fact that this is difficult to test is a reason to remove this constraint. It *may* be the case that it doesn't do anything useful, since a script can already collect data, but I think it is reasonable in for example a private browsing mode, and additionally it may be a security consideration that browsers store things in predictable ways. Closing this hole won't produce perfection, but it might narrow the attack surfaces usefully. And it gives someone a clear basis, if their browser *does* record information, to point out that this is unreasonable behaviour in a case that should clearly have been anticipated by implementors.
>> 
>> cheers
>> 
>> Chaals
>> 
>>> -Anssi
>> 
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> chaals@yandex-team.ru - - - Find more at http://yandex.com
>> 
> 
> 


Received on Wednesday, 14 January 2015 00:10:20 UTC

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