I had some conversations with :annevk about the difficulty of deciding on a process selection strategy for null principals on Slack earlier today. Leaving a ni? for any further thoughts on the issues next week.
One issue is that we likely cannot afford to mint a new process for every single null principal. We probably need to do some sort of strategy for collecting these processes together. This matches what Chrome does already where they appear to track the true site origins of null principals over time, so that when they're loaded in the future, they're loaded within the site which created them. For something like a
data: URI, this would be the site which initiated the load (
TriggeringPrincipal here), and for something like a sandboxed frame, it would be the unsandboxed result principal.
We could try to follow this strategy as well, however it can become quite complicated in some situations, as doing so might require adding tracking to our null principal representation of the origin which created that null principal. We don't do anything like that right now, and it seems like a strange addition to the null principal type, especially when it's only intended to help with tracking process selections. Alternatively, we could do some form of best-effort tracking, and when all else fails use a process fallback.
The most secure option, of course, would be to use a distinct process for every null principal which we load, but that is likely untenable in MVP for memory use and performance reasons.