Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on 32-bit platforms

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on 32-bit
platforms
+--
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.2.14-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, security-low, privcount  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:  SponsorQ
+--

Comment (by teor):

 Turns out that we only get 32 bits of random mantissa on 64-bit, so fixing
 this bug might be harder than I thought:
 {{{
   /* Test for regression to bug 23061, where we produced excessively
 granular
* random double values. */
   int low_bits_zero_count = 0;
   do {
 /* First check the value is within the range */
 d = crypto_rand_double();
 tt_assert(d >= 0);
 tt_assert(d < 1.0);
 /* Now check the granularity, by finding the last bit of the result.
  * doubles have a 53 bit mantissa. */
 d *= pow(2, 32);
 d -= trunc(d);
 low_bits_zero_count++;
 /* If the granularity is correct, this will fail with probability
  * 1 in 2**100, which is approximately the RAM bit error rate. */
 tt_assert(low_bits_zero_count <= 100);
   } while (d == 0.0);
 }}}

--
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] #23063 [Webpages/Website]: Re-point "We're hiring!" link on homepage to jobs page

[Tor Bug Tracker & Wiki]

#23063: Re-point "We're hiring!" link on homepage to jobs page
--+--
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * cc: hiro (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] #23063 [Webpages/Website]: Re-point "We're hiring!" link on homepage to jobs page

[Tor Bug Tracker & Wiki]

#23063: Re-point "We're hiring!" link on homepage to jobs page
--+--
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * status:  new => needs_review


Comment:

 Branch for review:
 https://github.com/arthuredelstein/webml/commit/23063

 Demo at https://torpat.ch/tpo

--
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] #23063 [Webpages/Website]: Re-point "We're hiring!" link on homepage to jobs page

[Tor Bug Tracker & Wiki]

#23063: Re-point "We're hiring!" link on homepage to jobs page
--+-
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Now that we are hiring for multiple positions, our "We're hiring" link
 should point to the main jobs page instead of the browser dev job page
 only.

--
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] #23062 [Applications/Tor Browser]: Tor browser bundle crashed when clicking on a link

[Tor Bug Tracker & Wiki]

#23062: Tor browser bundle crashed when clicking on a link
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Running macOS 10.12.6 (16G29)
 I clicked on http://blog.wizsec.jp/2017/07/breaking-open-mtgox-1.html#more
 inside of TBB with security slider on high, and running 7.0.2

--
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] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on 32-bit platforms

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on 32-bit
platforms
+--
 Reporter:  teor|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.2.14-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, security-low, privcount  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:  SponsorQ
+--

Comment (by teor):

 Also, this is UINT_MAX_PLUS_ONE_AS_DOUBLE:
 {{{
 #define UINT_MAX_AS_DOUBLE 4294967296.0
 }}}

--
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] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on 32-bit platforms

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on 32-bit
platforms
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core  |Version:  Tor: 0.2.2.14-alpha
  Tor/Tor |
 Severity:  Normal|   Keywords:  tor-relay, security-low, privcount
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorQ  |
--+
 On 32-bit platforms, crypto_rand_double() only produces 1 in every 2
 million possible values between 0 and 1.

 This happens because:
 * crypto_rand_double() divides a random unsigned int by UINT_MAX
 * an unsigned int on 32-bit platforms is 32 bits
 * the mantissa on a double is 53 bits

 So crypto_rand_double() doesn't fill the lower 21 bits with random values.

 This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit
 platforms.

 This fix shouldn't affect the unit tests, because they pass on 64-bit.

--
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] #22932 [Applications/Tor Browser Sandbox]: Support an amnesiac profile directory.

[Tor Bug Tracker & Wiki]

#22932: Support an amnesiac profile directory.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 At least pretend to understand the existing behavior, and don't reopen
 tickets.

--
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] #22932 [Applications/Tor Browser Sandbox]: Support an amnesiac profile directory.

[Tor Bug Tracker & Wiki]

#22932: Support an amnesiac profile directory.
--+--
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

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


Comment:

 Should it also copy the "Caches" directory into a new tmpfs mount inside
 the container?

--
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] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:17 gk]:
 > Replying to [comment:1 dcf]:
 > > A large fraction of the increase may be attributable to the use of
 FreeU Browser
 >
 > If that's the case I am wondering what the spike in Tor Browser
 downloads means. Is that the other large fraction, like 1/3 of the new
 users chose Tor Browser? Or just coincidence? Or...?

 I don't think FreeU accounts for all the new users, only part of them.
 There are for sure some Tor Browser users among them, as shown by the
 downloads graph and by the bridge users graph (FreeU users wouldn't be
 using bridges). Probably, a lot of circumvention systems and VPNs,
 including Tor, had an increase at the same time.

--
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] #23052 [Applications/Tor Browser]: I get Ukrainian IPs most of the time

