From your responses, I think I can conclude a few things:
1) The use case for Temporarily allow all this page is for someone who inspects every site they allow and uses it as a shortcut for multiple Temporarily allow some-site.com commands.
2) The wording of Temporarily allow all this page is a little misleading -- all could mean "all forever", but it's actually "all currently known".
3) There is currently no mechanism to say "I give up -- just display everything from this site".
I think there could be some benefits from addressing these, however:
A) The pop-up menu for NoScript is already crowded. Adding two new #3's (one for Temp Allow and one for Permanent Allow) would be a bit much. If the pop-up was replaced with a dialog containing a table, it might be worth revisiting.
B) You can accomplish #3 by one or more uses of #1, so the functionality is available -- it's just a little cumbersome when sites have layers of loading.
C) Given what I glean about NoScript's implementation, I'm not sure how you would code #3. AFAIK everything in NoScript uses a specific site name. It might take some work to implement "allow these unspecified future sites".
So I think I'm convinced that, for the most part, it's not worth changing. However, I do think two things are worth clarification:
I) In the FAQ, you should explain that Temporarily allow all this page works for the scripts/embeds currently known and that multiple uses might be required if the site uses successive loading.
II) To clarify #2, you should rename Temporarily allow all this page to Temporarily allow all known this page. This indicates that if more becomes known, it is not covered by the first usage.
Thanks all,
-Foam
NoScript More Aggressive?
Re: NoScript More Aggressive?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Re: NoScript More Aggressive?
1. for me TAA is kind of a "give up". either i don't have the time or inclination to mess around trying to get something to work.
2. correct, all currently known.
3. short of disabling NoScript & restarting the browser, no.
There are probably a few times when a #3 (disable ALL NoScript without the need to restart) would come in handy.
b. not really, because even if ALL domains are allowed there are still protections afforded in XSS/CSRF/ABE/... areas.
2. correct, all currently known.
3. short of disabling NoScript & restarting the browser, no.
There are probably a few times when a #3 (disable ALL NoScript without the need to restart) would come in handy.
b. not really, because even if ALL domains are allowed there are still protections afforded in XSS/CSRF/ABE/... areas.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript More Aggressive?
Allow scripts globally (dangerous), actually.therube wrote:3. short of disabling NoScript & restarting the browser, no.
If you find yourself cornered to this option too much often and you're afraid to forget reverting it, I suggest also to turn the noscript.tempGlobal about:config preference to true: this way it's automatically reversed on browser restart.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Re: NoScript More Aggressive?
That would be for JavaScript, but my #b notes above would still apply, yes?
And it would be in that respect, that I would want my "give up" to work.b. not really, because even if ALL domains are allowed there are still protections afforded in XSS/CSRF/ABE/... areas.
Already set to, true. Not that I use Allow Global that often, but should I enable & forget, it takes care of itself on restart.noscript.tempGlobal
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090705 SeaMonkey/2.0b1pre
Re: NoScript More Aggressive?
I agree 100% with GOL (possibly for the first time in recorded history ). Unless I have some vital need for that site that forces me through the hoops, I want nothing to do with a web site that has so little respect for my time.Grumpy Old Lady wrote:...if a page then wants to pull another babushka doll out of that one, I give up on the service, retailer,fun-provider,committed political activist, or whomever and take my eyes and/or my business somewhere else - and mostly this decision is not for security (since I could always research it, couldn't I) but for the effing time-waste these webmasters create for people with even half a brain.
(p. s. Reaching waaay back in history, wasn't the WWW supposed to make things more convenient for everyone? What happened? )
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 diehard
Re: NoScript More Aggressive?
@Foam Head:
Let's say we all go to coolmusic.example.com.
therube notices the page doesn't work properly, and I notice the icon is not all blue.
(Actually, I notice the page not working properly too. I just added that because some people don't seem to know when they need to take action. I'm currently in an e-mail discussion with a mozdev who gave up on NS because "it broke his favorite sites, and how would he know that there were scripts involved?" I'm not making this up. But back on topic.)
We all TA coolmusic.example.com.
Another script tries to load, from pwned.botnet.ru.
Under Foam Head's first proposed scenario, end of story. You've just joined the Botfleet Galactica or whatever.
Alan Baxter and I would safely enjoy the cool music, unless the attacker had so compromised the site that it wouldn't function at all without the malicious script running. In which case, we'd join Grumpy Old Lady, who has already gone somewhere else.
While you are pwned.
Don't blame Giorgio because some sites are coded by idiots, either with multi-layer loading, script-injection vulnerabilities, or both. Thank him for offering you the opportunity to protect yourself, and do a redirect of your anger to the webmaster.
Or if you're really going to just "give up" every time two more clicks are required (OMG!), just allow globally and keep the XSS/CSRF protection. But what good are those if you allow any malicious script to run at will? Isn't that why you installed NS in the first place?
</soapbox>
A mention in the FAQ, related to sites still not working or icon not changing color after reload, that "Poor site coding practices, or possible infection by malicious third parties, may require you to review the NS menu again after the page reloads. Be sure that these new scripts also come from sources you trust, and not from untrusted sources or infection by third parties." ... or words to that effect ... I would support.
Let's say we all go to coolmusic.example.com.
therube notices the page doesn't work properly, and I notice the icon is not all blue.
(Actually, I notice the page not working properly too. I just added that because some people don't seem to know when they need to take action. I'm currently in an e-mail discussion with a mozdev who gave up on NS because "it broke his favorite sites, and how would he know that there were scripts involved?" I'm not making this up. But back on topic.)
We all TA coolmusic.example.com.
Another script tries to load, from pwned.botnet.ru.
Under Foam Head's first proposed scenario, end of story. You've just joined the Botfleet Galactica or whatever.
Alan Baxter and I would safely enjoy the cool music, unless the attacker had so compromised the site that it wouldn't function at all without the malicious script running. In which case, we'd join Grumpy Old Lady, who has already gone somewhere else.
While you are pwned.
Don't blame Giorgio because some sites are coded by idiots, either with multi-layer loading, script-injection vulnerabilities, or both. Thank him for offering you the opportunity to protect yourself, and do a redirect of your anger to the webmaster.
Or if you're really going to just "give up" every time two more clicks are required (OMG!), just allow globally and keep the XSS/CSRF protection. But what good are those if you allow any malicious script to run at will? Isn't that why you installed NS in the first place?
</soapbox>
IMHO, if the contents have changed in any way, it is not the same page anymore. I don't care what the URL says, if scripts are trying to load now that didn't try when you first went there, it's a different page. The Page Source is different. You're being given a new page with new scripts. "Known" is redundant. How can any tool do anything about anything it doesn't know about? The terminology would confuse users more.Foam Head wrote: I) In the FAQ, you should explain that Temporarily allow all this page works for the scripts/embeds currently known and that multiple uses might be required if the site uses successive loading.
II) To clarify #2, you should rename Temporarily allow all this page to Temporarily allow all known this page. This indicates that if more becomes known, it is not covered by the first usage
A mention in the FAQ, related to sites still not working or icon not changing color after reload, that "Poor site coding practices, or possible infection by malicious third parties, may require you to review the NS menu again after the page reloads. Be sure that these new scripts also come from sources you trust, and not from untrusted sources or infection by third parties." ... or words to that effect ... I would support.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US at an expert level; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 diehard
Re: NoScript More Aggressive?
I'm a little surprised by some of the replies. I thought when I said "So I think I'm convinced that, for the most part, it's not worth changing. However, I do think two things are worth clarification:" that we were all on the same page. No problem, I enjoy a good discussion .
I thought we all understood the "give up on this page" use case, but let me enumerate it anyway. I visit a site is not trusted enough or visited frequently enough to be in my Whitelist, but I do generally trust it. For example, my TV broke and I need to visit the manufacturer's web page to get support. It's not worth adding to my Whitelist since I'll only visit that site once or twice, but it's generally safe to trust Sony, Pioneer, etc. Thus while I'm surfing (let's say) Sony's web site, I want a setting that says "for this browser session, let sony.com run any scripts/embeds from any sites it wants". I'm still using NoScript's other protection mechanisms, but all scripts/embeds are running.
Note that this use case implies that all known *and all future* sites for sony.com are enabled. The only way to simulate this with NoScript is to use Allow Scripts Globally (dangerous) like Giorgio said, however, this leaves you naked should you accidentally visit any other web site while in the middle of your sony.com operation. In truth, NoScript has no perfect way to address this use case. The closest is to Temporarily allow all this page over and over on all pages that pop-up a warning.
Yes, this use case does leave you less protected than finding a site broken, inspecting the sites for all scripts/embeds, and manually using Temporarily allow some-site.com and/or Temporarily allow all this page as appropriate. However, not all users are power users, especially when it comes to what should be trusted web sites that just don't merit a Whitelist entry.
Side Note: I keep going back to use cases because they are a way to enumerate the problems (aka the "what") that any piece of software is meant to address. If you can't define the "what", it's pointless to discuss the "how". Thus the two fundamental questions are 1) is my "give up on this page" use case something NoScript should support? and 2) if #1 is true, are the current solutions of Allow Scripts Globally (dangerous) (hopefully being careful not to visit anywhere else) or using Temporarily allow all this page multiple times good enough?
So back to my conclusion from last time: I think NoScript should support this use case, but it doesn't handle it as well as it could. While I'd welcome some changes to better support it, because of the A, B, and C points I mentioned in my prior message, I think it is acceptable for NoScript to maintain the current functionality provided you give some clarifications.
Re Tom's clarification comments: Just because it's clear what "this page" means to you, I doubt the semantics are clear to users who don't even know what JavaScript is. Regardless, right now there is no definition of "this page" either via an adjective like "known" or via the NoScript documentation. Since misinterpreting the definition of "this page" can make a user think that NoScript is buggy, it's a no-brainer that some clarification is required.
Lastly, it is not necessarily poor design to have scripts successively load one another. In fact, the entire AJAX paradigm is to streamline the client<->server interactions of browser applications by loading server content only when the client requires it. Tho successive loading is also a mechanism that hackers can use to inject malicious code, just because it conflicts with the security model of NoScript does not mean the practice of successive loading wrong.
-Foam
I didn't know about noscript.tempGlobal (is it documented anywhere? I don't see it in the FAQ) and I did set it for my protection, but using Allow Scripts Globally (dangerous) is *not* the same as "I give up on security for this page". Allow Scripts Globally (dangerous) enables scripts for all sites/pages, not just the ones on the current page.Giorgio Maone wrote:Allow scripts globally (dangerous), actually.therube wrote:3. short of disabling NoScript & restarting the browser, no.
If you find yourself cornered to this option too much often and you're afraid to forget reverting it, I suggest also to turn the noscript.tempGlobal about:config preference to true: this way it's automatically reversed on browser restart.
I thought we all understood the "give up on this page" use case, but let me enumerate it anyway. I visit a site is not trusted enough or visited frequently enough to be in my Whitelist, but I do generally trust it. For example, my TV broke and I need to visit the manufacturer's web page to get support. It's not worth adding to my Whitelist since I'll only visit that site once or twice, but it's generally safe to trust Sony, Pioneer, etc. Thus while I'm surfing (let's say) Sony's web site, I want a setting that says "for this browser session, let sony.com run any scripts/embeds from any sites it wants". I'm still using NoScript's other protection mechanisms, but all scripts/embeds are running.
Note that this use case implies that all known *and all future* sites for sony.com are enabled. The only way to simulate this with NoScript is to use Allow Scripts Globally (dangerous) like Giorgio said, however, this leaves you naked should you accidentally visit any other web site while in the middle of your sony.com operation. In truth, NoScript has no perfect way to address this use case. The closest is to Temporarily allow all this page over and over on all pages that pop-up a warning.
Yes, this use case does leave you less protected than finding a site broken, inspecting the sites for all scripts/embeds, and manually using Temporarily allow some-site.com and/or Temporarily allow all this page as appropriate. However, not all users are power users, especially when it comes to what should be trusted web sites that just don't merit a Whitelist entry.
Side Note: I keep going back to use cases because they are a way to enumerate the problems (aka the "what") that any piece of software is meant to address. If you can't define the "what", it's pointless to discuss the "how". Thus the two fundamental questions are 1) is my "give up on this page" use case something NoScript should support? and 2) if #1 is true, are the current solutions of Allow Scripts Globally (dangerous) (hopefully being careful not to visit anywhere else) or using Temporarily allow all this page multiple times good enough?
So back to my conclusion from last time: I think NoScript should support this use case, but it doesn't handle it as well as it could. While I'd welcome some changes to better support it, because of the A, B, and C points I mentioned in my prior message, I think it is acceptable for NoScript to maintain the current functionality provided you give some clarifications.
Re Tom's clarification comments: Just because it's clear what "this page" means to you, I doubt the semantics are clear to users who don't even know what JavaScript is. Regardless, right now there is no definition of "this page" either via an adjective like "known" or via the NoScript documentation. Since misinterpreting the definition of "this page" can make a user think that NoScript is buggy, it's a no-brainer that some clarification is required.
Lastly, it is not necessarily poor design to have scripts successively load one another. In fact, the entire AJAX paradigm is to streamline the client<->server interactions of browser applications by loading server content only when the client requires it. Tho successive loading is also a mechanism that hackers can use to inject malicious code, just because it conflicts with the security model of NoScript does not mean the practice of successive loading wrong.
-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
- Giorgio Maone
- Site Admin
- Posts: 9454
- Joined: Wed Mar 18, 2009 11:22 pm
- Location: Palermo - Italy
- Contact:
Re: NoScript More Aggressive?
Just to clarify, I've got nothing against loading data progressively as needed or against AJAX.Foam Head wrote: Lastly, it is not necessarily poor design to have scripts successively load one another. In fact, the entire AJAX paradigm is to streamline the client<->server interactions of browser applications by loading server content only when the client requires it. Tho successive loading is also a mechanism that hackers can use to inject malicious code, just because it conflicts with the security model of NoScript does not mean the practice of successive loading wrong.
However here we're talking about something completely different:
Code: Select all
<script>
// includes a script from a *different domain*, which will use the same technique for
// downloading a script from a 3rd domain and so on
document.write('<scr' + 'ipt src="http://ads.doubleclick.com/somescript.js"></scr' + 'ipt>');
</script>
BTW, last time I checked XMLHttpRequest worked only same domain (pending the new crossdomain.xml which will cause many woes, I bet).
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
-
- Ambassador
- Posts: 1586
- Joined: Fri Mar 20, 2009 4:47 am
- Location: Colorado, USA
Re: NoScript More Aggressive?
@tetrasect:
I moved your post to its own topic.
I moved your post to its own topic.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5