Resent-Date: Tue, 10 Mar 2020 17:59:35 +0000
Resent-Message-Id: <E1jBjAF-00020J-Gk@lyra.w3.org>
MIME-Version: 1.0
References:
 <CAKXHy=d260V9_63yNBwLjDG=upZ+HG3iJ8hKbnFc0KU7fCbVcQ@mail.gmail.com>
 <110aa602-33bd-4fbf-b3af-c5530d95fc44@www.fastmail.com>
 <CAKXHy=cAiuxSzEFx5TJ8Uzz3mAdXk2yCmq-fi6nLAZ+LRGEoWA@mail.gmail.com>
 <579453b7-99cf-45cc-809c-c91f29207a1f@www.fastmail.com>
In-Reply-To: <579453b7-99cf-45cc-809c-c91f29207a1f@www.fastmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 10 Mar 2020 12:58:41 -0500
Message-ID:
 <CAKKJt-eZBXn8ZS-QLzvofWYMprPr=QGxcZ84Ffx6hu=91Vmo=A@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000004833e405a083e09b"
Received-SPF: pass client-ip=2a00:1450:4864:20::235;
 envelope-from=spencerdawkins.ietf@gmail.com; helo=mail-lj1-x235.google.com
Subject: Re: Cookies and schemes.
Archived-At: =?utf-8?q?=3Chttps=3A//www=2Ew3=2Eorg/mid/CAKKJt-eZBXn8ZS-QLzvo?=
 =?utf-8?q?fWYMprPr=3DQGxcZ84Ffx6hu=3D91Vmo=3DA=40mail=2Egmail=2Ecom=3E?=
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--0000000000004833e405a083e09b
Content-Type: text/plain; charset="UTF-8"

A minor comment on this exchange:

On Tue, Mar 10, 2020 at 2:56 AM Martin Thomson <mt@lowentropy.net> wrote:

> > 2. Perhaps we prefix the non-secure cookie names with `__Non-secure-`
> > rather than minting a new header?
>
> That might work.  It's new mechanisms, but not new-header-field new
> mechanisms.  More below.
>

I'm not an expert at this, but think I'm following the discussion in this
thread.

Is "Non-secure" the best term that could be used as a prefix? ISTM that
part of the game here may be shaming people into not continuing to use this
mechanism for months/years/ever, and "secure/non-secure" seems an awfully
overloaded term. Could the prefix be more precise about what's at stake if
you continue to use it?

Random example unlikely to be the best suggestion: compare the shame of
__Non-secure to the shame of __Trivially-Hijackable, if that's the case,
and it's the worst accurate thing you can think of. If not, please
substitute the worst possible accurate characterization.

Make good choices, of course.

Best,

Spencer

--0000000000004833e405a083e09b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">A minor comment on this exchange:</div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, =
Mar 10, 2020 at 2:56 AM Martin Thomson &lt;<a href=3D"mailto:mt@lowentropy.=
net">mt@lowentropy.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">&gt; 2. Perhaps we prefix the non-secure cookie names=
 with `__Non-secure-` <br>
&gt; rather than minting a new header?<br>
<br>
That might work.=C2=A0 It&#39;s new mechanisms, but not new-header-field ne=
w mechanisms.=C2=A0 More below.<br></blockquote><div><br></div><div>I&#39;m=
 not an expert at this, but think I&#39;m following the discussion in this =
thread.=C2=A0</div><div><br></div><div>Is &quot;Non-secure&quot; the best t=
erm that could be used as a prefix? ISTM that part of the game here may be =
shaming people into not continuing to use this mechanism for months/years/e=
ver, and &quot;secure/non-secure&quot; seems an awfully overloaded term. Co=
uld the prefix be more precise about what&#39;s at stake if you continue to=
 use it?=C2=A0</div><div><br></div><div>Random example unlikely to be the b=
est suggestion: compare the shame of __Non-secure to the shame of __Trivial=
ly-Hijackable, if that&#39;s the case, and it&#39;s the worst accurate thin=
g you can think of. If not, please substitute=C2=A0the worst possible accur=
ate characterization.=C2=A0</div><div><br></div><div>Make good choices, of =
course.</div><div><br></div><div>Best,</div><div><br></div><div>Spencer</di=
v></div></div>

--0000000000004833e405a083e09b--