subject:"\[tor\-bugs\] #21952 \[Applications\/Tor Browser\]\: Onion\-location\: increasing the use of onion services through automatic redirects and aliasing"

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202004R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by emmapeel):

 Replying to [comment:138 mcs]:
 > Replying to [comment:136 acat]:
 > > Replying to [comment:133 steph]:
 > >
 > > Thanks, revised the torbutton patch in
 https://github.com/acatarineu/torbutton/commit/21952+2.

 > r=brade,r=mcs
 > These two patches look good to us.

 The strings on this patch look good to 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202004R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:136 acat]:
 > Replying to [comment:133 steph]:
 >
 > Thanks, revised the torbutton patch in
 https://github.com/acatarineu/torbutton/commit/21952+2.
 >
 > Regarding Tor Browser patch, we are going with no-icon for the
 notification, so this should be the right branch:
 https://github.com/acatarineu/tor-browser/commit/21952+8_noicon.

 r=brade,r=mcs
 These two patches look good to us.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202004R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:134 sysrqb]:
 If I'm not wrong, as long as [https://httpwg.org/http-extensions/draft-
 ietf-httpbis-header-structure.html#token sh-token] accepts all URLs (I
 think it does), we should be able to specify the header using
 [https://httpwg.org/http-extensions/draft-ietf-httpbis-header-
 structure.html structured header] spec and preserve backwards
 compatibility.

 For example:
 {{{
 Onion-Location = sh-token parameters
 }}}
 Should accept a URI + optional parameters.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202004R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:133 steph]:

 Thanks, revised the torbutton patch in
 https://github.com/acatarineu/torbutton/commit/21952+2.

 Regarding Tor Browser patch, we are going with no-icon for the
 notification, so this should be the right branch:
 https://github.com/acatarineu/commit/21952+8_noicon.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 acat and I briefly discussed the header format earlier. One piece of
 feedback reminded me that we should use X-Onion-Location, because we are
 not implementing a standardized HTTP header. However, acat pointed me to
 https://tools.ietf.org/html/rfc6648 where `X-*` headers are considered
 deprecated. So, we should think a little harder about the format of the
 value for this field. The `Location` HTTP header is
 [https://tools.ietf.org/html/rfc7231#page-68 defined] as:
 {{{

The "Location" header field is used in some responses to refer to a
specific resource in relation to the response.  The type of
relationship is defined by the combination of request method and
status code semantics.

  Location = URI-reference

The field value consists of a single URI-reference.  When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).

For 201 (Created) responses, the Location value refers to the primary
resource created by the request.  For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for
automatically redirecting the request.

If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the
URI reference used to generate the request target (i.e., the
redirection inherits the original reference's fragment, if any).

For example, a GET request generated for the URI reference
"http://www.example.org/~tim; might result in a 303 (See Other)
response containing the header field:

  Location: /People.html#tim

which suggests that the user agent redirect to
"http://www.example.org/People.html#tim;

Likewise, a GET request generated for the URI reference
"http://www.example.org/index.html#larry; might result in a 301
(Moved Permanently) response containing the header field:

  Location: http://www.example.net/index.html

which suggests that the user agent redirect to
"http://www.example.net/index.html#larry;, preserving the original
fragment identifier.
 }}}

 In the future, we may find it advantageous if we specify `Onion-Location`
 as a [https://httpwg.org/http-extensions/draft-ietf-httpbis-header-
 structure.html structured header] with a backwards compatible format
 matching that of the Location header.

 To be clear, we can use the current implementation and get this into
 Nightly builds, but we should think about this idea before the feature
 moves to Stable.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by steph):

 No, I didn't, thank you!

 So I think this covers it:

 onionLocation.alwaysPrioritize=Always Prioritize Onions
 onionLocation.alwaysPrioritizeAccessKey=a
 onionLocation.notNow=Not Now
 onionLocation.notNowAccessKey=n
 onionLocation.description=There’s a more private and secure version of
 this site available over the Tor network via onion services. Onion
 services help website publishers and their visitors defeat surveillance
 and censorship.
 onionLocation.tryThis=Try Onion Services
 onionLocation.onionAvailable=.onion available
 onionLocation.learnMore=Learn more…
 onionLocation.always=Always
 onionLocation.askEverytime=Ask every time
 onionLocation.prioritizeOnionsDescription=Prioritize .onion sites when
 known.
 onionLocation.onionServicesTitle=Onion Services

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:129 steph]:
 >
 > > @steph @pili @mcs @brade @pospeselr: We are using this text at the
 prompt. Any thought? Let me know if we are ok to reach l10n.
 >
 > How about we mirror with what's on the community page and say:
 >
 > .onion available
 > Try Onion Services
 > There’s a more private and secure version of this site available over
 the Tor network via onion services. Onion services help website publishers
 and their visitors defeat surveillance and censorship.
 > Learn more…
 > Not Now
 > Always Prioritize Onions
 >

 steph: I don't see comments for the strings in `about:preferences`, I'm
 not sure if it's because they are fine as they are, or because you only
 saw the ones in the mockup for the urlbar notification. These should be
 all the strings that are currently in the latest patch:
 {{{
 onionLocation.alwaysPrioritize=Always Prioritize Onionsites
 onionLocation.alwaysPrioritizeAccessKey=a
 onionLocation.notNow=Not Now
 onionLocation.notNowAccessKey=n
 onionLocation.description=Website publishers can protect users by adding a
 security layer. This prevents eavesdroppers from knowing that you are the
 one visiting that website.
 onionLocation.tryThis=Try this: Onionsite
 onionLocation.onionAvailable=Onionsite available
 onionLocation.learnMore=Learn more
 onionLocation.always=Always
 onionLocation.askEverytime=Ask you every time
 onionLocation.prioritizeOnionsDescription=Prioritize onionsites when they
 are available.
 onionLocation.onionServicesTitle=Onion Services
 }}}

 and the screenshots where these appear:
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952_latest_aboutpreferences.png
 and
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/withouticon.png
 (note the latter strings differ from the mockup antonela sent). Perhaps
 you already saw this, but I just wanted to make sure.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "21952_latest_aboutpreferences.png" 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by steph):

 * cc: stephw (removed)
 * cc: steph (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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Thanks, Steph!

 Looks good for 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-30 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by steph):

 > @steph @pili @mcs @brade @pospeselr: We are using this text at the
 prompt. Any thought? Let me know if we are ok to reach l10n.

 How about we mirror with what's on the community page and say:

 .onion available
 Try Onion Services
 There’s a more private and secure version of this site available over the
 Tor network via onion services. Onion services help visitors and
 publishers defeat surveillance and censorship.
 Learn more…
 Not Now
 Always Prioritize 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-27 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  11.5 => 11.6


