This requires migrating some members from WebExtensionPolicy to
WebExtensionPolicyCore. The mHostPermissions member could not be fully
transferred, as the WebIDL reflector needs to be cached for
WebExtensionPolicy.allowedOrigins, however the threadsafe core is shared.
Differential Revision: https://phabricator.services.mozilla.com/D163039
This migrates the restricted domain preference handling to be performed on the
ExtensionPolicyService, wrapping it in an RWLock, making it threadsafe to
interact with.
Differential Revision: https://phabricator.services.mozilla.com/D163038
Now that all fields and methods in WebAccessibleResource have been made
threadsafe, we can make the type itself be threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D158885
In order to make WebAccessibleResource threadsafe, as well as other places, it
needs to be possible to look up a `WebExtensionPolicyCore` from any thread.
This is handled by using a static method on the ExtensionPolicyService for this
task, and keeping a seperate mutex-guarded static table under the hood.
Theoretically the table within `ExtensionPolicyService()` could also be
removed, however I held off on doing that in case it would have a negative
performance impact to take extra locks and follow extra pointers.
Differential Revision: https://phabricator.services.mozilla.com/D158884
Similar to MatchGlob, this is fairly straightforward, but is complicated
slightly by `MatchPatternSet`, which allows being destructured into the
contained `MatchPattern` instances in a `[Constant]` method. To handle this a
cache is added for the wrappers in the cycle-collected `MatchPatternSet`.
Differential Revision: https://phabricator.services.mozilla.com/D158883
This threadsafe core type also acts as a weak reference to the main-thread
WebExtensionPolicy when needed. This will be used when information about a
WebExtension is needed to be accessible off-main-thread in the future.
Differential Revision: https://phabricator.services.mozilla.com/D158879
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
Now that all fields and methods in WebAccessibleResource have been made
threadsafe, we can make the type itself be threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D158885
In order to make WebAccessibleResource threadsafe, as well as other places, it
needs to be possible to look up a `WebExtensionPolicyCore` from any thread.
This is handled by using a static method on the ExtensionPolicyService for this
task, and keeping a seperate mutex-guarded static table under the hood.
Theoretically the table within `ExtensionPolicyService()` could also be
removed, however I held off on doing that in case it would have a negative
performance impact to take extra locks and follow extra pointers.
Differential Revision: https://phabricator.services.mozilla.com/D158884
Similar to MatchGlob, this is fairly straightforward, but is complicated
slightly by `MatchPatternSet`, which allows being destructured into the
contained `MatchPattern` instances in a `[Constant]` method. To handle this a
cache is added for the wrappers in the cycle-collected `MatchPatternSet`.
Differential Revision: https://phabricator.services.mozilla.com/D158883
This threadsafe core type also acts as a weak reference to the main-thread
WebExtensionPolicy when needed. This will be used when information about a
WebExtension is needed to be accessible off-main-thread in the future.
Differential Revision: https://phabricator.services.mozilla.com/D158879
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
Now that all fields and methods in WebAccessibleResource have been made
threadsafe, we can make the type itself be threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D158885
In order to make WebAccessibleResource threadsafe, as well as other places, it
needs to be possible to look up a `WebExtensionPolicyCore` from any thread.
This is handled by using a static method on the ExtensionPolicyService for this
task, and keeping a seperate mutex-guarded static table under the hood.
Theoretically the table within `ExtensionPolicyService()` could also be
removed, however I held off on doing that in case it would have a negative
performance impact to take extra locks and follow extra pointers.
Differential Revision: https://phabricator.services.mozilla.com/D158884
Similar to MatchGlob, this is fairly straightforward, but is complicated
slightly by `MatchPatternSet`, which allows being destructured into the
contained `MatchPattern` instances in a `[Constant]` method. To handle this a
cache is added for the wrappers in the cycle-collected `MatchPatternSet`.
Differential Revision: https://phabricator.services.mozilla.com/D158883
This threadsafe core type also acts as a weak reference to the main-thread
WebExtensionPolicy when needed. This will be used when information about a
WebExtension is needed to be accessible off-main-thread in the future.
Differential Revision: https://phabricator.services.mozilla.com/D158879
This also involves making MatchGlob operate on UTF8String instead of DOMString,
as the rust `regex` crate operates on utf-8 strings. This should have no
functional impact on callers.
Differential Revision: https://phabricator.services.mozilla.com/D158877
object-src used to be required because it controls plugins, and we did
not want to load unsafe sources as plugins. With NPAPI plugin support
having been dropped a long time ago, this reason no longer exist.
The requirement for "secure" object-src CSP directive meant that
extensions had to specify a boilerplate object-src if they wanted to
modify script-src.
This patch removes the object-src requirement from extension CSP,
which simplifies the usage and learning curve of CSP usage in
extensions.
With this change, extensions can now load "unsafe" (remote) content
via `<embed>` and `<object>` tags. This relaxation does not reduce
the security because this was already possible with `<iframe>` tags.
Differential Revision: https://phabricator.services.mozilla.com/D156747
