[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Neal Krawetz's abcission proposal, and Tor's reputation

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 <arma@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to