Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Georg Koppen]

Rusty Bird:
> Georg Koppen:
>> FYI: the proposal is now the first Tor Browser proposal:
>> https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
> 
> Sounds great. One nit:
> 
> | Website operators should be aware that tools like tordnsel have
> | false positive potential (they might treat Tor users as non-Tor users)
> 
> -> "false negative"

Thanks, fixed (with commit 1582a35eb10c20c24bcfd008edea75d2803bbe0e).

Georg



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

> with the exact same
> restrictions and semantics as the Location HTTP header

Maybe that should be 'syntax'?  Semantics would mean that the header
behaves the same way right?  But it doesn't. Location is a prompt-less
redirect, O-L is a prompted redirect.  Additionally, O-L has an
additional restriction that the URI specified must be .onion?

> websites with lots of client traffic are encouraged

Why do we need to encourage them? Aren't they sufficiently motivated
themselves? I would go so far as to suggest they do _not_ do that,
because there is no fully reliable detection mechanism.  But if they
want to, we 'can provide suggestions for them'?

And perhaps one suggestion is to detect User-Agent and only serve it
to one of the five user-agents that support Tor? (Since we discourage
anything else?)  (TB, TBA, Brave, Orfox, OnionBrowser)

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Rusty Bird]

Georg Koppen:
> FYI: the proposal is now the first Tor Browser proposal:
> https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt

Sounds great. One nit:

| Website operators should be aware that tools like tordnsel have
| false positive potential (they might treat Tor users as non-Tor users)

-> "false negative"

Rusty


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Georg Koppen]

George Kadianakis:
> Georg Koppen  writes:
> 
>> [ text/plain ]
>> George Kadianakis:
>>> As discussed in this mailing list and in IRC, I'm posting a subsequent
>>> version of this proposal. Basic improvements:
>>> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
>>> - Does not do auto-redirect; it instead suggests the onion based on
>>>   antonella's mockup: 
>>> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
>>
>> I don't see that or any particular idea of informing the user in the
>> proposal itself, though. I think more about those browser side plans
>> should be specified in it (probably in section 2). Right now you are
>> quite specific about the redirection part and its pro and cons but
>> rather vague on the actual UX improvements (having the header is just
>> half of what you need).
>>
> 
> Hello,
> 
> pushed another commit to the onion-location branch in my repo for
> addressing the concerns in GeKo's email:
>
> https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location=14fc750e3afcd759f4235ab955535a07eed24286

FYI: the proposal is now the first Tor Browser proposal:
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt

Georg



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Iain Learmonth]

Hi,

On 13/07/18 16:24, Tom Ritter wrote:
> Ah, that makes sense. You want /foo.html to serve an Onion-Location
> that goes to /foo.html

Exactly! But I might also want that /foo/bar.html goes to /bar.html on
the onion service while /baz/bar.html goes to /bar.html on another onion
service. Otherwise I don't think we can claim that the Onion-Location
header is similar to the Location header.

> But you're saying you did this manually for each file?  I guess I
> hadn't thought about how I would implement this (for Apache)... http
> -> https redirection is done with mod_write, typically something like

My personal website is currently hosted by Netlify. They allow you to
provide a file that is used to send custom headers on a per-URL basis.

https://www.netlify.com/docs/headers-and-basic-auth/

I've attached the script I'm using for this. It's a manual step in that
I have to run the script. I could probably automate it if I learnt a
little more Hugo.

> I don't mess with Apache/mod_rewrite much, but surely there's a way to
> write out the Onion-Location header with the supplied path/querystring
> automatically?

I would imagine there are ways to configure this, but I don't know what
they are.

> I agree that if a Location header is present, the browser should
> follow it immediately. If the subsequent location has an
> Onion-Location header (and no Location header) then the browser should
> prompt.

This sounds reasonable.

> Location is a non-prompt, non-negotiable redirect.
> Onion-Location is a prompted, user-chosen redirect.
> 
> The only question in my mind is if the user has opted in to always
> following Onion-Location redirects, then the question is: which header
> do you follow? And I would suggest Onion-Location although I don't
> have a strong argument for that choice besides "It's our feature, we
> should give it precedence."

I think in this case, I would prefer to follow the Onion-Location header
first, as the user has chosen to make the usability trade-off for
security by enabling the automatic redirects.

Would it be worthwhile for me to write some text to this effect as a
patch for the proposal document?

Thanks,
Iain.
#!/usr/bin/zsh

hugo

find public | \
grep index.html | \
sed 's/^public//' | \
sed 's/index.html$//' | \
awk '{ print $0 "\n  Onion-Location: 
http://tvin5bvfwew3ldttg5t6ynlif4t53y3mbmb7sgbyud7h5q6gblrpsnyd.onion; $0 }' \
> static/_headers

# Limited compatibility with Healthy Onions add-on
sed -i 's,^  Onion-Location: 
http://tvin5bvfwew3ldttg5t6ynlif4t53y3mbmb7sgbyud7h5q6gblrpsnyd.onion/$,  
Onion-Location: 
http://tvin5bvfwew3ldttg5t6ynlif4t53y3mbmb7sgbyud7h5q6gblrpsnyd.onion,' 
static/_headers


signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 7 July 2018 at 13:07, Iain Learmonth  wrote:
> Hi,
>
> I've had a go at implementing this for my personal blog. Here are some
> things:

Good feedback!

> My personal website is a static site (mostly). In my implementation, I
> took a list of all possible HTML URLs (excluding images, stylesheets,
> etc.) and generated a list of corresponding onion locations.
>
> I figured that being a blog, people often link to individual pages
> instead of just to my homepage (which is probably the least useful page
> on the site). Having the Onion-Location header on every page someone
> could land on gives the best chance that they will discover the onion
> service.

Ah, that makes sense. You want /foo.html to serve an Onion-Location
that goes to /foo.html

But you're saying you did this manually for each file?  I guess I
hadn't thought about how I would implement this (for Apache)... http
-> https redirection is done with mod_write, typically something like

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

I don't mess with Apache/mod_rewrite much, but surely there's a way to
write out the Onion-Location header with the supplied path/querystring
automatically?


> But then I realised that some of the locations I had generated
> Onion-Locations for would also be serving Location headers as they were
> old URLs. What should a browser do in this case? What should an
> implementer do? In my implementation, I've thrown in the Onion-Location
> headers regardless of whether or not a Location header is also present
> because it was easier.

I think that is fine but

> It could be preferable that the redirection is followed after switching
> to the Onion service (i.e. Location header is ignored until user
> responds to the Onion-Location header prompt), but this would mean the
> page wouldn't have loaded before you get the prompt to go to the Onion
> service, which may be confusing for users. Alternatively, if the page
> has a Location header then the Onion-Location header should be ignored.

I agree that if a Location header is present, the browser should
follow it immediately. If the subsequent location has an
Onion-Location header (and no Location header) then the browser should
prompt.

Location is a non-prompt, non-negotiable redirect.
Onion-Location is a prompted, user-chosen redirect.

The only question in my mind is if the user has opted in to always
following Onion-Location redirects, then the question is: which header
do you follow? And I would suggest Onion-Location although I don't
have a strong argument for that choice besides "It's our feature, we
should give it precedence."

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Iain Learmonth]

Hi,

I've had a go at implementing this for my personal blog. Here are some
things:

> We introduce a new HTTP header called "Onion-Location"
> with the exact same restrictions and semantics as the
> Location HTTP header. Websites can use the Onion-Location
> HTTP header to specify their onion counterpart, in the
> same way that they would use the Location header.
>
> Example:
>  Onion-Location: http://vwc43ag5jyewlfgf.onion

This example is perhaps not the best example. I tried to get things
working with the Healthy Onions add-on, but found that the developer had
interpreted this to mean that the Onion-Location value is just a
replacement for the protocol and domain parts of the URL, not a
replacement for the whole URL.

There may not be a 1:1 mapping in the URL space between the two URL
domains. At the very least, I would add a trailing slash (/) to the
example. The Healthy Onions developer seems to expect the string to end
with ".onion".

My personal website is a static site (mostly). In my implementation, I
took a list of all possible HTML URLs (excluding images, stylesheets,
etc.) and generated a list of corresponding onion locations.

I figured that being a blog, people often link to individual pages
instead of just to my homepage (which is probably the least useful page
on the site). Having the Onion-Location header on every page someone
could land on gives the best chance that they will discover the onion
service.

But then I realised that some of the locations I had generated
Onion-Locations for would also be serving Location headers as they were
old URLs. What should a browser do in this case? What should an
implementer do? In my implementation, I've thrown in the Onion-Location
headers regardless of whether or not a Location header is also present
because it was easier.

It could be preferable that the redirection is followed after switching
to the Onion service (i.e. Location header is ignored until user
responds to the Onion-Location header prompt), but this would mean the
page wouldn't have loaded before you get the prompt to go to the Onion
service, which may be confusing for users. Alternatively, if the page
has a Location header then the Onion-Location header should be ignored.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

Georg Koppen  writes:

> [ text/plain ]
> George Kadianakis:
>> As discussed in this mailing list and in IRC, I'm posting a subsequent
>> version of this proposal. Basic improvements:
>> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
>> - Does not do auto-redirect; it instead suggests the onion based on
>>   antonella's mockup: 
>> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
>
> I don't see that or any particular idea of informing the user in the
> proposal itself, though. I think more about those browser side plans
> should be specified in it (probably in section 2). Right now you are
> quite specific about the redirection part and its pro and cons but
> rather vague on the actual UX improvements (having the header is just
> half of what you need).
>

Hello,

pushed another commit to the onion-location branch in my repo for
addressing the concerns in GeKo's email:
   
https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location=14fc750e3afcd759f4235ab955535a07eed24286

I was not sure what other stuff to put in section 2 but please let me
know if you don't feel fullfiled with the current ones!!!

Also, I wiped out the improvements section because i was not sure what
to put there.

As a side thing, I found this extension which does the bottombar part of
this proposal, but it gets the redirection list from a local file
instead of an HTTP header: https://github.com/Someguy123/HiddenEverywhere

Cheers!


>> 
>> 
>> 
>> UX improvement proposal: Onion redirects using Onion-Location HTTP header
>> 
>> 
>> 1. Motivation:
>> 
>>Lots of high-profile websites have onion addresses these days (e.g. Tor ,
>
> Tor,
>
>>NYT, blockchain, ProPublica).  All those websites seem confused on what's
>>the right way to inform their users about their onion addresses. Here are
>>some confusion examples:
>>  a) torproject.org does not even advertise their onion address to Tor 
>> users (!!!)
>>  b) blockchain.info throws an ugly ASCII page to Tor users mentioning 
>> their onion
>> address and completely wrecking the UX (loses URL params, etc.)
>>  c) ProPublica has a "Browse via Tor" section which redirects to the 
>> onion site.
>> 
>>Ideally there would be a consistent way for websites to inform their users
>>about their onion counterpart. This would provide the following positives:
>>  + Tor users would use onions more often. That's important for user
>>education and user perception, and also to partially dispell the 
>> darkweb myth.
>>  + Website operators wouldn't have to come up with ad-hoc ways to 
>> advertise
>>their onion services, which sometimes results in complete breakage of
>>the user experience (particularly with blockchain)
>> 
>>This proposal specifies a simple way forward here that's far from perfect,
>>but can still provide benefits and also improve user-education around 
>> onions
>>so that in the future we could employ more advanced techniques.
>> 
>>Also see Tor ticket #21952 for more discussion on this:
>>   https://trac.torproject.org/projects/tor/ticket/21952
>> 
>> 2. Proposal
>> 
>>We introduce a new HTTP header called "Onion-Location" with the exact same
>>restrictions and semantics as the Location HTTP header. Websites can use 
>> the
>>Onion-Location HTTP header to specify their onion counterpart, in the same
>>way that they would use the Location header.
>> 
>>The Tor Browser intercepts the Onion-Location header (if any) and informs
>>the user of the existense of the onion site, giving them the option to 
>> visit
>
> s/existense/existence/
>
>>it. Tor Browser only does so if the header is served over HTTPS.
>> 
>>Browsers that don't support Tor SHOULD ignore the Onion-Location header.
>> 
>> 3. Improvements
>
> Did you plan to write anything here? I guess there are at least UX
> improvements to the ad-hoc things you mentioned at the beginning of the
> proposal.
>
>> 4. Drawbacks
>> 
>> 4.1. No security/performance benefits
>> 
>>While we could come up with onion redirection proposals that provide
>>security and performance benefits, this proposal does not actually provide
>>any of those.
>> 
>>As a matter of fact, the security remains the same as connecting to normal
>>websites (since we trust its HTTP headers), and the performance gets worse
>
> s/its/their/
>
>>since we first need to connect to the website, get its headers, and then
>>also connect to the onion.
>> 
>>Still _all_ the website approaches mentioned in the "Motivation" section
>>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>>ways to inform users abou their onions. So this simple proposal will still
>
> 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Georg Koppen]

George Kadianakis:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: 
> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png

I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).

