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

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 20:35:16 UTC