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

I agree with Chaals that we don’t want to lost this consideration completely, while at the same time recognizing that we want testable MUST assertions.

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 Tuesday, 13 January 2015 19:30:22 UTC