[tor-bugs] #32874 [Webpages/Blog]: Tor blog tags not showing up on mobile

[Tor Bug Tracker & Wiki]

#32874: Tor blog tags not showing up on mobile
+---
 Reporter:  annalee_|  Owner:  hiro
 Type:  defect  | Status:  new
 Priority:  Low |  Component:  Webpages/Blog
  Version:  |   Severity:  Normal
 Keywords:  Tags, Tor Blog, Mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 While loading the Tor Blog on mobile browsers the tags of each article
 don't show up.

--
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] #32873 [Core Tor/Tor]: 'GETINFO status/fresh-relay-descs' error message unhelpful

[Tor Bug Tracker & Wiki]

#32873: 'GETINFO status/fresh-relay-descs' error message unhelpful
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Perfect! Thanks Nick, I'll give that a whirl so we can keep the test.

--
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] #32873 [Core Tor/Tor]: 'GETINFO status/fresh-relay-descs' error message unhelpful

[Tor Bug Tracker & Wiki]

#32873: 'GETINFO status/fresh-relay-descs' error message unhelpful
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I agree with your suggestions above.

 As a workaround for now, you can set the Address option to an IP.  You
 might need to set other options for Tor to accept a private IP address,
 but it should work.

--
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] #32873 [Core Tor/Tor]: 'GETINFO status/fresh-relay-descs' error message unhelpful

[Tor Bug Tracker & Wiki]

#32873: 'GETINFO status/fresh-relay-descs' error message unhelpful
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Ahhh, the log has the underlying reason...

 {{{
 Jan 03 15:10:57.267 [warn] Don't know my address while generating
 descriptor
 }}}

 This explains why the test passes ~70% of the time (sometimes we've
 bootrapped sufficiently to get an address, and sometimes we don't). There
 are two issues here...

 1. The control port's error response should get this reason rather than
 the log.

 2. If determining our address is a lengthy process our spec should state
 that it is a requirement for this GETINFO option and how to check if it is
 available.

--
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] #32873 [Core Tor/Tor]: 'GETINFO status/fresh-relay-descs' error message unhelpful

[Tor Bug Tracker & Wiki]

#32873: 'GETINFO status/fresh-relay-descs' error message unhelpful
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi network team. Recently we
 [https://gitweb.torproject.org/stem.git/commit/?id=670100c added a stem
 integ test for 'GETINFO status/fresh-relay-descs'] which in practice fails
 quite a bit with...

 {{{
 Error generating descriptor
 }}}

 
[https://gitweb.torproject.org/tor.git/tree/src/feature/control/control_getinfo.c#n1254
 This comes from tor]. I'm dropping this test from Stem. It might be useful
 for tor to provide a more explicit error message if we'd care for this to
 be a reliable and useful GETINFO option.

--
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] #32846 [Core Tor/Tor]: Tor Manual: Alphabetize Client Options

[Tor Bug Tracker & Wiki]

#32846: Tor Manual: Alphabetize Client Options
-+-
 Reporter:  swati|  Owner:  (none)
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation, tor-client, manpage,  |  Actual Points:
  gsod   |
