On Tue, Feb 17, 2015 at 2:41 AM, 'Mike West' via net-dev
<net...@chromium.org> wrote:
> +blink-dev@, net-dev@, and erikwright@.
>
> Contact emails
> mk...@chromium.org
>
> Spec
> https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this
> is a pretty early draft with more than a few open questions; details will
> certainly change based on implementation experience)
I'm fairly cool to this, if only because of the significant
complications we've encountered at the networking stack due to the
notion of first-/third-party requests and the ambiguous security
guarantees there.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
No LGTM needed, but this sounds like a worthwhile experiment to me!Ryan's question about exit strategy is a good one, although I don't know what the answer ought to be :)
Spechttps://tools.ietf.org/html/draft-west-first-party-cookies (Note that this is a pretty early draft with more than a few open questions; details will certainly change based on implementation experience)
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; First-Party-Only;
Keep-Alive: timeout=5...
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Cache-Control: no-store, no-cache...
Connection: keep-alive...
Pragma: no-cache...
Content-Security-Policy: default-src 'none'...
Public-Key-Pins: pin-sha256=...
On Tuesday, 17 February 2015 10:43:21 UTC, Mike West wrote:Spechttps://tools.ietf.org/html/draft-west-first-party-cookies (Note that this is a pretty early draft with more than a few open questions; details will certainly change based on implementation experience)First... yes please, I think this is a really good idea :-)
But, just so it's mentioned... can we check the naming convention along with HttpOnly (no hyphens) and Max-Age (which isn't supported in <= IE8).
The draft currently says the attribute should be "First-Party-Only", for example:Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; First-Party-Only;But for some additional comparisons:Keep-Alive: timeout=5...
X-Content-Type-Options: nosniffStrict-Transport-Security: max-age=31536000; includeSubDomainsCache-Control: no-store, no-cache...
Connection: keep-alive...
Pragma: no-cache...
Content-Security-Policy: default-src 'none'...
Public-Key-Pins: pin-sha256=...Also... out of interest Mike, did you copy the SID from rfc6265 for your draft? It seems odd that they are both 31d4d96e407aad42 :-)
I picked one and ran with it. If there are strong anti-hyphen feelings, I'm happy to change the spelling. This isn't something I have strong feelings about (except insofar as I've already implemented the hypenated property, and it would be a little annoying to change it).
"<iframe>"s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.
"<iframe>"s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.So if evil.com loaded bank.com in an iFrame, it wouldn't get any cookies marked as First-Party-Only. Let's say the user logs into bank.com inside that iframe on evil.com, what would happen? Would any cookies that bank.com tried to set via logging in (i.e. to store session info) just not be set because the origin is still evil.com? I assume this would break how StumbleUpon does their iFrame'd stuff and not allow people to log into sites that used First-Party-Only cookies for storing session information, correct?