Page 1 of 1

RFE: Encrypted whitelist

Posted: Mon Nov 12, 2012 5:01 pm
by Devistation
It would be great if some sort of encryption with password could be set to ensure that the list of trustworthy websites can only be read by the one who has the password. This could ensure more security because if your PC is compromised by a hacker, they can not identify what web pages you visited. I was thinking about a password prompt each time you start Firefox (with Noscript of course). Of course this option should be of free will, so there should be an option to activate or deactivate this feature. I was thinking of the encryption standard AES.

Re: RFE: Encrypted whitelist

Posted: Mon Nov 12, 2012 10:10 pm
by Thrawn
What kind of compromise did you have in mind?

On the whole, detecting the list of websites you trust is a relatively minor compromise, especially if you're assuming that someone has taken complete control of your computer (and could do much worse things to you, starting with installing keyloggers/trojans). However, if it really concerns you, then you can Temporarily Allow sites instead of permanently allowing them.

Re: RFE: Encrypted whitelist

Posted: Tue Nov 13, 2012 7:58 am
by Tom T.
Devistation wrote: if your PC is compromised by a hacker, they can not identify what web pages you visited.
As Thrawn noted, if your computer is compromised by a hacker, you have far worse problems than someone knowing which sites you trust or visit.
And they can track your visits anyway, and if a keylogger or other tools are used, they'd capture your passwords, too.

The only way to attempt the level of security you're describing is by one of the various full-disk-encryption (FDE) systems, which require the password at boot time. (Not Windows Logon password protection, which is notoriously weak.) Some of them have been bypassed in various ways. And you need to be completely sure that the machine is 100% clean when you install the FDE, else the keylogger will send the hacker your FDE password along with all the others.

The best that most of us can do is to keep the hacker out in the first place, and you've taken a major step there by using NoScript, if used for maximum benefit.
For other ideas on how to defend yourself, this thread is interesting.

Re: RFE: Encrypted whitelist

Posted: Tue Nov 13, 2012 4:56 pm
by Devistation
Ok thanks for the info :D. I already thought of encrypting my whole drive but I have lot of data on it and it would take alot of time to make a backup. I just thought it was a good idea because Firefox already has something like that but only for passwords (master password). I rigged my whole computer for privacy, (deleting cache, cookies, etc with every PC start and every browser start) that's why I saw the whitelist as a little privacy problem because deleting the browser history wouldn't have much use then would it? :?

Re: RFE: Encrypted whitelist

Posted: Tue Nov 13, 2012 10:52 pm
by Thrawn
It shouldn't be possible for sites to directly detect which sites are on your whitelist. I suppose it's possible for a site to manually probe whether scripts for other sites are allowed - but only if you've first chosen to trust that site.

And you could block any such attempt, if it concerns you, using the RequestPolicy addon. If you really want privacy, you should definitely check RP out. Remember, NoScript is primarily a security tool, with privacy coming as a side-benefit.

Re: RFE: Encrypted whitelist

Posted: Wed Nov 14, 2012 12:39 pm
by Tom T.
Devistation wrote: I just thought it was a good idea because Firefox already has something like that but only for passwords (master password).
Storing passwords in any Internet-facing application, especially a web browser (in which vulnerabilities are found regularly), carries huge additional risks.
Some users prefer solutions that store them at some encrypted site, using encrypted connections. You still don't know whom you're trusting; disgruntled employee, etc.

We ultra-paranoid users Image prefer to keep it all on the machine that is under our physical control, in an app which never contacts the Internet. I *personally* prefer Password Safe, with encryption by world-class cryptogeek Bruce Schneier. One single encrypted file stores all, including URLs, notes such as "challenge questions", PINs, etc.; will auto-browse to the URL and auto-type user/pass; entire app is about 2MB, and the critical database file, which for me presently holds 71 complete entries, is about 18kb.

You can store the entire app on a thumb drive, take it with you, use it on other machines without worrying about leaving traces on the host machine, and if you lose the thumb drive, the finder can't get in without that (very strong, of course), master pw. Back up that single 18k file regularly, esp. after any changes. Then, if PS goes out of business tomorrow, and your entire hard drive dies, just run the installer that you saved on thumb drive, CD, whatever, on your new HD. Import the backup of the database, and you're ready to go. Total freeware. No ads, no nags.

