Confirmed users
717
edits
| Line 107: | Line 107: | ||
<b>Another meta-issue</b>: if we don't isolate non-SSL domains from each other, do we create a potential "cesspool", making it impossible to determine the origin of a given non-SSL request, and makes it difficult to police SSL and non-SSL interactions? Clearly we don't really trust the origin of any non SSL request anyway. But are there any situations where a non-SSL domain has elevated privileges compared to other domains when interacting with its SSL counterpart? This could have implications for HTTP content loading HTTPS assets, for example, and vice versa. | <b>Another meta-issue</b>: if we don't isolate non-SSL domains from each other, do we create a potential "cesspool", making it impossible to determine the origin of a given non-SSL request, and makes it difficult to police SSL and non-SSL interactions? Clearly we don't really trust the origin of any non SSL request anyway. But are there any situations where a non-SSL domain has elevated privileges compared to other domains when interacting with its SSL counterpart? This could have implications for HTTP content loading HTTPS assets, for example, and vice versa. | ||
==Plugins== | |||
Plugins are not planned to be sandboxed yet, since they require their own broker architecture, mostly due to challenges around: | |||
- filesystem access (file uploads, downloads, media playback) | |||
- auto-update | |||
- potentially registry and network access (binary sockets, etc) - or allow them unlimited access | |||