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

Re: Why aren't most devices virtual web services?

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Fri, 08 Jan 2010 13:27:20 -0800
Message-ID: <4B47A338.7060700@oracle.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
CC: "ext Mark S. Miller" <erights@google.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Two comments:
1, If you are making local invocations you do not need any authorization.
2. For local invocations it's much more efficient to use in-memory 
mechanisms than message passing.
But, perhaps, you have a different usecase in mind.
All the best, Ashok


Frederick Hirsch wrote:
> Welcome to the group Mark, and thank you for your suggestion.
>
> Isn't privacy a bit different than authorization, which seems to be 
> what you are talking about?
>
> For example, the privacy concern is not only whether I have access to 
> some contact information (I might)  but whether I might retain it, 
> pass it on to others, use it inappropriately and so on. In that sense 
> I'm not sure what you mention addresses the concern, though it might.
>
> To repeat what I think you said,  you suggest that we might adopt a 
> universal approach of having Javascript APIs that all act as if they 
> made a remote invocation even if  locally implemented  and thus be 
> able to reuse other network mechanisms for authorization. Would this 
> impact performance, requiring unnecessary messaging? Would this 
> presume constant connectivity? What are the assumptions here? 
> Apologies if I am asking the obvious.
>
> Thanks
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Jan 7, 2010, at 9:47 PM, ext Mark S. Miller wrote:
>
>> Hi,
>>
>> I'm new to this working group. I recently joined because a number of 
>> people had privately expressed alarm to me over the approaches to 
>> security being taken in this WG. Several of them made the same 
>> suggestion, I think independently. Of the others, they found this 
>> suggestion plausible, so I thought I'd pass it on. For most devices, 
>> why not treat each device as a virtual web service, exposing its API 
>> as a RESTful API in terms of GETs and POSTs. This would reduce the 
>> present security problems to a previously unsolved problem, of how 
>> one web site becomes authorized to use web services provided by 
>> another site.
>>
>> The case is clearest for contacts. Why should authorizing Facebook to 
>> access my local contacts be different than, for example, authorizing 
>> Facebook to access my gmail contacts? There are already several 
>> proposed solutions to this problem, including the debate between CORS 
>> and UMP at the public-webapps group. For current browsers, it is also 
>> the motivating problem behind OAuth. I am *not* suggesting that we at 
>> the public-device-apis WG attempt to pick a winner among these three. 
>> Rather, that we should merely provide device APIs as RESTful GET/POST 
>> APIs, so that we can make use of whatever comes to be the resolution 
>> of this debate. The scheme of device URLs might be something other 
>> than http: or https:, but they should still be accessible through XHR 
>> and its successors.
>>
>> For some devices, an objection that has been raised: receiving and 
>> reacting to notifications from RESTful web services is awkward. 
>> However, once again, the problem is a problem with web services in 
>> general. It should be solved for web services in general. Then, 
>> devices can again be made polymorphic with web services providing 
>> similar functionality.
>>
>> Let's please avoid introducing unnecessary cases into web standards. 
>> KISS.
>>
>> -- 
>>    Cheers,
>>    --MarkM
>>
>
Received on Friday, 8 January 2010 21:31:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC