Section 220.127.116.11 of the current WhatWG draft sez the following about leaking intranet URIs: Leaking Intranet URIs. The mechanism described in this section can result in secret Intranet URIs being leaked, in the following manner: 1. The user registers a third-party content handler as the default handler for a content type. 2. The user then browses his corporate Intranet site and accesses a document that uses that content type. 3. The user agent contacts the third party and hands the third party the URI to the Intranet content. No actual confidential file data is leaked in this manner, but the URIs themselves could contain confidential information. For example, the URI could be https://www.corp.example.com/upcoming-aquisitions/samples.egf, which might tell the third party that Example Corporation is intending to merge with Samples LLC. Implementors might wish to consider allowing administrators to disable this feature for certain subdomains, content types, or protocols. The one way I could think of to implement this to some degree would be to have a list of the RFC 1918, and not allow URIs from inside that address space (assuming that's where the user is) to be sent to content handlers outside it. I imagine there'd be issues with proxies. I seem to remember mconnor thinking about this for some other feature, so I'm CCing him here. Marked blocking1.9? largely because I think this _might_ want to be wanted1.9.
If we do do this, and that other feature I remember mconnor talking about wasn't feeds, we should probably do it for content-handling (currently just feeds) as well.
Changing title to clarify the scope of this bug. Note that doing such blacklisting universally could break legitimate use cases; some users may want to use third-party content handlers with intranet sites. Furthermore, while RFC1918 addresses usually indicate an address on the local LAN, the reverse does not hold true: intranet sites can use routable IP addresses, and that seems particularly likely with IPv6.
Summary: address intranet URI leakage concerns, if possible → Third-party content handlers can leak intranet URIs
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.