Closed mmccool closed 4 years ago
This seems not to be a Scripting API issue per se, since the API provides TD's and does not specify how those TD's should be retrieved by implementations, nor does it expose any directory information. A malicious user of the API could gather only the information exposed in the discovered TDs themselves.
All the phases of discovery should be encapsuleted by implementations. The issue could also be mitigated using proxy directories (an architectural solution for mitigation).
In particular, if during the "introduction" phase a set of directory service URLs are made available via a scripting API
The Scripting API does not expose directory service URLs, only uses them.
it might be possible to infer location (using fingerprinting...) from the set of directories discovered
What is the mechanism of discovering directories (used for discovery)? Looks like this assumed mechanism needs to mitigate location fingerprinting, not the Scripting API.
Are there other threats? There is a generic query
element in ThingFilter
used in discovery that might in theory specify location, but that is a feature. If sensitive, a UA doesn't need to support that (there are separate conformance classes for client, server and discovery).
I suggest removing the "Scripting API for"
part from the title: this issue would be valid then and the outcome could eventually be used in the Scripting spec as well, if threats justify.
My suggestion (discussed March 23 in the Scripting API call) that we (a) first gain some experience with a PoC (b) the privacy issue raised by being able to specify the mechanism can be mitigated by simply configuring the runtime in privacy-sensitive contexts to not allow access to these mechanisms (and in fact, perhaps the runtime can be configured with a simple "directory" that only provides access to specific devices).
Maybe the issue is that we should provide some guidance in the implementation of runtimes to mitigate these risks.
Closing, since I think my conclusion is that the Scripting API as currently specified does not need to change.
The proposed two-phase discovery process does not completely mitigate privacy risks. In particular, if during the "introduction" phase a set of directory service URLs are made available via a scripting API, it might be possible to infer location (using fingerprinting...) from the set of directories discovered. So either the user needs to be warned about this (discovery can result in loss of information about location) OR a suitable high-level abstraction needs to be included in the scripting API design for discovery so that the exact list of directories is not available to the application.