Block non-.onion subresources on .onion websites?
Right now, .onion sites can load HTTP or HTTPS subresources (scripts, images, etc.).
But is this safe? Loading non-.onion subresources means we are potentially leaking information including:
- the .onion domain
- the full top-level .onion URL
- other information about the content of the page
- the list of subresources requested by a .onion page
Leaks might happen by referer, fetch request, query string, etc. (I haven't tested these yet and I'm not sure what leaks happen in practice.) Such leaks would be particularly bad for "stealth" onion sites.
Even worse, some of the non-.onion subresources may leak the onion site's IP address. For example, a .onion website improperly configured may accidentally include URLs pointing to their own server's non-.onion IP address. Loading those subresources leaks the IP address not just to the user but to anyone watching connections outside the Tor network.
While it's true that warnings in Tor Browser's URL bar .onion icons from #23247 (moved) help a little (especially with HTTP subresources), they don't show any warning when onion sites from load non-.onion HTTPS subresources. And a warning icon is actually too late -- the subresource has already been requested by the time a user sees the warning.
So, my question is: should we apply a more strict blocking rule? Possible alternative rules could be:
- No non-.onion subresources can be loaded from a .onion site.
- No "active" non-.onion subresources can be loaded from a .onion site.
I guess it depends on how many existing onion sites we break. But my feeling is that allowing mixed content was a mistake for HTTPS sites and we should avoid making the analogous mistake.