Skip to content

Finalize adr-013-script-preloading-security.md #807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 21, 2024
Merged

Finalize adr-013-script-preloading-security.md #807

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions architecture/adr-013-script-preloading-security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

| Type | ID | Status | Title |
| ------------- | ------------- | ------------- | ------------------------------------------- |
| ADR | adr-013 | Draft | Security requirements for preloaded scripts |
| ADR | adr-013 | Accepted | Security requirements for preloaded scripts |


# Security requirements for preloaded scripts
Expand Down Expand Up @@ -66,15 +66,15 @@ windows created in the renderer process without additional parameters.

## Decision

TBA
Windows opened via window.open() or a similar mechanism are considered "popup windows". These are non-persistent and non-dockable. They are owned by the module that opened them and they are closed if the module is closed.

To minimize risks associated with untrusted content, popup windows and iframes will not inherit the parent window's module identity or injected scripts.
When a module wants to pop up another window, it has to do so using container APIs (eg. FDC3 `raiseIntent` or `open`, or the Module Loader `start` API).
To minimize risks associated with untrusted content popup windows and iframes will not inherit the parent window's module identity or injected scripts. The same applies if the module tries to navigate to another domain.
If a new window needs access to these features it has to be opened as a separate module using container APIs (eg. FDC3 `raiseIntent` or `open`, or the Module Loader `start` API).

We provide fine-grained control over script injection in web views. Plugins can examine the originating module's manifest,
the target URL and its context (eg. a popup window or iframe) when determining what to preload. Frames without reference to a module instance
will not receive any preloaded scripts unless some shell features require them.
Depending on user feedback we may design way(s) for limited communication between a module main window and its child windows and iframes. This would still not grant direct access to the container but developers could have more flexibility in these kinds of interactions. We still need to consider access control to these features (e.g. allow-listing origins in the module manifest).

## Consequences

TBA
Safety concerns related to loading potentially hostile arbitrary urls with access to the container api are covered.
Modules that expect to open windows or make use of iframes that access the container features will not work with the container.
Even if we add communication options in the future we cannot ensure these features will be container agnostic.
Loading