> 
> 
> 
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> 
> 
> 1. Motivation:
> 
>Lots of high-profile websites have onion addresses these days (e.g. Tor ,

Tor,

>NYT, blockchain, ProPublica).  All those websites seem confused on what's
>the right way to inform their users about their onion addresses. Here are
>some confusion examples:
>  a) torproject.org does not even advertise their onion address to Tor 
> users (!!!)
>  b) blockchain.info throws an ugly ASCII page to Tor users mentioning 
> their onion
> address and completely wrecking the UX (loses URL params, etc.)
>  c) ProPublica has a "Browse via Tor" section which redirects to the 
> onion site.
> 
>Ideally there would be a consistent way for websites to inform their users
>about their onion counterpart. This would provide the following positives:
>  + Tor users would use onions more often. That's important for user
>education and user perception, and also to partially dispell the 
> darkweb myth.
>  + Website operators wouldn't have to come up with ad-hoc ways to 
> advertise
>their onion services, which sometimes results in complete breakage of
>the user experience (particularly with blockchain)
> 
>This proposal specifies a simple way forward here that's far from perfect,
>but can still provide benefits and also improve user-education around 
> onions
>so that in the future we could employ more advanced techniques.
> 
>Also see Tor ticket #21952 for more discussion on this:
>   https://trac.torproject.org/projects/tor/ticket/21952
> 
> 2. Proposal
> 
>We introduce a new HTTP header called "Onion-Location" with the exact same
>restrictions and semantics as the Location HTTP header. Websites can use 
> the
>Onion-Location HTTP header to specify their onion counterpart, in the same
>way that they would use the Location header.
> 
>The Tor Browser intercepts the Onion-Location header (if any) and informs
>the user of the existense of the onion site, giving them the option to 
> visit

s/existense/existence/

>it. Tor Browser only does so if the header is served over HTTPS.
> 
>Browsers that don't support Tor SHOULD ignore the Onion-Location header.
> 
> 3. Improvements

Did you plan to write anything here? I guess there are at least UX
improvements to the ad-hoc things you mentioned at the beginning of the
proposal.

> 4. Drawbacks
> 
> 4.1. No security/performance benefits
> 
>While we could come up with onion redirection proposals that provide
>security and performance benefits, this proposal does not actually provide
>any of those.
> 
>As a matter of fact, the security remains the same as connecting to normal
>websites (since we trust its HTTP headers), and the performance gets worse

s/its/their/

>since we first need to connect to the website, get its headers, and then
>also connect to the onion.
> 
>Still _all_ the website approaches mentioned in the "Motivation" section
>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>ways to inform users abou their onions. So this simple proposal will still

s/abou/about/

>help those websites and also pave the way forward for future auto-redirect
>techniques.
> 
> 4.2. Defining new HTTP headers is not the best idea
> 
>This proposal defines a new non-standard HTTP header. This is not great
>because it makes Tor into a "special" thing that needs to be supported with
>special headers. However, the fact that it's a new HTTP header that only
>works for Tor is a positive thing since it means that non-Tor browsers will
>just ignore it.
> 
>Furthermore, another drawback is that this HTTP header will increase the
>bandwidth needlessly if it's also served to non-Tor clients. Hence websites
>with lots of client traffic are encouraged to use tools that detect Tor
>users and only serve the header to them (e.g. tordnsel).
> 
> 5. The future
> 
>As previously discussed, this 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 8 December 2017 at 15:48, teor  wrote:
>
> On 9 Dec 2017, at 03:27, Tom Ritter  wrote:
>
>>> We introduce a new HTTP header called "Onion-Location" with the exact same
>>>   restrictions and semantics as the Location HTTP header.
>>
>> For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2
>
> Because this is a non-standard header, does it need to be spelled:
> "X-Onion-Location"?

Nope =)
https://tools.ietf.org/html/rfc6648

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[teor]

On 9 Dec 2017, at 03:27, Tom Ritter  wrote:

>> We introduce a new HTTP header called "Onion-Location" with the exact same
>>   restrictions and semantics as the Location HTTP header.
> 
> For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

Because this is a non-standard header, does it need to be spelled:
"X-Onion-Location"?

T
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 8 December 2017 at 09:06, George Kadianakis  wrote:
> As discussed in this mailing list and in IRC, I'm posting a subsequent
> version of this proposal. Basic improvements:
> - Uses a new custom HTTP header, instead of Alt-Svc or Location.
> - Does not do auto-redirect; it instead suggests the onion based on
>   antonella's mockup: 
> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
>
>
>
> 
> UX improvement proposal: Onion redirects using Onion-Location HTTP header
> 
>
> 1. Motivation:
>
>Lots of high-profile websites have onion addresses these days (e.g. Tor ,
>NYT, blockchain, ProPublica).  All those websites seem confused on what's
>the right way to inform their users about their onion addresses. Here are
>some confusion examples:
>  a) torproject.org does not even advertise their onion address to Tor 
> users (!!!)
>  b) blockchain.info throws an ugly ASCII page to Tor users mentioning 
> their onion
> address and completely wrecking the UX (loses URL params, etc.)
>  c) ProPublica has a "Browse via Tor" section which redirects to the 
> onion site.
>
>Ideally there would be a consistent way for websites to inform their users
>about their onion counterpart. This would provide the following positives:
>  + Tor users would use onions more often. That's important for user
>education and user perception, and also to partially dispell the 
> darkweb myth.
>  + Website operators wouldn't have to come up with ad-hoc ways to 
> advertise
>their onion services, which sometimes results in complete breakage of
>the user experience (particularly with blockchain)
>
>This proposal specifies a simple way forward here that's far from perfect,
>but can still provide benefits and also improve user-education around 
> onions
>so that in the future we could employ more advanced techniques.
>
>Also see Tor ticket #21952 for more discussion on this:
>   https://trac.torproject.org/projects/tor/ticket/21952
>
> 2. Proposal
>
>We introduce a new HTTP header called "Onion-Location" with the exact same
>restrictions and semantics as the Location HTTP header.

For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2

> Websites can use the
>Onion-Location HTTP header to specify their onion counterpart, in the same
>way that they would use the Location header.
>
>The Tor Browser intercepts the Onion-Location header (if any) and informs
>the user of the existense of the onion site, giving them the option to 
> visit
>it. Tor Browser only does so if the header is served over HTTPS.
>
>Browsers that don't support Tor SHOULD ignore the Onion-Location header.
>
> 3. Improvements
>
> 4. Drawbacks
>
> 4.1. No security/performance benefits
>
>While we could come up with onion redirection proposals that provide
>security and performance benefits, this proposal does not actually provide
>any of those.
>
>As a matter of fact, the security remains the same as connecting to normal
>websites (since we trust its HTTP headers), and the performance gets worse
>since we first need to connect to the website, get its headers, and then
>also connect to the onion.

I would specifically call out that the user has provided any
identifying information (cookies) that may be present, as well as
opened themselves to any possible browser-based attack vector served
by the target domain.