[Tor Bug Tracker & Wiki]

#23052: I get Ukrainian IPs most of the time
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Jepp. So far I am not convinced this is an actual Tor Browser bug.

--
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] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

 * cc: gk (added)


Comment:

 Replying to [comment:1 dcf]:
 > A large fraction of the increase may be attributable to the use of FreeU
 Browser

 If that's the case I am wondering what the spike in Tor Browser downloads
 means. Is that the other large fraction, like 1/3 of the new users chose
 Tor Browser? Or just coincidence? 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] #23024 [Applications/Tor Browser]: Flags to increase hardening on Windows

[Tor Bug Tracker & Wiki]

#23024: Flags to increase hardening on Windows
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707  |  Actual Points:
Parent ID:  #21448| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201707R => TorBrowserTeam201707
 * cc: boklm (added)
 * status:  needs_review => needs_revision


Comment:

 I tested `-fstack-protector-strong` on top of the latest `tor-browser-
 bundle` commit. And the compilation worked as expected. Is that a `tor-
 browser-build` issue? Or maybe the GCC version bump (tor 5.4.0) resolved
 this problem?

 Regarding fortify source: Have you checked whether the `_chk` part is
 actually there after compiling with `-D_FORTIFY_SOURCE=2`? Because it does
 not seem to be the case. Doing a
 {{{
 i686-w64-mingw32-nm -C firefox.exe | grep strcpy
 }}}
 after compiling with the flags in your patch does only give ma a
 {{{
 0041b3f4 I _imp__strcpy
 00413320 T strcpy
 }}}
 (Note: In order to check it the way I did you need to compile the browser
 part with `--disable-strip` and `--disable-install-strip`)

 Assuming I am not mistaken then the likely root cause of this problem is a
 GCC bug which the RedHat people are tracking in
 https://bugzilla.redhat.com/show_bug.cgi?id=1324759.

--
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] #19479 [Applications/Tor Browser]: Document.timeline.currentTime leaks ms-resolution clock in Firefox >=48

[Tor Bug Tracker & Wiki]

#19479: Document.timeline.currentTime leaks ms-resolution clock in Firefox >=48
--+
 Reporter:  arthuredelstein   |  Owner:  rah
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ff59-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by rah):

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


--
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] #19479 [Applications/Tor Browser]: Document.timeline.currentTime leaks ms-resolution clock in Firefox >=48

[Tor Bug Tracker & Wiki]

#19479: Document.timeline.currentTime leaks ms-resolution clock in Firefox >=48
--+--
 Reporter:  arthuredelstein   |  Owner:  rah
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rah):

 Replying to [comment:8 gk]:
 > I think you should have access to `document.timeline` if you switched
 `dom.animations-api.core.enabled` to `true`

 That worked, thanks.  I tested my patch in Firefox Nightly and it worked;
 the output of document.timeline.currentTime was clamped to 100ms.  I then
 tested the patch in tor-browser and it also worked.  However, when I
 tested tor-browser without my patch, I was surprised to find that I got
 the same behaviour.  I used the same test with a binary download of the
 latest tor browser bundle and again, got the same behaviour.  My patch is
 superfluous and in fact, this bug has already been fixed.

 The DocumentTimeline Web Animations API interface inherits its currentTime
 property from AnimationTimeline.  The get method for this property is
 bound to mozilla::dom::AnimationTimeline::GetCurrentTimeAsDouble().  This
 method in turn calls the virtual method GetCurrentTime(), which is
 implemented in mozilla::dom::DocumentTimeline.  However,
 GetCurrentTimeAsDouble() uses AnimationUtils::TimeDurationToDouble() to
 convert the value returned by GetCurrentTime().  In
 [https://gitweb.torproject.org/tor-
 browser.git/commit/?h=esr24=167f4e468d8458b6e69f54ba16aef066d3f08160
 commit 167f4e468d8458b6e69f54ba16aef066d3f08160],
 AnimationUtils::TimeDurationToDouble() was modified to clamp the value to
 100ms.  In fact, that commit includes a mochitest test which checks
 document.timeline.currentTime among others.

 So, this bug was already fixed along with #16337.

--
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] #23060 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS everywhere does not activate on picgur.org

[Tor Bug Tracker & Wiki]

#23060: HTTPS everywhere does not activate on picgur.org
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |   Keywords:  HTTPS
 Severity:  Blocker  |  everywhere
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 HTTPS everywhere does not activate on picgur.org, unknown 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] #22542 [Applications/Tor Browser]: Tor Browser 7.0 Security Settings Window too small on macOS 10.12

[Tor Bug Tracker & Wiki]

#22542: Tor Browser 7.0 Security Settings Window too small on macOS 10.12
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-security-slider, TorBrowserTeam201707R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  merge_ready => needs_review