Parent ID:  #4310| Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Thanks for the pull request!

 Running
 {{{
 sed -ne '/^== CLIEN/,/^==/p'|sed -ne 's/^\[\[\([^ ]*\)\]\].*/\1/p'
 }}}
 to extract the entry anchors, and comparing sorted and unsorted versions,
 I see:

 {{{
 --- /tmp/unsort.txt 2020-01-03 14:04:32.0 -0600
 +++ /tmp/sorted.txt 2020-01-03 14:04:47.0 -0600
 @@ -2,10 +2,9 @@
  AutomapHostsOnResolve
  AutomapHostsSuffixes
  Bridge
 -CircuitsAvailableTimeout
 -LearnCircuitBuildTimeout
  CircuitBuildTimeout
  CircuitPadding
 +CircuitsAvailableTimeout
  CircuitStreamTimeout
  ClientAutoIPv6ORPort
  ClientBootstrapConsensusAuthorityDownloadInitialDelay
 @@ -29,16 +28,19 @@
  DownloadExtraInfo
  EnforceDistinctSubnets
  EntryNodes
 -ExcludeNodes
  ExcludeExitNodes
 +ExcludeNodes
  ExitNodes
  FascistFirewall
  FirewallPorts
  GeoIPExcludeUnknown
 +GuardfractionFile
 +GuardLifetime
  HidServAuth
  HSLayer2Nodes
  HSLayer3Nodes
  HTTPTunnelPort
 +LearnCircuitBuildTimeout
  LongLivedPorts
  MapAddress
  MaxCircuitDirtiness
 @@ -47,17 +49,21 @@
  NATDPort
  NewCircuitPeriod
  NodeFamily
 +NumDirectoryGuards
 +NumEntryGuards
 +NumPrimaryGuards
  OptimisticData
 +OtherSocksPortFlags
  PathBiasCircThreshold
  PathBiasDropGuards
  PathBiasExtremeRate
 +PathBiasExtremeUseRate
  PathBiasNoticeRate
 -PathBiasWarnRate
 -PathBiasScaleThreshold
 -PathBiasUseThreshold
  PathBiasNoticeUseRate
 -PathBiasExtremeUseRate
 +PathBiasScaleThreshold
  PathBiasScaleUseThreshold
 +PathBiasUseThreshold
 +PathBiasWarnRate
  PathsNeededToBuildCircuits
  ReachableAddresses
  ReachableDirAddresses
 @@ -68,7 +74,6 @@
  SafeSocks
  SocksPolicy
  SocksPort
 -OtherSocksPortFlags
  SocksPortFlagsMisc
  SocksTimeout
  StrictNodes
 @@ -81,12 +86,7 @@
  UpdateBridgesFromAuthority
  UseBridges
  UseEntryGuards
 -GuardfractionFile
  UseGuardFraction
 -GuardLifetime
 -NumDirectoryGuards
 -NumEntryGuards
 -NumPrimaryGuards
  UseMicrodescriptors
  VirtualAddrNetworkIPv4
  VirtualAddrNetworkIPv6
 }}}

 I'm checking to see whether each out-of-order entry is commented with a
 suitable explanation. Anyone else like to help out with that?

 It looks like this line was accidentally removed from CircuitBuildTimeout?
 {{{
 -(Default: 60 seconds)
 }}}

 There are also a few possible line movements that `git diff --color-moved`
 isn't unambiguously marking as "moved", so I'll want to do some extra
 checking of those.

--
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] #32870 [Applications/Tor Browser]: Bump version of pion webrtc in Tor Browser

[Tor Bug Tracker & Wiki]

#32870: Bump version of pion webrtc in Tor Browser
--+--
 Reporter:  cohosh|  Owner:  cohosh
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .7
Parent ID:  #31971| Points:  1
 Reviewer:|Sponsor:  Sponsor28
--+--
Changes (by cohosh):

 * component:  Circumvention/Snowflake => Applications/Tor Browser


Comment:

 Switching components so the Tor Browser team know to look at 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

Re: [tor-bugs] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 Hray!! Finally!! :-D

 Please make sure this makes it in the next alpha TB 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] #32636 [Applications/Tor Launcher]: Clean up locales shipped with Tor Launcher

[Tor Bug Tracker & Wiki]

#32636: Clean up locales shipped with Tor Launcher
---+--
 Reporter:  gk |  Owner:  brade
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201912R  |  Actual Points:  0.4
Parent ID: | Points:  0.25
 Reviewer: |Sponsor:
---+--

Comment (by sysrqb):

 Replying to [comment:3 mcs]:
 > Here is a patch for review:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug32636-01=d95b8fa0448623bdd47b32b8b3ce60274bc3c540
 >

 The patch looked good, I merged it on master as commit
 d95b8fa0448623bdd47b32b8b3ce60274bc3c540. I didn't test all of the
 locales, but I tested a couple and they still look good.

--
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] #32636 [Applications/Tor Launcher]: Clean up locales shipped with Tor Launcher

[Tor Bug Tracker & Wiki]

#32636: Clean up locales shipped with Tor Launcher
---+--
 Reporter:  gk |  Owner:  brade
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201912R  |  Actual Points:  0.4
Parent ID: | Points:  0.25
 Reviewer: |Sponsor:
---+--

Comment (by sysrqb):

 Replying to [comment:3 mcs]:
 > Unfortunately, the patch is somewhat large due to all of the locale
 updates (including removal of a bunch of old locales). The good news is
 that after this is merged we will ship a lot fewer locales within the Tor
 Launcher part of Tor Browser.

 We can probably make our lives slightly easier by injecting the list of
 locales into the script via an environment variable. tor-browser-build
 should be able to set that for us. in the script, if that environment
 variable is not set then it can use a default value, like the current one.