>Still _all_ the website approaches mentioned in the "Motivation" section
>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>ways to inform users abou their onions. So this simple proposal will still
>help those websites and also pave the way forward for future auto-redirect
>techniques.
>
> 4.2. Defining new HTTP headers is not the best idea
>
>This proposal defines a new non-standard HTTP header. This is not great
>because it makes Tor into a "special" thing that needs to be supported with
>special headers. However, the fact that it's a new HTTP header that only
>works for Tor is a positive thing since it means that non-Tor browsers will
>just ignore it.
>
>Furthermore, another drawback is that this HTTP header will increase the
>bandwidth needlessly if it's also served to non-Tor clients. Hence websites
>with lots of client traffic are encouraged to use tools that detect Tor
>users and only serve the header to them (e.g. tordnsel).

I would talk about how users could experience false positives and
false negatives if this mechanism is used.



I think it is also worth addressing that this does not stop sysadmins
from (trying to) detect tor users, and send the onion address in the
Location header, thus triggering a non-prompting 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

As discussed in this mailing list and in IRC, I'm posting a subsequent
version of this proposal. Basic improvements:
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
  antonella's mockup: 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png




UX improvement proposal: Onion redirects using Onion-Location HTTP header


1. Motivation:

   Lots of high-profile websites have onion addresses these days (e.g. Tor ,
   NYT, blockchain, ProPublica).  All those websites seem confused on what's
   the right way to inform their users about their onion addresses. Here are
   some confusion examples:
 a) torproject.org does not even advertise their onion address to Tor users 
(!!!)
 b) blockchain.info throws an ugly ASCII page to Tor users mentioning their 
onion
address and completely wrecking the UX (loses URL params, etc.)
 c) ProPublica has a "Browse via Tor" section which redirects to the onion 
site.

   Ideally there would be a consistent way for websites to inform their users
   about their onion counterpart. This would provide the following positives:
 + Tor users would use onions more often. That's important for user
   education and user perception, and also to partially dispell the darkweb 
myth.
 + Website operators wouldn't have to come up with ad-hoc ways to advertise
   their onion services, which sometimes results in complete breakage of
   the user experience (particularly with blockchain)

   This proposal specifies a simple way forward here that's far from perfect,
   but can still provide benefits and also improve user-education around onions
   so that in the future we could employ more advanced techniques.

   Also see Tor ticket #21952 for more discussion on this:
  https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

   We introduce a new HTTP header called "Onion-Location" with the exact same
   restrictions and semantics as the Location HTTP header. Websites can use the
   Onion-Location HTTP header to specify their onion counterpart, in the same
   way that they would use the Location header.

   The Tor Browser intercepts the Onion-Location header (if any) and informs
   the user of the existense of the onion site, giving them the option to visit
   it. Tor Browser only does so if the header is served over HTTPS.

   Browsers that don't support Tor SHOULD ignore the Onion-Location header.

3. Improvements

4. Drawbacks

4.1. No security/performance benefits

   While we could come up with onion redirection proposals that provide
   security and performance benefits, this proposal does not actually provide
   any of those.

   As a matter of fact, the security remains the same as connecting to normal
   websites (since we trust its HTTP headers), and the performance gets worse
   since we first need to connect to the website, get its headers, and then
   also connect to the onion.

   Still _all_ the website approaches mentioned in the "Motivation" section
   suffer from the above drawbacks, and sysadmins still come up with ad-hoc
   ways to inform users abou their onions. So this simple proposal will still
   help those websites and also pave the way forward for future auto-redirect
   techniques.

4.2. Defining new HTTP headers is not the best idea

   This proposal defines a new non-standard HTTP header. This is not great
   because it makes Tor into a "special" thing that needs to be supported with
   special headers. However, the fact that it's a new HTTP header that only
   works for Tor is a positive thing since it means that non-Tor browsers will
   just ignore it.

   Furthermore, another drawback is that this HTTP header will increase the
   bandwidth needlessly if it's also served to non-Tor clients. Hence websites
   with lots of client traffic are encouraged to use tools that detect Tor
   users and only serve the header to them (e.g. tordnsel).

5. The future

   As previously discussed, this is just a simple proposal to introduce the
   redirection concept to people, and also to help some sysadmins who are
   currently coming up with weird ways to inform people about their
   onions. It's not the best way to do this, but it's definitely one of the
   simplest ways.

   In the future we could implement with more advanced auto-redirect proposals 
like:

   a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
  autoredirects for us (performance benefits, and security benefits under 
many
  threat models).

   b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
  by comment:42 in #21952.

   But both of the designs above require non-trivial engineering/policy work
   and would still confuse people. So I think 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

teor  writes:

>> 
>> On 16 Nov 2017, at 00:38, Alec Muffett  wrote:
>> 
>>> I think it's important to point out that a Tor client is never
>>> guaranteed to hold a *definitive* consensus.
>>> 
>> That's why I say "(mostly) definitive" in my text - my feeling is that a 
>> locally-held copy of the consensus to be queried is going to be on average 
>> of far higher quality, completeness, and non-stagnancy than something that 
>> one tries to scrape out of Onionoo every 15 minutes.
>
> Please don't use a consensus or a tor client to check for exits for
> this purpose. It produces significant numbers of false negatives,
> because some exits use other IP addresses for their exit traffic.
>

I'm actually not a fan of Alec's idea, and I agree with you that there
will be a significant number of false negatives, but it might be worth
pointing out that IIUC false negatives are probably not so damaging in
this use case, because it would result in users getting thrown to the
normal website instead of the onion site, because the website didn't
realize they are Tor users. So not much damage done there.

False positives are a bit more damaging for reachability because it
means that the website would throw normal users to the onion website
which would fail, but that's not so likely (except if exit node
operators surf from their exit node, or if an exit node IP is shared to
other people).
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[teor]

> 
> On 16 Nov 2017, at 00:38, Alec Muffett  wrote:
> 
>> I think it's important to point out that a Tor client is never
>> guaranteed to hold a *definitive* consensus.
>> 
> That's why I say "(mostly) definitive" in my text - my feeling is that a 
> locally-held copy of the consensus to be queried is going to be on average of 
> far higher quality, completeness, and non-stagnancy than something that one 
> tries to scrape out of Onionoo every 15 minutes.

Please don't use a consensus or a tor client to check for exits for
this purpose. It produces significant numbers of false negatives,
because some exits use other IP addresses for their exit traffic.

Using Onionoo or TorDNSEL reduces your false negatives, because it
pulls data from Exitmap to populate exit_addresses. (Tor clients do
not pull data from Exitmap, and that data is not in the consensus.)

> On 16 Nov 2017, at 03:03, Tom Ritter  wrote:
> 
> Detecting exit nodes is error prone, as you point out. Some exit nodes
> have their traffic exit a different address than their listening
> port.[1]
> 
> ...
> [1] Hey does Exonerator handle these?

Exonerator uses data from Exitmap, which queries a service through each
exit to discover the address(es) the exit uses to send client requests
to websites.

The list is updated every 24 hours.
So there's really no need to scrape OnionOO every 15 minutes.

>> but now we are discussing weird tor
>> modules that communicate with the Tor daemon to decide whether to
>> redirect clients, so it seems to me like an equally "special" Tor setup
>> for sysadmins.
>> 
> I can see how you would think that, and I would kind-of agree, but at least 
> this would be local and cheap.  Perhaps instead of a magic protocol, it 
> should be a REST API that's embedded in the local Tor daemon?  That would be 
> a really, REALLY common pattern for an enterprise to query.


You can download the set of exit addresses every 24 hours, and write a
small tool that implements a REST API to query it:

https://check.torproject.org/exit-addresses

In fact, you could even adapt the "check" service to your needs, if it
doesn't do what you want already:

https://gitweb.torproject.org/check.git

Is this the kind of JSON reply you would want?

https://check.torproject.org/api/ip

{"IsTor":true,"IP":"176.10.104.243"}

Or for the interactive version, see:

https://check.torproject.org/cgi-bin/TorBulkExitList.py

(And if you supply a destination port, it's more accurate, because it
checks exit policies as well.)

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Philipp Winter]

On Tue, Nov 14, 2017 at 02:51:55PM +0200, George Kadianakis wrote:
> Let me know what you think :)

Section 9.4 in the Alt-Svc draft talks about abusing the header for
tracking.  In particular, a malicious website could give each Tor user
a unique onion domain to track their activity.  That's particularly
problematic if the "persist" flag is used in the Alt-Svc header.

Granted, malicious websites can already do that to an extent by serving
unique onion domains on each page load, but we should still keep this
issue in mind.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

On 15 November 2017 at 05:35, Alec Muffett  wrote:
> Apologies, I am waiting for a train and don't have much bandwidth, so I will
> be brief:
>
> 1) There is no point in issuing  to anyone unless
> they are accessing  via an exit node.
>
> 2) It's inefficient to issue the header upon every web access by every
> person in the world; when the header is only relevant to 1-in-a-few-thousand
> users, you will be imposing extra bandwidth cost upon the remaining
> 99.99...% -- which is unfair to them

Agreed (mostly). I could see use cases where users not accessing a
website via Tor may wish to know an onionsite is available, but they
are also the vast minority.


> 3) Therefore: the header should only be issued to people arriving via an
> exit node.  The means of achieving this are
>
> a) Location
>
> b) Bending Alt-Svc to fit and breaking web standards
>
> c) Creating an entirely new header
>
> 4) Location already works and does the right thing.  Privacy International
> already use this and issue it to people who connect to their .ORG site from
> an Exit Node.
>
> 5) Bending Alt-Svc to fit, is pointless, because Location already works
>
> 6) Creating a new header? Given (4) and (5) above, the only potential
> material benefit of it that I can see would be to "promote Tor branding" -
> and (subjective opinion) this would actually harm the cause of Tor at all
> because it is *special*.
>
> 6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor
> over the past 10 years has pivoted upon "needing special software to
> access", and creating (pardon me) a "special" header to onionify a fetch
> seems to be promoting the weirdness of Tor, again.
>
> The required goal of redirection to the corresponding Onion site does not
> require anything more than a redirect, and - pardon me - but there are
> already 4x different kinds of redirects that are supported by the Location
> header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels
> specially for Tor?


I think there are some additional things to gain by using a new header:

Software that understands the header can handle it differently than
Location. I think the notification bar and the 'Don't redirect me to
the onionsite' options are pretty good UI things we should consider.
They're actually not great UX, but it might be 'doing our part' to try
and not confuse users about trusted browser chrome.[0]

Users who _appear_ to be coming from an exit node but are not using
Tor are not blackholed. How common is this? I've seen reports from
users who do this. If I were in a position to, I would consider having
exit node traffic 'blend into' more general non-exit traffic (like a
university connection) just to make the political statement that "Tor
traffic is internet traffic".

Detecting exit nodes is error prone, as you point out. Some exit nodes
have their traffic exit a different address than their listening
port.[1]


Location is really close to what we need, but it is limited in some
ways. I'm still on the fence.


[0] Except of course that notification bars are themselves spoofable
chrome but lets ignore that for now...
[1] Hey does Exonerator handle these?



On 15 November 2017 at 07:38, Alec Muffett  wrote:
> I can see how you would think that, and I would kind-of agree, but at least
> this would be local and cheap.  Perhaps instead of a magic protocol, it
> should be a REST API that's embedded in the local Tor daemon?  That would be
> a really, REALLY common pattern for an enterprise to query.

This information should already be exposed via the Control Port,
although there would be more work on behalf of the implementer to
parse more information than desired and pare it down to what is
needed.

-tom
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

I think it's important to point out that a Tor client is never
guaranteed to hold a *definitive* consensus.


That's why I say "(mostly) definitive" in my text - my feeling is that a
locally-held copy of the consensus to be queried is going to be on average
of far higher quality, completeness, and non-stagnancy than something that
one tries to scrape out of Onionoo every 15 minutes.

True "definitiveness" can wait. A solution which does not require treading
beyond the local area network for a "good enough" result, is a sufficient
90+% solution :-)


If we were to create "the definitive exit node oracle" we would need a
Tor client that polls the dirauths the second a new consensus comes out,


So let's not do that, then.


Furthermore, you said that enterprises might be spooked out by
tor-specific "special" HTTP headers,


Yes.


but now we are discussing weird tor
modules that communicate with the Tor daemon to decide whether to
redirect clients, so it seems to me like an equally "special" Tor setup
for sysadmins.


I can see how you would think that, and I would kind-of agree, but at least
this would be local and cheap.  Perhaps instead of a magic protocol, it
should be a REST API that's embedded in the local Tor daemon?  That would
be a really, REALLY common pattern for an enterprise to query.

How about that?

- alec
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

Alec Muffett  writes:

> On 15 Nov 2017 12:18, "Iain R. Learmonth"  wrote:
>
> Is this not what TorDNSEL does?
> https://www.torproject.org/projects/tordnsel.html.en
>
>
> Hi Iain!
>

Hey Alec,

thanks for the feedback.

> That certainly sounds like it will give you the answer! But although it
> would give the right kind of answer, it is not what I am asking for.
>
> At the scale of websites like Facebook or the New York Times, a timely
> response is required for the purposes of rendering a page. The benefits of
> solving the problem at "enterprise" scale then trickle down to
> implementations of all sizes.
>
> Speaking as a programmer, it would be delightfully easy to make a DNS query
> and wait for a response to give you an answer... but then you have to send
> the query, wait for propagation, wait for a result, trust the result, debug
> cached versions of the results, leak the fact that all these lookups are
> going on, and so forth.
>
> This all adds adds up to latency and cost, as well as leaking metadata of
> your lookups; plus your local DNS administrator will hate you (cf: doing
> name resolution for every webpage fetch for writing Apache logs, is frowned
> upon.  Better to log the raw IP address and resolve it later if you need.
>
> On the other hand: if you are running a local Tor daemon, a copy of the
> entire consensus is held locally and is (basically) definitive.  You query
> it with near zero lookup latency, you get an instant response with no
> practical lag behind "real time", plus there are no men in the middle, and
> there is no unwanted metadata leakage.
>

I think it's important to point out that a Tor client is never
guaranteed to hold a *definitive* consensus. Currently Tor clients can
stay perfectly happy with a consensus that is up to 3 hours old, even if
they don't fetch the latest one (which gets made every hour).

In general, the Tor network does not have a definitive state at any
point, and different clients/relays can have different states at the
same time.

If we were to create "the definitive exit node oracle" we would need a
Tor client that polls the dirauths the second a new consensus comes out,
and maybe even then there could be desynchs. Perhaps it's worthwhile
doing such a thing, and maybe that's exactly what tordnsel is doing, but
it's something that can bring extra load to the dirauths and should not
be done in many instances.

Furthermore, you said that enterprises might be spooked out by
tor-specific "special" HTTP headers, but now we are discussing weird tor
modules that communicate with the Tor daemon to decide whether to
redirect clients, so it seems to me like an equally "special" Tor setup
for sysadmins.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

On 15 Nov 2017 12:18, "Iain R. Learmonth"  wrote:

Is this not what TorDNSEL does?
https://www.torproject.org/projects/tordnsel.html.en


Hi Iain!

That certainly sounds like it will give you the answer! But although it
would give the right kind of answer, it is not what I am asking for.

At the scale of websites like Facebook or the New York Times, a timely
response is required for the purposes of rendering a page. The benefits of
solving the problem at "enterprise" scale then trickle down to
implementations of all sizes.

Speaking as a programmer, it would be delightfully easy to make a DNS query
and wait for a response to give you an answer... but then you have to send
the query, wait for propagation, wait for a result, trust the result, debug
cached versions of the results, leak the fact that all these lookups are
going on, and so forth.

This all adds adds up to latency and cost, as well as leaking metadata of
your lookups; plus your local DNS administrator will hate you (cf: doing
name resolution for every webpage fetch for writing Apache logs, is frowned
upon.  Better to log the raw IP address and resolve it later if you need.

On the other hand: if you are running a local Tor daemon, a copy of the
entire consensus is held locally and is (basically) definitive.  You query
it with near zero lookup latency, you get an instant response with no
practical lag behind "real time", plus there are no men in the middle, and
there is no unwanted metadata leakage.

If the Tor daemon is on the local machine, then the lookup cost is
near-zero, and - hey! - you are encouraging more people to run more tor
daemons, which (as above) has to be a good thing.

So: the results are very close to what TorDNSEL provides, but what I seek
is something with different and better latency, security, reliability and
privacy qualities than TorDNSEL offers.

- alec
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Iain R. Learmonth]

Hi,

On 15/11/17 11:35, Alec Muffett wrote:
> 8) So, to pass concrete advice on the basis of experience: rather than
> pursue novel headers and reinvent a bunch of established,
> widely-understood web redirection technologies, I would ask that Tor
> focus its efforts instead upon providing a service - perhaps a listener
> service embedded in little-t tor as an enable-able service akin to
> SOCKSListener - which can accept a request from ,
> receive an newline-terminated IP address, and return a set of flags
> associated with that IP (exit node, relay, whatever) - or "none" where
> the IP is not part of the tor network.  Riff on this protocol as you see
> fit.

Is this not what TorDNSEL does?

https://www.torproject.org/projects/tordnsel.html.en

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

Apologies, I am waiting for a train and don't have much bandwidth, so I
will be brief:

1) There is no point in issuing  to anyone unless
they are accessing  via an exit node.

2) It's inefficient to issue the header upon every web access by every
person in the world; when the header is only relevant to
1-in-a-few-thousand users, you will be imposing extra bandwidth cost upon
the remaining 99.99...% -- which is unfair to them

3) Therefore: the header should only be issued to people arriving via an
exit node.  The means of achieving this are

a) Location

b) Bending Alt-Svc to fit and breaking web standards

c) Creating an entirely new header

4) Location already works and does the right thing.  Privacy International
already use this and issue it to people who connect to their .ORG site from
an Exit Node.

5) Bending Alt-Svc to fit, is pointless, because Location already works

6) Creating a new header? Given (4) and (5) above, the only potential
material benefit of it that I can see would be to "promote Tor branding" -
and (subjective opinion) this would actually harm the cause of Tor at all
because it is *special*.

6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor
over the past 10 years has pivoted upon "needing special software to
access", and creating (pardon me) a "special" header to onionify a fetch
seems to be promoting the weirdness of Tor, again.

The required goal of redirection to the corresponding Onion site does not
require anything more than a redirect, and - pardon me - but there are
already 4x different kinds of redirects that are supported by the Location
header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels
specially for Tor?

7) Story: when I was implementing the Facebook onion, I built infra to
support such (eventual) redirection and/or exit-node-usage tracking. Hit "
facebook.com/si/proxy/" from Tor/NonTor to see it in action. The most
challenging thing for me was to get a reliable and cheap way to look-up,
locally, quickly, cheaply and reliably, whether a given IP address
corresponded to an exit node. The closest that I could get to that idea was
to scrape Onionoo every so often and to cache the results into a
distributed, almost-memcache-like table for the entire site. ie: squillions
of machines. This mechanism suffers from all the obvious flaws, notably
Onionoo crashes and/or "lag" behind the state of the consensus.

8) So, to pass concrete advice on the basis of experience: rather than
pursue novel headers and reinvent a bunch of established, widely-understood
web redirection technologies, I would ask that Tor focus its efforts
instead upon providing a service - perhaps a listener service embedded in
little-t tor as an enable-able service akin to SOCKSListener - which can
accept a request from , receive an newline-terminated IP
address, and return a set of flags associated with that IP (exit node,
relay, whatever) - or "none" where the IP is not part of the tor network.
Riff on this protocol as you see fit.

This would mean more people running more tor daemons in more datacentres
(and possibly configuring some of them as relays) - using this lookup
service to establish quickly whether $CLIENT_ADDR is an exit node or not,
and whether it should be issued "308 Permanent Redirect With Same Method"