Comment:

 I forgot to address antonela's review comment, to remove the left margin
 of the doorhanger. That is actually a space that is reserved for an icon,
 since it was easy apart from removing the space I also tried adding an
 icon, just in case you prefer the version with the icon to the other one.
 This is a screenshot with icon and this is without.

 I also modified the icon that pospeselr attached, since it was not being
 displayed (and I had not tested it). I added `width` and `height`
 properties, so I assume those were missing.

 Branch with icon: https://github.com/acatarineu/commit/21952+8_icon
 (https://trac.torproject.org/projects/tor/attachment/ticket/21952/withicon.png)

 Branch without: https://github.com/acatarineu/commit/21952+8_noicon
 
(https://trac.torproject.org/projects/tor/attachment/ticket/21952/withouticon.png)

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-27 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "withouticon.png" 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-27 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "withicon.png" 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-26 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Thanks for the review, I added the icon you attached in
 https://github.com/acatarineu/tor-browser/commit/21952+7.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-25 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 I attached a version of the icon that is stripped down a bit:
 https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/21952/onionlocation.svg

 Apart from that this looks good to 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-25 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by pospeselr):

 * Attachment "onionlocation.svg" 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-24 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:117 acat]:
 > Here is a revised patch for review: https://github.com/acatarineu/tor-
 browser/commit/21952+6.

 r=brade,r=mcs
 This looks good to us. Richard, please do a second review.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-24 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Thanks, revised in:

 https://github.com/acatarineu/torspec/blob/21952+1/proposals/ideas/onion-
 location.txt.

 Replying to [comment:122 asn]:
 > Replying to [comment:119 acat]:
 > > I updated the Onion-Location proposal from asn to match the current
 implementation:
 > >
 > > https://github.com/acatarineu/torspec/blob/21952/proposals/ideas
 /onion-location.txt
 > >
 > >
 
https://github.com/acatarineu/torspec/commit/b39f480eba95dc4a3ed08d7a63067c3f44353b89
 >
 > LGTM!
 >
 > Perhaps the  thing can go into its own section? Because it is a
 bit hidden like that.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-23 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:120 acat]:
 > And builds of 21952+6 branch for UX review:
 https://people.torproject.org/~acat/builds/21952+6/.

 Thank you!

 - Both /meta and /header demos work for me.
 - The general setting works well and without reload (we may need user
 feedback on this flow, but is a current firefox issue, I'll open a
 different ticket for it).
 - Can we remove the left margin at the doorhanger?

 @steph @pili @mcs @brade @pospeselr: We are using this text at the prompt.
 Any thought? Let me know if we are ok to reach l10n.

 {{{
 Try this: Onionsite

 Website publishers can protect users by adding a security layer. This
 prevents eavesdroppers from knowing that you are the one visiting that
 website.
 }}}

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-23 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 Replying to [comment:119 acat]:
 > I updated the Onion-Location proposal from asn to match the current
 implementation:
 >
 > https://github.com/acatarineu/torspec/blob/21952/proposals/ideas/onion-
 location.txt
 >
 >
 
https://github.com/acatarineu/torspec/commit/b39f480eba95dc4a3ed08d7a63067c3f44353b89

 LGTM!

 Perhaps the  thing can go into its own section? Because it is a bit
 hidden like that.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-22 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherpunks):

 In all of this, how do you interact with:
 https://github.com/MikeBishop/dns-alt-svc
 A common solution would be nice

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-22 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 And builds of 21952+6 branch for UX review:
 https://people.torproject.org/~acat/builds/21952+6/.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-22 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.5
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  11 => 11.5


Comment:

 I updated the Onion-Location proposal from asn to match the current
 implementation:

 https://github.com/acatarineu/torspec/blob/21952/proposals/ideas/onion-
 location.txt

 
https://github.com/acatarineu/torspec/commit/b39f480eba95dc4a3ed08d7a63067c3f44353b89

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-19 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  10 => 11


