Re: [tor-bugs] #33047 [Circumvention]: How can we optimise the anti-censorship suite for mobile?

[Tor Bug Tracker & Wiki]

#33047: How can we optimise the anti-censorship suite for mobile?
---+
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-size   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by gaba):

 * keywords:   => tor-size


Comment:

 Right! Let's start to track tickets related with tor's size with #tor-size

--
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] #26068 [Metrics/Website]: better describe bridges vs. relays in the glosary

[Tor Bug Tracker & Wiki]

#26068: better describe bridges vs. relays in the glosary
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31281   | Points:
 Reviewer:   |Sponsor:  Sponsor30-can
-+---
Changes (by gaba):

 * parent:   => #31281


--
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] #26068 [Metrics/Website]: better describe bridges vs. relays in the glosary

[Tor Bug Tracker & Wiki]

#26068: better describe bridges vs. relays in the glosary
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor30-can
-+---
Changes (by gaba):

 * sponsor:   => Sponsor30-can


--
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] #33010 [Metrics/Ideas]: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a cloudflare-hosted static site

[Tor Bug Tracker & Wiki]

#33010: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a
cloudflare-hosted static site
---+--
 Reporter:  arma   |  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health gsoc-ideas  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * keywords:  network-health => network-health gsoc-ideas


--
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] #32905 [Core Tor/Tor]: Remove the ClientAutoIPv6ORPort option

[Tor Bug Tracker & Wiki]

#32905: Remove the ClientAutoIPv6ORPort option
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #29641| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by teor):

 * version:  Tor: unspecified =>
 * type:  defect => enhancement


--
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] #32753 [Core Tor/Tor]: Tor should lower-case its BridgeDistribution string

[Tor Bug Tracker & Wiki]

#32753: Tor should lower-case its BridgeDistribution string
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0432,|  Actual Points:
  035-backport 041-backport 042-backport easy|
  anticensorship-wants fast-fix 043-should   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor28
-+-
Changes (by teor):

 * keywords:
 035-backport 041-backport 042-backport easy anticensorship-wants fast-
 fix 043-should
 =>
 consider-backport-after-0432, 035-backport 041-backport 042-backport
 easy anticensorship-wants fast-fix 043-should


Comment:

 This fixes a serious usability issue for bridge operators, so we should
 backport it to all supported versions.

--
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] #32778 [Core Tor/Tor]: Initialise pubsub in Windows NT service mode

[Tor Bug Tracker & Wiki]

#32778: Initialise pubsub in Windows NT service mode
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0431,|  Actual Points:  .2
  041-backport 042-backport extra-review crash   |
  regression 043-must BugSmashFund   |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * keywords:
 consider-backport-after-043-stable, 041-backport 042-backport extra-
 review crash regression 043-must BugSmashFund
 =>
 consider-backport-after-0431, 041-backport 042-backport extra-review
 crash regression 043-must BugSmashFund


Comment:

 Since this breaks NT services, let's backport it sooner.

--
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] #33050 [Core Tor/Tor]: O1.3 - Integration test Tor relays over IPv6 using chutney (was: O1.3 Integration test Tor relays over IPv6 using chutney)

[Tor Bug Tracker & Wiki]

#33050: O1.3 - Integration test Tor relays over IPv6 using chutney
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

--
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] #33048 [Core Tor/Tor]: O1.1 - Propose and implement IPv6 ORPort reachability checks on relays

[Tor Bug Tracker & Wiki]

#33048: O1.1 - Propose and implement IPv6 ORPort reachability checks on relays
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+
Description changed by gaba:

Old description:

> * Write IPv6 reachability proposal
> * Optional: Write optional parts of IPv6 reachability proposal

New description:

 * Write proposal 311: Relay IPv6 Reachability
 * Optional: Write optional parts of IPv6 reachability proposal

--

--
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] #33049 [Core Tor/Tor]: O1.2 - Make relays figure out their own IPv6 address

[Tor Bug Tracker & Wiki]

#33049: O1.2 -  Make relays figure out their own IPv6 address
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+
Description changed by gaba:

Old description:

> * Write IPv6 address auto-detection proposal
> * Optional: Write optional parts of IPv6 address auto-detection proposal

New description:

 * Write proposal 312: Automatic Relay IPv6 Addresses
 * Optional: Write optional parts of IPv6 address auto-detection proposal

