Go to some HTTP Onion like http://yjuwkcxlgo7f7o6s.onion/ (archive.tp, see onion.tp)
Click on the NoScript icon, the popup will show you yjuwkcxlgo7f7o6s.onion in red (contrary to some HTTPS Onion like https://3g2upl4pq6kufc4m.onion/ (DDG Onion))
(Not sure if there's something needed on the browser side so that's why I'm setting the component as TB though this is probably entirely a NoScript issue)
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.
PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.
That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.
Trac: Status: new to closed Resolution: N/Ato wontfix
PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.
That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.
I think it might be a good idea, but only if I've got a sure-fire way to tell NoScript is running inside the Tor browser.
PS: Just to be clear, I'm not calling for JS to be enabled for HTTP onions on Safer security setting in this ticket, only that ALL onions should be marked as secure in the NoScript UI.
That's a good thing to bring up with the NoScript dev but it is nothing we'll fix in Tor Browser ourselves.
I think it might be a good idea, but only if I've got a sure-fire way to tell NoScript is running inside the Tor browser.
Thanks, that's better. There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)
A general note, while testing rc11:
After installing it in the browser I needed to click twice on the NoScript icon until the page related info showed up. On first click only a small empty menu was visible.
After restarting the browser it takes like 5-10 second until the NoScript icon gets clickable at all and CPU of my laptop gets eaten meanwhile. There is something computationally heavy going on in the background here...
There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)
There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)
There is still the scary http: in red which should not be relevant for .onions either. Additionally, the expectation here is that onions over http:// on medium level security can actually run JavaScript etc. because http:// is secure for .onion domains They should get treated as loaded over https://. Could you address those two items for Tor Browser users? (I am fine opening a new bug for the latter if you like)
Seems to work nicely, thanks! FWIW: I can still see the problem mentioned in comment:9:ticket:27313 that the NoScript settings show only up every other time after updating the NoScript version in the browser. Pasting here my STR for convenience:
The bug as described is visible: the NoScript menu contents are shown only every other click on the icon (otherwise the menu is empty). A restart seems to fix that, though.
Okay, I managed to reproduce my other issue as well: the start-up of rc15 is extremely slow on higher security levels. E.g. on my machine there is a gap of almost 10 seconds between the first two messages:
[10-29 14:15:22] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"collect","recipientInfo":{"tabId":1,"frameId":0}},"_messageName":"collect"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]
and
[10-29 14:15:31] Torbutton INFO: Message received from NoScript: [{"__meta":{"name":"started","recipientInfo":null},"_messageName":"started"},{"id":"{73a6fe31-595d-460b-a920-fcc0f8843232}","url":"moz-extension://07d31867-b62c-4014-aa90-56981c414124/_generated_background_page.html","envType":"addon_child","extensionId":"{73a6fe31-595d-460b-a920-fcc0f8843232}","contextId":274877906946},null]
which makes me a bit nervous given that the user can meanwhile surf the web but the security settings are set only after the started or pageshow` one.
I suspect that's because of legacy/trac#23719 (moved), actually. I wonder whether stable users would be hitting the bug on the standard mode, too, given that WASM is disabled there as well. ma1: What kind of JIT/WASM parts are you using for the initial loading of NoScript's state that could cause this?
Trac: Keywords: TorBrowserTeam201910R deleted, TorBrowserTeam201910 added Status: reopened to needs_information
Fixed with the bump to 11.0.4 (commit 6cbbd55840577c4d3ab5581e76cffde26a5f5ff6 and 8623975e60c99b2a526bbda133168d7de5f8d329 on tor-browser-build's maint-9.0 and master branches), thanks!
The issues mentioned in my two previous comments are still visible, though.
Trac: Status: needs_information to closed Resolution: N/Ato fixed
I suspect that's because of legacy/trac#23719 (moved), actually. I wonder whether stable users would be hitting the bug on the standard mode, too, given that WASM is disabled there as well. ma1: What kind of JIT/WASM parts are you using for the initial loading of NoScript's state that could cause this?
Actually that issue is solved with 11.0.7 for me. However, the options button is still behaving funky. Part of that is legacy/trac#23719 (moved) but other parts not. I've opened legacy/trac#32403 (moved) for the latter.