- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Fri, 08 Jan 2010 13:27:20 -0800
- 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