php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #70000 First-Party-Only Cookies
Submitted: 2015-07-06 09:52 UTC Modified: 2015-07-06 11:16 UTC
From: craig at craigfrancis dot co dot uk Assigned:
Status: Suspended Package: HTTP related
PHP Version: Irrelevant OS: N/A
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: craig at craigfrancis dot co dot uk
New email:
PHP Version: OS:

 

 [2015-07-06 09:52 UTC] craig at craigfrancis dot co dot uk
Description:
------------
Google Chrome is currently considering implementing First-Party-Only Cookies.

https://code.google.com/p/chromium/issues/detail?id=459154

https://tools.ietf.org/html/draft-west-first-party-cookies-01

https://www.chromestatus.com/feature/4672634709082112

This is an interesting security feature, so should the setcookie() function be updated to also support this?

http://php.net/setcookie

bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false  [, bool $firstonly = false ]]]]]]] )


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-06 10:42 UTC] requinix@php.net
-Status: Open +Status: Suspended -Type: Bug +Type: Feature/Change Request
 [2015-07-06 10:42 UTC] requinix@php.net
Most recent draft: https://tools.ietf.org/html/draft-west-first-party-cookies-03

The RFC is still in draft, Chromium has had some back-and-forth regarding an actual implementation (or so I read in the revision history), and apparently there's been some question regarding Chromium's behavior versus Firefox's
  https://groups.google.com/a/chromium.org/d/topic/blink-dev/ZvMEJMSU6po/discussion

Supporting First-Party-Only seems like a no-brainer to me, but I'm thinking we'd best wait until the proposal reaches RFC status. Maybe even until it reaches the major browsers.

(setcookie's signature is getting unwieldy - maybe there can be some additional work with it?)
 [2015-07-06 10:58 UTC] craig at craigfrancis dot co dot uk
-Summary: First-Party-Only Cookies +Summary: craig@craigfrancis.co.uk
 [2015-07-06 10:58 UTC] craig at craigfrancis dot co dot uk
Agreed, it was more to start the discussion now (although perhaps not waiting for too many implementations, as I know it takes a while for the likes of RedHat to get new versions of PHP into a shipping product).

And I agree that the setcookie signature is getting a bit too long:

setcookie('name', 'value', 0, '/', 'example.com', true, true, true);

Out of interest, to support this (and potentially other) flags now, I suspect it will involve re-creating the setcookie() function with a header() call?
 [2015-07-06 10:59 UTC] craig at craigfrancis dot co dot uk
-Summary: craig@craigfrancis.co.uk +Summary: First-Party-Only Cookies
 [2015-07-06 10:59 UTC] craig at craigfrancis dot co dot uk
/ Password manager changing subject.
 [2015-07-06 11:16 UTC] requinix@php.net
>Out of interest, to support this (and potentially other) flags now, I suspect it
>will involve re-creating the setcookie() function with a header() call?
Hard to say - there's not much precedent to look to. There are a couple PHP RFCs worth mentioning:
  https://wiki.php.net/rfc/named_params (stalled)
  https://wiki.php.net/rfc/skipparams (declined)

The most "obvious" solution would be an options array, like
  bool setcookie(string $name [, string $value [, array $options ]])
or, for just the flags,
  $name [, $value [, $expire [, $path [, $domain [, array $options ]]]]]
strtr() is an example of that kind of duality of usage.

But again, hard to say. Changing a function as important as this one would likely require some discussion internally.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 15:01:29 2024 UTC