Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mcs):

 * cc: brade, mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mrphs):

 * cc: mrphs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by alecmuffett):

 * cc: alec.muffett@… (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 Another example for what can go wrong with onion addresses is that I found
 many websites which have problems with replacing internal links with the
 onion address, this can have anonymity consequences, I would rather trust
 client-side rules to never allow any clearnet connection to happen

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 Why do I need to trust the DNS and TLS systems so that I can avoid it
 later with the onion address it provides? And hoping each time that I am
 redirected to the genuine onion address

 With client-side rules, you only trust the community once which should
 provide the proofs that the onion addresses are genuine anyway

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 Can I disable server-side redirects when something is wrong with the onion
 address? This happens often and is a major problem

 Client-side redirects gives the control to the user which is a good
 argument

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by ilf):

 cypherpunks: What "safety" properties are you looking for?

 If you visit https://pad.riseup.net, you put some level of trust in DNS,
 TLS (with X.509), and the server itself. But once you connect to it, you
 trust the server to give you the content that you requested and that it is
 autorized to give you.

 We propose to allow that server in that connection to tell you his hidden
 service and redirect you to it. If this can successfully be MITM'd, so can
 the original content. So the attack vector is no different there.

 OTOH, this makes it a lot easier to discover the .onion of a server,
 because clients get it directly from the server itself, not from any third
 entity like plugins or other websites. This minimizes a human attack
 vector like error or wrong information.

 What I would recommend against is a redirect already on cleartext HTTP
 without HTTPS, like http://ev0ke.net/ is currently doing. That's why we
 want to test and discuss this to find and write down best practices.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 How safe are server-side redirects? How can I be sure some capable
 adversary or a malicious exit node didn't redirect me?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by ilf):

 We are aware of the issue. I think the advantages outweigh the occasional
 inconvenience:

 1. We get more users to use onions, because they will use them even when
 they would not know about them.
 2. We get more users to use TBB, because they will use TBB to handle onion
 links. See the real-world example I encountered above.
 3. We circumvent the delegation of trust that is X.509 as much as possible
 in favor of the more direct system of trust that are onions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 I dislike the automatic redirection for tor users (at least if you
 implement it like it is implemented on lists.riseup.net) because it breaks
 links.

 I want to be able to give out a _single_ URL without knowing if this is
 clicked by a Tor user or non-tor user and they should end up all on the
 _same_ content.

 To give you an example with an URL. If you give this URL:
 - http://lists.riseup.net/directory/tech/
 to a tor user, he will be redirected to
 - http://xpgylzydxykgdqyg.onion/www/
 while non-tor users will see the actual intended content
 for tor users the content would be here:
 - http://xpgylzydxykgdqyg.onion/directory/tech/

 So now everytime I send someone a link I have to send two urls one for tor
 users and one for non-tor users since I don't know if the user uses tor or
 not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by ilf):

 Thanks Linda for opening this ticket and everyone for jumping in.
 Unfortunately, I feel we are both a little too quick and merging too many
 things into one.

 So first things first:

 == Let's auto-redirect Tor-Users to Hidden Services! ==

 Some websites already redirect Tor users to their Hidden Services:

 * https://securitywithoutborders.org/
 * https://www.privacyinternational.org/
 * https://lists.riseup.net/
 * https://pad.riseup.net/
 * http://ev0ke.net/

 (We planned to publically document how to do this. And then discuss this
 on tor-users. This ticket surpassed our timeline.)

 == This is awesome ==

 1. Other websites punish Tor users. Let's embrace (and "reward") them.
 2. Discovering onions is hard. Let's make it easier.
 3. Client-side redirects (like https://github.com/chris-barry/darkweb-
 everywhere and #19812) are nice. But server-side redirects are better:
   a. The server knows its onion, the client would have to verify it out-
 of-band or trust someone else.
   b. The server admin '''already''' controls, "what sort of security
 properties they get while connecting to your website", [comment:17 arma].
 We are doing the same thing with redirects to HTTPS, TLS properties,
 logging policies, etc. It's the admins server, afterall.

 == User response ==

 Most users didn't freak out. We now have hundreds of users and most don't
 provide feedback. (Like always.)

 Some users do provide feedback, and most say they like it. (Like me.)

 As [comment:16 micah] said, there was only '''one''' user that ran an exit
 at his home but didn't use TBB himself. He now does.

 This works the other way around, too. When I shared a .onion address via
 chat, the other user knew what it was, but never bothered to get TBB
 before. To view the URL, they got TBB - and still use it today. I would
 not have shared the onion URL if I hadn't been auto-redirected.

 And there was '''one''' user, who "freaked out" about the redirect. And
 only because that user used TBB, but didn't know what hidden services are.
 This is exactly the kind of person, i '''want''' to get using TBB.

 == Moving foward ==

 The original issue we gave to Linda was the '''one''' user "freaking out"
 about the server-side redirect.

 A rough first idea was: ''"Maybe TBB should inform users about .onion the
 first time they visit one?"''

 From there it evolved into this bigger debate about UX, URL bars, tabs,
 HTTPS, same-origin policy, darkweb everywhere, and more.

 I'm not exactly sure where we move from here.

 1. Maybe a first step would be to discuss, if TBB should do something the
 very first time it visits a .onion.
 2. When we finally got around to documenting the server-side-onion-
 redirect, I propose to discuss that on tor-users.

 Opinions?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arma):

 Replying to [comment:16 micah]:
 > redirect any user that comes from an IP in the above list to the onion
 address

 I've been recommending to websites that they *not* do this.

 First, it breaks your website the people in the case of false positives
 (e.g. where an apartment building has one IP address and one exit relay).

 But more importantly, it should be up to the users what sort of security
 properties they get while connecting to your website, and you're taking
 away their choice. Privacy is about control and choice -- putting up a
 little dynamic section of the page that says "Hey, did you know we have an
 onion address?" is great, but sending them somewhere else based on their
 IP address seems like a slippery slope.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by micah):

 Right now, the current way that Riseup is doing this is the first one that
 asn enumerates:

 1. 1/hr cronjob that downloads the current exit list
 2. leaning on apache/nginx geoip modules to webserver redirect any user
 that comes from an IP in the above list to the onion address

 This works fairly well, I have reasonable ways to do it in apache and
 nginx. This was the mechanism that ilf and I were developing and were
 wanting to document and promote more to get onion operators to do, rather
 than trying to do this tor mapping thing.

 There are a couple cases where it doesn't work perfectly that I've run
 into:

 1. One user who runs an exit node on their home network router, NATing all
 their connections through that same IP, but does not run TBB, was unhappy
 that they were redirected to .onion sites because they didn't want to use
 TBB all the time. This was a bit of a rare case. The user agreed to try to
 use TBB instead in the future, but also was willing to provide me his
 relay FP so I could remove it from the redirect rules.

 2. One user who was concerned about the redirection, thought they had been
 hacked and were being redirected to a nefarious site.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by guido):

 * cc: guido@… (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by micah):

 * cc: hacim (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by asn):

 Hey Linda. Thanks for thinking about this problem.

 FWIW, I definitely find this idea quite compelling and I think it's well
 motivated. That said, I feel that Roger raised some very good points in
 comment:4. e.g. what happens when a user uses onion+HTTPS which seems like
 it's not currently handled by the mockups above.

 And then of course there is the question of how are those ''automatic
 redirects'' caused?

 - Does this proposal apply only to clearnet sites that actually do an
 HTTPS 302 redirect to an onion site? This rarely happens right now.

 - Or does this proposal assume that there is some out-of-scope mechanism
 that does automatic redirects from clearnet to onion sites (like Roger's
 (b), or the various ideas from our [https://blog.torproject.org/blog
 /cooking-onions-names-your-onions recent blog post]? WRT Roger's (b) idea,
 I definitely echo that the Tor Project should not be responsible for
 mapping names to onions: I think that's a huge rabbithole of sadness that
 should probably be handled by a third-party organization (e.g. EFF) or as
 a community project (e.g. we include darkweb-everywhere in TBB, like we do
 for https-everywhere).

 Anyhow I will not complicate this thread further with more doubts and
 edge-cases, as there are various open questions here already.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by blockflare):

 My modest suggestion: If such a redirect proposal is implemented, instead
 of scaring the user with such unexpected behavior, make it optional, and
 ask the user with a dialog when he first installs the Tor Browser to
 choose whether he wants to be automatically redirected to some onion
 services or not (additionally with some non-technical information on what
 they are and their security benefits).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by tokotoko):

 * cc: fdsfgs@… (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 My suggestion as a long time user of these rules:

 It should be easy to disable/revert the redirection for times when the
 onion address is down or doesn't provide the same functionality as the
 clearnet one, for example trac.torproject.org onion mirror doesn't allow
 logging in

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by gk):

 #8686 has already had some discussion about the UX in the URL bar.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by gk):

 #19812 is at least related.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 If it will be useful here is my collection of 290 clearnet to onion rules.
 It is the personal continuation of "darkweb-everywhere" but does not
 include the proofs. Most of them are official mirrors, some addresses are
 unofficial but useful mirrors, obvious or potential scam websites were not
 added. To use them, just copy the rules to the HTTPSEverywhereUserRules
 folder inside your Tor Browser profile. Since the goal was just to collect
 all such addresses, I didn't bother with cleaning obsolete rules.
 Nevertheless it is up to date and contains most of the major websites that
 has onion addresses. But Facebook is turned off by default since that
 would make the user fingerprintable, is there a way to use the redirection
 only if the person visits facebook.com?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arma):

 Replying to [comment:4 arma]:
 > C) The browser has a bunch of built-in defenses, under the broad term
 "cross site something"

 Yawning helpfully supplies the phrase "same-origin policy".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by arma):

 * cc: arma (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arma):

 Three thoughts:

 A) If I'm using onion *and* https, I want some visual way to learn that.
 That's because an https cert for an onion site, especially if it's an EV
 cert, probably means that I can be more assured that I'm really on the
 site I meant to be on. In particular, if you replace the https lock icon
 with the onion one, then it could be harder for me to know whether I have
 the https layer too.

 B) I think the UX part might need to depend on how exactly we're choosing
 to do the redirects. Do we have a local database, a la httpseverywhere,
 that has a mapping for us? And when we type in foo.com, it auto rewrites
 it to foo.onion? In that case, I think it is a really compelling idea to
 have the browser tab display "foo.com" for us when we're at the site that
 it "knows" is foo.onion. We could even do that swap if the user went
 directly to foo.onion, since we can look it up to see that we should
 display foo.com. But in this case, we should also have a good plan for how
 to handle the case where the user is on an onion address that isn't in our
 rewrite table. I guess we put the cool blue onion label in the url tab,
 but leave the address alone (as xyz.onion)? Does that create a world where
 we have first tier onions and second tier onions, and users learn to
 mistrust second tier onions? Is that a feature or a bug?

 Shipping such a table with Tor Browser means more centralization of the
 naming system. Especially if users trust sites in the table more than
 sites not in the table, we're going to see pressure from various folks to
 get their onion address added to the list. Do we add the particular
 sketchy sites, or do we opt not to, effectively censoring them? How about
 when some government agency comes to us asking us to remove one of the
 entries?

 Maybe there are other approaches to helping users do the rewrite that
 don't suffer from the centralization / central point of intervention
 issues above. See e.g. the proposals for having CAs include both foo.com
 and an altname of foo.onion in the same https cert, to effectively bind
 the names together.

 C) The browser has a bunch of built-in defenses, under the broad term
 "cross site something", which aim to provide isolation of cookies,
 javascript, etc between domains. These defenses are often keyed off of
 what's written in the url bar. So we should have some smart browser people
 think through whether we would be undermining these defenses with this
 change. (Alternatively, maybe we can get away with not changing what the
 browser thinks is in the url bar, but just changing how it's displayed to
 the user.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 > From my observation, people don't mind automatically being redirected to
 https sites from http sites, but freak out when redirected from an
 http/https site to an onion site. I don't think that this is because
 people know what https is and find the idea comforting (although this can
 help).

 Have you tested the opposite, whether users notice anything different
 about a downgrade attack when they're being redirected from https to http?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by linda):

 Hey asn and dgoulet: I'd love to hear your thoughts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Description changed by linda:

Old description:

> ilf is experimenting with automatically redirecting Tor users to .onion
> versions of websites that they visit (because they want more people to
> visit onion sites and they will do so if it is painless to them). But
> when users were redirected automatically to an onion site, they freaked
> out about it because they didn't know what happened, didn't know what
> onion sites were, and the "https" was dropped.
>
> asn and dgoulet also were trying to find a solution to make onion sites
> more accessible to use. Specifically, onion addresses are quite long and
> random-ish, making them hard to remember and hard to type. There were
> many solutions discussed casually to try and resolve this, but none stood
> out as a clear winner.
>
> I like the idea of redirecting users to .onion sites automatically when
> they type in the websites non-onion address. This way, users don't need
> to remember anything else, need to type in anything long, or really even
> know what onion sites are.
>
> My suggestion is to follow the https design pattern, and create a similar
> indicator for .onion sites.
>

>
> The proposed solution would be this: when a user types in a website
> (pad.riseup.net), they would automatically be redirected to the onion
> site. When this happens, there would be an onion icon next to the address
> bar (replacing the https lock icon if there is one, or just being there
> an https lock icon would be if redirection from an http website), similar
> to that of the https lock icon. The address in the address bar can turned
> a different color or indicated in some way that this is an alias for the
> onion site.
>
> From my observation, people don't mind automatically being redirected to
> https sites from http sites, but freak out when redirected from an
> http/https site to an onion site. I don't think that this is because
> people know what https is and find the idea comforting (although this can
> help). I speculate that they don't mind because they don't notice, and
> the reason why users freaked out at the redirect to onion sites is that
> they saw the website address visibly change in the address bar.
>
> If we want to show users the address of the onion site, we can
> additionally have a feature to reveal the onion site when the user clicks
> in the address bar. But I don't know how I feel about this, since it may
> just be confusing, and just shock the user later. Users don't know that
> pad.riseup.net resolves to some numerical IP address, and that isn't
> displayed to users. So there could be an argument made for just
> indicating that the address is an alisas and not ever showing the .onion
> address, either. This will confuse way less of the general population.

New description:

 ilf is experimenting with automatically redirecting Tor users to .onion
 versions of websites that they visit (because they want more people to
 visit onion sites and they will do so if it is painless to them). But when
 users were redirected automatically to an onion site, they freaked out
 about it because they didn't know what happened, didn't know what onion
 sites were, and the "https" was dropped.

 asn and dgoulet also were trying to find a solution to make onion sites
 more accessible to use. Specifically, onion addresses are quite long and
 random-ish, making them hard to remember and hard to type. There were many
 solutions discussed casually to try and resolve this, but none stood out
 as a clear winner.

 I like the idea of redirecting users to .onion sites automatically when
 they type in the websites non-onion address. This way, users don't need to
 remember anything else, need to type in anything long, or really even know
 what onion sites are.

 My suggestion is to follow the https design pattern, and create a similar
 indicator for .onion sites.

 [[Image(onion-address-idea.png,600px)]]

 The proposed solution would be this: when a user types in a website
 (pad.riseup.net), they would automatically be redirected to the onion
 site. When this happens, there would be an onion icon next to the address
 bar (replacing the https lock icon if there is one, or just being there an
 https lock icon would be if redirection from an http website), similar to
 that of the https lock icon. The address in the address bar can turned a
 different color or indicated in some way that this is an alias