The existing "privileged" content processes that we have behave just like web content processes. After discussing with :mconley and :ursula, we do not plan to give this new process more privileges, at least not at this time. What is important here is that we separate certain pages that currently have access to more information (such as Activity Stream) into their own special process. This way, if normal content processes get compromised, they are separated via the process boundary from the powers and information inside these pages. Due to that, we should rename "privileged" to something else so that it is not misleading. Until we have decided a better name, I am planning to rename this to "Internal Content Process" for now.
The process *does* have additional privileges, though, in that it has access to Activity Stream data. A normal content process requesting that data should never get it.
I guess the problem we were attempting to solve for here was confusion over the (admittedly overloaded word) "privileged" in this context. Privileged could mean something like... can access the disk or network directly. Can read or write to the Windows registry, that sort of thing. So, I agree, it does have privileged access to information, and has slightly more power due to the fact that the pages loaded in it can ask for more things... The only reason this came up was because of bug 1416066 comment 82, where some confusion already manifested - Jay got sent down a path where he started finding ways of locking down the process from accessing remote web content and scripts. I don't think that's fully necessary, unless I'm greatly mistaken. Do you disagree about the potential confusion around the word "privileged" here, and how it can suggest more capability than exists?
Upon further reflection, this is probably fine. If this ends up burning or confusing more people, let's re-open this, but I don't think this should block enabling the pref by default.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #2) > The only reason this came up was because of bug 1416066 comment 82, where > some confusion already manifested - Jay got sent down a path where he > started finding ways of locking down the process from accessing remote web > content and scripts. I don't think that's fully necessary, unless I'm > greatly mistaken. I don't think that was entirely a matter of confusion. The question of locking down the process came up because the content process sends script bytecode back to the parent for caching and use in other processes. For normal web content processes, we stop sending data as soon as we start loading a document, to make sure untrusted scripts don't have a chance to contaminate it. For the AS process, we pushed that window back significantly, which means that if it does run untrusted code before we send back our bytecode, that code may get a chance to contaminate it for other processes. That said, while I don't think there was confusion, I also don't think that's a blocker. The parent process has the same potential problems, and any untrusted code we did run would have a very small window to compromise the cache. And even then, it would only compromise other content processes if the AS process was the first one we got script data from.
You need to log in before you can comment on or make changes to this bug.