I apologise that my personal opinion and cheery demeanour appears to be extrapolatable into a couple of contrasting strategic positional statements. To put my personal opinion at greater and more clear length: In the context of URI schemes, accessing a Tor onion site (currently) over HTTP or HTTPS is precisely *that* - a fetch of HTML or other content which a HTTP or HTTPS request might typically be used to access - without the client software needing to be adapted for Tor access at "Layer 7". Such a fetch is functionally just a vanilla HTTP/S over an “alternate" transport, the latter generally enabled by a SOCKS proxy or a content-aware VPN. Such fetches currently work, have done so for several years, and have been used by many, many thousands of users, possibly millions. Similarly, ssh://user@someonionaddress.onion is equally an extant and functional SSH request to someonionaddress.onion Equally git://someonionaddress.onion/user/project-name.git would not immediately strike me as needing to be forcibly changed to “onion-git://“ simply because Git is invoked over an "alternate” transport with a “alternate” name resolution. It currently works, so why break it? From this observation, my personal opinion of “the proper scheme for an HTTP/S fetch to an Onion address" is something of a duck-test: TEST: if a fetch looks like HTTP/S and quacks like HTTP/S, then I think that it should likely be given a HTTP/S scheme. Conversely: it’s arguable that schemes like “daap” or “rtsp” are also “HTTP-based”, and that *they* have special schemes, so perhaps fetches from Onion-addresses should “have special schemes” too? I can sympathise with this argument. It makes logical sense. I personally differentiate and resolve this argument in terms of intent, and in terms of client and server-software. “rtsp://” for instance is used for streaming, and requires magic, RTSP-specific headers, and the frontend is something like VLC or iTunes, and the backend requires a special streaming stack. To me, this smells of specialism. Equally: if iTunes incorporates a webview and fetches a bunch of web-content for human consumption, it likely uses a HTTP/S scheme to do so, rather than a specialist “ituneshttps://“ scheme. This smells of specialist software trying to be a "general-purpose browser". So, given these conditions: - if the intent is largely to provide HTML+CSS content to human beings, - if the client software is most likely a well-known browser (tor browser = firefox) operating in its normal mode - …but not necessarily or exclusively a browser… - and if the server software is something like Apache + {Wordpress, Drupal, a bunch of static HTML} …then under these conditions, again, I apply the duck test. I feel that such fetches are HTTP/S and should have that scheme. Hence why I feel that the extant, vanilla HTTP/S schemes are most appropriate for fetching browser content from onion addresses. The other matters, regarding domain name resolution and generic URI syntax, I have already covered at some length. - a *aside: using VLC to RTSP to an Onion address will work just fine when SOCKS (etc) is configured… etc... — Alec Muffett Security Infrastructure Facebook Engineering London |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail