- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 8 Jan 2010 13:21:39 -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>, Ashok Malhotra <ashok.malhotra@oracle.com>
On Fri, Jan 8, 2010 at 12:34 PM, Frederick Hirsch <frederick.hirsch@nokia.com> wrote: > 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. In general, it's difficult to constrain what a piece of code will do once you hand it a piece of information. The code can exfiltrate the information in many subtle ways. If you're worried about how some code might misuse the information, you're probably better off not giving it to them in the first place. > 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? Do you have example uses of these APIs that we could benchmark? I suspect the performance impact will be insignificant. > Would this presume constant connectivity? Now, the user agent would respond to these URLs, just like HTML user agents respond to data URLs. > What are the assumptions here? Apologies if I am asking the obvious. I think Mark's suggestion is to make these APIs webby by giving them URLs and letting code interact with them the same way code interacts with every other web service. Instead of having these URLs represent remote services, they would represent local services. This lets us leverage a lot of existing infrastructure, especially in terms of privacy and security, and aligns the device APIs with the web architecture. Adam
Received on Friday, 8 January 2010 21:22:33 UTC