W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

Re: CfC to change Sensor approach, not progress current draft : OBJECTION

From: Bryan Sullivan <blsaws@gmail.com>
Date: Thu, 22 Mar 2012 12:36:15 +0800
To: Josh Soref <jsoref@rim.com>, W3C DAP <public-device-apis@w3.org>
Message-ID: <CB90CBEB.21B9B%blsaws@gmail.com>
I note that in the F2F I requested Jose be provided with more specific
description of the benefits to security & privacy of distinct APIs (in
these specific cases, or others). It was agreed to provide that info,
which I think is necessary as those issues were one of the main concerns
expressed with the generic API.

One the "better design" assertions, the only significant argument I can
see there is that it easier to avoid superfluous API aspects (e.g.
Parameters that are useless or ambiguous for specific sensors) with
distinct APIs. Other than that, can we also have some other details on why
distinct APIs are better (again in the cases below or for other APIs).

Finally, are there any downsides of distinct APIs? (I can think of some,
but I want to hear what the proponents have to say)

On 3/22/12 12:27 PM, "Josh Soref" <jsoref@rim.com> wrote:

>> Privacy and security threat analysis might vary with the type of sensor,
>> arguing for the need to analyze different sensors independently, making
>> sure each has the appropriate approach.
>Jose wrote:
>> This has yet to be demonstrated.
>We have benefited from distinct APIs for at least:
>Network Information
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.
Received on Thursday, 22 March 2012 04:36:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC