869182 - Use the child process id and inner window id to ensure a unique identifier in dom/identity

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Identity, defect)

Description

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

As per Comment 17 in Bug 868530#c17, nsDOMIdentity should use a combination of child process id and innerwindow id to identify callers.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I spoke with jparsons on IRC about this, and I am not very clueful about it.

I think it is useful to have some kind of "uniqueWindowId" property on a window that is guaranteed to unique across all windows and never be reused, and which works whether or we're using e10s.

I don't think it is a great idea for the DOM identity code (and similar code written in other components) to calculate this "unique Window ID" itself. In particular, dealing with the potential for process IDs to be reused and whatnot should all be handled in one spot, instead of in each component that needs such a unique ID.

And, also, I read the discussion in the other bugs that lead up to this one, and I understand that this is somehow a unique situation. But, I am surprised by that because it seems like it must be very common for us to need to serialize a reference to an object in the child process to send to/from Gaia, and then deserialize that reference so we can send information retrieved from Gaia back to the child process. Wouldn't we do this, for example, when prompting for HTTP auth credentials? I guess there must be something different here that I'm not understanding, and I don't want to derail the bug talking about alternative approaches, but it might be helpful to talk to people that have solved similar problems already.

Comment 2

[Justin Lebar (not reading bugmail)]

What this bug summary describes is the best state of the art we have for a unique window id.

But you're right, we should do better.  It's not too hard...

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Justin Lebar [:jlebar] from comment #2)
> What this bug summary describes is the best state of the art we have for a
> unique window id.

Is this technique used anywhere else right now?

Jed: You asked me about how to to use XPCOM or jsctypes to expose the child process ID. The way I would do it would be to find the XPCOM interface that exposes the window id, and then extend that XPCOM interface (updating the UUID in the process) to expose an additional readonly "uniqueWindowID" property. Then, extend the implementations of that interface to implement the uniqueWindowID property by calling ContentParent::ChildID. But, people on the DOM team would know better than me exactly what needs to be done to make that happen.

I don't think that we need to use the PID of the child process here. Instead, we could just assign each child process its own serial number, where the serial number is based on a monotonically-increasing, atomically-updated large (64-bit) counter. This would work on all platforms and it would eliminate the need to be concerned about PIDs being reused. It seems that Linux tries its best to reuse PIDs as little as possible, but Windows reserves the right to reuse a PID any time after the process that has that PID terminates. As people are working on more e10s stuff in the browser, it seems best to not rely on Linux's PID semantics. Also, I don't think it is great to rely on the Linux "reuse as little as possible" behavior for something that is security-sensitive like BrowserID.

Comment 4

[Justin Lebar (not reading bugmail)]

> I don't think that we need to use the PID of the child process here.

The "child process id" isn't the pid of the child process.  It's ContentChild::GetID, or ContentParent::ChildID.  So it's [child process] id, not child [process id].  The child process id is guaranteed unique.  We definitely shouldn't rely on pid uniqueness.

> The way I would do it would be to find the XPCOM interface that exposes the window id

nsIDOMWindowUtils, I believe.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could we, in child proceses, make the first window ID be "child-process-id * 2^20" and count consecutively from that? It seems pretty unlikely that we'll have 2^20 child processes without rebooting.

Or, if we want to be really safe, set up some sort of protocol that lets a child process generate a million consecutive unique IDs, and once it runs out of that, request another million IDs from the parent process.

Comment 6

[Justin Lebar (not reading bugmail)]

It's a security error if we roll over these IDs.  Maybe if we crash the phone when we hit the max, that would be OK.

dzbarsky is working on nested content processes these days, btw.

Comment 7

[Justin Lebar (not reading bugmail)]

(In reply to Justin Lebar [:jlebar] from comment #6)
> dzbarsky is working on nested content processes these days, btw.

Sorry, that was opaque.

What I meant was, this scheme obviously falls over with nested content processes.

The right thing to do, I think, would be to have a structure

 [window ID, ID of parent, ID of grandparent, ...]

and use that as the content process ID.  We could still assign it when we create the child process.

Anyway if we're OK with the status quo (I am), it may be better to let this bug shake itself out during the nested content process work, for which I think we'll very likely need to do something like what I suggested here.

Comment 8

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Ah, I see.  Yes, I agree it makes sense to hold off for the nested content process work.

Comment 9

[Firefox Bug Husbandry Bot]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1497358; closing remaining open bugs in this component.