On 14 June 2017 at 16:08, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
That part reminds me a bit of https://phabricator.wikimedia.org/T156847, which is about outputting different addresses in links for the mobile site versus the desktop site. The same solution might work for both onion links and mobile site links.
This is basically what we did at Facebook; architecture and other tips are published at https://storify.com/AlecMuffett/tor-tips
The only real "gotcha" with such an approach is to only "onionify" links which are in the process of being rendered to go to the user's browser; if your software stack also makes site-internal fetches (eg: for database access) in order to render a page, then onionifying *those* will result in badness.
The other nice thing to bear in mind is that onionification is generally best done with 1:1 mappings between onion addresses and DNS domains, and that consistency is beneficial; in other words:
foo.com <-> aaaa1111.onion bar.com <-> bbbb2222.onion
...and even if you are rendering a page for foo.com/aaaa1111, you'll get a nicer experience by also fixing-up the bar.com/bbbb2222 HREFs, should you happen to generate any.
This is one point where EOTK wins-out, because it operates after-the-fact of content generation & site caching, so has a marginally easier time; the demo EOTK config for a Wikipedia onion currently performs 11 simultaneous mappings, as documented at: https://github.com/alecmuffett/eotk/blob/master/demo.d/wikipedia.tconf
- alec