I think this is a better goal for Tor to be pursuing.  What do you think?

- alec
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

Tom Ritter  writes:

> I am a big proponent of websites advertising .onions in their Alt-Srv.
>
>> 4.2. No security/performance benefits
>>
>>While we could come up with auto-redirect proposals that provide security
>>and performance benefits, this proposal does not actually provide any of
>>those.
>>
>>As a matter of fact, the security remains the same as connecting to normal
>>websites (since we trust its HTTP headers), and the performance gets worse
>>since we first need to connect to the website, get its headers, and then
>>also connect to the onion.
>>
>>Still _all_ the website approaches mentioned in the "Motivation" section
>>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>>ways to inform users abou their onions. So this simple proposal will still
>>help those websites and also pave the way forward for future auto-redirect
>>techniques.
>
> I envision a future Onion Everywhere extension like HTTPS Everywhere
> that works similar to the HSTS preload list. Crawlers validate a
> websites intention to be in the Onion Everywhere extension, and we
> cache the Alt-Srv information so it is used on first load.
>

Yep, that's yet another cool way to do this. 

>
>> 4.3. Alt-Svc does not do exactly what we want
>>
>>I read in a blog post [*] that using Alt-Svc header "doesn’t change the 
>> URL
>>in the location bar, document.location or any other indication of where 
>> the
>>resource is; this is a “layer below” the URL.". IIUC, this is not exactly
>>what we want because users will not notice the onion address, they will 
>> not
>>get the user education part of the proposal and their connection will 
>> still
>>be slowed down.
>>
>>I think we could perhaps change this in Tor Browser so that it rewrites 
>> the
>>onion address to make it clear to people that they are now surfing the
>>onionspace.
>>
>>[*]: https://www.mnot.net/blog/2016/03/09/alt-svc
>
>
> I am a big opponent of changing the semantics of Alt-Srv.
>
> We'd have to change the semantics to only do redirection for onion
> domains. We'd also have to figure out how to handle cases where the
> onion lives alongside non-onion (which takes precedence?) We'd also
> have to maintain and carry this patch ourselves because it's pretty
> antithetical to the very intent of the header and I doubt the
> networking team at Mozilla would be interested in maintaining it.
>
> Besides those issues, it also eliminates Alt-Srv as a working option
> to something *else* websites may want: to silently redirect users to
> their .onion _without_ the possibility of confusion for the user by
> changing the address bar. I think Alt-Srv is an option for partial
> petname support in TB.
>
> There is a perfectly functioning mechanism for redirecting users: the
> Location header. It does a lot of what you want: including temporary
> or persistent redirects, updating the addess bar. Obviously it doesn't
> work for all users, most don't know what .onion is, so Facebook isn't
> going to deploy a .onion Location redirect even if they attempted to
> detect TB users.
>
> But they could send a new Onion-Redirect header that is recognized and
> processed (with a notification bar) by any UA that supports Tor and
> wants to implement it. This header would have a viable path to uplift,
> support in extensions, and even standardization. Onion Everywhere can
> preload these headers too.
>

Agreed, the semantics of Alt-Svc are not what we want, and it's probably
not a good idea to change it from an engineering/policy perspective.

Establishing our own header, with the same semantics as Location, seems
to be a cleaner way to approach this.

When I find some time (hopefully this or next week) I will fix up the
proposal based on received feedback.

>
> On 14 November 2017 at 11:25, teor  wrote:
>>> 4. Drawbacks
>>
>> You missed the biggest one:
>>
>> If the onion site is down, the user will be redirected to the downed site.
>> (I've used onion site redirects with this issue, it's really annoying.)
>> Similarly, if a feature is broken on the onion site, the user will be
>> redirected to a site they can't use.
>>
>> Or if the user simply wants to use the non-onion site for some reason
>> (maybe they want a link they can share with their non-onion friends,
>> or maybe they don't want to reveal they're using Tor Browser).
>>
>> Users *must* have a way to disable the redirect on every redirect.
>
> Right now, I don't agree with this. (I reserve the right to change my
> mind.) Websites can already redirect users to broken links through
> mistakes. Why is "my onion site is not running" a scenario we want to
> code around but "my subdomain is not running" is not? If a website
> wants to redirect users they should be responsible enough to monitor
> the uptime of their onion domain and keep it running.  Maybe we need
> better tooling for that, but that's 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Tom Ritter]

I am a big proponent of websites advertising .onions in their Alt-Srv.


On 14 November 2017 at 06:51, George Kadianakis  wrote:
> 3.1. User education through notifications
>
>To minimize the probability of users freaking out about auto-redirects Tor
>Browser could inform the user that the auto-redirect is happening. This
>could happen with a small notification bar [*] below the URL bar informing
>users that "Tor Browser is auto-redirecting you to the secure onion site".
>
>The notification bar could also have a question mark button that provides
>the user with additional information on the merits of onion sites and why
>they should like them.
>
>[*]: like this one: 
> http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg


I think this is a good idea, and would be the best place to put the
"Never show me this again" option.

> 4.2. No security/performance benefits
>
>While we could come up with auto-redirect proposals that provide security
>and performance benefits, this proposal does not actually provide any of
>those.
>
>As a matter of fact, the security remains the same as connecting to normal
>websites (since we trust its HTTP headers), and the performance gets worse
>since we first need to connect to the website, get its headers, and then
>also connect to the onion.
>
>Still _all_ the website approaches mentioned in the "Motivation" section
>suffer from the above drawbacks, and sysadmins still come up with ad-hoc
>ways to inform users abou their onions. So this simple proposal will still
>help those websites and also pave the way forward for future auto-redirect
>techniques.

I envision a future Onion Everywhere extension like HTTPS Everywhere
that works similar to the HSTS preload list. Crawlers validate a
websites intention to be in the Onion Everywhere extension, and we
cache the Alt-Srv information so it is used on first load.


> 4.3. Alt-Svc does not do exactly what we want
>
>I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
>in the location bar, document.location or any other indication of where the
>resource is; this is a “layer below” the URL.". IIUC, this is not exactly
>what we want because users will not notice the onion address, they will not
>get the user education part of the proposal and their connection will still
>be slowed down.
>
>I think we could perhaps change this in Tor Browser so that it rewrites the
>onion address to make it clear to people that they are now surfing the
>onionspace.
>
>[*]: https://www.mnot.net/blog/2016/03/09/alt-svc


I am a big opponent of changing the semantics of Alt-Srv.

We'd have to change the semantics to only do redirection for onion
domains. We'd also have to figure out how to handle cases where the
onion lives alongside non-onion (which takes precedence?) We'd also
have to maintain and carry this patch ourselves because it's pretty
antithetical to the very intent of the header and I doubt the
networking team at Mozilla would be interested in maintaining it.