--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-19 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:116 mcs]:

 > * UX: Now that clicking "Always Prioritize Onionsites" flips the pref
 for me, I expect that the redirect will be followed for that page without
 me doing more. Would it surprise people too much if we did that or would
 it be an improvement?

 Maybe we can ask for more opinions, but I thought this made sense and
 implemented it in the revision.

 > * Kathy and I expected that `privacy.prioritizeonions.showNotification`
 would default to `true` to indicate that the notification should be
 displayed. That is what I meant in comment:111 when I said "reverse the
 meaning."
 True, I missed this one. Thanks.

 

 Here is a revised patch for review: https://github.com/acatarineu/tor-
 browser/commit/21952+6. While working on it, I realized that the
 implementation could be buggy in some (not so common) cases. This is
 because the cleanup of the `OnionLocation` in `browser.js` was being done
 in the `XULBrowserWindow` `onStateChange` function, which fires only in
 the currently selected tab. That means that if a tab which had a
 `OnionLocation` UI changed to a different location while not selected, the
 `onionsite available` badge would not be removed. To fix it I moved the
 cleanup to the `onStateChange` function of the `TabsProgressListener`,
 which should also fire for tabs that are not currently selected.

 The `Add search engines` badge implementation in Firefox is also buggy in
 the same way, so I'll file a bugzilla ticket if it's not already there.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-18 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:115 acat]:
 > Thanks for the reviews! Here are the revised patches:
 https://github.com/acatarineu/tor-browser/commit/21952+5 and
 https://github.com/acatarineu/torbutton/commit/21952+1. I took the
 suggested string changes for now, let's wait for the final string review.

 The changes look good. Just two comments:
 * UX: Now that clicking "Always Prioritize Onionsites" flips the pref for
 me, I expect that the redirect will be followed for that page without me
 doing more. Would it surprise people too much if we did that or would it
 be an improvement?
 * Kathy and I expected that `privacy.prioritizeonions.showNotification`
 would default to `true` to indicate that the notification should be
 displayed. That is what I meant in comment:111 when I said "reverse the
 meaning."

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-17 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Thanks for the reviews! Here are the revised patches:
 https://github.com/acatarineu/tor-browser/commit/21952+5 and
 https://github.com/acatarineu/torbutton/commit/21952+1. I took the
 suggested string changes for now, let's wait for the final string review.

 I will upload some tor-browser builds with these changes and also add an
 updated `Onion-Location` spec that reflects the current implementation, so
 that asn and maybe others can review.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-17 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:110 mcs]:
 > * Does onionLocation.learnMoreURL need to be localized? It could be
 handled like securityLevel.learnMoreURL (use a hard-coded URL but insert
 the current locale). Also, please go ahead and file a child ticket to
 track creation of the "learn more" page.

 Now, we have #33512 as a child here.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-17 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:111 mcs]:
 > Here are some UX and code-related comments for the `21952+4` branch from
 Kathy and me:
 > * UX: The "Onion Services" and "Onion Services Authentication" sections
 are not near each other within about:preferences#privacy. Is that okay or
 should we move one of them?

 I think Onion Services first makes sense. We can group Onion Services Auth
 with Logins and Passwords. The list may look like:

 1. Onion Services
 2. Cookies and Site Data
 3. Logins and Passwords
 4. Onion Services Auth
 5. History
 6. Address Bar

 > * UX: Should clicking the "Always Prioritize Onions" option flip the
 pref as well as take the user to about:preferences? It surprises us that
 clicking it does not carry out the action.

 Ideally, yes. There is also a highlight animation when the preferences get
 open. The behavior is the same when users click `Advanced Security
 Settings` in the toolbar icon.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-13 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by micah):

 * cc: hacim (removed)
 * cc: micah (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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-11 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Here are some UX and code-related comments for the `21952+4` branch from
 Kathy and me:
 * UX: The "Onion Services" and "Onion Services Authentication" sections
 are not near each other within about:preferences#privacy. Is that okay or
 should we move one of them?
 * UX: Should clicking the "Always Prioritize Onions" option flip the pref
 as well as take the user to about:preferences? It surprises us that
 clicking it does not carry out the action.
 * Please expand the commit message to mention a little bit about the new
 behavior (Onion-Location HTTP and meta http-equiv are both supported,
 etc.).
 * Please add a Tor copyright notice to the new files.
 * Should we move the new code under browser/components/onionservices or
 would that be too messy? When Kathy and I picked that name we were hoping
 some other .onion-related code could be placed there so we don't end up
 adding too many directories under browser/components.
 * A general comment: you could use `const` in more places, e.g., replace
 `let win = event.target.ownerGlobal;` with `const win =
 event.target.ownerGlobal;`.
 * Consider renaming the pref `privacy.prioritizeonions.notification` to
 `privacy.prioritizeonions.notification.shown` or reverse the meaning and
 rename it to `privacy.prioritizeonions.showNotification`.
 * In browser/base/content/browser.js, consider adding a blank line and/or
 comment above the `OnionLocationParent.onStateChange(browser);` statement
 (since that line is unrelated to the `clear out search-engine data` code).
 * In browser/components/onionlocation/OnionLocationChild.jsm
 `receiveMessage()`, consider renaming the `document` variable to `doc`
 (the former makes me think of the window's document property from HTML-
 land).
 * In browser/components/onionlocation/OnionLocationChild.jsm
 `onPageShow()` it looks like the second parameter to the
 `OnionLocation:Set` IPC message can be removed since it is not used on the
 receiving end.
 * In browser/components/onionlocation/OnionLocationParent.jsm
 `showNotification()`, remove the blank line after `let seen = ...` and
 move the `let win = ...` statement after the `if (seen)` block.

 Sorry if many of these seem nit-picky, but hopefully we are down to nits.
 Maybe Richard will find something bigger to complain about ;)

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-11 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Here are some string-related comments from Kathy and me (I will post code-
 related comments separately):
 * For onionLocation.alwaysPrioritize, the word '''Prioritize''' should
 begin with a capital letter since it is a button label.
 * For onionLocation.askEverytime, add a space like so: '''Ask you every
 time'''
 * Do we want to use the term '''onionsite''' in some places? For example:
 '''Always Prioritize Onionsites''', '''Try this: Onionsite''',
 '''Onionsite available'''
 * For onionLocation.description, reword as: '''Website publishers can
 protect users by adding a security layer. This prevents eavesdroppers from
 knowing that you are the one visiting that website.'''
 * For onionLocation.prioritizeOnionsDescription, possibly reword as:
 '''Prioritize onionsites when they are available.'''
 * Does onionLocation.learnMoreURL need to be localized? It could be
 handled like securityLevel.learnMoreURL (use a hard-coded URL but insert
 the current locale). Also, please go ahead and file a child ticket to
 track creation of the "learn more" page.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-11 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by pili):

 * cc: emmapeel, stephw (added)


Comment:

 Adding in stephw for string review and emmapeel for localization

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-10 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 And here is a torbutton patch for the strings:
 https://github.com/acatarineu/torbutton/commit/21952 (although I think the
 strings themselves still need review).

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-03-05 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  10
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * actualpoints:  9 => 10


Comment:

 Patch for review in https://github.com/acatarineu/tor-
 browser/commit/21952+4. The internal `Onion-Location` logic is now done in
 `Document.cpp` instead of `nsHttpChannel.cpp`, and `Onion-Location` can be
 set either as a header or `https://people.torproject.org/~acat/test/onionlocation/header/ for the
 header case and
 https://people.torproject.org/~acat/test/onionlocation/meta/ for meta.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-02-25 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 I sent an e-mail about this to Will Shackleton from Facebook, explaining
 the problem we're trying to solve and suggesting three alternatives:

 1. A Onion-Location header which must be sent with a 30X response code.

 2. A Onion-Location header (or similarly named) which can be added
 independently of the response code (and body).

 3. A https://www.facebook.com should the server return 3XX with onion-location
 and then return the full web-page response for FB? How will non-Tor-
 browsers know what to do with this? I think the purpose of 3XX codes is
 "go somewhere else and do nothing but that", so using a 3XX to represent
 an optional redirect seems odd. Is the goal to let the server say "regular
 browsers go to X, onion browsers go to Y"?

 For 2 and 3, I think a meta tag makes more sense for a few reasons:
 a. complex web apps like FB serve a lot of resources. Only a small
 percentage of returned assets are actually web pages, and web pages are
 precisely the things that users sit and look at (ie. are full page loads),
 which are the places where you would want to prompt the user to maybe
 learn about onion services.
 b. there's already a whole load of meta tags like `rel="canonical"` and
 alternative-language versions for saying "here's other URLs for this
 thing" that are scraped by search engines in well-defined ways. Putting
 this in a meta tag I think makes sense if a search engine were to scrape
 this information. It certainly seems more like an optional suggestion to
 the browser compared to an HTTP header, which I think makes a meta tag
 more suitable here.
 c. (this is not how FB does things, but:) lots of websites serve their
 HTTP headers in their load-balancers. The product logic in the web servers
 deals only with HTML, which is likely where the onion equivalent would be
 served.

 In summary, I think the meta tag is much less intrusive and breaks fewer
 layer boundaries in my mind. To me, "here's the onion for this thing" is a
 property of a web-page, not an arbitrary HTTP request which could be a
 POST request, API call, JS file load, video stream, websocket, etc, given
 that this would redirect the whole user experience across to an onion.

 This brings me on to another point: FB currently do not advertise
 facebookcorewwwi to facebook.com users. The reason for this is that our
 general security communication says "if it doesn't say facebook.com,
 you're being hacked!". We tacitly acknowledge that people who know what an
 onion is are smart enough to understand that facebookcorewwwi is the one
 exception to this otherwise global rule.

 If we were to advertise our onion to facebook.com Tor users (we don't have
 plans to do this), we would likely take users through a flow on
 facebook.com where we educate people about the differences and benefits of
 an onion before presenting them with the redirect. Today, we would
 implement this using our existing Tor exit IP detection. Even with the
 presence of things like onion-location we would likely want to still
 present the user with our own information about onions before we redirect
 them, and we would then issue a regular 302 redirect to the onion.

 Given that we suspect that the majority of Tor users don't know what an
 onion is, it would be great if Tor Browser could tell servers (a) "this
 user is using a browser that supports onion services", and also possibly
 (b) "Tor Browser confirms that this user understands onion services and
 understands what they do and don't do". This could be perhaps sent in the
 user-agent header. (a) allows websites like ours to stop scraping Tor exit
 IPs which is unreliable, and (b) would allow a website to show such a flow
 for moving to an onion service only to users who know what one is.
 Finally, this allows us to save some bytes on the wire for our non-Tor
 users by not serving this new header / meta tag to everyone.

--
Ticket URL:

Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-02-18 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 Replying to [comment:103 acat]:
 > Perhaps this would make it closer to the semantics of "Refresh" header
 instead of "Location" (see https://www.w3.org/TR/WCAG20-TECHS/H76.html).
 More specifically a Refresh with a 0 timeout:
 `Refresh="0;URL='http://some.onion/whatever'"`. If we would follow this,
 with onion auto-redirects enabled we could internally treat "Onion-
 Location" (or "Onion-Refresh"?) as a "Refresh=0;URL=..." which takes
 precedence over regular Refresh headers, and if auto-redirects are off we
 would just not treat it as a Refresh and display the .onion available UI
 instead.

 +1 This proposal makes a lot of sense to me and seems to neatly side-step
 the issues of intermixing new logic into the existing redirect headers.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-02-18 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202002R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherpunks):

 short note: Refresh is working not only in meta but as HTTP Header
 "Refresh"

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-02-18 Thread Tor Bug Tracker & Wiki

Comment (by acat):

Replying to [comment:98 pospeselr]:
> acat: Ah, I missed the final 'are we already on an onion' check in that
if. Though that does lead to another question. What is the correct
behavior if foo.onion sends Onion-Location: bar.onion?

Sorry for the late reply, I had missed this question. If a .onion site
wants to redirect to a different .onion it can always use a regular
`Location` redirect instead of `Onion-Location`, so I think it should be
fine to ignore `Onion-Location` headers if we are already in a .onion
site.

Replying to [comment:101 sysrqb]:
> Maybe we should specify that `Onion-Location` should only be used with
`300 Multiple Choices`? If a server sends `301 Moved Permanently`, `307
Temporary Redirect`, or `308 Permanent Redirect`, then that seems like it
implies the user-agent should redirect to the provided location without
user intervention.

I was not aware of the `300 Multiple Choices`, I think that's probably the
option that would respect the standards most, if we are going to use 30X
redirects. However, I still think that serving different response codes
for Tor Browser users can be problematic from the server point of view. If
I'm not wrong, (for all detected Tor Browsers users) the server would need
to either:

* Serve the full site (all subpages) with `300` response code + `Onion-
Location` header (I mean with the actual page body and without `Location`
header).

* Offer three distinct URLs for each resource in the site:
1. One non-onion URL which we would **never** respond to with a `Onion-
Location` redirect (e.g. https://www.facebook.com/?noonionlocation=1)
2. The .onion one. (e.g. https://www.facebookcorewwwi.onion/)
3. The well-known non-onion one, for which we would return `300 Multiple
Choices` with `Location` equal to URL number 1, and `Onion-Location` equal
to URL number 2 (e.g. https://www.facebook.com/)

Otherwise, I don't see a way how the server is able to know when it has to
send a `300 Onion-Location` redirect and when it doesn't. For either
solution, the server could always limit it to the just top-level page,
which would make it less costly, I guess.
\\
>Thinking about adoption, also note that the current implementation
(ignoring response code) could allow achieving the same via a http://some.onion;> HTML tag, in case
adding headers is more difficult for website owners than adding meta tags
in the page content.
>
>>This is a neat idea.

Perhaps this would make it closer to the semantics of "Refresh" header
instead of "Location" (see https://www.w3.org/TR/WCAG20-TECHS/H76.html).
More specifically a Refresh with a 0 timeout:
`Refresh="0;URL='http://some.onion/whatever'"`. If we would follow this,
with onion auto-redirects enabled we could internally treat "Onion-
Location" (or "Onion-Refresh"?) as a "Refresh=0;URL=..." which takes
precedence over regular Refresh headers, and if auto-redirects are off we
would just not treat it as a Refresh and display the .onion available UI
instead.

For us, we could argue that we follow the semantics of a "Refresh=0;URL"
header (when auto-redirect is enabled), and this might be easier than
trying to get the "right" behaviour with 30X redirects. For the servers
implementing this, I think it would be simpler not having to care about
redirect response codes: they would be able to serve the regular page
alongside the header (or attribute), which would be displayed
normally if onion auto-redirects were off. Another advantage I already
mentioned: it would give more freedom for the implementer, as it would be
possible to choose between serving a header or a
depending on what's easier. And this one is out of scope, but maybe using
a attribute might be more friendly for some search engine
crawlers/robot able to add the .onion alternative to their index?

In any case, I'll (finally) contact will shackleton for some feedback on

Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-02-05 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R, network-team-roadmap-   |
  2020Q1 |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:99 acat]:
 > Replying to [comment:98 pospeselr]:
 > > Regarding servers sending 3XX responses with {{{Onion-Location}}} sans
 {{{Location}}}: I think that the browser should only transparently treat
 {{{Onion-Location}}} as if it were {{{Location}}} if the user has the auto
 onion redirect pref on. If that pref is on, I think we should look for
 {{{Onion-Location}}} first in the case of 3XX redirects and then fallback
 to {{{Location}}}.
 >
 > For the cases where there needs to be a redirect in any case, having
 both `Onion-Location` and `Location` in a 30X works fine I think. And the
 priority you suggest looks like the right one.

 Maybe we should specify that `Onion-Location` should only be used with
 `300 Multiple Choices`? If a server sends `301 Moved Permanently`, `307
 Temporary Redirect`, or `308 Permanent Redirect`, then that seems like it
 implies the user-agent should redirect to the provided location without
 user intervention.

 I prefer we explicitly define which conditions cause a redirect verses
 cause the badge UI. A response with code `308` and `Onion-Location` is
 saying "This resource is not at the URL you requested anymore, please load
 it from this onion location, but only if the user chooses to use the new
 location (onion address). Meanwhile, please enjoy the page I just was
 permanently moved", right?

 >
 > The problem I see is when there would be no need to redirect
 [snip]
 >
 > So I think making `Onion-Location` (or an equivalent header with a
 different name) behaviour independent of the status code of the response
 is preferable, but I might be missing something.

 Yeah, I think we are experiencing some scope-creep here :) But maybe this
 is okay. We should resolve any confusion or ambiguity for how this should
 be used and the expected behavior before we merge this.

 > Replying to [ticket:21952 linda]:
 >>  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.

 The original idea was only intended as an alternative for simply and
 forcefully redirecting all users to an onion address (based on exit node
 IP address). Making this opt-in may make this less scary and an
 "educational experience". My understanding is this directly changes the
 behavior of `307`and `308`, but I am concerned this is not the best
 behavior.

 >
 > Thinking about adoption, also note that the current implementation
 (ignoring response code) could allow achieving the same via a `http://some.onion;>` HTML tag, in case
 adding headers is more difficult for website owners than adding meta tags
 in the page content.

 This is a neat idea.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-01-10 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:98 pospeselr]:
 > Regarding servers sending 3XX responses with {{{Onion-Location}}} sans
 {{{Location}}}: I think that the browser should only transparently treat
 {{{Onion-Location}}} as if it were {{{Location}}} if the user has the auto
 onion redirect pref on. If that pref is on, I think we should look for
 {{{Onion-Location}}} first in the case of 3XX redirects and then fallback
 to {{{Location}}}.

 For the cases where there needs to be a redirect in any case, having both
 `Onion-Location` and `Location` in a 30X works fine I think. And the
 priority you suggest looks like the right one.

 The problem I see is when there would be no need to redirect, e.g. the
 request is ok, yet we still want to have the `Onion-Location` header in
 the response to give Tor Browsers the possibility of doing so if the
 conditions are met. For those cases, if we enforce 30X for Onion-Location,
 we could send the `Onion-Location` header without the `Location` one and
 include the page body in the response, as the redirection would be
 optional (usually in 30X responses there is no body). This feels very non-
 standard. An alternative would be to force 30X responses with both `Onion-
 Location` and `Location` headers, even if the redirection was unnecessary.
 I think that would make adoption more difficult, as the server would need
 to have some logic to decide whether to return the 30X redirect, or the
 "real" response. Note that this also has implications on the `.onion
 available` UI, e.g. in the current implementation the button would not be
 shown if the `Onion-Location` header was only present in the redirect
 response.

 So I think making `Onion-Location` (or an equivalent header with a
 different name) behaviour independent of the status code of the response
 is preferable, but I might be missing something.

 Thinking about adoption, also note that the current implementation
 (ignoring response code) could allow achieving the same via a `http://some.onion;>` HTML tag, in case
 adding headers is more difficult for website owners than adding meta tags
 in the page content. In principle, `meta http-equiv` should be equivalent
 to setting a http response header, but there is some kind of whitelist of
 allowed headers for this, so it would need to be explicitly
 enabled/implemented in https://searchfox.org/mozilla-
 esr68/rev/1eba6d228a3903f04ea99124343db445c202e4b9/dom/base/Document.cpp#3759.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-01-09 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 **acat**: Ah, I missed the final 'are we already on an onion' check in
 that {{{if}}}. Though that does lead to another question. What is the
 correct behavior if {{{foo.onion}}} sends {{{Onion-Location: bar.onion}}}?

 Regarding servers sending 3XX responses with {{{Onion-Location}}} sans
 {{{Location}}}: I think that the browser should only transparently treat
 {{{Onion-Location}}} as if it were {{{Location}}} if the user has the auto
 onion redirect pref on. If that pref is on, I think we should look for
 {{{Onion-Location}}} first in the case of 3XX redirects and then fallback
 to {{{Location}}}.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-01-09 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Thanks for the reviews. Revised in https://github.com/acatarineu/tor-
 browser/commits/21952+3.
 \\
 > Kathy and I think it would be safer to use a higher bit for
 LOAD_FLAGS_ONION_REDIRECT, since we are not sure where or how the lower
 bits are used. The comment "reserved for internal use by nsIWebNavigation
 implementations" makes us think that other code may count on 0x1, 0x2,
 0x4, and 0x8 being available/unused by the core code.
 Yes, that was also my concern, but unfortunately all the other reload
 flags are already used, I think. See https://github.com/acatarineu/tor-
 
browser/blob/3a9929a559c8505f3032f8f317fbb600d1a71e92/docshell/base/nsIWebNavigation.idl#L87.
 If this is too risky, I could try to find an alternative way of doing the
 "manual" redirect without the new reload flags.
 \\
 > Do you think that would make the patches simpler or more complex? From
 Mozilla's perspective (assuming we could possibly uplift these patches
 someday), the C++ approach is probably better.

 I'm not so sure, to be honest. I guess it's fine to keep it C++.
 \\
 > Clicking the [x] has the same effect as clicking "Not Now" and therefore
 the [x] does not seem necessary.
 Fixed.
 \\
 >> Using a doorhanger for the prompt makes us think that it is safe to
 click the [.onion available] button to dismiss the prompt (because that is
 how most of Firefox's other doorhangers work). I am not sure how to fix
 this issue though.
 > Well, it *is* safe to click the [.onion available]. And actually, since
 we are promoting the discovery doorhanger just the first time and
 meanwhile the automatic redirect is not enabled in about:preferences, it
 should get closed when the button is clicked.
 So, I'm assuming this is fine as it is for now.
 \\
 >> There is no way to dismiss the prompt in such a way that it will be
 shown a second time, which surprises Kathy and me.
 > True. I made a version with a [Ask me again in the future], but it
 slightly moved out-of-scope. I'm happy to explore that option in the
 future (as a non-prompt/transparent re-direct flow too).
 Ok, leaving this one as it is for now too.
 \\
 >> But I guess the "Always prioritize Onions" prompt is only intended to
 serve as a form of onboarding. I wonder if the prompt should be adjusted
 to open about:preferences instead of directly modifying the
 privacy.prioritizeonions.enabled pref? Opening the preferences would teach
 users where to find the setting in the future.
 >Maybe, yes. Since it is a global feature and also if selected, the prompt
 will not show anymore, we may want to open about:preferences also as an
 educational opportunity.

 Right now the behaviour is to flip the pref and reload the page so that it
 redirects to .onion automatically. Instead of that, should the new
 behaviour be just opening about:preferences without flipping the pref and
 without redirecting the original page to .onion? I revised with the latter
 behaviour for now, but asking to make sure.
 \\
 > In modules/libpref/init/StaticPrefList.h, please add a comment that
 explains the purpose of the privacy.prioritizeonions.enabled preference.

 Done.
 \\
 > We will need a torbutton.dtd patch to add the strings. Since these are
 new strings, you could use a properties file instead; see our patch here
 for an example: https://gitweb.torproject.org/user/brade/tor-
 
browser.git/diff/browser/modules/TorStrings.jsm?h=bug30237-03=50fe8ef29fa3cb2915bdfb050d4512014081

 Changed to use the `TorPropertyStringBundle` from the patch you pointed
 to.
 \\
 > In OnionLocationParent.jsm inside the setOnionLocation() and
 updateOnionLocationBadge() functions, is it necessary to check browser
 against ...selectedBrowser? As it is now, if an https page that returns an
 Onion-Location header finishes loading in the background the [.onion
 available] button is not displayed.

 Nice catch, thanks. I remember fixing this before, so I must have re-added
 the bug when

Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-01-07 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 **Backend**

 So one weird thing that stands about the changes to nsHttpChannel.cpp is
 that the new {{{Onion-Location}}} code seems to supersede all logic
 surrounding the returned HTTP Status. Whether that's okay or not kind of
 depends on the {{{Onion-Location}}} spec.

 How are properly configured web-servers meant to use the {{{Onion-
 Location}}} header? Is it meant to be there in every HTTP response sent to
 the client, or only in certain situations? The spec is unclear about which
 HTTP status codes it is meant to be used with. It does state that
 {{{Onion-Location}}} has the same restrictions and semantics as
 {{{Location}}} which according to [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Headers/Location Mozilla] only has meaning for {{{3XX}}}
 and {{{201}}} responses.

 If we are only supposed to redirect in those contexts then the checks for
 that block checking for and getting the {{{Onion-Location}}} header could
 (probably?) go down into {{{nsHttpChannel::AsyncProcessDirection}}}.

 We don't seem to check if we are *already* on the Onion site the {{{Onion-
 Location}}} header suggests we redirect to.

 **Frontend**

 The frontend logic seems good to 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2019-12-16 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam201912R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:93 mcs]:
 > Here are some UX comments related to the "Always prioritize Onions"
 prompt (but note that Kathy and I have not closely followed all of the
 discussions related to this feature):

 Thanks for this review mcs and brade!

 > * Clicking the `[x]` has the same effect as clicking "Not Now" and
 therefore the `[x]` does not seem necessary.

 Agreed. There is not [x] in the default doorhanger, too.
 
