On Windows, pretty much everything deals in HWNDs, which is an integer
index into a kernel handle table. This means HWNDs, which are just
integer window ids, are good across processes. The fact that all of
the Windows APIs work in HWNDs, means that it is the primitive for
NativeWindow and NativeView on Windows.
On Linux, we have a similar concept, the X window id. However, our
NativeWindow is currently a GtkWindow, and NativeView is a GtkWidget.
Both a GtkWindow (this is the top level application window) and a
GtkWidget can be backed by a GdkWindow, which encapsulates the X
window id. Gtk is a cross-platform toolkit, which is one of the
reasons you don't deal w/ the window ids directly.
A recent example of this I've encountered is
DidMove(WebPluginGeometry), which has a NativeView handle. This is
not going to be IPC-able, as this would be a pointer to a GtkWidget
instance, which obviously won't be good across processes. In order to
have something that would be, we would need to do GtkWidget ->
GdkWindow -> x window id. Then on the other side we'd have to create
a new GdkWindow around the x window id.
It seems we might need some new abstractions, since on Linux both
NativeView and NativeWindow are pointers, not integers that are valid
between processes. It seems like we need some NativeWindowId
abstraction. Hey, I just looked at the code, I noticed someone added
a NativeViewId type and conversion methods, so we already have the
abstraction. We just need to start using them.
I'm not sure this is enough security-wise though. It is scary to
allow the to renderer send messages to the browser, telling it to do
operations on arbitrary windows. I think this is where Adam mentioned
something like HMAC, or we could do some sort of handle type thing to
implement security. This might be a bit tricky, depending where the
window is created an used (we have 3 processes involved, plugin,
browser, and renderer). It would be nice if we could also enforce IDs
per-renderer process, and not just HMAC'd to any renderer.
In some of these cases, we are probably just using the HWND out of
convenience so we don't have to keep state. It seems like it's
probably a mess to try to duplicate the state in the browser process,
but that's also one possible solution.
I'm thinking maybe the best solution is along the lines of Adam's
idea. Basically some opaque 64-bit (or bigger) ID that we can pass to
the renderer and have it pass back. This ID will encapsulate a
NativeViewId, along with security privileges. This could be
implemented all in the ID, along with an HMAC to make sure it's not
tampered with. It could also be an ID into a state table, much like
how securable HANDLE objects work on Windows. The HMAC implementation
is probably the easiest.
I have no idea what the situation is like on Mac.
This is going to effect us immediately, as we're pulling up
multiprocess Linux. So I think it should be a priority to figure this
out soon.
Thanks
-- dean
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
