Re: [via Web of Sensors Community Group]

Peter,


All good questions and to be honest I think I'm not able to answer  
them in a sufficient detail. I ask Anne van Kesteren (he's the Editor  
of the spec) to give it a shot, please?

Cheers,
	Michael
--
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 24 Feb 2012, at 08:55, Peter Waher wrote:

> 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 09:12:18 UTC