--

--
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] #33051 [Core Tor/Tor]: O1.4 - Measure the number of Tor relays that support IPv6 reachability checks

[Tor Bug Tracker & Wiki]

#33051: O1.4 - Measure the number of Tor relays that support IPv6 reachability
checks
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by nusenu):

 onionoo provides you with that data.

 daily updated onionoo based IPv6 stats:
 https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

--
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] #33051 [Core Tor/Tor]: O1.4 - Measure the number of Tor relays that support IPv6 reachability checks

[Tor Bug Tracker & Wiki]

#33051: O1.4 - Measure the number of Tor relays that support IPv6 reachability
checks
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+
Description changed by gaba:

Old description:



New description:

 This objective will include the proposal 311: Relay IPv6 Reachability

--

--
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] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by nusenu):

 > By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but
 functionally, only 20% of Tor’s available bandwidth supports IPv6.

 These numbers seem outdated.

 onionoo data from 2020-01-24 23:00 UTC:

 What cw fraction / guard/middle/exit probability has an IPv6 ORPort?
 CW Fraction: 31.83%
 Guard: 29.06%
 Middle:  29.79%
 Exit: 39.24%
 Relays count:  1210

 daily updated onionoo based IPv6 stats:
 https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

--
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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

[Tor Bug Tracker & Wiki]

#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018   | Points:  0.4
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 I have been running this patch on moria1 lately, with an additional patch
 where I send a 503 response to vanilla-flavored consensus fetches, or old-
 style descriptor fetches, if they're not from a dir auth or relay address,
 even if I otherwise have enough bandwidth to answer them.

 With both patches in place, moria's outbound traffic has gone from
 200-500mbit/s down to 10-40mbit/s.

 Here are some stats from a one hour period (1400 to 1500 EST):

 
 == Dir auth requests ==

 I whitelisted 13 dirport connections from dir auths during this time:
 {{{
 Jan 24 14:18:32.445 [notice] Prioritizing dir auth response
 Jan 24 14:31:28.374 [notice] Prioritizing dir auth response
 Jan 24 14:50:03.921 [notice] Prioritizing dir auth response
 Jan 24 14:50:04.452 [notice] Prioritizing dir auth response
 Jan 24 14:50:04.836 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.016 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.261 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.458 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.575 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.697 [notice] Prioritizing dir auth response
 Jan 24 14:50:05.808 [notice] Prioritizing dir auth response
 Jan 24 14:50:07.510 [notice] Prioritizing dir auth response
 Jan 24 14:50:09.915 [notice] Prioritizing dir auth response
 }}}
 Looking through the logs, these are all for /extra/d or server/d, i.e.
 old-style descriptors. Most of them occur a little bit after :50, which
 makes sense because that would be when those other dir auths discovered
 new descriptors from the vote I just sent them.

 
 == Relay requests ==

 I whitelisted 847 dirport requests from relay addresses during this
 period. Of these, 763 of them happened in the first half of the period
 (:00 through :30), which makes sense because fetch-extra-early tries to
 get a cached copy of the consensus in place before clients start asking
 for it. Accounting for a bit of time skew, 830 of the 847 happened between
 :00 and :33.

 Spot-checking these fetches, every single one of them that I looked at was
 a fetch for /micro/d, i.e. fetching a new microdescriptor. That's weird! I
 would have thought many of them would be fetching a microdesc-flavored
 consensus. I wonder if I am failing to log those, or if the process of
 answering them bypasses global_write_bucket_low().

 
 == Non-relay requests ==

 I sent back 110818 "503" responses during this hour (i.e. averaging over
 thirty "503" responses per second).

 Of those, 105452 were for "network status lists":
 Jan 24 14:00:00.038 [info] handle_get_current_consensus(): Client asked
 for network status lists, but we've been writing too many bytes lately.
 Sending 503 Dir busy.
 which I think is almost entirely requests to

 And the remaining 5366 were for "server descriptors":
 Jan 24 14:00:02.387 [info] handle_get_descriptor(): Client asked for
 server descriptors, but we've been writing too many bytes lately. Sending
 503 Dir busy.

--
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] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by arma):

 Replying to [ticket:33045 gaba]:
 > In order to better support IPv6, we aim to increase the client to Guard
 relay bandwidth that supports IPv6 to 33%.

 Great goal! One of the steps that will help the network health team help
 us get there is if we have a way to visualize progress. Like, a graph on
 the metrics site, or even a graph off to the side of the metrics site if
 they are too worried about having to maintain it forever, and maybe it
 only needs to be updated once a day if that's easier, where anybody can
 check what number we're at today.

 Then it becomes an advocacy thing where we can cheer ourselves on for
 making progress, and point relay operators to so they can see the impact
 of their changes.

 teor has identified some great technical improvements that will make it
 easier for relay operators to help out here, and we should definitely do
 those in order to make this change sustainable. But doing the
 visualization in parallel, so we can see our progress, would be swell.

 Having the automation of a graph over time also lets anybody notice, even
 after we close this ticket as completed, that the number has mysteriously
 dropped and needs to be looked into.

 Gaba, is this something you can bring to the metrics team? Especially if
 teor gives them a script that takes in a consensus and outputs a fraction?

--
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] #32975 [Core Tor/Tor]: Tor Socks unresponsive behaviour after 24-36 hours of runtime

[Tor Bug Tracker & Wiki]

#32975: Tor Socks unresponsive behaviour after 24-36 hours of runtime
--+--
 Reporter:  ntrn  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Can you point us to which relay this is?

 What are you doing to decide that the socksport is unresponsive? Or is it
 something else, since you say 'socks proxy' not socksport?

 The "No buffer space available" error seems weird and like a good hint:
 maybe the vps is artificially constrained in some resource like sockets or
 kernel buffers. I'd check 'dmesg' too.

--
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

[tor-bugs] #33052 [Core Tor/Tor]: O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6

[Tor Bug Tracker & Wiki]

#33052: O1.5 - Measure the number of connections, and consumed bandwidth, using
IPv4 and IPv6
+
 Reporter:  gaba|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #33045
   Points:  |   Reviewer:
  Sponsor:  Sponsor55-must  |
+


--
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

[tor-bugs] #33051 [Core Tor/Tor]: O1.4 - Measure the number of Tor relays that support IPv6 reachability checks

[Tor Bug Tracker & Wiki]

#33051: O1.4 - Measure the number of Tor relays that support IPv6 reachability
checks
+
 Reporter:  gaba|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #33045
   Points:  |   Reviewer:
  Sponsor:  Sponsor55-must  |
+


--
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

[tor-bugs] #33050 [Core Tor/Tor]: O1.3 Integration test Tor relays over IPv6 using chutney

[Tor Bug Tracker & Wiki]

#33050: O1.3 Integration test Tor relays over IPv6 using chutney
+
 Reporter:  gaba|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #33045
   Points:  |   Reviewer:
  Sponsor:  Sponsor55-must  |
+


--
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] #33049 [Core Tor/Tor]: O1.2 - Make relays figure out their own IPv6 address

[Tor Bug Tracker & Wiki]

#33049: O1.2 -  Make relays figure out their own IPv6 address
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+
Changes (by gaba):

 * type:  defect => project


--
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

[tor-bugs] #33049 [Core Tor/Tor]: O1.2 - Make relays figure out their own IPv6 address

[Tor Bug Tracker & Wiki]

#33049: O1.2 -  Make relays figure out their own IPv6 address
+
 Reporter:  gaba|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #33045
   Points:  |   Reviewer:
  Sponsor:  Sponsor55-must  |
+
 * Write IPv6 address auto-detection proposal
 * Optional: Write optional parts of IPv6 address auto-detection proposal

--
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] #33048 [Core Tor/Tor]: O1.1 - Propose and implement IPv6 ORPort reachability checks on relays (was: Propose and implement IPv6 ORPort reachability checks on relays)

[Tor Bug Tracker & Wiki]

#33048: O1.1 - Propose and implement IPv6 ORPort reachability checks on relays
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33045| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by gaba):

 

--
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] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+
Changes (by gaba):

 * sponsor:  Sponsor55 => Sponsor55-must


--
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

[tor-bugs] #33048 [Core Tor/Tor]: Propose and implement IPv6 ORPort reachability checks on relays

[Tor Bug Tracker & Wiki]

#33048: Propose and implement IPv6 ORPort reachability checks on relays
+
 Reporter:  gaba|  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #33045
   Points:  |   Reviewer:
  Sponsor:  Sponsor55-must  |
+
 * Write IPv6 reachability proposal
 * Optional: Write optional parts of IPv6 reachability proposal

--
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] #32975 [Core Tor/Tor]: Tor Socks unresponsive behaviour after 24-36 hours of runtime

[Tor Bug Tracker & Wiki]

#32975: Tor Socks unresponsive behaviour after 24-36 hours of runtime
--+--
 Reporter:  ntrn  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ntrn):

 did not solved the issue.
 Have to reboot the server at least daily to let it run 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] #31427 [Circumvention/BridgeDB]: Update BridgeDB's documentation

[Tor Bug Tracker & Wiki]

#31427: Update BridgeDB's documentation
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o22a3 anti-censorship-roadmap-   |  Actual Points:
  2020Q1 |
Parent ID:   | Points:  0.2
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30
-+-
Changes (by gaba):

 * keywords:   => s30-o22a3 anti-censorship-roadmap-2020Q1
 * status:  needs_information => needs_revision
 * sponsor:   => Sponsor30


Comment:

 This is almost done. Let's try to include it in the S30.

--
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] #33039 [Core Tor/Tor]: Memory leaks in handle_control_getconf

[Tor Bug Tracker & Wiki]

#33039: Memory leaks in handle_control_getconf
-+-
 Reporter:  nickm|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-must, memory-leak, regression,   |  Actual Points:  2
  tor-tests-coverage |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => nickm


Comment:

 This looks solid to me, and CI is passing.  Thanks!  I'm merging it now.

 Please close this tickete, after un-parenting the child or

--
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] #33039 [Core Tor/Tor]: Memory leaks in handle_control_getconf

[Tor Bug Tracker & Wiki]

#33039: Memory leaks in handle_control_getconf
-+-
 Reporter:  nickm|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-must, memory-leak, regression,   |  Actual Points:  2
  tor-tests-coverage |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 This looks solid to me, and CI is passing.  Thanks!  I'm merging it now.

 Please close this ticket, after un-parenting or closing the child ticket
 as appropriate?

--
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

[tor-bugs] #33047 [Circumvention]: How can we optimise the anti-censorship suite for mobile?

[Tor Bug Tracker & Wiki]

#33047: How can we optimise the anti-censorship suite for mobile?
---+
 Reporter:  phw|  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Mobile applications have significant space constraints, which makes it
 difficult to bundle Tor and its circumvention suite.  For example,
 obfs4proxy 0.0.7 in Debian Buster currently has a binary size of 5.2 MB
 and snowflake-client in Tor Browser 9.5 has a binary size of 7.7 MB. This
 is largely due to both projects being implemented in golang, which only
 supports static linking.

 What can we do to reduce our circumvention suite's disk footprint? The
 obvious answer would be to re-implement obfs4 and snowflake in a
 dynamically-linked language. What else can we do?

--
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] #33039 [Core Tor/Tor]: Memory leaks in handle_control_getconf

[Tor Bug Tracker & Wiki]

#33039: Memory leaks in handle_control_getconf
-+-
 Reporter:  nickm|  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-must, memory-leak, regression,   |  Actual Points:  2
  tor-tests-coverage |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * status:  accepted => needs_review
 * actualpoints:   => 2


Comment:

 Pull request in https://github.com/torproject/tor/pull/1684

 As a bonus, unit test coverage in `handle_control_getconf()` is now at
 100%.

 I did confirm that the new unit tests correctly detect the leak under
 valgrind on Ubuntu Bionic.  (valgrind doesn't work with OpenSSL on Xenial,
 so I had to install a new VM.)  For some reason, AddressSanitizer doesn't
 catch the leaks in tor itself, but does catch them in the test program.
 (Both Xenial and Bionic, and I think both clang and gcc.)  I wish we could
 understand why.

--
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] #30939 [Applications/Tor Browser]: Use Firefox's Enhanced Tracking Protection as a means for performance improvements

[Tor Bug Tracker & Wiki]

#30939: Use Firefox's Enhanced Tracking Protection as a means for performance
improvements
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 #33046 for reference and historical record (or however that works).

--
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] #33046 [Applications/Tor Browser]: Test ETP enabled in Tor Browser

[Tor Bug Tracker & Wiki]

#33046: Test ETP enabled in Tor Browser
--+
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by sysrqb):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 And attached script produced some graphs from the results.

--
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] #33046 [Applications/Tor Browser]: Test ETP enabled in Tor Browser

[Tor Bug Tracker & Wiki]

#33046: Test ETP enabled in Tor Browser
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * Attachment "torbrowser_perf.py" 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

[tor-bugs] #33046 [Applications/Tor Browser]: Test ETP enabled in Tor Browser

[Tor Bug Tracker & Wiki]

#33046: Test ETP enabled in Tor Browser
--+-
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-performance
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Last year I ran some experiments comparing the loading of pages with
 Enhanced Tracking Protection (ETP) disabled and then with it enabled. The
 results from these experiments were not statistically significant, but the
 preliminary results showed that ETP noticeably reduces the best and
 average case timing, but the variance is still problematic.

 On the bright side, this is a good starting point. From an email I sent:
 {{{
 I started measuring Tor Browser's
 speed while loading various webpages. This was with the goal of
 comparing Tor Browser with the measurements Mozilla made two years ago
 [0] when they released Quantum (and compared Firefox and Chrome). It
 uses benchmarks provided by Firefox's Javascript API (using the
 Navigation Timing API).

 It seems like Tracking Protection does has a noticable impact on
 page-load time. I still have the feeling that investigating ad and
 tracker blockers is a worthwhile initiative (especially if we want to
 remain relevant). There are some interesting results that require
 further analysis because I can't explain them right now.

 In the future, it would be very helpful if we extended these
 measurements by including tor controller events related to circuit
 build and stream sentconnect/connected events. We should also run these
 tests from different geographic areas (particularly locations with low
 throughput connections).

 My takeaway from this is if (ideally) pages should load with 6 seconds
 (as was Mozilla's target [0]), then I believe this is achievable as the
 other network improvements (correcting weighting, solving bottlenecks,
 etc.) are rolled out. In addition, as usual, this will require some
 advocacy for helping promote tor-friendly websites.

 

 Mozilla's measurements used Selenium for automating the tests. Luckily,
 Kushal already made a Tor Browser Selenium driver[1], so adapting
 Mozilla's test[2] was relatively simple.

 These measurements used a slightly non-standard Tor Browser
 configuration. The Navigation Timing API is a fingerprinting vector, so
 it is disabled by default. |privacy.resistFingerprinting| was disabled
 for these tests. Similarly, NoScript's XSS protection required manual
 input while pages loaded, so the XSS protection was disabled for these
 tests.

 Two sets of tests were run. The first test did not change any other Tor
 Browser settings. The second test enabled Tracking Protection. Each test
 loaded 20 webpages[3] (19 webpages in that file plus
 http://newsweek.com/). The list of webpages is shuffled before each run,
 and Tor Browser is restarted between each run.

 [0]
 https://hacks.mozilla.org/2017/11/comparing-browser-page-load-time-an-
 introduction-to-methodology/
 [1] https://github.com/webfp/tor-browser-selenium
 [2] https://github.com/onkeltom/browser_pageloadspeed
 [3]
 https://github.com/onkeltom/browser_pageloadspeed/blob/master/news.txt
 [4] https://w3c.github.io/navigation-timing/#processing-model
 }}}

 #30939 is a consequence of this work.

 I described in another email how the tests were run:
 {{{
 I pushed a branch page_load_timing on
 https://github.com/sysrqb/tor-browser-selenium/

 It requires the same setup configuration as described in the README. I
 installed the dependencies with --user.
   - pip install --user tbselenium
   - pip install --user -r tor-browser-selenium/requirements-dev.txt
   - Downloaded geckodriver from the Github repo

 I didn't use xvfb (simply for convenience), so I ran the page-load test
 directly with:

 $ NO_XVFB=1 TBB_PATH=~/tor-browser_en-US/ py.test tor-browser-
 selenium/tbselenium/test/test_pageload.py

 Change TBB_PATH and path/to/test_pageload.py, as needed. Don't be
 surprised if the browser doesn't launch immediately (it take 5-10
 seconds on slower computers).

 And, in case you're not aware, tor-browser-selenium currently only works
 on Linux (the README says Debian/Ubuntu and I successfully used it on
 Fedora). You'll need a system tor installed, too (or at least an
 instance of tor running already listening on port 9050). I'd like to add
 support for letting Tor Browser bootstrap and control its own tor in the
 future.
 }}}

 See #32976 for a better way we get geckodriver.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The 

Re: [tor-bugs] #32642 [Archived/Nyx]: nyx crashes on startup with `ValueError: Input needs to be a non-negative integer, got '-33538'`

[Tor Bug Tracker & Wiki]

#32642: nyx crashes on startup with `ValueError: Input needs to be a 
non-negative
integer, got '-33538'`
--+
 Reporter:  strugee   |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Archived/Nyx  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by strugee):

 Hey, I meant to update this ticket months ago and totally forgot - turns
 out that actually the bug seemed to go away when I restarted the core Tor
 daemon. Interestingly apparently while this was happening the network did
 not recognize my relay as a relay (according to Tor Metrics/ExoneraTor,
 can't remember which I checked - and confirmed by the amount of traffic
 after Tor was restarted). I might consider backing out this patch since
 the bug seems to be in Tor core and not Nyx, and the patch IIRC didn't
 actually fix anything 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

[tor-bugs] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor55 |
--+
 By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but
 functionally, only 20% of Tor’s available bandwidth supports IPv6. This is
 because some Guard relays are also Exit relays, and as such, they are only
 used as Exits by Tor clients. These limitations mean that even if an Exit
 relay supports IPv6, it doesn’t functionally increase the Tor network’s
 client to Guard IPv6 bandwidth.

 In order to better support IPv6, we aim to increase the client to Guard
 relay bandwidth that supports IPv6 to 33%. Reaching this goal (and
 completing this project) is the first step in a longer-term effort to
 implement “fast fallback,” which will make sure that Tor clients first try
 IPv4 and then try IPv6 after a short delay, using whichever option works.

 To increase the functional relay bandwidth that supports IPv6, we need to
 improve the way we handle configuration for dual stack Tor relays (relays
 that support both IPv4 and IPv6). As it stands, dual stack relays require
 some manual configuration, which can be a setup barrier for relay
 operators. Automating relay IPv6 address discovery and reachability checks
 will help operators to run more dual stack relays more easily and, over
 time, increase the number of relays that support IPv6.

 More information about this project at
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55

--
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] #33035 [Applications/Tor Browser]: create strings for onion service error pages

[Tor Bug Tracker & Wiki]

#33035: create strings for onion service error pages
--+
 Reporter:  brade |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19251| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by brade):

 Thanks! I think we should keep the Learn More Label the same as Mozilla
 (Learn More...) and consistent for all of the errors, so I don't think we
 need that last column.

--
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] #33035 [Applications/Tor Browser]: create strings for onion service error pages

[Tor Bug Tracker & Wiki]

#33035: create strings for onion service error pages
--+
 Reporter:  brade |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19251| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by antonela):

 Thanks for filing this ticket brade. I've started a spreadsheet here
 https://nc.torproject.net/s/QAwoi7MfeeiTPp2

--
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] #33044 [Community/Tor Support]: Outreachy internship timeline

[Tor Bug Tracker & Wiki]

#33044: Outreachy internship timeline
---+-
 Reporter:  PROTechThor|  Owner:  PROTechThor
 Type:  project| Status:  assigned
 Priority:  Very Low   |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Trivial| Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by ggus):

 * owner:  (none) => PROTechThor
 * status:  new => assigned
 * component:  - Select a component => Community/Tor Support


--
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] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,|  Actual Points:
  network-team-roadmap-november, |
  TorBrowserTeam202001, network-team-roadmap-|
  2020Q1 |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:14 acat]:
 > 4. Via "some UX solution", show the human-memorable .tor.onion in the
 urlbar even though the actual location is a "long" .onion.
 >
 Yes. We should show the memorable .tor.onion in the url bar and we should
 rely on the circuit display for showing the long onion. I made some props
 [https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/30024/30024%20-%20TB9%20-%20onions.png, here]. Look at
 the image 4.0.

 > 5. (Maybe) also do 3) when the user navigates to some .onion directly
 for which we know some *.tor.onion ("reverse lookup").
 >
 I'm thinking about this flow.

 > 6. (Maybe) allow users to view the local .tor.onion -> .onion mappings.
 >
 I don't think this is prior to this release.

--
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] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, tor-ux,|  Actual Points:
  network-team-roadmap-november, |
  TorBrowserTeam202001, network-team-roadmap-|
  2020Q1 |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Replying to [comment:11 acat]:
 > Some thoughts after thinking a bit how to implement this.

 thanks for sharing this walking through, acat :)

 > A few questions/issues regarding showing short `.tor.onion` in urlbar:
 >
 >   1. Whenever there is a `.tor.onion` -> `.onion` redirect, should we
 display the full original URL in the urlbar,   or just replace the
 hostname for the human-memorable one in the final URL? For example, let's
 say we observe a redirect from http://nytimes.securedrop.tor.onion to
 https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from
 `.tor.onion` + adding www). In this case I think it would not make much
 sense to show the original URL, but just display
 https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution
 I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on
 it).
 >

 Right. The urlbar should display the onion icon + the .onion name:
 `[⊚] https://www.[nytimes.securedrop.tor.onion]`

 >   2. What should we do when user keeps navigating in subpages of some
 `.onion`, given the fact that the `.tor.onion` -> `.onion` is only
 observed in the first navigation? Should we show the human-memorable
 `.tor.onion` in the urlbar for that tab until the user navigates away from
 the underlying `.onion`? Do we also need to show `.tor.onion` for links
 opened in a new tab from there?
 >

 Maybe, ideally, yes. I wonder what sysrqb or pospeselr think about this.
 It is hard for me to map all the problems it could carry.

 >   3. Do we need to show `.tor.onion` when user navigates directly to a
 `.onion` page for which we have some `.tor.onion` "rule"? (mentioned by
 sysrqb in a IRC conversation)
 >

 This is a good question and I think we should define it before anything
 because it can be very weird. If we have a strong communication about
 onion names (via trusted parties, like SecureDrop), then showing an
 unmemorable onion address to end-users is not smart. If a user
 writes/copypaste the `.onion` we can think about how to communicate the
 `.tor.onion` redirect for first time users with any UI fashion (a
 doorhanger can do this work very nicely)

 > So I would suggest discussing/deciding about the `Add support for
 viewing rulesets (?)` feature, as I'm not sure how it could look like if
 we are going to do this with https-everywhere.
 >

 Maybe this is out of scope. We will not allow users to add nor remove
 .onion related rulesets. IMO showing them at the UI is not needed on this
 sprint.

--
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

[tor-bugs] #33044 [- Select a component]: Outreachy internship timeline

[Tor Bug Tracker & Wiki]

#33044: Outreachy internship timeline
-+--
 Reporter:  PROTechThor  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Very Low |  Component:  - Select a component
  Version:   |   Severity:  Trivial
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I'm rearranging the timeline of my Outreachy internship, keeping tracking
 of what's been done so far and upcoming tasks.

 **Month 1 (Dec 3 to Jan 3):**
 - Resolved about 250 frontdesk tickets, not counting those marked as spam.
 - https://github.com/torproject/lego/pull/13
 - Opened a new ticket based on user feedback:
 https://trac.torproject.org/projects/tor/ticket/32853
 - Wrote the December 2019 feedback report:
 https://lists.torproject.org/pipermail/tor-
 project/2020-January/002645.html

 **Month 2 (Jan 4 to Feb 4):**
 - Resolved about 30 new frontdesk tickets, not counting those marked as
 spam.
 - Closed some old unassigned open frontdesk tickets.
 - The frontdesk queue has been reduced from 320 to 40 tickets.
 - Worked on the Tor Mobile manual:
 https://github.com/torproject/manual/pull/58
 - Created new issue based on user feedback:
 https://dip.torproject.org/torproject/web/tpo/issues/56

--
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] #32650 [Community/Translations]: Check translations for bogus characters

[Tor Bug Tracker & Wiki]

#32650: Check translations for bogus characters
+--
 Reporter:  gk  |  Owner:  emmapeel
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by pili):

 * cc: tbb-team (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] #33028 [Core Tor/Tor]: v0.4.1.6 bug journalctl failed assertion

[Tor Bug Tracker & Wiki]

#33028: v0.4.1.6 bug journalctl failed assertion
--+--
 Reporter:  anonproject   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:  hs cache, newnym  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * component:  - Select a component => Core Tor/Tor


--
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] #33035 [Applications/Tor Browser]: create strings for onion service error pages

[Tor Bug Tracker & Wiki]

#33035: create strings for onion service error pages
--+
 Reporter:  brade |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19251| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * cc: stephw (added)


Comment:

 Hi Steph,

 Can you help us craft some good strings/error messages? Should we have a
 quick meeting/brainstorming session with antonela about this?

--
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