Firefox/NoScript bug with major downstream effects
Dear TBB developers, I wanted to make sure you've seen this issue regarding uploads and NoScript's "Sanitize cross-site suspicious requests" option: https://bugzilla.mozilla.org/show_bug.cgi?id=1532530 https://github.com/hackademix/noscript/issues/64 https://github.com/freedomofpress/securedrop/issues/4078 https://github.com/micahflee/onionshare/issues/899 As far as we've been able to tell, this option, which is enabled by default and intended to guard against XSS attacks, is causing large uploads in non-JS upload forms to break intermittently. This may ultimately be due to a bug in Firefox itself (the first link). The only reason the SecureDrop and OnionShare issues are closed is that we've implemented ugly workaround instructions for now, and NoScript considers it an upstream issue in Firefox. Since this impacts Tor browser users much more than Firefox users, perhaps some folks on this list may be able to help bring this to a resolution. In any case, I wanted to flag it to this group given the impact his issue is having. Warmly, Erik -- Principal Project Manager Freedom of the Press Foundation
Erik Moeller:
Dear TBB developers,
I wanted to make sure you've seen this issue regarding uploads and NoScript's "Sanitize cross-site suspicious requests" option:
https://bugzilla.mozilla.org/show_bug.cgi?id=1532530 https://github.com/hackademix/noscript/issues/64 https://github.com/freedomofpress/securedrop/issues/4078 https://github.com/micahflee/onionshare/issues/899
As far as we've been able to tell, this option, which is enabled by default and intended to guard against XSS attacks, is causing large uploads in non-JS upload forms to break intermittently. This may ultimately be due to a bug in Firefox itself (the first link).
The only reason the SecureDrop and OnionShare issues are closed is that we've implemented ugly workaround instructions for now, and NoScript considers it an upstream issue in Firefox.
Since this impacts Tor browser users much more than Firefox users, perhaps some folks on this list may be able to help bring this to a resolution. In any case, I wanted to flag it to this group given the impact his issue is having.
Thanks for doing so. Would it be helpful if we just disabled the XSS protection in the coming release (it causes other issues like #29647 and we have a bug treating "allow/deny always" cases (#29646) properly, so the motivation to do so is kind of independent of your bug)? Georg
On 3/6/19 11:16 PM, Georg Koppen wrote:
Thanks for doing so. Would it be helpful if we just disabled the XSS protection in the coming release (it causes other issues like #29647 and we have a bug treating "allow/deny always" cases (#29646) properly, so the motivation to do so is kind of independent of your bug)? Thanks for the quick response!
Yes, that would be very helpful; the impact of this bug appears to be widespread and severe, and it's very difficult for users and devs to understand why it is occurring and how they can work around it. If the root cause is indeed an upstream Firefox bug, perhaps the balance will shift again in favor of enabling the feature by default, once that bug is resolved. If you do decide to disable this preference, can you already anticipate when that update would likely reach users? Thank you once again for your help with this. :) Warmly, Erik -- Principal Project Manager Freedom of the Press Foundation
Erik Moeller:
On 3/6/19 11:16 PM, Georg Koppen wrote:
Thanks for doing so. Would it be helpful if we just disabled the XSS protection in the coming release (it causes other issues like #29647 and we have a bug treating "allow/deny always" cases (#29646) properly, so the motivation to do so is kind of independent of your bug)? Thanks for the quick response!
Yes, that would be very helpful; the impact of this bug appears to be widespread and severe, and it's very difficult for users and devs to understand why it is occurring and how they can work around it.
If the root cause is indeed an upstream Firefox bug, perhaps the balance will shift again in favor of enabling the feature by default, once that bug is resolved.
If you do decide to disable this preference, can you already anticipate when that update would likely reach users?
We could try to squeeze this in into the upcoming release which should be available for users next Tuesday, March 19, in Tor Browser 8.0.7. Georg
On 3/11/19 8:12 AM, Georg Koppen wrote:
We could try to squeeze this in into the upcoming release which should be available for users next Tuesday, March 19, in Tor Browser 8.0.7.
Thanks for the update; that would be fantastic, but either way, we'll keep our eyes peeled on the SecureDrop side, and will issue an update to remove the clunky workaround instructions from our upload interface once this change has landed. :) Warmly, Erik -- Principal Project Manager Freedom of the Press Foundation
Erik Moeller:
On 3/11/19 8:12 AM, Georg Koppen wrote:
We could try to squeeze this in into the upcoming release which should be available for users next Tuesday, March 19, in Tor Browser 8.0.7.
Thanks for the update; that would be fantastic, but either way, we'll keep our eyes peeled on the SecureDrop side, and will issue an update to remove the clunky workaround instructions from our upload interface once this change has landed. :)
You might want to follow https://trac.torproject.org/projects/tor/ticket/29733 to see what we are actually going to do with the help of Giorgio, if possible. Please chime in where you feel to do so! Georg
participants (2)
-
Erik Moeller -
Georg Koppen