Make sure binding security checks don't pass if the frame is remote.

Make sure binding security checks don't pass if the frame is remote.

Blink assumes that remote frames will always fail the security origin
check. Unfortunately, reality is not that simple. There are several
instances where this assumption fails to hold. For example:

  1. Navigate to a.com.
  2. a.com opens a new window.
  3. Navigate the new window to b.com via the omnibox.
  4. Click a link to c.com in both windows.

Because browser-initiated navigations go cross-process but
renderer-initiated navigations do not [1], the two c.com windows will
end up in different renderer processes.

Both windows have the same origin but see each other as RemoteFrames.
This means that SecurityOrigin's canAccess check will pass… but this
ends up violating many assumptions in Blink that passing the security
check implies a local frame.

[1] https://www.chromium.org/developers/design-documents/process-models#Caveats

BUG=601629
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1887553002

Cr-Commit-Position: refs/heads/master@{#387087}
(cherry picked from commit f23b8e77a83a5aafabf64acf723cf2ac02c5cf0e)

Committed: https://chromium.googlesource.com/chromium/src/+/7a0bbe39f45e7bd26a4b9328ce2660bc6094ef84

[dcheng, 2016-04-19 18:48:50]

Description was changed from

==========
Make sure binding security checks don't pass if the frame is remote.

Blink assumes that remote frames will always fail the security origin
check. Unfortunately, reality is not that simple. There are several
instances where this assumption fails to hold. For example:

  1. Navigate to a.com.
  2. a.com opens a new window.
  3. Navigate the new window to b.com via the omnibox.
  4. Click a link to c.com in both windows.

Because browser-initiated navigations go cross-process but
renderer-initiated navigations do not [1], the two c.com windows will
end up in different renderer processes.

Both windows have the same origin but see each other as RemoteFrames.
This means that SecurityOrigin's canAccess check will pass… but this
ends up violating many assumptions in Blink that passing the security
check implies a local frame.

[1] https://www.chromium.org/developers/design-documents/process-models#Caveats

BUG=601629
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1887553002

Cr-Commit-Position: refs/heads/master@{#387087}
(cherry picked from commit f23b8e77a83a5aafabf64acf723cf2ac02c5cf0e)
==========

to

==========
Make sure binding security checks don't pass if the frame is remote.

Blink assumes that remote frames will always fail the security origin
check. Unfortunately, reality is not that simple. There are several
instances where this assumption fails to hold. For example:

  1. Navigate to a.com.
  2. a.com opens a new window.
  3. Navigate the new window to b.com via the omnibox.
  4. Click a link to c.com in both windows.

Because browser-initiated navigations go cross-process but
renderer-initiated navigations do not [1], the two c.com windows will
end up in different renderer processes.

Both windows have the same origin but see each other as RemoteFrames.
This means that SecurityOrigin's canAccess check will pass… but this
ends up violating many assumptions in Blink that passing the security
check implies a local frame.

[1] https://www.chromium.org/developers/design-documents/process-models#Caveats

BUG=601629
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1887553002

Cr-Commit-Position: refs/heads/master@{#387087}
(cherry picked from commit f23b8e77a83a5aafabf64acf723cf2ac02c5cf0e)

Committed:
https://chromium.googlesource.com/chromium/src/+/7a0bbe39f45e7bd26a4b9328ce26...
==========

[dcheng, 2016-04-19 18:48:51]

Committed patchset #1 (id:1) manually as
7a0bbe39f45e7bd26a4b9328ce2660bc6094ef84.