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

I do not think we should use http://localhost/ as it removes the ability for third parties to easily expose "device services" into the browser.

Doug


On Jan 13, 2010, at 11:51 AM, Frederick Hirsch wrote:

> To be clear I understand,  you are saying that the URI resolution would indicate a local access, directly invoking an API without network access in this case. However this would need to be done without inventing new URIs to avoid web arch issues, but an example could be use of localhost?
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Jan 13, 2010, at 2:45 PM, ext Doug Turner wrote:
> 
>> 
>> I do not think that the remote server would have to make a HTTP connection to some api server on the device by itself.  Instead, similar to the use of device Javascript APIs, the server would send down some javascript that would have a XHR to a URI that could be resolved locally.
>> 
>> For example,
>> 
>> navigator.geolocation.getCurrentPosition(successCallback,
>>                                        errorCallback);
>> 
>> function successCallback(position) {
>> }
>> 
>> function errorCallback(error) {
>> }
>> 
>> 
>> 
>> could become (strawman; lots of spec'ing this out needed):
>> 
>> 
>> var httpRequest = new XMLHttpRequest();
>> httpRequest.open('GET', 'geolocation://', true);
>> 
>> httpRequest.onreadystatechange = function(){
>> if (httpRequest.readyState == 4) {
>>   // everything is good
>> } else {
>>   // still not ready
>> }
>> };
>> 
>> 
>> Doug
>> 
>> 
>> On Jan 13, 2010, at 11:31 AM, John Kemp wrote:
>> 
>>> Hi Frederick,
>>> 
>>> On Jan 13, 2010, at 2:05 PM, Frederick Hirsch wrote:
>>> 
>>>> Mark, my concern was that these (e.g. OAuth others noted) all seem to imply network connectivity, yet there might be a requirement to have contact book access (to give an example) without network access.
>>> 
>>> If you imagine that you have a local Web server running, and providing the contacts API, then if a remote site were to access that service (from off-device), it might send an HTTP request to do. This would be a standard Web scenario, and the remote requester would have to know the DNS name or IP address of the device if it wished to make an HTTP request.
>>> 
>>> However, imagine if that same Web server, running on the device, is accessed from some other piece of software (like a browser ;), running on the same device. It might still be secured by OAuth, CORS, UMP or something else. The method of access, however, will not be over a network as such - it will be a "localhost" connection essentially (either to a local Web server, or a cached copy of a document acquired from somewhere else). I believe that is the case you are thinking of?
>>> 
>>> The difference in the use of device Javascript APIs is that the requester in these cases is the one who has written some Javascript using the Device API specifications. That requester won't need to know the IP address of the device in order to use that device's services, because the device requested a page that contains the Javascript calls, and makes a response containing the API calls (which are essentially then a request whose results don't have to leave the device).
>>> 
>>> In all of these cases, though, I am not sure that any extra network connection is needed in order to use OAuth tokens, or any of the other mechanisms suggested to secure the APIs. The requester should be authorized to access the API of course. In the "offline" case, if you were to use OAuth tokens, then the device would ask the user whether the cached page could access her contacts, and give the cached/localhost page an OAuth token to use in accessing that API.
>>> 
>>> Regards,
>>> 
>>> - johnk
>>> 
>>>> 
>>>> regards, Frederick
>>>> 
>>>> Frederick Hirsch
>>>> Nokia
>>>> 
>>>> 
>>>> 
>>>> On Jan 13, 2010, at 1:23 PM, ext Mark S. Miller wrote:
>>>> 
>>>>> Still catching up. Answering out of order.
>>>>> 
>>>>> 
>>>>> On Wed, Jan 13, 2010 at 7:26 AM, Frederick Hirsch <Frederick.Hirsch@nokia.com> wrote:
>>>>> use of OAuth.
>>>>> 
>>>>> 
>>>>> That was just an example of one approach to the inter-site authorization problem. Others are CORS and UMP. As I said in the initial proposal, I don't think this WG should try to pick a winner in this debate. They should just position device APIs so that they can leverage whatever the winner is, by recasting devices as RESTful GET/POST apis. By so doing, we reduce the security issues to a previously unsolved problem ;).
>>>>> 
>>>>> 
>>>>> 
>>>>> regards, Frederick
>>>>> 
>>>>> Frederick Hirsch
>>>>> Nokia
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jan 13, 2010, at 9:55 AM, ext Robin Berjon wrote:
>>>>> 
>>>>> On Jan 13, 2010, at 15:50 , Frederick Hirsch wrote:
>>>>> Is there a requirement to allow local access to contacts, for example, even when disconnected from the network? How would this work in this model, or is disconnected operation not a requirement? It seems a mobile device should still operate as much as possible when disconnected.
>>>>> 
>>>>> That's entirely orthogonal. Either the web server is local, or (perhaps more likely) it is emulated by the user agent. You never go to the network, whether connected or not.
>>>>> 
>>>>> I thought the proposal was to go to the network for authorization, in which case it is not orthogonal.
>>>>> 
>>>>> I don't read that in the original proposal, can you clarify which part you're thinking of?
>>>>> 
>>>>> --
>>>>> Robin Berjon
>>>>> robineko — hired gun, higher standards
>>>>> http://robineko.com/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Cheers,
>>>>> --MarkM
>>>> 
>>>> 
>>> 
>>> 
>> 
>

Received on Wednesday, 13 January 2010 19:57:41 UTC