chrome://Brief RSS and ABE settings

[poutnikl]

I use great Brief FF entension, running on separate FF tab on chrome:// FF internal protocol
( chrome://brief/content/brief.xul )

As chrome:// is whitelisted by NS by default, Is there any chrome specific ABE settings, good to be applied to this,
e.g. to avoid eventual attacks from RSS related external pages ?

e.g. like this ?

Code: Select all

site ^https?://.*
Accept GET from ^chrome://brief/.*
Deny from ^chrome://brief/.*

[poutnikl]

Possibly rather the opposite... ?

Site ^chrome://brief/.*
Deny from ^https?://.*

[Thrawn]

Your second attempt is closer, but what kind of attacks are you trying to prevent? XSS?

Please describe exactly what you want your ABE rule to do, and we should be able to help you write it.

[Thrawn]

1 - Preventing access of external sites through chrome:// to local resources

This shouldn't be an issue. Unless I'm very wrong, the browser won't allow external sites to make requests to chrome. chrome:// is an internal protocol used by the core browser and its addons, very much off-limits to external websites.

2 - Preventing attacks from of external sites related to RSS via trusted chrome://

Again, I'm almost certain that sites can't send any kind of request to chrome://, so I can't visualise a scenario where ABE would be needed.

The only real way that I know of for sites to compromise chrome:// is if some privileged code (like an addon) is poorly designed and allows sites to tamper with it. That's beyond the scope of ABE, though.

[Thrawn]

it looks to me rather like more user friendly interactive way to provide subset of ABE functionality.

That's an excellent description . Guardian and I have a side project to combine the two, using an RP-style interface to write ABE rules, but haven't had time to work on it lately.

Using RP is an excellent way to control permissions on a site-specific basis - eg allowing Google Analytics in NoScript, but only allowing selected sites to use it - but it adds a whole new level of 'sites will break by default', so it's only for those who really want full control.

If I understand well, cross site requests must pass now approvals of both extensions.

You're close: cross-site requests for active content (eg JavaScript, Java, Flash) must now pass both extensions.

NoScript doesn't care about static requests like images and stylesheets. But most cross-site requests these days do include scripts, so usually every site will appear in both lists.

But interesting thing is, that RP is reporting in context menu1 conflicting extension - Brief.
On other context menu line it say that requests from chrome:// cannot be blocked. Is it an issue ?

I haven't tried the two extensions together; if you want to do so and report the results to the RequestPolicy author, then please do.

I think that ABE can block requests from chrome://, but RP can't. That's probably by design, though, because a default-deny policy for chrome:// requests would be a Bad Thing.

[Thrawn]

NoScript doesn't care about static requests like images and stylesheets. But most cross-site requests these days do include scripts, so usually every site will appear in both lists.

Unless ABE restrictions are strong, if I understand it correctly......

Yes. ABE is similar to RequestPolicy.