- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 06 Feb 2015 11:55:23 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
* Harald Alvestrand wrote: >I would see much more benefit in someone trying for a writeup that >describes precisely the threat they see, what mitigations they see >against the possible threat, and - importantly - what functionality we >would lose by implementing those mitigations. > >So far, we've been tossing around the term "private IP address" without >a precise definition, stating that it is a privacy concern without >specifying what attacks are possible based on that information, tossing >around words about possible mitigations (user prompts, browser >configurations), and not tying those possible mitigations to possible >loss of functionality (user prompt blindness, lessened usability, >failures in setting up intra-LAN peer connections). This is not engineering. Like I said, "If this actually allows random web sites to know that I am using the addresses 192.168.12.96, 192.168.3.222, and 192.168.200.7 (Ethernet, Wifi, virtual machine) on this computer then that is pretty much like broadcasting a device GUID" and a fairly persistent one. That seems reasonably specific to me, and the problems a covertly-obtainable GUID poses should be clear. It is quite possible many systems offer fewer bits of identifying information than my configuration, do we have any scientific research on that? There are any number of ways to discourage use of this information for purposes other than those intended, starting with saying that it is not to be used for other purposes in the specification. User interaction can be required before sending such information (think file uploads and pop- up blockers), browsers could indicate when they send the addresses using some sort of notification so obtaining the information covertly would be difficult, the API could give sites the option to omit private addresses to avoid such notifications; sending private addresses could be disabled if the code is running in some iframe and not the main page. And so on and so forth. None of this would come with an actual loss of features. It would also help if we actually had a working draft of the API speci- fication, the latest one is from 2013 and if it had Security and Privacy considerations, even the editor's draft for the API has only a "TBD" Security section. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Received on Friday, 6 February 2015 10:55:55 UTC