RE: [via Web of Sensors Community Group]

Hello Michael.

Others seem to share the interest in this topic (CORS API), so I'll send the reply to this list. Sorry for spamming.

I've read the CORS API documentation, and although it allows for some cross domain access, it would not solve the issues in this case for the following reasons. Please correct me if I'm wrong:

1) The CORS API adds requirements to the secondary resources (if primary being the web or IP-TV-portal in our example, and secondary being SPARQL endpoints or sensors in a home network). This would probably be difficult to implement with all the millions (or billions) of devices from thousands of manufacturers already in existence, coming to existence as we speak. My belief is that for a solution to this use case to be possible, it cannot imply additional requirements on UPnP or DLNA devices. 

2) There's a heavy responsibility placed on the secondary resource for knowing what primary resources can access it, which causes conflicts of interest. Producers of consumer electronics wouldn't want to place restrictions on this, while the home owner wouldn't want anybody to get access to their devices.

3) For our use case, it would make more sense for the primary resource to list what secondary resources (domains) it would like to access, instead of the other way around. For instance, the web or IP-TV portal would ask permission (using HTTP Headers) to get access to the secondary resource domains, and the browser, using its security model would grant or deny access accordingly.

4) There are static bindings between the origins (domains) (unless the * is chosen, which would allow everything). This is also contrary to the dynamic nature of UPnP and other no-admin service discovery mechanisms. In a static model, how do you request access to devices in your home network? Do you access 192.168.*.* ? That would of course impose huge security problems, you wouldn't want anybody to get access of your web camera or DLNA hard drives.

5) Dynamic services come and go during the life time of the web application, which makes static links difficult to maintain without reloading the page.

6) How do you handle the entrance of IPv6 and DLNA?

To me it therefore seems more reasonable for the primary resource to require permissions to access the secondary resources. However, addressing of these resources should not be limited to IP-address, since they may vary. Domain names might not be available either. If UPnP is chosen, the device ID could be used, and the browser would have the responsibility to grant or deny access to devices depending on the domain of the web application (and/or current user). 

Best regards,
Peter Waher


-----Original Message-----
From: Michael Hausenblas [mailto:michael.hausenblas@deri.org] 
Sent: den 23 februari 2012 08:52
To: Peter Waher
Cc: Marcos Caceres; Myriam Leggieri; Arthur Barstow; public-sensorweb@w3.org; public-xg-ssn@w3.org WG; Manfred Hauswirth
Subject: Re: [via Web of Sensors Community Group]


Peter,


> * The ability to call resources across different domains (for instance 
> internet, where page might be located, and local network, where sensor 
> gateway/SPARQL endpoint is located). This can be allowed in controlled 
> networks (such as IP-TV networks), but for general solutions (i.e. 
> combining web & home networks) security vulnerabilities makes this 
> difficult.


We are actively advocating the upcoming W3C standard 'Cross-Origin Resource Sharing' (CORS) [1] to address this issue and to this end maintain http://enable-cors.org/ - feel free to ping me off-list if you want to discuss this.

Cheers,
	Michael

[1] http://www.w3.org/TR/cors/
--
Dr. Michael Hausenblas, Research Fellow
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute NUIG - National University of Ireland, Galway Ireland, Europe Tel. +353 91 495730 http://linkeddata.deri.ie/ http://sw-app.org/about.html

On 23 Feb 2012, at 08:43, Peter Waher wrote:

