On 14 June 2017 at 16:08, Brad Jorsch (Anomie) <bjor...@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 _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
