Delivery-Date: Sun, 17 May 2015 15:12:14 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 8FFB61E0CC9
	for <archiver@seul.org>; Sun, 17 May 2015 15:12:12 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B0F9A350E3;
	Sun, 17 May 2015 19:12:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 591FC350B1
 for <tor-talk@lists.torproject.org>; Sun, 17 May 2015 19:12:05 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ja6gVWwodvmp for <tor-talk@lists.torproject.org>;
 Sun, 17 May 2015 19:12:05 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 324E034924
 for <tor-talk@lists.torproject.org>; Sun, 17 May 2015 19:12:05 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 071661E0CC9; Sun, 17 May 2015 15:12:01 -0400 (EDT)
Date: Sun, 17 May 2015 15:12:01 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20150517191201.GG7800@moria.seul.org>
References: <20150517112641-728-3379-mailpile@mailpile-home>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20150517112641-728-3379-mailpile@mailpile-home>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Making a Site Available as both a Hidden Service and
 on the www - thoughts?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Sun, May 17, 2015 at 11:26:41AM -0000, Ben wrote:
> I've got a (www) site that I'm debating making available as a Hidden
> Service, and I was wondering what peoples thinking on doing this was
> nowadays.

Hi Ben!

Great list of topics. For your first one, I'll paste my paragraph from
the earlier tor-talk thread that included this topic:

"""
I've also been talking to EFF about kicking off a Tor Onion Challenge
(to follow on from their Tor Relay Challenges), to a) get many people
to make their website or other service accessible as an onion site,
and b) come up with and/or build a novel use of onion services, to go
with the quite cool list that we have already but have done a poor job
of publicizing: Pond, Globaleaks, SecureDrop, Ricochet, OnionShare,
facebook's https onion, etc. You see, I used to be on the "making your
normal website reachable as an onion service is stupid" side of the fence,
but I have since come to realize that I was wrong. You know how, ten
years ago, website operators would say "I don't need to offer https for
my site, because my users ____" and they'd have some plausible-sounding
excuse? And now they sound selfish and short-sighted if they say that,
because everybody knows it should be the choice of the *user* what
security properties she gets when reaching a service? I now think onion
services are exactly in that boat: today we have plenty of people saying
"I don't need to offer a .onion for my site, because my users _____". We
need to turn it around so sites let their *users* decide what security
(encryption, authentication, trust) properties they want to achieve
while interacting with each site.
"""

tl;dr: sounds great!

> So I've been scrawling a few perceived challenges and wondered whether
> anyone can think of anything I've missed (or has suggestions on those I
> haven't?):

Don't forget the "decreasing load and reliance on exit relays" benefit,
in case we arrive in that dismal future where it grows increasingly hard
to operate exit relays in a diverse and well-dispersed set of locations.

--Roger

-- 
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

