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

Re: Torbutton 1.3.0-alpha: Community Edition!

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
great idea. 

That being said, the ability to bookmark a site securely is 
advantageous. Plus, relative URL's referenced on a host would inherit
the scheme.

Based on:


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
support this.

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/