[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Torbutton 1.3.0-alpha: Community Edition!
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Torbutton 1.3.0-alpha: Community Edition!
- From: David Bennett <dbennett455@xxxxxxxxx>
- Date: Fri, 01 Oct 2010 12:32:35 -0500
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Fri, 01 Oct 2010 13:32:53 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Kk6jVA/sgTRyuGmTS03sbR3YlPEAjfEsScM6TmjFluo=; b=LqvG/E55wNzHaNGKXGkRVAbLogdpfpMqOQfCBHUCpTw3gdYlh34b9vE7bShgvKBfhP 0DECEpTUFt3L6rQDbipPsMhNdsHKgfrcDSobnHPN8m+HPQA+Jaf+Pz3Iay2teowLu87q XAwl8xdTTRytBqbJ90NKWY5nTQC+YUMsJjCZk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=u03g8f6yW1jlyFN+0e+IET6JHPNBGm27ThQc9diOyvoasayhF9mJK9AODOfMDn3t7e fe5pgY8IuCdKf9y9Uzfel19INVXLWdQFn2vXS6egMcvpxvKF/T0gA5QebWuEEAHH2UDM zN+y9WyiZ8MpYDh0JOHM5NkxDp7hN2qLAZbBc=
- In-reply-to: <20101001013645.GA15005@xxxxxxxxxxxxxxxxxxx>
- References: <20100930225748.GC13960@xxxxxxxxxx> <20101001013645.GA15005@xxxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7
On 09/30/2010 08:36 PM, Drake Wilson wrote:
>> This release features "tor://" and "tors://" urls that will
>> automatically enable Tor before loading the corresponding http or
>> https url.
> Ick. This sort of layer-mixing is the sort that forces people to use
> a certain protocol for no actual reason.
> Is there a reason not to use something like tor+http and tor+https for
> the schema, thus opening up the space for (as a facetious example)
> tor+nntp or analogous usages later?
Drake is correct, I don't think that scheme transport swap method is a
That being said, the ability to bookmark a site securely is
advantageous. Plus, relative URL's referenced on a host would inherit
I agree that tor+scheme or tor.scheme would be a better nomenclature. It
appears that +, _ and . can be used as separators.
For example: tor.mailto:user@xxxxxxxxxxxxx could use an SMTP anonymizer.
I do understand why it was implemented this way. Scheme stacking would
be much more difficult to pull off given current browser technology. To
the best of my knowledge, there are no browsers that would easily
If you could specify tor.* as a scheme and that scheme would launch tor,
set the proxy in the browser and then reprocess with the rvalue
recursively then this would be feasible However, it would require
non-trivial customization of the browser.
I can think of other uses for this such as blind.http:// that would
launch a non-visual accessibility browser. Then the visually impaired
user could access anonymously using:
Someone needs to write a 'scheme stacking' URI extension RFC.
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/