[https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png,
 Ref].


 > * Using a doorhanger for the prompt makes us think that it is safe to
 click the `[.onion available]` button to dismiss the prompt (because that
 is how most of Firefox's other doorhangers work). I am not sure how to fix
 this issue though.

 Well, it *is* safe to click the [.onion available]. And actually, since we
 are promoting the discovery doorhanger just the first time and meanwhile
 the automatic redirect is not enabled in `about:preferences`, it should
 get closed when the button is clicked.

 > * There is no way to dismiss the prompt in such a way that it will be
 shown a second time, which surprises Kathy and me.

 True. I made a version with a [Ask me again in the future], but it
 slightly moved out-of-scope. I'm happy to explore that option in the
 future (as a non-prompt/transparent re-direct flow too).

 >But I guess the "Always prioritize Onions" prompt is only intended to
 serve as a form of onboarding. I wonder if the prompt should be adjusted
 to open about:preferences instead of directly modifying the
 `privacy.prioritizeonions.enabled` pref? Opening the preferences would
 teach users where to find the setting in the future.

 Maybe, yes. Since it is a global feature and also if selected, the prompt
 will not show anymore, we may want to open `about:preferences` also as an
 educational opportunity.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2019-12-12 Thread Tor Bug Tracker & Wiki

Comment (by mcs):

Replying to [comment:85 acat]:
> Revised branch for review in https://github.com/acatarineu/tor-
browser/commits/21952+2.
>
> I split the changes into two commits for reviewing purposes, UI and
"internals" needed for the http redirect. For the internals, I used a
couple of flags (`LOAD_FLAGS_ONION_REDIRECT` and `LOAD_ONION_REDIRECT`)
the value of which I think is not used anywhere else.

Kathy and I reviewed all of your changes and overall everything looks
really good to us. Nice work!

We are not very up-to-date on the page load and networking code, so it
would be good to get a review (even a quick one) from a Mozilla engineer
who has expertise in those areas. But we can wait and see what Richard has
to say after he completes his review.

Kathy and I think it would be safer to use a higher bit for
`LOAD_FLAGS_ONION_REDIRECT`, since we are not sure where or how the lower
bits are used. The comment "reserved for internal use by nsIWebNavigation
implementations" makes us think that other code may count on 0x1, 0x2,
0x4, and 0x8 being available/unused by the core code.

> But as I said, I'm not sure if it would be better to rewrite that commit
and use the `redirectTo` JavaScript API instead.

Do you think that would make the patches simpler or more complex? From
Mozilla's perspective (assuming we could possibly uplift these patches
someday), the C++ approach is probably better.

Here are some UX comments related to the "Always prioritize Onions" prompt
(but note that Kathy and I have not closely followed all of the
discussions related to this feature):
* Clicking the `[x]` has the same effect as clicking "Not Now" and
therefore the `[x]` does not seem necessary.
* Using a doorhanger for the prompt makes us think that it is safe to
click the `[.onion available]` button to dismiss the prompt (because that
is how most of Firefox's other doorhangers work). I am not sure how to fix
this issue though.
* There is no way to dismiss the prompt in such a way that it will be
shown a second time, which surprises Kathy and me. But I guess the "Always
prioritize Onions" prompt is only intended to serve as a form of
onboarding. I wonder if the prompt should be adjusted to open
about:preferences instead of directly modifying the
`privacy.prioritizeonions.enabled` pref? Opening the preferences would
teach users where to find the setting in the future.

Other code-related comments:
In modules/libpref/init/StaticPrefList.h, please add a comment that
explains the purpose of the `privacy.prioritizeonions.enabled` preference.

We will need a `torbutton.dtd` patch to add the strings. Since these are
new strings, you could use a properties file instead; see our patch here
for an example:
https://gitweb.torproject.org/user/brade/tor-

browser.git/diff/browser/modules/TorStrings.jsm?h=bug30237-03=50fe8ef29fa3cb2915bdfb050d4512014081

In OnionLocationParent.jsm inside the `setOnionLocation()` and
`updateOnionLocationBadge()` functions, is it necessary to check `browser`
against `...selectedBrowser`? As it is now, if an https page that returns
an `Onion-Location` header finishes loading in the background the `[.onion
available]` button is not displayed.

A nit: in browser/components/onionlocation/content/onionlocation-
urlbar.css, please add a space before each occurrence of `!important`
(easier to read, at least for Kathy and me).

Do we need another ticket to track creation of a new page for the
"learnMore" link or is there an existing page that we can use?

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2019-12-02 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam201912R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by pili):

 * reviewer:   => pospeselr, mcs, brade


--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911R,   |
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * keywords:
 ux-team, tor-hs, network-team-roadmap-november, TorBrowserTeam201911,
 tbb-9.5
 =>
 ux-team, tor-hs, network-team-roadmap-november, TorBrowserTeam201911R,
 tbb-9.5


--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 OSX builds:
 [https://people.torproject.org/~acat/builds/TorBrowser-9.5a2-osx64_en-
 US_21952+2.dmg TorBrowser-9.5a2-osx64_en-US_21952+2.dmg]
 [https://people.torproject.org/~acat/builds/TorBrowser-9.5a2-osx64_en-
 US_21952+2.dmg.sig TorBrowser-9.5a2-osx64_en-US_21952+2.dmg.sig]

 >Do we have your commit streamed to some nightly build?

 If you mean whether there is some automatic nightly build that includes
 this then no, I think for that the commits would have to be reviewed and
 accepted first.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:85 acat]:


 > For the UI, you'll see that the notification title does not look exactly
 the same as in
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png.
 But I tried to use only the JS API to save a few lines of css and markup,
 and thought this was close enough to be acceptable. But feel free to
 insist if you still think the notification should be closer to
 `UI_review.png` one. I'll update with build + snapshot/video later.
 >


 In UI terms, we are good to go for me. Let me add some comms people to the
 loop so we can review the copy text.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 thanks for this iteration! This looks awesome! Do we have your commit
 streamed to some nightly build?

 I'll work on the animation in the meantime and we can discuss it when you
 are back.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Video [https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/21952/21952%2B2.webm here]. Note: I did not implement
 the lock -> onion animation when redirecting, as my understanding is that
 is not yet decided. For the same reason, for now I also kept the
 OnionLocation prefs in the `Security/Privacy` section.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "21952+2.webm" 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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * status:  needs_revision => needs_review
 * actualpoints:  5.5 => 9


Comment:

 Revised branch for review in https://github.com/acatarineu/tor-
 browser/commits/21952+2.

 I split the changes into two commits for reviewing purposes, UI and
 "internals" needed for the http redirect. For the internals, I used a
 couple of flags (`LOAD_FLAGS_ONION_REDIRECT` and `LOAD_ONION_REDIRECT`)
 the value of which I think is not used anywhere else. But as I said, I'm
 not sure if it would be better to rewrite that commit and use the
 `redirectTo` JavaScript API instead. For the UI, you'll see that the
 notification title does not look exactly the same as in
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png.
 But I tried to use only the JS API to save a few lines of css and markup,
 and thought this was close enough to be acceptable. But feel free to
 insist if you still think the notification should be closer to
 `UI_review.png` one. I'll update with build + snapshot/video later.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2019-11-25 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:83 cypherpunks]:
 > Replying to [comment:80 antonela]:
 >
 > > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.
 > >
 >
 > it tells about eyedropper. shouldnt it be spelled eavesdropper?

 Yes. Content is a placeholder for now; it is up to get reviewed.

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2019-11-24 Thread Tor Bug Tracker & Wiki

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherpunks):

 Replying to [comment:80 antonela]:

 > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.
 >

 it tells about eyedropper. shouldnt it be spelled eavesdropper?

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:81 acat]:
 > Thanks for the review.
 >
 > > 3. Can we use the circular onion icon? I aim to have updated all the
 onions at the URL bar and the circuit display too.
 >
 > Is there a svg for that one? I could not find one with just a single
 color like the ones in your design.
 >

 Yes, here browser/components/tornetworksettings/content/torNetworkIcon.svg

 >
 > > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.
 >
 > I think it makes sense. This came for free by using the internal Firefox
 page action API, but we can just make it not be a page action, and be at
 the left of those, like the reader mode button for example.
 >
 >

 I prefer that. We can discuss it with the team during the meeting on
 Monday.

 > > 5. Can we prompt the discover-like doorhanger just for first-time
 users? I don't want to suggest users change the general settings every
 time they have an onion available. It will add extra friction in the
 entire experience which I don't think is needed.
 > > 6. If users have selected [ask me every time] then we show the onion-
 label suggestion pill. If users have selected [always use .onion when
 available] then we redirect to the onion using the proposed animation. So,
 the onion-label pill doesn't need a menu. Again, am i missing something?
 >
 > Ok, so clicking on the pill should directly go to the .onion, and the
 doorhanger should appear only once, for the opt-in. I think that makes
 sense, and then there's no need for contextual menu, indeed.
 >

 Exactly. Awesome!

 > > 9. As part of #30024, I made this micro animation for when the onion
 gets updated. Do you think it is something doable? The persistent pill
 seems too much for it.
 > > https://trac.torproject.org/projects/tor/attachment/ticket/30024
 /prompt-onion-2.gif
 >
 > Not completely sure how easy that will be, but I will try. The animation
 only affects the "lock"/onion icon and the pill, right? That's for "ask me
 everytime", for "always use .onion" the animation would be only on the
 "lock"/onion (as there would be no pill), if I am correct.
 >

 We can discuss it during the next meeting. I'm not sure what is going to
 be the case of CV/EV and onions and maybe the lock is needed in the
 future.

 > > 10. The panel at `about:preferences` looks great. Should we move it
 under the Tor section? I suggested to have it on Privacy & Security and
 maybe it is the right place to have it. What do others think?
 >
 > I'm not sure. Is the Tor section supposed to mean "settings for Tor
 client", or just any setting related to Tor? I don't know if it should be
 in `Privacy/Security` either, as I'm not sure it has much privacy/security
 benefits actually (as noted in
 https://gitweb.torproject.org/user/asn/torspec.git/tree/proposals/ideas
 /onion-location.txt?h=onion-
 location=14fc750e3afcd759f4235ab955535a07eed24286).
 >
 Let's talk about it during the next meeting. I'm fine keeping it as the
 first option in privacy/security.


 Thanks for your quick reply!!

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  5.5
  roadmap-november, TorBrowserTeam201911,|
  tbb-9.5|
Parent ID:  #30024   | Points:  6
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * status:  assigned => needs_revision


Comment:

 Thanks for the review.

 > 3. Can we use the circular onion icon? I aim to have updated all the
 onions at the URL bar and the circuit display too.

 Is there a svg for that one? I could not find one with just a single color
 like the ones in your design.

 > 4. I don't think we need a menu under the [...] It adds noise and I
 don't see a real use case for it. Do you think I'm missing something? Let
 me know.

 I think it makes sense. This came for free by using the internal Firefox
 page action API, but we can just make it not be a page action, and be at
 the left of those, like the reader mode button for example.

 > 5. Can we prompt the discover-like doorhanger just for first-time users?
 I don't want to suggest users change the general settings every time they
 have an onion available. It will add extra friction in the entire
 experience which I don't think is needed.
 > 6. If users have selected [ask me every time] then we show the onion-
 label suggestion pill. If users have selected [always use .onion when
 available] then we redirect to the onion using the proposed animation. So,
 the onion-label pill doesn't need a menu. Again, am i missing something?

 Ok, so clicking on the pill should directly go to the .onion, and the
 doorhanger should appear only once, for the opt-in. I think that makes
 sense, and then there's no need for contextual menu, indeed.

 > 9. As part of #30024, I made this micro animation for when the onion
 gets updated. Do you think it is something doable? The persistent pill
 seems too much for it.
 > https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-
 onion-2.gif

 Not completely sure how easy that will be, but I will try. The animation
 only affects the "lock"/onion icon and the pill, right? That's for "ask me
 everytime", for "always use .onion" the animation would be only on the
 "lock"/onion (as there would be no pill), if I am correct.

 > 10. The panel at `about:preferences` looks great. Should we move it
 under the Tor section? I suggested to have it on Privacy & Security and
 maybe it is the right place to have it. What do others think?

 I'm not sure. Is the Tor section supposed to mean "settings for Tor
 client", or just any setting related to Tor? I don't know if it should be
 in `Privacy/Security` either, as I'm not sure it has much privacy/security
 benefits actually (as noted in
 https://gitweb.torproject.org/user/asn/torspec.git/tree/proposals/ideas
 /onion-location.txt?h=onion-
 location=14fc750e3afcd759f4235ab955535a07eed24286).

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

Comment (by antonela):

hey alec! Thanks for this build! It looks awesome. Running UI Review here:

1. Let's organize the items at the URL bar. Is it possible to have the
onion-label item first? see

[https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png,
here]

2. I know the original design has the purple at the hover, but i think is
more significant to show the color change when it loads. See

[https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952%20-%20UI%20Review.png,
here]

3. Colors are from
[https://design.firefox.com/photon/visuals/color.html#purple, Photon]

Light theme: Purple 70 #6200A4 / Blue 60 #0060DF
Dark theme: Purple 50 #9400ff / Blue 60 #0060DF

3. Can we use the circular onion icon? I aim to have updated all the
onions at the URL bar and the circuit display too.

4. I don't think we need a menu under the [...] It adds noise and I don't
see a real use case for it. Do you think I'm missing something? Let me
know.

5. Can we prompt the discover-like doorhanger just for first-time users? I
don't want to suggest users change the general settings every time they
have an onion available. It will add extra friction in the entire
experience which I don't think is needed.

6. If users have selected [ask me every time] then we show the onion-label
suggestion pill. If users have selected [always use .onion when available]
then we redirect to the onion using the proposed animation. So, the onion-
label pill doesn't need a menu. Again, am i missing something?

7. I see an onboarding experience when we explain to users how to opt-in
via `about:preferences`. I will file that ticket.

8. I like how users don't need to restart the browser to op-out the
automatic redirect.

9. As part of #30024, I made this micro animation for when the onion gets
updated. Do you think it is something doable? The persistent pill seems
too much for it.
https://trac.torproject.org/projects/tor/attachment/ticket/30024/prompt-
onion-2.gif

10. The panel at `about:preferences` looks great. Should we move it under
the Tor section? I suggested to have it on Privacy & Security and maybe it
is the right place to have it. What do others think?

--
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 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing