[tor-dev] User perception of onion service discovery

[Alec Muffett]

On 14 October 2017 at 19:43, dawuud <dawuud at riseup.net> wrote:
>
> Plaintext communications intermediaries like tor2web violate the end
> to end principle and the principle of least authority. If we as the
> Tor community are committed to human rights then it follows we would
> abolish terrible things like tor2web or at least frown upon it's use.
>


I would recommend continuing to enable/support Tor2Web, or at least not
moving to make such a solution inoperable.


Dawuud is absolutely right re: violation of E2E* and a bunch of other
criticisms also apply; however I have three observations on this topic:

1) Someone invented Tor2web, therefore someone else is likely to want to
reimplement it; ideas tend to persist in this way

2) (as observed above) Google *do* crawl onion sites via "onion.to", which
is a fun surprise for people who insist that "The Dark Web Is Not Indexed
And Is Therefore Spooky"

3) Making such a move to block Tor2web-like sites might engender false
trust amongst the people who set up Onion sites: "It's Okay, Google Can't
Get At Us"


I would recommend investing more effort in Tor2web/similar, because having
a permeable barrier between IP-Space and OnionSpace appears useful.

At very most I might propose that:

a) OnionSites become aware of the X-Tor2web header which (from legit T2W
instances, at least) permits the OnionSite operator to block or redirect
the user to use a "proper" Onion network connection

b) That TheTorProject consider indexing known Tor2web sites and publish
them, perhaps adding a feature to optionally block them from TorBrowser
access**, thereby to prevent stupid intra-Tor deanonymisation loops

    - a


*although speaking as a geek I believe that re-engineering T2W to support
SSL via SNI-Sniffing would address this, it would be a gross and pointless
hack, complicated still further by certificate issuance, and all reasonable
use cases for which would be better addressed by running a local copy of
Tor.

**the hardcore alternative of blocking them from being accessed by exit
nodes causing a likely-intolerable argument.


-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171015/e72f2eac/attachment-0001.html>