search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Scripting API for Discovery should Mitigate location fingerprinting #160

Closed mmccool closed 4 years ago

mmccool commented 4 years ago

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.

zolkis commented 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).

zolkis commented 4 years ago

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.

mmccool commented 4 years ago

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

mmccool commented 4 years ago

Maybe the issue is that we should provide some guidance in the implementation of runtimes to mitigate these risks.

mmccool commented 4 years ago

Closing, since I think my conclusion is that the Scripting API as currently specified does not need to change.