Besides those issues, it also eliminates Alt-Srv as a working option
to something *else* websites may want: to silently redirect users to
their .onion _without_ the possibility of confusion for the user by
changing the address bar. I think Alt-Srv is an option for partial
petname support in TB.

There is a perfectly functioning mechanism for redirecting users: the
Location header. It does a lot of what you want: including temporary
or persistent redirects, updating the addess bar. Obviously it doesn't
work for all users, most don't know what .onion is, so Facebook isn't
going to deploy a .onion Location redirect even if they attempted to
detect TB users.

But they could send a new Onion-Redirect header that is recognized and
processed (with a notification bar) by any UA that supports Tor and
wants to implement it. This header would have a viable path to uplift,
support in extensions, and even standardization. Onion Everywhere can
preload these headers too.



On 14 November 2017 at 11:25, teor  wrote:
>> 4. Drawbacks
>
> You missed the biggest one:
>
> If the onion site is down, the user will be redirected to the downed site.
> (I've used onion site redirects with this issue, it's really annoying.)
> Similarly, if a feature is broken on the onion site, the user will be
> redirected to a site they can't use.
>
> Or if the user simply wants to use the non-onion site for some reason
> (maybe they want a link they can share with their non-onion friends,
> or maybe they don't want to reveal they're using Tor Browser).
>
> Users *must* have a way to disable the redirect on every redirect.

Right now, I don't agree with this. (I reserve the right to change my
mind.) Websites can already redirect users to broken links through
mistakes. Why is "my onion site is not running" a scenario we want to

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[teor]

> On 14 Nov 2017, at 23:51, George Kadianakis  wrote:
> 
> 3.2. Auto-redirects too intrusive? Make them optional.
> 
>   If we think that auto redirects are too intrusive, we should consider making
>   them optional, or letting the website specify the desired behavior.
> 
>   If a website wants to specify an onion address but doesn't like
>   auto-redirects, it could specify that as part of Alt-Svc and we could still
>   inform the user that an onion is available using a notification bar again.

Inform the user that the onion address is available.

Make the default behaviour *not* to redirect (it's not faster, it's not more 
secure, and it's surprising). But I'd be willing to compromise here, by
letting the site specify an initial default, and having the Tor Browser default
be whatever.

 Let *the user* control the behaviour via the notification bar, and maybe
allow them to set a session default.
(This won't be persistent, for disk leak reasons.)

> 4. Drawbacks

You missed the biggest one:

If the onion site is down, the user will be redirected to the downed site.
(I've used onion site redirects with this issue, it's really annoying.)
Similarly, if a feature is broken on the onion site, the user will be
redirected to a site they can't use.

Or if the user simply wants to use the non-onion site for some reason
(maybe they want a link they can share with their non-onion friends,
or maybe they don't want to reveal they're using Tor Browser).

Users *must* have a way to disable the redirect on every redirect.

T

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis]

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header


1. Motivation:

   Lots of high-profile websites have onion addresses these days (e.g. Tor ,
   NYT, blockchain, ProPublica).  All those websites seem confused on what's
   the right way to inform their users about their onion addresses. Here are
   some confusion examples:
 a) torproject.org does not even advertise their onion address to Tor users 
(!!!)
 b) blockchain.info throws an ugly ASCII page to Tor users mentioning their 
onion
address and completely wrecking the UX (loses URL params, etc.)
 c) ProPublica has a "Browse via Tor" section which redirects to the onion 
site.

   Ideally there would be a consistent way for websites to inform their users
   about their onion counterpart. This would provide the following positives:
 + Tor users would use onions more often. That's important for user
   education and user perception, and also to partially dispell the darkweb 
myth.
 + Website operators wouldn't have to come up with ad-hoc ways to advertise
   their onion services, which sometimes results in complete breakage of
   the user experience (particularly with blockchain)

   This proposal specifies a simple way forward here that's far from perfect,
   but can still provide benefits and also improve user-education around onions
   so that in the future we could employ more advanced techniques.

   Also see Tor ticket #21952 for more discussion on this:
  https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

   Websites use the Alt-Svc HTTP header to specify their onion counterpart:
 http://httpwg.org/http-extensions/alt-svc.html

   The Tor Browser intercepts that header (if any) and auto-redirects the user
   to the onion site. Tor Browser only does so if the header is served over 
HTTPS.

   (That's it.)

3. Improvements

3.1. User education through notifications

   To minimize the probability of users freaking out about auto-redirects Tor
   Browser could inform the user that the auto-redirect is happening. This
   could happen with a small notification bar [*] below the URL bar informing
   users that "Tor Browser is auto-redirecting you to the secure onion site".

   The notification bar could also have a question mark button that provides
   the user with additional information on the merits of onion sites and why
   they should like them.

   [*]: like this one: 
http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg

3.2. Auto-redirects too intrusive? Make them optional.

   If we think that auto redirects are too intrusive, we should consider making
   them optional, or letting the website specify the desired behavior.

   If a website wants to specify an onion address but doesn't like
   auto-redirects, it could specify that as part of Alt-Svc and we could still
   inform the user that an onion is available using a notification bar again.

4. Drawbacks

   This proposal is far from the perfect solution of course. Here are a few
   reasons why:

4.1. Auto-redirects are scary

   Novice users or paranoid users might freak out with auto-redirects since
   it's unexpected. They might think they are under attack or they got hacked.

   An argument against that is that we are already using HTTPS-everywhere which
   is basically a redirection layer, and while its redirection technique is
   simpler, sometimes the derivative URL is not similar to the original URL,
   and we still don't see people freaking out. I think that's because people
   trust Tor Browser to do the right thing. Combining this knowledge with
   section 3.1 might solve this problem.

4.2. No security/performance benefits

   While we could come up with auto-redirect proposals that provide security
   and performance benefits, this proposal does not actually provide any of
   those.

   As a matter of fact, the security remains the same as connecting to normal
   websites (since we trust its HTTP headers), and the performance gets worse
   since we first need to connect to the website, get its headers, and then
   also connect to the onion.

   Still _all_ the website approaches mentioned in the "Motivation" section
   suffer from the above drawbacks, and sysadmins still come up with ad-hoc
   ways to inform users abou their onions. So this simple proposal will still
   help those websites and also pave the way forward for future auto-redirect
   techniques.

4.3. Alt-Svc does not do exactly what we want

   I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
   in the location bar, document.location or any other indication of where the
   resource is; this is a “layer below” the URL.". IIUC, this is not exactly
   what we want because users will not notice the onion address, they will not
   get the user education part of the proposal and their connection will still
   be slowed