> Hello.
>
> UPnP seems (to me) a very good solution, combined with SPARQL.
>
> The browser does not have to support SPARQL, only the SPARQL endpoint 
> does. The browser just sends a SPARQL query (a string) to the endpoint 
> (using a simple HTTP POST, or SOAP/REST request) and the endpoint 
> returns different formats (depending on the Accept header for 
> instance). JSON is a valid format, and is already defined:
> http://www.w3.org/TR/rdf-sparql-json-res/
> http://www.w3.org/TR/sparql11-results-json/
>
> So, the only thing missing today, to be able to use SPARQL & JSON in 
> browser code is:
>
> * The ability to call resources across different domains (for instance 
> internet, where page might be located, and local network, where sensor 
> gateway/SPARQL endpoint is located). This can be allowed in controlled 
> networks (such as IP-TV networks), but for general solutions (i.e. 
> combining web & home networks) security vulnerabilities makes this 
> difficult.
>
> * Detect resources. UPnP & DLNA use UDP & HTTPU. To be able to access 
> these directly from a browser would also induce security 
> vulnerabilities if combining web & home networks.
>
> However, if you through the browser code could get access to UPnP 
> Devices & Interfaces already recognized (for instance through an 
> properties in the DOM), you could add a security model in the browser 
> where you could control what pages would have access right (and what 
> access rights) to individual devices and/or what interfaces. That 
> would definitely be interesting for a multitude of reasons, not only 
> sensor networking and home automation, but home entertainment as well. 
> A UPnP device & interface description would have to be defined for 
> SPARQL endpoints. (Much like the security models used for Windows 7 
> sensors, where privileges to individual sensors are controlled on a 
> user level.)
>
> And if you defined an UPnP interface for the SPARQL endpoint, which 
> had a SPARQL Query action defined, you could perform the SPARQL query 
> over UPnP (i.e. HTTP) instead of using the XHR object, and the cross 
> domain problems would be solved as well.
>
> SPARQL (see it as an SQL for semantic networks) is exceptionally 
> powerful in that it does not pose limitations on how data is 
> structured or linked, where individual data items reside, and allows 
> for cross domain (and cross protocol) joins. SPARQL does for linked 
> internet data what SQL did for relational databases that traditionally 
> were accessed using procedural APIs. Nobody wants to use such 
> procedural APIs anymore, if they have access to an SQL parser/endpoint 
> (if they've taken the trouble to learn SQL).
>
> If somebody wants to learn more about SPARQL:
>
> SPARQL 1.0:
> http://www.w3.org/TR/rdf-sparql-query/
>
> SPARQL 1.1:
> http://www.w3.org/TR/sparql11-query/
>
> Best regards,
> Peter Waher
>
> -----Original Message-----
> From: Marcos Caceres [mailto:w3c@marcosc.com]
> Sent: den 22 februari 2012 20:40
> To: Peter Waher
> Cc: Myriam Leggieri; Arthur Barstow; public-sensorweb@w3.org; 
> public-xg-ssn@w3.org  WG; Manfred Hauswirth; Michael Hausenblas
> Subject: Re: [via Web of Sensors Community Group]
>
>
>
> On Wednesday, February 22, 2012 at 6:25 PM, Peter Waher wrote:
>
>>
>> When it comes to browser support for the semantic sensor networks, we 
>> have an interesting use case we would like to see realized:
>> Consider IP-TV together with semantic home networks (for energy 
>> management, home automation, residential services, etc.)
> Out of interest, are there commercially available solutions of the 
> above that are currently using semantic web technologies?
>> We work with both areas, but one problem that arises is this: How can 
>> the IP-TV system access and use sensors at home? Today, the sensor 
>> values have to travel from the sensors, through gateways to a 
>> centralized metering system, communicating with the IP-TV system, 
>> that then publishes the information to the user, a couple of meters 
>> away from the sensor. This, apart from inducing many items that could 
>> fail, also puts load on the network, and latency.
>
> Yes, it's annoying and overly complicated...
>> However, if the set-top-box (running a browser) would be able to 
>> access the gateway (through XHR), locally, or using HTML5 extensions, 
>> could access the SPARQL endpoint in the local network, and all data 
>> there, a better architecture and solution would be available. This of 
>> course leads to a whole series of security issues, some more or less 
>> delt with if HTTP/HTTPS and authentication is used, but anyway. Also 
>> the issue of service detection (or endpoint detection in networks).
>
>
> So, questions I have: no browser natively supports SPARQL (or any 
> Semantic Web technology, and they have no plans to do so), but 
> browsers will soon support IndexedDB (experimental builds are already 
> coming from Moz, Google, and MS)... would it make sense to explore using 
> an IndexedDB solution? Also, browsers support JSON natively, so why 
> not try to build something on that (and see where it breaks down for 
> the particular use cases... whatever they might be)?
>
> Also, given the proliferation of UPNP and DLNA devices... would it not 
> be worth while to look at exploiting those first?
>
> --
> Marcos Caceres
>
>
>

Received on Friday, 24 February 2012 08:58:29 UTC