W3C home > Mailing lists > Public > public-webscreens@w3.org > March 2017

[openscreenprotocol] [SSDP] Investigate mechanisms to pre-filter devices by Presentation URL

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Mon, 27 Mar 2017 21:31:01 +0000
To: public-webscreens@w3.org
Message-ID: <issues.opened-217381448-1490650259-sysbot+gh@w3.org>
mfoltzgoogle has just created a new issue for https://github.com/webscreens/openscreenprotocol:

== [SSDP] Investigate mechanisms to pre-filter devices by Presentation URL ==
Forked from https://github.com/webscreens/openscreenprotocol/pull/20/files#r108024628.


Including presentation URLs in the SEARCH or response has a couple of issues:

* It's not great from a privacy perspective, as it exposes them to passive network listeners.
* These messages need to fit in a UDP packet, which limits them to about 1420 bytes.


louaybassbouss 2 days ago Collaborator

I agree with you question is as I mentioned in other comments we need to make clear what is the input and output of the discovery process. Question is here do we want to have device filtering in discovery or later after handshake? filter devices during discovery reduce the number of unnecessary calls (to displays that cannot present a specific URL) but raises on the other hand couple of privacy issues as you mentioned. From my point of view, I prefer a solution where the presentation display exposes in a way more information about the content that can be presented. I was thinking about a regular expression that can be exposed in a SSDP header (in SEARCH response or alive messages) where the controller can detect if the display can present a specific URL or not. For example if a display allows only https then the regular expression will be something like https://* or if the receiver is cast device a accepts only cast applications then the regular expression could be https://cast.google.com#castAppId=*. In this case there is no need to share the presentation URLs in the discovery messages.

mfoltzgoogle just now Collaborator
I think if there's a privacy preserving way to optimize away some connections to the receiver service that would be a benefit. If the primary benefit is to separate out generic endpoints (https://) from application-specific ones (e.g., casts://) a simple scheme advertisement approach might work.

Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/21 using your GitHub account
Received on Monday, 27 March 2017 21:31:07 UTC

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