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

[markafoltz]

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

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 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.

[markafoltz]

Assuming that PR #59 is considered a good approach, we should apply it to mDNS as well (via a TXT record).

[markafoltz]

There was a proposal here from the Berlin F2F that apparently wasn't captured in GitHub:

https://www.w3.org/2018/05/17-webscreens-minutes.html#x06

For SSDP, make advertisement of supported schemes truly optional, in that controllers will still connect to the receiving device in the absence of the PROTOCOLS info. We'll adopt a similar mechanism for mDNS. (per data minimization guidelines)

I think the PR #59 will need to be further revised to cover this; in fact, it looks incredibly complicated in retrospect and should be simplified to match the proposal above.

We can discuss this further at TPAC.

[markafoltz]

Closing as:

• We are not using SSDP any more so discussion of SSDP is moot.
• There is a standard way to advertise device-specific capabilites through protocol extensions: https://w3c.github.io/openscreenprotocol/#protocol-extensions