W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

RE: [discovery] Adding CORS to NSD API - proposal and issues

From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Date: Fri, 4 Oct 2013 13:48:11 +0000
To: Rich Tibbett <richt@opera.com>, Device APIs Working Group <public-device-apis@w3.org>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F53837D@ADELE.crf.canon.fr>
Hi Rich, 

Thanks for bringing this proposal forward.

As you may think, I prefer the alternate proposal. 
From my perspective, it looks more consistent with the current technology ecosystem.

For instance, as stated in [2] section 6.3, DNS TXT information should ideally not be necessary to start the communication.
This information should be recoverable by directly communicating with the service and if possible, just seen as an optimization.
With the proposed approach, the web app will not be able to start communicating with the service if this information is not provided.

The proposed approach seems also to mandate services to decide between "CORS for nobody" and "CORS for all".
One may think of scenarios where local services agree to talk with only a limited list of origins.
This should not be precluded as CORS already supports this.

I need to think more about the issue you raised with the alternate proposal.
It would be great if it could just be covered through implementation guidelines.

Concerning the idea of not advertising services that the web app cannot talk to, I am not totally sure that it always makes sense (except if that raises some security issues...).
It may for instance be confusing for a user to see that his windows media player can detect 3 media libraries while its preferred media player web app can only discover one.
As long as a web app can differentiate services it can do XHR from other services, shouldn't it be left to the web app developer hands to decide what to do with the services it may not directly do XHR?

Concerning the whitelisting mechanism, I look forward for more details on it.
When going quickly through it, I had some questions like:
Should whitelist be based on specific criteria like service type as suggested in the discovery mechanisms specific rules?
Should it be let entirely to browsers? In which case, should the spec provide recommendations? 


> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: jeudi 3 octobre 2013 13:22
> To: Device APIs Working Group
> Subject: [discovery] Adding CORS to NSD API - proposal and issues
> Hi folks,
> I'm in the process of adding tentative CORS support to the NSD API spec as
> we have been discussing in [1]. This email is a technical summary of the
> current thinking around this and a discussion of the current issues we are
> facing with this approach.
> ---
> Current Proposal:
> To provide access only to CORS-enabled networked services it would be
> good to have a way to detect CORS support during network service discovery
> processes themselves; before those networked services are offered up to
> users and before they are shared with web pages. A networked service that
> does not provide cross-site request communication would be relatively
> useless and is a situation we are trying to avoid.
> The NSD API spec currently details the network service discovery processes
> for three mechanisms: SSDP (UPnP), mDNS+DNS-SD and DIAL and the
> method for each of these mechanisms to indicate a networked service
> supports CORS could be as follows:
> - For SSDP, a <service> node contained within a UPnP Device Descriptor File
> must provide a <corsEnabled> sub-element whose value must be set to '1',
> 'yes', 'y' or 'true'. Otherwise, the <service> is said not to support CORS and is
> therefore not accessible to web pages (except if the service type is
> whitelisted by the user or user agent).
> - For DNS-SD, a developer must add a 'corsEnabled' key to their DNS-SD SRV
> record's corresponding DNS TXT record. This key would be case-insensitive in
> line with the DNS-SD spec itself [2]. Otherwise, the DNS-SD service is said not
> to support CORS and is therefore not accessible to web pages (except if the
> service type is whitelisted by the user or user agent).
> - For DIAL, the discovery message response must contain a 'Access-Control-
> Allow-Origin' HTTP header and the value of this header must be '*'.
> Otherwise, the DIAL service is said not to support CORS and is therefore not
> accessible to web pages (except if the DIAL service type is whitelisted by the
> user or user agent).
> Each of the above mechanisms is currently a tentative proposal and each
> warrants further discussion both on this list and in their respective
> standardization groups.
> We should also offer an override mechanism for users and/or user agents to
> create a network services whitelist - enabling access to non-CORS-enabled
> networked services also. Implementation of such a network services
> whitelist remains at an implementer's discretion.
> In case any of the conditions above occur, a network service could be
> accessed from web pages via the the Network Service Discovery API (subject
> to all the conditions therein). Web page themselves are not privy to the
> CORS-detection procedures outlined above since the CORS opt-in process is
> abstracted away from the API itself to the respective discovery processes.
> ---
> Current Proposal Issues:
> The main problem with this approach is that dissonance has now been
> introduced between a.) the indicating of support for CORS during the
> discovery process and b.) _actual_ support for CORS in subsequent service
> interactions. i.e. If a networked service indicates it supports CORS during the
> discovery process and then subsequently fails to provide 'Access-Control-
> Allow-Origin: *' in all subsequent HTTP responses or the networked service
> doesn't implement the ability to respond to CORS preflight requests correctly
> (among other potential CORS-related pitfalls) then the process of
> communicating with a networked service fails and the service is broken for
> all meaningful purposes (I can't communicate with a discovered process from
> a web page).
> One solution to this issue may be to require networked services to opt-in to
> cross-site requests during their discovery processes (as proposed above) but
> then for the user agent to 'simulate' CORS support for that networked
> service's URL endpoint. This is similar to the way the API is currently drafted,
> by adding service URLs to a URL whitelist that requires the user agent to
> treat service URLs as if they supported CORS without the service itself
> needing to support CORS directly.
> The new part in this process is that networked services need to opt-in to
> cross-site requests during discovery (via the mechanisms above) rather than
> the user agent providing that access for all networked services by default (as
> per the previously specced approach). That seems to meet the objectives of
> this exercise without introducing any potential dissonance between the
> service discovery process and the service communication process.
> Minor point: If we do agree to go with this idea instead then it may make
> more sense to rename 'corsEnabled' to 'xsEnabled' in the discovery
> processes above.
> So the process essentially becomes CORS-like (where services need to opt-in
> to cross-site sharing) but the result is 'simulated CORS'
> (where the user agent acts as if CORS is enabled for URLS belonging to
> shared networked services).
> -------
> Alternative Proposal:
> During the current drafting an alternative proposal came up and it may be
> worth mentioning here.
> Instead of introducing the dissonance discussed above we could instead rely
> on issuing tentative preflight requests [3] to networked service endpoint
> URLs once the network service discovery process has been completed as
> normal (without services needing to opt-in at the discovery stage). This
> approach has the benefit of actually ensuring CORS is properly supported
> since we are feature-detecting CORS directly on actual network service URLs
> rather than trusting a corsEnabled directive during discovery that assues us
> that CORS is supported on any corresponding network service URLs.
> ---
> Alternative Proposal Issues:
> The major problem with adopting this alternative approach is that the root of
> a networked service endpoint URL is not always configured to return 200 OK
> responses (some networked services may provide access only in sub-
> directories or non-standard root locations which can differ per network
> service type). CORS preflight requests abort if the HTTP response is not 200
> OK, in which case this approach would fail to capture legitimate CORS-
> enabled networked services during this process.
> ---
> So it seems there are a few things we need to think about further here and all
> feedback is welcome on the best way for us to proceed.
> br/ Rich
> ---
> [1] http://lists.w3.org/Archives/Public/public-device-

> apis/2013Sep/0040.html
> [2] http://tools.ietf.org/html/rfc6763#section-6

> [3] http://www.w3.org/TR/cors/#preflight-request

Received on Friday, 4 October 2013 13:49:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC