InformAction Forums

Grumpy Old Lady wrote:Ahem, Sandboxie plus NS/Fx - - there's no hiding inside any sandbox from active exploits that use the web, as opposed to your operating system.
http://hackademix.net/2008/01/12/malware-20-is-now/

Yes. Of course. Thanks for the reminder.

Hmm, a deadlinks check on that hackademix link
http://hackademix.net/2008/01/12/malware-20-is-now/
reveals that the first link out to the commentary on the Italian bank's XSS is broken.
It's still up at the wayback machine
http://web.archive.org/web/200802141206 ... -hack.aspx
- and here's the link to the original description for good measure
http://news.netcraft.com/archives/2008/ ... sters.html

Sandboxing is like putting your shields up. However, I seems to me, that sooner or later you're going to have to do something outside your sandbox. While your shields are down, you better know what doing, where you're going, etc. or you're going to get hit. You need education to know what to avoid. That's why I would prefer badware detection and notification even while I'm in the sandbox.

donwms wrote:I would prefer badware detection and notification even while I'm in the sandbox.

Me too. NoScript and my AV still work while I'm in a sandbox.

Hi,

I've been a happy NS user for some time now, and have joined the forums to make a couple of feature requests. In this thread, I found a better suggestion which (when implemented) will give a better answer to the need that prompted my ideas. I still wanted to bring them up, because I think they may be easier to implement and/or someone else will see other uses for them.

The pain I have is with sites using 3rd-party JavaScript APIs such as Google's or Yahoo's. I find two pain points with such sites:
1) When I temporarily allow, say googleapis.com, I usually do it for use in one site; I don't really want to allow it for other sites in the same session (not to mention, already open in other tabs).
2) Recently, such APIs have started to spread across domains; e.g. to really allow Google APIs, you sometime need to also allow google.com and gstatic.com etc.

My ideas were to solve these problems separately:
1) Make tab-specific permissions, and make "temporarily allow..." apply only to the tab where it was used;
2) Allow the definition of site groups, such as suggested by Foam Head (independently of the policy groups he suggests). Then, if, say googleapis.com shows up, add a "temporarily allow the google apis group" to the NS menu.

However, looking through this thread, I ran into the suggestion to support sites defined as "trusted if parent trusted"; if I understand this correctly, if the google API sites are given this trust level, then temporarily allowing a site which uses them, will allow them only in the using site; this solves both my problems, with a simpler user interface.

So -- thanks, and keep up the good work,

Shai.

Yes! Bravo! I concur! I've long wanted the ability to control allowed scripts on a per tab, per site or per domain level. For example; just because I want to allow site A to gather browsing statistics on me via some marketing tool page doesn't mean I want EVERY site to be able to do so en-mass.

Yes, I like your example. I want conditional trust. I may be willing to let a top level trusted site abc.com use def.com to collect browsing stats, but not when some other trusted site is the top level. In both cases the top level is trusted. However, trust for def.com is conditional based on who is the top-level.

I've not given much thought on nested levels of trust. It gets way too complicated, fast. That is, trusted site A calls trusted site B who calls conditionally trusted site C.

Please see ongoing topic, "Site-specific permissions policy".

I'm sorry this went unanswered for so long.

I'd third the need for "site specific policies".

For example, I typically disable GoogleAPIs.
However, there are a couple of websites that tend to require it beyond what would be "normal".

So... when I hit those websites, I hit "temporarily allow".

Then system then refreshes all websites rather than the specific domain for which it was enabled. And, invariably I forget to revoke the temporary permissions.

I.E. on whitelisted (or partially whitelisted websites), one should be able to specific other resources that could be accessed on a domain by domain basis.

I suppose the same would be true with YouTube. I'd like the minimum necessary for it to run when I go to the YouTube website. However, I don't want it to pop up without being specifically enabled when embedded elsewhere.

Yahoo mail has hidden iframes from a different domain (yahoo.net, yimg.com). There needs to be a way to not block them for the mail app, while otherwise continuing to block iframes. The more complex ajaxy applications are more likely to require specific configuration to work properly.

I came here to request this feature and noticed that this discussion has stalled somewhere in 2009.
is this feature still planned ?

hatchetman82 wrote:I came here to request this feature and noticed that this discussion has stalled somewhere in 2009.
is this feature still planned ?

It stalled mainly because those asking for it are usually advanced enough to use this work-around based on ABE.
Also, the problem is often overstated because it's not clear to everyone that if the main site is not in the whitelist, none of its 3rd party scripts can load and run anyway.

Giorgio Maone wrote:It stalled mainly because those asking for it are usually advanced enough to use this work-around based on ABE.
Also, the problem is often overstated because it's not clear to everyone that if the main site is not in the whitelist, none of its 3rd party scripts can load and run anyway.

I don't think there are any workarounds for embedding permissions. There are many scenarios (e.g. new yahoo mail beta) where cross domain iframes need to load for the application to function properly. This is exacerbated if one prefers forbidIFramesContext=2, because in general, the more blocking the better. In numerous and ever growing number of cases of complex sites/apps that rely on (third party) widgets/components in the form of iframes or plugins, site specific configuration would be extremely useful.

Giorgio, what are your thoughts on the value of per site customized embeddings permissions?

Still I can't understand how ABE doesn't suffice for a power user with this kind of needs.
Please name a policy which cannot currently be expressed by ABE grammar, in one or more chained rules.