ptheriault a écrit :
- restrict cross-domain communication etc
This is hardly sufficient to offer a significant protection from a
malicious application. If the application wants to break the protection
brought by cross-domain restriction, it will.
Cross-domain restriction has a use case, but it's not that big.
- load once, then cache. Drop permissions if app changes (or prevent
from changing without update workflow)
If you successfully find a model that's safe by default, it's not
obvious whether this is still is an important feature.
If it's safe by default, we don't care what the application actually
contains, it will still be safe.
The model that gives permissions based on the exact content of the
extension is weak. Very weak. The user didn't audit the extension, he
saw how it behaves, and thought it was correct. But he didn't see
everything. If the application is dangerous after the change, it may
just as well have already been before.
So you really need to make it safe by default, and not rely on having to
blindly trust what the application contains, and "drop permission if the
app changes" is a bit snake oil.
However in some implementations of the safe by default model, it may be
required to associate an identity with the app, so that it doesn't
successively acquire permissions that combined together are dangerous,
so that you are able to reject a permission for an app that used to have
another incompatible one.
The "CRX Package Format" that chrome uses
(http://code.google.com/chrome/extensions/crx.html) includes a digital
signature. That's not PKI, there's no authority that validates that
signature, it just proves the origin of the extension stays the same.
If the signature of the extension changes, it's not really a problem,
but it just makes it a separate extension, that has no access to the
data (or maybe already obtained permissions) of the previous one.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
