InformAction Forums

1) It would apparently be useful for therube , who originated the RFE. It would be useful for me, and for some others who have expressed support.

2)

I have either allowed it, which means I don't mind it being accessed when it shows up or untrusted it, which means no matter how many times it shows up, its not going to do squat, so either way I am covered.

Not true. If you've never been to the site before, you don't know what calls it will make, or whether you need them.

3)

If I want to TA something I have previously decided to untrust, then I find it under untrusted menu, I TA it and move on, or if it has a placeholder, just click that, it automatically TA it and when I am done, goes back to the way I had decided in the past,

You can't "untrust" an individual object in NS itself (vs. ABE, which is not on the table here). You either uncheck "Forbid Flash" (or whatever), or you don't, and you either "Apply to whitelisted", or you don't.

I think we're talking about two different things here, so I have nothing more to add to this. So long as you don't object, then there is support for the RFE, and no objection.

Recently blocked means exactly that, recently BLOCKED. Which means that it was either done by default behavior, which means it will show up on my regular menu to make a decision, if already untrusted, then it will show up under that menu, again, already decided or will decide if its a new site. Recently blocked is simply keeping track of what decisions I have made or has been made on my behalf by default behavior, again that serves me no purpose. I already know via the regular means. That list is just that, a list of decisions made. Serves no independent purpose that the regular interface doesn't provide already.

Interesting discussion of the Recently Blocked menu...should it become its own topic?

Thrawn wrote:Interesting discussion of the Recently Blocked menu...should it become its own topic?

It already is.

I pointed GµårÐïåñ to this post because it contained an example of a site that generates Recently Blocked Sites, whereas he said everything was either allowed, untrusted, or default-denied. Yet with finely-grained permissions, RBS's pop up fairly frequently, and some may need to be TA'd.

STR: Remove any script permissions related to Microsoft's web site. Set NS Appearance to show Base and Full Domains.
Go to http://technet.microsoft.com/en-us/secu ... n/ms12-may
TA technet.microsoft.com
Note three Recently Blocked Sites, which may or may not be necessary, depending on what functions you want.
Not the best example, but the quickest I could think of.

Once again, recently blocked menu is just a list of "RECENTLY" blocked items, has nothing to do with the page you are on NOW.

To prove it, I went to your provided link, see this picture? What do you see? Do I need to really spell it out or you guys get it now?



Do you seriously think that just because I was on the netgear support page before I loaded the microsoft link you gave me that somehow they are calling netgear and need it and I need to make any damn decision about TA-ing anything on that list? Seriously?

GµårÐïåñ wrote:Once again, recently blocked menu is just a list of "RECENTLY" blocked items, has nothing to do with the page you are on NOW.

Well, as I've mentioned before, I'd personally find more value in being able to Untrust things from that menu, so that I can easily blacklist unwanted sites that I notice have recently been default-blocked.
But c'est la vie.

What I actually meant is that this is getting O/T...

GµårÐïåñ wrote:Do you seriously think that just because I was on the netgear support page before I loaded the microsoft link you gave me that somehow they are calling netgear and need it and I need to make any damn decision about TA-ing anything on that list? Seriously?

I said nothing about netgear or anywhere else. I re-did my demo, and it produced this time only one RBS, from socialservices.MS or something. Not going to bother with a pic. Last time, it produced three RBS, all from MS, related to the page I was on, and yes, I cleared RBS before the demo, d'oh.

Yes, this is O/T. I'll drop it too, but did want to note that some sites do produce RBS *of their own* that you may need. If I come across a better example, I'll post it at the RFE thread. Or maybe Giorgio will add the feature before then.

That's what I have been saying, to each their own and if its useful, use it, if he wants to implement all the power to him, _I_ just don't see any use for it, but that doesn't mean its not of value to someone else. I have just been stating my position to further the discussion, but not to change anyone's mind. To each their own and just like you said in French.

On the original topic: another addon to consider is IDND, for detecting URLs that mix international characters with English ones (which is a red flag for phishing scams).

(1)

Whenever you want to logout from "Face..." you have to enable Javascript for the following sites:
akamai... .com
face... .com

What happens, is that after logout, this website is able to trace you on other websites, if you don't deactivate Javascript again.

Is it possible to find a way, where you can easily switch off any Javascript after you have logged out from a website? Probably, a mechanism would be helpful which allows activated Javascript for the "active" website only (i.e. the website whose url you find in the web address line. When you are finished, you only need to close the browser tab or window in order to deactivate any Javascript authorization.


(2)

Whenever you are browsing in "private mode" Noscript still remembers any authorizations you gave in "normal mode". Is this a bug? It would be helpful if you know, that "private mode" really means "private mode".

nospam1234 wrote: What happens, is that after logout, this website is able to trace you on other websites, if you don't deactivate Javascript again.

If you don't want to be traced across website, you'd better look at this FAQ

nospam1234 wrote: Whenever you are browsing in "private mode" Noscript still remembers any authorizations you gave in "normal mode". Is this a bug? It would be helpful if you know, that "private mode" really means "private mode".

It would be a bug if it was the way around, i.e. if NoScript remembered the authorization you gave if private mode. When you're in private mode, the authorizations you give are temporary.

Giorgio Maone wrote:

nospam1234 wrote: What happens, is that after logout, this website is able to trace you on other websites, if you don't deactivate Javascript again.

If you don't want to be traced across website, you'd better look at this FAQ

But would you say, it is possible to implement a deactivation on any Javascript of the websites in the current tab upon closing the browser tab?

nospam1234 wrote: Whenever you are browsing in "private mode" Noscript still remembers any authorizations you gave in "normal mode". Is this a bug? It would be helpful if you know, that "private mode" really means "private mode".

It would be a bug if it was the way around, i.e. if NoScript remembered the authorization you gave if private mode. When you're in private mode, the authorizations you give are temporary.

No, these days it happened that Noscript remembered my Javascript-activation from the "normal mode" in the "private mode"

nospam1234 wrote: No, these days it happened that Noscript remembered my Javascript-activation from the "normal mode" in the "private mode"

In facts, this is not a bug. "Private mode" just means "don't save anything on disk which originates in this session/window".

Giorgio Maone wrote:

nospam1234 wrote: No, these days it happened that Noscript remembered my Javascript-activation from the "normal mode" in the "private mode"

In facts, this is not a bug. "Private mode" just means "don't save anything on disk which originates in this session/window".

I am glad to hear that it is not a bug. Thank you very much for all your efforts you put into this helpful project.

Another security-related suggestion: if you are using a modern version of Firefox, then you should be immune to the BEAST attack, so you can safely disable the weak RC4 ciphers.
In about:config, search for 'rc4' and disable the six ciphers that appear.

You can also do this using the CipherFox addon.