--
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] #32872 [Community/Relays]: New https-proxy implementation for shared hosting

[Tor Bug Tracker & Wiki]

#32872: New https-proxy implementation for shared hosting
-+--
 Reporter:  SomeoneElse  |  Owner:  Nusenu
 Type:  project  | Status:  new
 Priority:  Medium   |  Component:  Community/Relays
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I was reading https protocol and noticed that by moving the request
 url(final destination) from "Request url" to something else it would allow
 us to use shared hostings as proxy servers. I had a little implementation
 of this and worked fine as a concept though I was missing detailed
 implementations. Please consider developing this protocol as it would help
 searching for relay network of tor project also helps people to create
 cheaper proxy servers and it would be harder to stop them as they have
 shared IP address. I live in such countries so please don't share my
 identity

--
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] #32871 [Core Tor/Tor]: Static linking issue with OpenSSL

[Tor Bug Tracker & Wiki]

#32871: Static linking issue with OpenSSL
--+--
 Reporter:  ffontaine |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * status:  new => needs_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

[tor-bugs] #32871 [Core Tor/Tor]: Static linking issue with OpenSSL

[Tor Bug Tracker & Wiki]

#32871: Static linking issue with OpenSSL
--+--
 Reporter:  ffontaine |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 There is a static linking issue with OpenSSL, link order of libz must be
 adjusted to solve bug with static linking and host paths must be removed
 when looking for openssl.

 The patch is available at
 https://git.buildroot.net/buildroot/tree/package/tor/0001-Fix-static-
 linking-with-OpenSSL.patch

--
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] #31873 [Circumvention/BridgeDB]: Create new bridge distribution mechanisms

[Tor Bug Tracker & Wiki]

#31873: Create new bridge distribution mechanisms
+---
 Reporter:  phw |  Owner:  (none)
 Type:  project | Status:  new
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o23a1   |  Actual Points:
Parent ID:  #31280  | Points:  20
 Reviewer:  |Sponsor:  Sponsor30-can
+---

Comment (by sigvids):

 Yes, they are free and public.

 The only explanation I can think of is suggested by the report "How China
 Detects and Blocks Shadowsocks." Blocking of SS/SSR is manual and
 discretionary. It's possibly that GFW operators choose to tolerate SS/SSR
 servers outside of politically sensitive periods.

 I speculate that Tor is seen as foreign and more threatening, and
 therefore more resolutely and consistently blocked.

--
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] #32865 [Applications/Tor Browser]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by alecmuffett):

 Replying to [comment:4 gk]:
 > Huh! We _are_ following web standards here. You might enjoy reading:
 https://tools.ietf.org/html/rfc6454#section-7.3. I'll quote the relevant
 part for you:
 > {{{
 > Whenever a user agent issues an HTTP request from a "privacy-
 > sensitive" context, the user agent MUST send the value "null" in the
 > Origin header field.
 > }}}
 > Note the `MUST` here. I think assuming that .onion sites are privacy-
 sensitive is a good default, as well.

 I stand corrected re: the text, but I differ on the presumption that all
 ".onion" sites are privacy-sensitive by default; because (apart from
 anything else) that you describe this as a "default" suggests there is a
 way to override the behaviour.

 I am not aware of a way for a website to declare to Tor Browser, that it
 should override this behaviour? Am I again wrong?

--
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] #32860 [Core Tor]: Bridge Dockerfile for Raspberry Pi 3

[Tor Bug Tracker & Wiki]

#32860: Bridge Dockerfile for Raspberry Pi 3
--+
 Reporter:  qdii  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  docker|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by phw):

 Thanks for providing a Docker file! It looks like your file changed `FROM
 debian:stable` to `FROM debian:buster-slim` and removed `libcap2-bin` from
 the list of installed packages. I wasn't aware of these "slim" images but
 that's something we may want to incorporate in our existing Docker file.
 Why did you remove libcap2-bin though? Is it not available in the slim
 image?

--
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] #31873 [Circumvention/BridgeDB]: Create new bridge distribution mechanisms

[Tor Bug Tracker & Wiki]

#31873: Create new bridge distribution mechanisms
+---
 Reporter:  phw |  Owner:  (none)
 Type:  project | Status:  new
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o23a1   |  Actual Points:
Parent ID:  #31280  | Points:  20
 Reviewer:  |Sponsor:  Sponsor30-can
+---

Comment (by phw):

 Replying to [comment:1 sigvids]:
 > Shadowsocks(R) and V2Ray proxy servers are openly distributed in
 Telegram groups.
 [[br]]
 Are these groups free for anyone to join? If so, I worry that this is not
 sustainable. Once it becomes a popular distribution mechanism, censors
 will join these groups.

--
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] #32865 [Applications/Tor Browser]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [ticket:32865 micahlee]:

 [snip]

 > One possible solution would be to treat onion sites that load resources
 from other onion sites different than onion sites loading resources from
 clearnet sites. When it's onion -> onion, it could send the actual
 `Referer` and `Origin` headers, but when it's onion -> clearnet, it could
 strip the `Referer` header and send `Origin: null`, which is the current
 behavior.

 On the positive side, I think this seems to be worth exploring to me
 (bonus points if we have a convincing argument as to why this is (still)
 spec-compliant).

--
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] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Cool, I built snowflake reproducibly using this branch:
 https://gitweb.torproject.org/user/cohosh/tor-browser-build.git/log/?h
 =pion-update

 and it's still performing well:
 {{{
 [1] "Average throughput (KB/s): 91.8818429737581"
 [1] "Maximum throughput (KB/s): 425.16961130742"
 [1] "Standard deviation: 86.1295446322453"
 }}}

 [[Image(reproducible-throughput.png,50%)]]

 I think this will solve the problem, I've put #32870 in needs_review.
 Might spend some time later looking at the changes to figure out 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] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

[Tor Bug Tracker & Wiki]

#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

 * Attachment "reproducible-throughput.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] #32865 [Applications/Tor Browser]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:3 alecmuffett]:
 > This strikes me as a farily fundamental question: Tor Browser in this
 instance is intentionally not following web standards behaviour in order
 to protect the "privacy of existence" / secrecy of given onion sites or
 pages.

 Huh! We _are_ following web standards here. You might enjoy reading:
 https://tools.ietf.org/html/rfc6454#section-7.3. I'll quote the relevant
 part for you:
 {{{
 Whenever a user agent issues an HTTP request from a "privacy-
 sensitive" context, the user agent MUST send the value "null" in the
 Origin header field.
 }}}
 Note the `MUST` here. I think assuming that .onion sites are privacy-
 sensitive is a good default, as well.

 Then there is https://fetch.spec.whatwg.org/#origin-header you might enjoy
 as well. (No referer boils actually down to Origin: null as well)

 Actually, the discussion in #32255 might be useful, too, where we fixed
 Mozilla's bogus behavior.

--
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] #32460 [Webpages/Website]: download page has confusing flow, especially with donate banner

[Tor Bug Tracker & Wiki]

#32460: download page has confusing flow, especially with donate banner
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by steph):

 Now we just need to remove the banner from all pages entirely as the
 campaign is over.

--
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]: pubsub_pub_

[Tor Bug Tracker & Wiki]

#32778: pubsub_pub_
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.5
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 as the error was reported, my tor was run as Windows service too and not
 otherwise yet. this is confirmable by me. But since i never saw this
 happening again. I sadly cannot tell more about it 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] #32865 [Applications/Tor Browser]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by alecmuffett):

 This strikes me as a farily fundamental question: Tor Browser in this
 instance is intentionally not following web standards behaviour in order
 to protect the "privacy of existence" / secrecy of given onion sites or
 pages. Questions for the TBB team include whether this non-standard
 behaviour will be plausibly copied (mandated?) in other browsers that
 implement onion networking, and how practical it is to assume that
 any/every onion site's threat model includes by-default privacy/secrecy,
 thereby breaking onions for (e.g.) TheIntercept and who knows whom else in
 future?

 Making broad assumptions of "intent" at layer 7, on the basis of layer 3,
 will continue to have unexpected consequences as Onion networking is more
 generally adopted.

--
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] #32865 [Applications/Tor Browser]: Setting Origin: null header still breaks CORS in Tor Browser 9.5

[Tor Bug Tracker & Wiki]

#32865: Setting Origin: null header still breaks CORS in Tor Browser 9.5
--+--
 Reporter:  micahlee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by alecmuffett):

 * cc: alecmuffett (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