Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

[Strategize] Isolation of security-related code #210

Open
twiss opened this issue Nov 8, 2014 · 4 comments
Open

[Strategize] Isolation of security-related code #210

twiss opened this issue Nov 8, 2014 · 4 comments

Comments

@twiss
Copy link
Collaborator

twiss commented Nov 8, 2014

Spin-off from #208.

For security, it may make sense to put the UI itself in a sandboxed iframe, and let the top frame handle communication between modules.

Only problem is, if the modules are inside the UI, I don't know of a way to communicate safely between the top frame and a module without the UI having the same capabilities as the modules.

@ferndot
Copy link
Member

ferndot commented Nov 19, 2014

Out of curiosity, what security benefits would this have? The editor is already placed in an iframe.

@twiss
Copy link
Collaborator Author

twiss commented Nov 19, 2014

The idea was reducing attack surface, mainly.

@ferndot
Copy link
Member

ferndot commented Nov 19, 2014

@twiss: ah, that makes sense.
@jackd1: is this feasible?

@jackd1
Copy link
Member

jackd1 commented Nov 19, 2014

I don't think this is really a feasible option, it's good practice, for example, I know google chrome does it with webpages. The only problem, however, is that the security restraints available are not specific enough to make sandboxing useful beyond just one level of security. Sandboxing a frame inside a sandboxed frame will not give us anything useful. And as for sandboxing the UI, I can't think of any use for this, there is no risk that I know of which could harm the user other than from documents opened in the program, and we already do what we can to sandbox that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants