On 14 June 2017 at 16:08, Brad Jorsch (Anomie) <bjorsch(a)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
--
http://dropsafe.crypticide.com/aboutalecm