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?)

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?

/ Password manager changing subject.

>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.