Comment:

 Replying to [comment:13 gk]:
 > Okay, I commented.
 Replying to [comment:14 brade]:
 > I replied to the comment in oniongit.
 Of course, it's good to know that you commented. But don't you think that
 openness and clearness of the project suffer? Especially, because oniongit
 without JS does nothing, except loading CPU. What was the reason to move
 the discussion to oniongit?

--
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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Thanks for review!  I'll get to the details later, but first:

 A similar discussion came up during the work on JSON handling parts of
 CollecTor and metrics-lib.  Thinking about this for a while, I'd say we
 should step back a little and tackle the main discussion to find a
 solution for having a clean API without any (cross-product) code
 duplication:

 Goals:
 1) keep metric-lib API a pure client API
 2) avoid all code duplication throughout Metrics' products

 CollecTor is an unusual metrics-lib client, because CollecTor alters
 descriptors and even creates the final descriptors (e.g., adding
 annotations, sanitizing privacy problematic data).  Thus, there is some
 functional overlap (extracting bytes, (de)compression, JSON processing)
 with metrics-lib.

 Adding another Metrics product for these cross-concerns seems too much
 overhead in terms of dealing with the additional dependency in Metrics'
 products, committing to maintain another product and another public API.
 Extending metrics-lib's API (as with the above sanitize method) breaks 1.
 On the other hand, rewriting parsing code (like for bridge-descs-
 sanitation) or de/compression functionality violates 2.

 Suggestion:
 (hope the following doesn't sound crazy)
 What about granting CollecTor the special role (which it has anyway) by
 providing an 'internal' API in metrics-lib?
 This would mainly consist in adding interfaces in sub-packages of
 o.tp.descriptor that allow access to implementational functionality, which
 are explicitly **not** part of the public (as in published javadoc-API)
 API.

 The 'internal' interfaces serve as the special contract between CollecTor
 and metrics-lib, i.e., CollecTor code should not access metrics-lib's
 implementation, but only the 'internal' and public API to avoid code
 duplication.  (For example, I could envision an interface
 o.tp.d.log.InternalLogDescriptor that enables setting the descriptor's
 byte array etc.  And, in case you worry, I would not add a 'sanitize()'
 method to such an interface.)

 This approach seems to have the benefits a new cross-concerns Metrics
 product could offer without the hassle of another code-base and what all
 is attached to it.
 I think, it also would finally pave the way for trimming down and
 streamlining all CollecTor modules.

 If that makes some sense, I can provide branches for the web-log related
 code for both metrics-lib and CollecTor.  So, we can see how the approach
 works in code.

--
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] #17959 [Applications/Tor Browser]: NoScript's click-to-play is unusable on YouTube in higher security modes

[Tor Bug Tracker & Wiki]

#17959: NoScript's click-to-play is unusable on YouTube in higher security modes
-+--
 Reporter:  teor |  Owner:  tbb-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability-website, noscript  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

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


Comment:

 Fixed by NoScript with MSE 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] #22345 [Applications/Tor Browser]: Something wrong with NoScript 5.0.4

[Tor Bug Tracker & Wiki]

#22345: Something wrong with NoScript 5.0.4
--+--
 Reporter:  cypherpunks   |  Owner:  ma1
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  new => assigned
 * owner:  tbb-team => ma1


Comment:

 Looks fixed (checked with NoScript 5.0.8.1).

--
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] #22362 [Applications/Tor Browser]: Tor Browser freezes when loading https://www.facebook.com/tr/ on a website

[Tor Bug Tracker & Wiki]

#22362: Tor Browser freezes when loading https://www.facebook.com/tr/ on a 
website
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  noscript, GeorgKoppen201707, |  Actual Points:
  TorBrowserTeam201707   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 5.0.8.1 is out and looks better.

--
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] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+--
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201707R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => TorBrowserTeam201707R
 * status:  needs_revision => 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

Re: [tor-bugs] #22981 [Applications/Tor Browser]: Don't block audio/video on https sites under Medium Security

[Tor Bug Tracker & Wiki]

#22981: Don't block audio/video on https sites under Medium Security
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security-slider,  |  Actual Points:
  ux-team|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 One other potentially useful comparison is the threat of exploits via
 content JS (non-JITed) vs the threat from video (and audio). Skimming
 through [https://www.cvedetails.com/product/3264/Mozilla-
 Firefox.html?vendor_id=452 Firefox's list of historical vulnerabilities]
 gives me the impression that the threat from scripts is higher than that
 from video. (Please correct me if I'm somehow getting the wrong
 impression.) A higher risk from scripts also appeals to my intuition,
 given that the C++ codebase exercised by Web APIs is pretty huge.

 If it's true that scripts pose a greater threat than video, the benefit of
 blocking videos while allowing scripts seems not so compelling.

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