DISCLAIMER: Personal opinion only; not an official endorsement by this forum, its Admin/Developer, or any other person, nor can this site offer support for third-party products. Offered in the hope that it may be of some use, but because I can't control the product, your use of it, etc., I cannot accept any responsibility or liability from your use of it, or the consequences thereof. IF YOU DO NOT ACCEPT THESE TERMS, DO NOT CONSIDER, HEED, OR USE THIS OPINION.
that's why I saw the whitelist as a little privacy problem because deleting the browser history wouldn't have much use then would it?
If it really bothers you, use only Temp-Allow, and revoke before leaving each site. But it shouldn't really be a problem, because:
Thrawn wrote: I suppose it's possible for a site to manually probe whether scripts for other sites are allowed - but only if you've first chosen to trust that site.
I'm not visualizing a way to do it *manually* without actually attempting to load the third-party script, which would show up in NS Menu. If both the first and third parties are trusted, it's theoretically possible that both would load before you had a chance to do anything about it, but then clearly you've trusted a rather untrustworthy site. ;)

Ditto with running the third-party code as an inline script on your trusted site. What trustworthy site would do that?

And to clarify, IMTFO (In my tin-foil-hat opinion), NONE of these are trustworthy, and are never allowed by this user. (OP: Check the sticky posts on "surrogates" to see why they don't need to be allowed even when sites "require" them.)

Re: RFE: Encrypted whitelist

Posted: Wed Nov 14, 2012 9:23 pm
by Thrawn
Tom T. wrote:
Thrawn wrote: I suppose it's possible for a site to manually probe whether scripts for other sites are allowed - but only if you've first chosen to trust that site.
I'm not visualizing a way to do it *manually* without actually attempting to load the third-party script, which would show up in NS Menu.
Yes, that was what I had in mind. Clunky, only allows them to probe specific sites rather than just reading your history, doesn't say anything about when or how often you've been there, and it would be blindingly obvious when your NoScript menu suddenly had 10000 entries in it, but theoretically a whitelisted site could use this to check where you've been...

I wonder how well NoScript would handle this situation? It would be practically a DoS attack.

Re: RFE: Encrypted whitelist

Posted: Thu Nov 15, 2012 10:49 am
by Tom T.
Thrawn wrote: Clunky, only allows them to probe specific sites rather than just reading your history, doesn't say anything about when or how often you've been there...
Exactly, esp. the latter.
Thrawn wrote: and it would be blindingly obvious when your NoScript menu suddenly had 10000 entries in it, but theoretically a whitelisted site could use this to check where you've been... It would be practically a DoS attack.
From a trustworthy site? :o

(There have been many other privacy attacks based on sniffing history, cache, color of links visited/not visited, CSS, etc., mostly powered by JS. Keep out the data-miners, and any site that is found to do this -- let the whole world know. :evil: Also helps to disable disk caching, offline caching, session restore, [sessionstore.X], DOM storage...)
I wonder how well NoScript would handle this situation?
I'm thinking that you'd have other resource problems first -- bandwidth, ISP throttling, CPU and memory -- when a site loads 10,000 script sources, especially because each domain name may have many, many scripts. I use Yahoo Mail, and have restricted the permissions from the default whitelist to only

mail.yahoo.com
yimg.com


denying www dot yahoo.com, and TA-ing yahooapis pro re nata. Still, I've seen as many as 122 scripts running there, with just these permissions.

Of course not all are that intensive, but many sites run dozens of scripts, so 10,000 domains may be hundreds of thousands of scripts.
The NS menu might scroll forever, *if* all that traffic made it past the intersections on the way. What do you think?

Re: RFE: Encrypted whitelist

Posted: Thu Nov 15, 2012 10:02 pm
by Thrawn
Tom T. wrote: The NS menu might scroll forever, *if* all that traffic made it past the intersections on the way. What do you think?
I think that a properly-used NoScript installation would block 99.9% of those scripts. I'm just wondering how well it would cope with such a tremendous menu. More a Firefox question, I guess, than specifically a NoScript one.

Re: RFE: Encrypted whitelist

Posted: Fri Nov 16, 2012 8:38 am
by Tom T.
Thrawn wrote:
Tom T. wrote: The NS menu might scroll forever, *if* all that traffic made it past the intersections on the way. What do you think?
I think that a properly-used NoScript installation would block 99.9% of those scripts. I'm just wondering how well it would cope with such a tremendous menu. More a Firefox question, I guess, than specifically a NoScript one.
Sorry, what I meant was "What do you think about the possibility of the 300,000-script web page load making it past your ISP, then having enough bandwidth, CPU, and memory to handle it, long before it got to NoScript?" -- assuming for the sake of argument that all of the sites involved were whitelisted.

Since NS blocks the requests to non-whitelisted sites, then assuming a prudent-length whitelist, yes, the menu would have a very long scroll, but the return traffic issue doesn't occur. I'm not aware of a limitation per se on the number of menu items, either in NS or in Fx.

Sorry that my previous wasn't clear.

Re: RFE: Encrypted whitelist

Posted: Sun Nov 18, 2012 12:37 am
by Tom T.
It occurred to me that this is another very good reason never to use "Globally Allow", in case a nasty site did indeed try such a thing, which probably would result in DoS.