RE: Some more questions on NSD+CORS

> > “Only Local-networked Services that pass a CORS preflight check should
> > be made available to web pages by a user agent.”
> >
> > “Made available” is a vague term but I understand it as “the user
> > agent communicates the URL of the service”, nothing more.
> >
> > If that is correct, why is this rule mandatory? Is it to cope with a
> > security issue? to ensure a good user experience?
> 
> Both security and UX issues are covered by this check.

I am not yet all clear with the security and UX issues behind that check.
We should not lose flexibility if there is no real gain behind.

To simplify things, why not always presenting all services to the user and deliver all services picked by the user, be they "safe" or not.
The "unsafe" NetworkService objects may have empty URL & config fields if that fixes real security issues.
The web app will then best use the available information to optimize the user experience (or minimize user frustration in that case).
This filtering (CORS, whitelist, blacklist and so on) would be described in a "web browser environment" section.

Some background related points below:

In terms of API, the current approach may have implications on the servicesAvailable field.
Should it count "safe" an "unsafe" services, or just "safe" services?
The same applies to onservicefound events. If such event is sent for an "unsafe" service, no new service would  actually be presented to the user when doing a new NSD call if the browser only displays "safe" services. 
One could restrict onservicefound events to "safe" services but that makes it more complex as well.

In terms of UX, whatever is done, browsers will present services to a user that a web app may not be able to use anyway (CORS limited to GET access e.g.). This check reduces that risk but web apps should better be prepared to deal with that anyway.
A user may be presented different service lists from two web apps that make the same request.
That may be difficult to understand from a user point of view and the web app can best explain this to the user.

In terms of security, delivering "unsafe" services to the web app may increase fingerprinting, but this is covered by user check.
There is also the possibility to more easily try loading services web resources through the browser if the service URL is passed to the web app.
It should be evaluated whether this is a threat or not. If it is, the NSD makes it bigger but does not create it; browser vendors should be made aware of that risk.

The case of a packaged app that has authorized access to a specific well-known statically assigned local IP address is interesting.
Like a secure-proof router with various services: content directory...
The packaged app may do XHR on the device without the NSD API but may have difficulties to discover which services are supported, which URL paths to use and so on. Using the NSD API would be useful here for the purpose of discovery (the core of the spec), not for the purpose of authorization (which may largely vary according the environments).


> A full diff of the changes is available at:
> https://dvcs.w3.org/hg/dap/diff/140b6c8d4c18/discovery-

> api/Overview.src.html.

Thanks a lot for your efforts and driving.

Regards,
 Youenn

Received on Thursday, 10 October 2013 09:32:09 UTC