Security/ProcessIsolation/ThreatModel: Difference between revisions

Jump to navigation Jump to search
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
Confirmed users
717

edits

Navigation menu