whitelisting for file:// URI subpaths?

[royce]

In NoScript 2.5, attempts to add file:// URIs with specific paths are truncated to just "file://".

Would there be any value in allowing users to whitelist specific paths, without having to whitelist all file:// URIs?

[dhouwn]

AFAIK, a limitation of the the browser.

[Giorgio Maone]

No, sorry.

[royce]

Is this a fundamental design constraint of the browser, something that would simply not provide any benefit, or something that would simply need to be looked into by the Firefox team and might have benefit? I'm unsure of which of these is what is meant by "No, sorry."

EDIT: To clarify, it seems from the FAQ that browser add-ons and other tools that require whitelisting of file:// URIs (Trillian, ScrapBook, Ubiquity, Google Toolbar) are a common FAQ topic for NoScript. Zotero also has this issue; see http://forums.zotero.org/discussion/147 ... g-together. It seems to me that if there is a more elegant way to handle this, or a way to guide add-on developers towards using resource: URIs instead, that this would reduce noise and improve security.

[Giorgio Maone]

Is this a fundamental design constraint of the browser

This one. From the ScriptSecurityManager's perspective, all the file:// URIs share the same principal (i.e. are deemed having the same identity, security wise) except that a certain file cannot access data from a resource in a different directory which is not descendant of the current one.