1 of 33

Out of Process <iframe>

Ken Buchanan <kenrb@chromium.org>

Daniel Cheng <dcheng@chromium.org>

​

​

2 of 33

What We Currently Do

​

​

3 of 33

What We Currently Do

​

​

4 of 33

What We Currently Do

​

​

5 of 33

What We Currently Do

​

​

6 of 33

What We Want To Do

​

​

7 of 33

Why?

Computers have more RAM than ever and we feel like we’re not using enough.

​

​

8 of 33

Why?

  • Renderer processes are sandboxed
  • Sandbox policy blocks exploits from running calc.exe
  • Compromised renderer can access web resources

​

​

9 of 33

Why?

​

​

10 of 33

Why?

  • Blink/V8 are, of course, known to be free of security bugs
  • But if they did have bugs...

​

​

11 of 33

Why?

  • Compromised renderer lies to the browser, claims it has gmail.com in a frame.
  • The browser gives the compromised renderer gmail.com cookies.
  • ???
  • Profit!

​

​

12 of 33

Why?

  • Shouldn’t X-Frame-Options prevent this?
  • … X-Frame-Options and similar security policies are enforced in the renderer. Doh!

​

​

13 of 33

Architecture Today

  • Already have some notion of swapping renderer processes.
  • Only works for the top-level view.
  • Kind of a hack.

​

​

14 of 33

Immediate Goals

  • Get basic rendering/input events working with out-of-process iframes
  • Create infrastructure for porting features to be out-of-process iframe aware.

​

​

15 of 33

Frame → LocalFrame/RemoteFrame

  • Frame is becoming base class for operations valid for any frame.
  • Base class implements some common behaviors, like accessing the frame tree.
  • Other things (e.g. postMessage) are virtual methods that subclasses need to implement.

​

​

​

16 of 33

LocalFrame

  • Subclass for a frame hosted in the current renderer.
  • LocalFrame is more or less what Frame used to be.

​

​

17 of 33

RemoteFrame

  • IPC stub for frames hosted in a separate renderer
  • Provides implementations for Frame virtual methods that understand how to hop to a separate process (e.g. postMessage)
  • By nature, must be asynchronous. One renderer cannot block on another.

​

​

18 of 33

Frame Tree

  • Frame tree moved out of Source/core into Source/web
  • Each renderer has a copy of the frame tree
  • Browser holds canonical frame tree representation

​

​

19 of 33

Frame Tree

​

​

20 of 33

Synchronization Issues

  • Isn’t changing things from sync to async going to break the web?
  • Cross-origin content doesn’t have sync points*

​

​

​

​

​

​

​

​

* except for frame name, unload events, and probably some other stuff

​

​

21 of 33

Conflict Resolution

  • Two frames try to navigate third frame at the “same” time
  • A frame tries to postMessage a frame that’s going to be detached

​

​

22 of 33

Process Transition

  • Blink starts a frame navigation
  • Frames always start as LocalFrames
  • ResourceRequest for navigation may be interrupted.
  • Embedder uses WebFrame::swap(), which handles the specifics

​

​

23 of 33

How We Render Remote Frames

  • Requirement: browser process compositing (Aura-only for now)
  • Necessary for security goals, but also makes it really easy
    • Compositor frames, DelegatedRendererLayer
    • Compositing Surfaces (coming soon, avoids multi-hop IPC transfers of compositor frames)

​

​

24 of 33

Input Events

  • Initial implementation modeled on flow of input events for plugins
  • Potential for nested iframes ⇒ unacceptable performance degradation

​

​

A

B

C

User clicks on C, nested 2 processes deep

Event routed back to browser, then to B process

Event routed back to browser, then to C process

​

​

25 of 33

Input Events v2

  • FocusController will be split into browser and renderer parts
  • Currently:

​

​

  • In future:

Focus = (focusedFrame, focusedElement)

Focus = (focusedRenderWidget, focusedFrame, focusedElement)

​

​

26 of 33

Input Events v2

  • FocusController will be split into browser and renderer parts
  • Currently:

​

​

  • In future:

Focus = (focusedFrame, focusedElement)

Focus = (focusedRenderWidget, focusedFrame, focusedElement)

(tracked in browser process, corresponds to renderer process)

​

​

27 of 33

Input Events v2

  • With Surfaces, browser compositor has enough information to translate a point to a renderer process
  • Directly dispatch to the hosting renderer
  • Blink hit testing should be mostly unchanged

​

​

28 of 33

Other Work

  • WebFrame/Frame owner relationship
  • History
  • ProgressTracker

​

​

29 of 33

Upcoming Work

  • RemoteDOMWindow
  • HTMLFrameOwnerElement
    • HTMLFrameOwnerElement directly used by FrameLoader

​

​

30 of 33

How to Write OOPI-aware Code

  • Can’t assume all frames are LocalFrames
  • Some features may simply need to forward a call into another renderer
  • Other features may require browser side support

​

​

31 of 33

Known Unknowns

  • Unload events
  • Modal dialogs
  • Performance

​

​

32 of 33

Future Goals

  • Blink becomes just a frame server
  • Browser process makes all security decisions
  • Plugin code merged with remote frames
  • WebView ported to use same infrastructure

​

​

33 of 33

The End

Lots more info @

http://dev.chromium.org/developers/design-documents/site-isolation

​

​

Questions?

​

​