This would also effect Onionshare’s user hosting anonymity, it would require file hosts to Reveal their identity or there onion address would keep changing. onionshare <https://github.com/micahflee/onionshare> > On Aug 30, 2017, at 10:18 AM, Roger Dingledine <a...@mit.edu> wrote: > > This is a really important point. Thinking of onion space right now as > the sum total of all that it can be is cutting off all of the future > innovation. > > My claim isn't "onion services are 3% of Tor traffic, so don't get > upset about anything you find on an onion service" -- my claim is "onion > services are still very early in terms of adoption, and as is usual for > many decentralized techologies the extra-early adopters are not great use > cases, and that means we need to help the space grow, and as it grows, > if we do it right, it will become more broad and thus more good". > > One concrete example of an onion service that the proposed design would > cut off is Ricochet. Ricochet users want longterm-stable identifiers, > and they want the identifiers to be self-authenticating. And of course > making every Ricochet user register and maintain a domain, plus run a > webserver, is both silly and harmful. > > This example also helps to illustrate why thinking of onion services as > only websites also artificially constrains their future. What if your > smart refridgerator registers an onion address when you first plug it > in, and it's only willing to receive secure updates via that channel, > meaning it has a hugely reduced surface area to attacks? > > As Alec says, the list of "things that could benefit from having a safe > communication channel" is both enormous and open-ended. People like to > use phrases like "dark web" or "dark continent" to evoke mystery and > intrigue, but really, do you want to use the communications channel where > you know for sure that you're talking to the person you meant to talk > to, and you know that it's hard for somebody to eavesdrop on the content > or the metadata? Or do you want to use the communications channel where > you don't know who you're talking to, you don't know who is listening, > and you don't know whether somebody is modifying the traffic? > > Calling onion services the "secure web" and everything else the "insecure > web" isn't very catchy, so maybe we should settle on calling everything > else (the places where you don't know who you're talking to or who's > listening) "dark". :) > > For those following along who haven't watched our 32c3 onion services > talk, you might find it enlightening: > https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think > > <https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think> > (The Defcon talk has a few more details about the next-generation onion > service design, but I'm told the video for it won't be up for another > couple of months.) > > I think finding ways to tie onion addresses to normal ("insecure web") > domains, when a service has both, is really important too. I'd like to > live in a world where Let's Encrypt gives you an onion altname in your > https cert by default, and spins up a Tor client by default to let users > reach your webserver using whichever level of security they prefer. > > And for those who made it this far down the mail, you might enjoy this > historical tor-talk mail too: > https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html > <https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html> > (see the paragraph towards the bottom that starts "I should also make > clear my opinion on some of the bad uses of Tor.")
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
