On 14 June 2017 at 16:08, Brad Jorsch (Anomie) <bjor...@wikimedia.org>

> 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

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:

    - alec

Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Reply via email to