I don't think there is a security vulnerability here, but it sounds like a bug.  I'll leave the restrict-view until Mike has had a chance to look at it.

Yeah, this is a bug. We're not setting the initiator correctly in this case.

Dropping the view restriction, as it's failing closed; there's no security issue, just annoyance.

And just to confirm, I consider this a bug, not a security vulnerability.

And thanks for looking into this Mike.

Same bug with  issue 616795 

 Issue 616795  has been merged into this issue.

I think this also comes into effect on the "Confirm Form Resubmission" page.

So if you submit a form (POST), maybe it shows an error message, the user follows a link (e.g. to find more information), then from that page they click on the back button to see the "Confirm Form Resubmission" page.

And while this is related to  Issue 615528 ...

If you open a PDF inline:

    Content-Type: application/pdf; charset=UTF-8
    Content-Disposition: inline; filename="Untitled.pdf"
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Expires: Thu, 19 Nov 1981 08:52:00 GMT

If you go to Save that PDF, a new request is made to re-download the PDF from the server, but this time without the SameSite cookies (in my case, this results in downloading the login page).

 Issue 620204  has been merged into this issue.

https://codereview.chromium.org/2080653002 is up for review, and will address a significant chunk of this. Might need some followup for things like downloads.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f2cb7dddfefb352de6c980d9597539674ba0272

commit 4f2cb7dddfefb352de6c980d9597539674ba0272
Author: mkwst <mkwst@chromium.org>
Date: Thu Jun 23 06:32:25 2016

SameSite: Correctly set requests' initiator for new tabs.

A user-initiatated navigation in a newly opened tab (via the omnibox, for
example) should be considered SameSite (this is step 1 of Section 2.1
of the spec[1]). This patch adjusts 'FrameLoadRequest' and 'RenderFrameImpl' accordingly.

Now when the browser initiates a navigation on a user's behalf, the frame
type will be set correctly (in 'RenderFrameImpl::NavigateInternal()'), and
the initiator will be updated only if it isn't already set (in
'RenderFrameImpl::willSendRequest()' and 'FrameLoadRequest()').

[1]: https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-2.1

BUG= 619603 

Review-Url: https://codereview.chromium.org/2080653002
Cr-Commit-Position: refs/heads/master@{#401552}

[modify] https://crrev.com/4f2cb7dddfefb352de6c980d9597539674ba0272/content/browser/loader/resource_dispatcher_host_browsertest.cc
[modify] https://crrev.com/4f2cb7dddfefb352de6c980d9597539674ba0272/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/4f2cb7dddfefb352de6c980d9597539674ba0272/third_party/WebKit/Source/core/core.gypi
[add] https://crrev.com/4f2cb7dddfefb352de6c980d9597539674ba0272/third_party/WebKit/Source/core/loader/FrameLoadRequest.cpp
[modify] https://crrev.com/4f2cb7dddfefb352de6c980d9597539674ba0272/third_party/WebKit/Source/core/loader/FrameLoadRequest.h

Just for my own notes... this is not in Chrome Canary 53.0.2777.0.

The log on:

https://chromium.googlesource.com/chromium/src.git/

Suggests that commit 4f2cb7d was done after "8886a87 Updating trunk VERSION from 2777.0 to 2778.0"... so I can presumably test when we have a build for 2778, or maybe 2779.

You can try chromium at download-chromium.appspot.com

Hi Mike,

As of Chrome Canary 53.0.2782.0, I can confirm the first issue has been resolved.

The remaining ones have not been (plus a new one), which I can demonstrate on:

http://www.krang.org.uk/misc/sameSiteCookies/

Test 1 has been fixed.

Test 2 relates to the "Confirm Form Resubmission" for a POST request (Comment 6).

Test 3 demonstrates what happens when saving a PDF (Comment 7)

Test 4 is new, and happens when saving the page as "Webpage, HTML Only".

If you right click a link and then click "Save Link As," the resulting request will not supply a samesite cookie, even if the request is bound for the same site.  I suspect this is the same as Craig's "Test 4" in Comment 13.

If the page is loaded in a cross domain iframe, the first request correctly blocks the SameSite cookie, but if the user interacts with that page, any links or forms will still block the SameSite cookies (see the new Test 5).

I realise the page is still in an iframe, but these subsequent requests are originating from the SameSite.

This is useful when a third party website is hosting a multi page application form, and are happy for the first page load to not receive any cookies (new application), but for the rest of the process they want their "session" cookie to be marked as SameSite.

Re #15, "Block third-party cookies and site data" has the same behaviour.

Re #16, If that setting is enabled (off by default), I think it should continue to block third-party cookies. In my case, I have it off, so third-party cookies should continue work when the request can be considered SameSite :-)

Thanks!

Regarding #13: I'll eventually split #2-4 out into separate bugs.

Regarding #15: This behavior is quite intentional. Requests are only considered "same-site" (or "first-party", as the case may be) if the whole ancestor chain is same-site. See https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-2.1.1 for a brief and convoluted discussion.

Thanks Mike, and I completely agree with SameSite cookies in iframes, they should be blocked, so please ignore comment #15.

This particular bug is fixed. Wrapping the remainder up under https://bugs.chromium.org/p/chromium/issues/detail?id=626242.

 Issue 625401  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e704a3c066cf58982cb44835de78628ded169db0

commit e704a3c066cf58982cb44835de78628ded169db0
Author: wangxianzhu <wangxianzhu@chromium.org>
Date: Fri Jul 29 01:11:34 2016

Always fallback to checking bitmaps during under-invalidation checking

There were some false positives of under-invalidation because the client
produces slightly different pictures for the same visual result.

Always fallback to checking bitmaps to avoid such false-positives.

This won't degrade performance because normally the pictures should
equal.

Also changed bitmap comparison to a more stable version and make the
result more readable.

BUG= 619603 

Review-Url: https://codereview.chromium.org/2184053003
Cr-Commit-Position: refs/heads/master@{#408543}

[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/core/paint/HTMLCanvasPainter.cpp
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/core/paint/LayoutObjectDrawingRecorder.h
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/platform/graphics/paint/DrawingDisplayItem.cpp
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/platform/graphics/paint/DrawingDisplayItem.h
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/platform/graphics/paint/DrawingRecorder.cpp
[modify] https://crrev.com/e704a3c066cf58982cb44835de78628ded169db0/third_party/WebKit/Source/platform/graphics/paint/DrawingRecorder.h