He who does not know wrote:I know that NS is whitelist-based and not blacklist. However, as I might have been unclear about the fact: I am using NS with the "temporary allow 2nd level top domain by default" ( I mentioned it in the first post, possibly not clear enough).
Not at all. I wasn't so much wading into the ABE discussion per se. What caught my eye was your stated goal, and on seeing all the ABE stuff, I admit I kind of glazed over it and went to, "Why is he even talking about ABE for a simple scripting issue"? So yes, I missed the 2ld line.
He who does not know wrote:Hence, when I surf to an unreliable site that uses tracking/privacy/exploit scripts on the same domain as the website I am open to these scripts during my whole browsing session, no matter which domain i visit as long as it has requests on that domain.
Not exactly -- more in a minute. But there are good reasons not to use the TA-2LD, and it's less effort than you might think to do it the safer way.
I find it too tedious to revoke temporary permissions after exiting every domain all the time, or shutting down the browser after every domain.
Yep. BUT -- google-analytics.com is NOT a sub-domain of google.com. If it were analytics.google.com, it would be.
Real example:
I use Yahoo mail. For best security, I do *not* allow the 2ld yahoo.com, either by whitelisting, or your way, checking the box on General tab.
Yahoo.com includes the following *actual* sub-domains. (Third-level domain names.)
mail.yahoo.com
finance.yahoo.com
news.yahoo.com
Etc.
I find that all I need to whitelist (
once, then never again) is:
mail.yahoo.com
mail.yimg.com (also *not* a subdomain of yahoo, but a separate base 2nd-LD.)
For certain rarely-used features, I may temp-allow yahooapis.com -- *also* not the same domain as yahoo, but I'm sure you get that now.
Google works fine without scripting allowed. You lose the auto-suggest feature, but you also lose them pinpointing your location much more accurately than the Firefox controversial geolocation feature,
even with the latter disabled. about:config >
geo.enabled if true, double-click to toggle to False.
But if you allow Google's scripting, they can nail you much more accurately, and both posters here seem very privacy-conscious, as am I.
You'll find that the list of sites at which you really *need* the scripting, regardless of whether the site would like to run it or how much you trust it, is much smaller than you think. My whitelist currently has twelve (12) entries, not counting about:(something). And the Untrusted list is about two lines long, that's all.
All else is blocked by default. How hard is this, once you set up your favorite trusted sites, versus working out complex ABE rules?
Tom T. wrote:Using a machine gun to kill a fly.
It's much less effort than it looks like, and ABE can be reserved until after the basics become easy and natural.
He who does not know wrote:This is why I want to use ABE, since it ignores the too permanent whitelisting NS does the way I have set it up.
See above. Don't whitelist what doesn't need to be.
He who does not know wrote:If i were to not allow scripts at all by default that is also too tedious.
If all else fails, read the instructions.
It is something that can be learned very quickly, after which there is no tedium.
I face tedium, because in doing support here, users ask me to visit hundreds of sites that I would never visit on my own, and I do need to figure out what's needed there. But this gets kind of intuitive after a while, so unless you plan to join the support team
, or visit fifty *new* sites every day, it just isn't that hard. I'll bet it took me longer to write the
NoScript Quick Start Guide, get feedback from the rest of the team, and post it than it would take you to read and absorb it.
Giorgio put many hours into the FAQ, and many more into updating them as needed, and thousands of hours to build, maintain, and enhance a
free tool. You can't spend half an hour or so some day browsing the FAQ?
He who does not know wrote:Allow scripts globally is not tedious at all, however that is slightly too unsecure for me,
Defeats most of the purpose of NS, but still offers protections you can't get in IE.
He who does not know wrote: but if there is no choice I can accept it.
Don't.
He who does not know wrote:I am currently using FFx this way together with ABE anonymize and it is working great, but perhaps a bit too insecure.
If you're happy with your ABE settings, just add the very simple precautions above -- the ones which were
the original basis for NoScript.
He who does not know wrote:When I ran temporary allow top domain 2nd level by default with sandbox and anon in ABE, it sadly broken the possibility to run flash from 3rd party domains (which is actually a feature of sandbox).
Get
RequestPolicy. Use no default whitelist. Uncheck that 2LD, as discussed. When SiteX.com offers a YT video, TA it in RequestPolicy (or since RP allows you to specify both origin and destination, which will be coming in NS3.x -- a few hundred more hours by Giorgio, and it will be out soon), you can permanently allow requests from SiteX to YT, or wherever the video is hosted. YouTube scripts are in the default whitelist, though not actually needed for basic services. (Advanced features may require them.) If the video doesn't play, open NS menu, and if script from the video site is blocked, allow it. If you trust both, make that a permanent allow, and there's something else you'll never have to do again.
If I run temporary allow top domain 2nd level by default without ABE all works fine, until I happen to surf to a domain I don't want session allow on all websites, no matter 3rd domain or not. (lets pretend google has tracking scripts on google.com as well. I use google to search but I dont want google tracking to run on downwithsomeoppressivegovernment.now
See above. google-analytics.com is blocked by default, (even at Google!
) and the safe surrogate runs by default. Why do you feel the burden of having to do something?
He who does not know wrote:Thank you for all the help and answers, I will study the text you linked to in order to see if I have missed anything
No offense is intended in saying that most of it was missed.
I think you'll rethink this whole approach after having the facts.
Would you pilot an airplane without ever taking a flying lesson, then once you got in the air (that part's easy; it's landing that's tricky), try to figure out the various controls, how they function, what is safe and what isn't?
MacOtaku wrote:
* Another issue this would be helpful for, which whitelist mode doesn't entirely protect against, [[WRONG]] is preventing a malicious script which finds its way onto one trusted site from effecting an account on another trusted site. For example, if a successful exploit against a vulnerability in Facebook, for which I have JS enabled (so the site will work), manages to get a malicious script onto FB, I don't want that script to be able to exploit a vulnerability on which might exist on (say) Amazon, even if I happen to be logged into Amazon while reading my FB news feed. (Again, I could probably accomplish this on a site-by-site basis, but I'd like to make this work in the default case.
One hates to sound like a broken record, but our savior Signore Maone has already accomplished all of that for you, and more. (Another thousand or so hours of his time. I did the math once -- he works 36 hours/day.)
What you have described is a classic Cross-Site Scripting Attack, or XSS, and NoScript not only protects you at Amazon by default (is anyone getting tired of the word "default" in relation to NS protections yet?), it will
actually protect you at Facebook as well -- by default.
So again sounding like a broken record, please read the
XSS FAQ. Then come back here and let us know if you feel well-protected.
I'm not touching the ABE part. It's best to learn to walk before trying to fly.