From nobody Sun Oct 1 01:26:40 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=wTskTiTgjepMjwJ//2r/TPnSU1o=; b=LpwPXjbNZJBvctSX fm3Wxtpg2PppkRbrwideKUl95DgzjSIUvNsaFsdu8PLSgrOSs4+Efm5intVZMn8h dT5s1oKnmXHMqOBvDPb9YvzBYpaXoaKm7ZXFvAM4IsJnH8OmijLLNOuf/4drdzwf yxGHwZOtOvv8vGpNj1CssXGnecQ= Date: Sun, 01 Oct 2017 08:26:37 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed Subject: [httpwg/http-extensions] headers -> header fields (#411) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d0a6bcb2c28_64a23fdb29f00f3463113"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 08:26:39 -0000 ----==_mimepart_59d0a6bcb2c28_64a23fdb29f00f3463113 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit You can view, comment on, or merge this pull request online at: https://github.com/httpwg/http-extensions/pull/411 -- Commit Summary -- * headers -> header fields -- File Changes -- M draft-ietf-httpbis-origin-frame.md (2) -- Patch Links -- https://github.com/httpwg/http-extensions/pull/411.patch https://github.com/httpwg/http-extensions/pull/411.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/411 ----==_mimepart_59d0a6bcb2c28_64a23fdb29f00f3463113 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

You can view, comment on, or merge this pull request online at:

  https://github.com/httpwg/http-extensions/pull/411

Commit Summary

  • headers -> header fields

File Changes

Patch Links:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d0a6bcb2c28_64a23fdb29f00f3463113-- From nobody Sun Oct 1 07:34:35 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=yp2MtFJmKYg+bhWlummNQMpzUq4=; b=uJkL9xhXqnvBiEt2 sjLOyy2yiiQWn5ECZGEKBqzhEvb5bWZ76BqEg7nn05ZMZGgEjapoBrdVCO9ggwkw 3l+NGTYDETO4IORQta8J7mM7F9HYz7mbCstzgsLLcTML1gt/uQKXRbJz6oyjHr9a yPl0ILc+89L68oRjNx63ZkZNpCk= Date: Sun, 01 Oct 2017 14:34:31 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] [cache-digests] Avoid sending the digest when not used (#410) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d0fcf76c0a5_270403ff153d1ef28764d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 14:34:34 -0000 ----==_mimepart_59d0fcf76c0a5_270403ff153d1ef28764d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Is it really a perf regression if the first RT is otherwise idle? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/410#issuecomment-333380771 ----==_mimepart_59d0fcf76c0a5_270403ff153d1ef28764d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Is it really a perf regression if the first RT is otherwise idle?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d0fcf76c0a5_270403ff153d1ef28764d-- From nobody Sun Oct 1 07:36:20 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sun, 01 Oct 2017 07:36:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1506868575; bh=vwRQw591Cj4aPFAZQHRHlEBdIjUQCNydCc2RKuG5LI8=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=16Rh1uZiwkdwHnPB/iLuCB2avZcVuBk31lhL++bMqAlsHS7+jO7i1xgtzSX5T8f7C Ax40/c+wiZhfxAV1K/pnq6RKB5pmKO45FpDYnvXGkM5k+Fc6uxemy8JOYmaNesBmBG 4unApy2+9DZLZ/KHhUMJEC6U/Rvv22mtDyK23WkM= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] headers -> header fields (#411) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d0fd5fbfd73_26703fa03afd0f3884648"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 14:36:18 -0000 ----==_mimepart_59d0fd5fbfd73_26703fa03afd0f3884648 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #411. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/411#event-1273089746 ----==_mimepart_59d0fd5fbfd73_26703fa03afd0f3884648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #411.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d0fd5fbfd73_26703fa03afd0f3884648-- From nobody Sun Oct 1 08:29:00 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -6.782 X-Spam-Level: X-Spam-Status: No, score=-6.782 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sun, 01 Oct 2017 08:28:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1506871736; bh=hM52XQ/Xf+W+tqHhBIn2Nz91/qZJ3DuD7vxS01whn/o=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uiFa5fEfL5HRi4kzOI0y79oTfX+6kFKHS5uscB0XrLkiBmds3n85u1hZ9hr5gPvJP arQHIrfm0/x57UMFXkyy/I3tWivV/79xlZfNkpUf7nY5+pFHixmChMO4iaOLoi1kKv Kfq4V99FcVGrLw2oQbDro1DWJ5oTgOdQ33caZ+wA= To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Contributing (#362) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d109b89298e_7e1f3fb2b3562f3478911"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 15:28:59 -0000 ----==_mimepart_59d109b89298e_7e1f3fb2b3562f3478911 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @mnot pushed 1 commit. 4a3bcb8 Update CONTRIBUTING.md -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/362/files/e04a223747c78998df0206842c313c0154e68a7d..4a3bcb809b2cb702ade8062f7874f1cd4fbc9e94 ----==_mimepart_59d109b89298e_7e1f3fb2b3562f3478911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@mnot pushed 1 commit.

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59d109b89298e_7e1f3fb2b3562f3478911-- From nobody Sun Oct 1 08:29:39 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sun, 01 Oct 2017 08:29:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1506871776; bh=LuGVuWqXo5u6X+XXU/Y/TyB7H1ClBgHdE0cgB0XkF90=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=B/ODSvyJVublG/iADUIGBbxr4UiYTbZwm/sE3fsQgt9ZjdQ+gPchLx+FyZu3309Iu NICJBdLbUBoXjXXPi9aG+rysQj+z/Fno1XZhDbMNVfkuE6/2MsY50sMHoBy44zDg8o Rep++PHNng9gzFls5I+XYsB5L0g/POctfktDJNl8= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Contributing (#362) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d109e03aebb_12c223fefa1bd0f30966b0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 15:29:38 -0000 ----==_mimepart_59d109e03aebb_12c223fefa1bd0f30966b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit OK. I added an explicit statement about "membership" at the top -- that should clarify things. I don't think that with that context "we" is harmful or misleading. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/362#issuecomment-333384448 ----==_mimepart_59d109e03aebb_12c223fefa1bd0f30966b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

OK. I added an explicit statement about "membership" at the top -- that should clarify things. I don't think that with that context "we" is harmful or misleading.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d109e03aebb_12c223fefa1bd0f30966b0-- From nobody Sun Oct 1 09:06:06 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -8.254 X-Spam-Level: X-Spam-Status: No, score=-8.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sun, 01 Oct 2017 09:06:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1506873962; bh=G5F+S8m7VtxdqyvT0VkcmbtgFJmWTrXdNVCnXbR2hB0=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Lv1y0m68MUIx5P8Cr1xSUZLE9c/+1ZIutCVfskjAgWN1NpXye8u26SWikEJPXoaBZ vAC6vMbZyqAsWXDh1SihfWW028Kgyr3l6uKWcVKR8L1zRPQRAhBxR4BK3L64TfwrmP L8sadrzhLRtcIvcXnwwPkGHup5ZVlUrEOZscekHw= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Contributing (#362) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d1126a51af6_5483fb0921d8f3095684"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 16:06:04 -0000 ----==_mimepart_59d1126a51af6_5483fb0921d8f3095684 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit OK fine, thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/362#issuecomment-333386856 ----==_mimepart_59d1126a51af6_5483fb0921d8f3095684 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

OK fine, thanks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d1126a51af6_5483fb0921d8f3095684-- From nobody Sun Oct 1 09:12:41 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -4.882 X-Spam-Level: X-Spam-Status: No, score=-4.882 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Sun, 01 Oct 2017 09:12:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1506874356; bh=dqc3rbBOEXz4j4jTa/H6aGP6zBCw3qcsZm3ivm9Fslk=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=npQ9/cX7Z5d/MYWA6B0PJ0PPu4Sv/rQr56DqtGMKnuqJ7l3Nof+66+kPIYI/pTaN2 3iU+U4nGXQ4xdSERv+60HvrXBdZwpEr8g12lIn73itC3KqvOJ7GUuEp0nsWxbz5yzS ydgO1LMDuGWz1RkpIr7PA5ygLuhrkYoXa9+XumYI= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] rough in ORIGIN_SUPPORT (#406) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d113f4c1513_26bb3fd4a82ecf2c4261f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2017 16:12:39 -0000 ----==_mimepart_59d113f4c1513_26bb3fd4a82ecf2c4261f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #406. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/406#event-1273118279 ----==_mimepart_59d113f4c1513_26bb3fd4a82ecf2c4261f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #406.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d113f4c1513_26bb3fd4a82ecf2c4261f-- From nobody Wed Oct 4 21:51:36 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -3.982 X-Spam-Level: X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 04 Oct 2017 21:51:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507179092; bh=Vl3KovLbbXGmucs2cXFY4S9K54bYSd9JL3ozMw6wIYk=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sLy/PEBuR37pmO45YgA4vDPZnAmT1CXBfFBgZN/sqcwjoOdG+Hips/aXlNBc91tAw 2YZJ9S9yP86gr5u5lCK1TmvQqru04d+ae62+0c1n+C5csgniMnM0AQQGMLf71onCSF FD69GmJa+d0eXyIXuXky4BRyrlFOiweIGUweKufQ= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] [cache-digests] Avoid sending the digest when not used (#410) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5ba54b213a_649a3fda85e7ef3829715"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 04:51:35 -0000 ----==_mimepart_59d5ba54b213a_649a3fda85e7ef3829715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Since a typical website connects to multiple hosts, and connections established to fetch subresources often contend on bandwidth with other subresource fetches, sending digests for nothing could result in uplink bandwidth contention, and could delay subresource requests from going up. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/410#issuecomment-334358439 ----==_mimepart_59d5ba54b213a_649a3fda85e7ef3829715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Since a typical website connects to multiple hosts, and connections es= tablished to fetch subresources often contend on bandwidth with other sub= resource fetches, sending digests for nothing could result in uplink band= width contention, and could delay subresource requests from going up.

=

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_59d5ba54b213a_649a3fda85e7ef3829715-- From nobody Wed Oct 4 22:15:51 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=p1AmbUDzsRoBDNIlQCbCgsydATs=; b=E0ClTGATUe+sx+Fd +sQKPEzu30HX2AGSuix8PL8fHwhSI3li/ognFO8I2YY3FBUI5BP8wEb3vIqVfU9R sC9lGGj7phCINejFaIFqyAQPApN0nABpzcuMoUkntOVVex2BkfZNYHdTHRtzrYmv /Bznb/2+XjLt5Bi9/HMNhSJkyc8= Date: Thu, 05 Oct 2017 05:15:49 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] reference format (#384) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5c00475571_34633fa08594ef3410419"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:15:51 -0000 ----==_mimepart_59d5c00475571_34633fa08594ef3410419 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #384. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/384#event-1279235531 ----==_mimepart_59d5c00475571_34633fa08594ef3410419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #384.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d5c00475571_34633fa08594ef3410419-- From nobody Wed Oct 4 22:18:33 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=y/AjBYv59Rw169P6gBFn9FiLLVE=; b=VoGPDFtqEsvPuhuB UZv/OmZgjSFybkncPk5XRwq3eKCDoyPIMN29vyKF6h3Bim1aRnzadLQrAjqw6146 E8eImhQzsZi4MUDgscE8a7PCnWeCl6JKf24YuVpsWh79jpVkBYHy0vE99nFfiiC7 BF02ZhZ883NAHvNuhFY1Qfg5WRk= Date: Thu, 05 Oct 2017 05:18:19 +0000 (UTC) To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cite a recent HTML spec (#292) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5c09b554cc_631f3fda85e7ef383059d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:18:30 -0000 ----==_mimepart_59d5c09b554cc_631f3fda85e7ef383059d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @estark37 pushed 1 commit. 68dad4e Merge branch 'master' into html-citation -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/292/files/35331e6f4fa46d04d454d5fb4f6a9276e862f78c..68dad4ebea1ff276ce9c01290b0724cd3d0de288 ----==_mimepart_59d5c09b554cc_631f3fda85e7ef383059d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@estark37 pushed 1 commit.

  • 68dad4e Merge branch 'master' into html-citation

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59d5c09b554cc_631f3fda85e7ef383059d-- From nobody Wed Oct 4 22:20:03 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -8.181 X-Spam-Level: X-Spam-Status: No, score=-8.181 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 04 Oct 2017 22:19:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507180799; bh=2tfXJxtNChS74wZbn4HSgOivVLZjArGGkPyP5doechQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ds0A57OqPZ6aZHRGAAEhF1eWaMy1BGNRkhzAXuWbkjXnYqNdV8HUAwg9WRK1fezSQ ZC/KReKCl5YbNbHH+WM3mb+Cdk1hKgrUKMTRmTpdc5aexycGAgpeKBMD40VJfxAqJI sF44v2Q1fKOUNwCv4btNFFZavqSfDO0it/8sgEW4= To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cite a recent HTML spec (#292) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5c0ffeab14_4eb83f952ad40f2c735d4"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:20:02 -0000 ----==_mimepart_59d5c0ffeab14_4eb83f952ad40f2c735d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @estark37 pushed 1 commit. 1db4060 fix typo in conflict resolution -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/292/files/68dad4ebea1ff276ce9c01290b0724cd3d0de288..1db4060ad7ace30b59be512e67e2680049845f06 ----==_mimepart_59d5c0ffeab14_4eb83f952ad40f2c735d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@estark37 pushed 1 commit.

  • 1db4060 fix typo in conflict resolution

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59d5c0ffeab14_4eb83f952ad40f2c735d4-- From nobody Wed Oct 4 22:22:35 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.381 X-Spam-Level: X-Spam-Status: No, score=-5.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 04 Oct 2017 22:22:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507180950; bh=ddAWSSVaHtMDiUIT/0Sf2HxAlpsyk+GNPqyAQyclLxo=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wdQtGOP0hr10qE1WK7Y/k8QvO79cxanCMf8z2ksLv5YJm6S32V01KXsabFioqCAkn D0P0i6ebE5j4cMYBwwkpKzUR0ldGdAgm1XTaeYP/z92szSBLOs8WxLrMoGIFxnY3a7 n8g6uPq5dPAhgdxb7OXtIt/e4lLAx+GVQQpkeGng= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cite a recent HTML spec (#292) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5c1961ce2b_6cde3fa08594ef341373b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:22:35 -0000 ----==_mimepart_59d5c1961ce2b_6cde3fa08594ef341373b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #292. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/292#event-1279239957 ----==_mimepart_59d5c1961ce2b_6cde3fa08594ef341373b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #292.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d5c1961ce2b_6cde3fa08594ef341373b-- From nobody Wed Oct 4 22:22:43 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -8.253 X-Spam-Level: X-Spam-Status: No, score=-8.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 04 Oct 2017 22:22:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507180955; bh=LELtBYgYb25EVCEoFhU8TyAmzL6BlxcqQNlDVdRqVzc=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Up5SrTwBbab4ZfG+tzFLe+Wr394ABlH3KYvFtiGcA6g3A47cSPrntCa8oHwa4V48b Lmg/5T5RrLWCvg8Z4nCdxrwvU9/YEfuY4VGUy2JpuKDwJsodR7MV1H5JHCuXvnCIYR ekGZzzhc9r3rFBowlikZLTfGMPiPe1KL5sv2F2eY= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Cite a recent HTML spec (#292) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d5c19bfa7f_25733fcbfa430f3474272"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 05:22:37 -0000 ----==_mimepart_59d5c19bfa7f_25733fcbfa430f3474272 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/292#issuecomment-334362486 ----==_mimepart_59d5c19bfa7f_25733fcbfa430f3474272 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d5c19bfa7f_25733fcbfa430f3474272-- From nobody Fri Oct 6 10:37:22 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.901 X-Spam-Level: X-Spam-Status: No, score=-7.901 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 06 Oct 2017 10:36:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507311411; bh=BdpM1VLUwLVwEsoLMuHpcoQejv3MHTYW9h22oPa1m9Q=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qCwJzA/4CuAZ/WKeHfVwkXSncJuvEVfYC1Top/70totEXQF7ST33u5fPhJomCEBxH /VMXUCQIx3AonzaI1nfN9rKzU1gz3bfnU2k1qf/X9sXAr7Nh176qiuSf1Cl9+63d7p dHALiN+76lAAMJT93sayEqnslp8me+BG9rPXeOoc= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7bf331a9ca_ea83ffb8cc38f301047f3"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:37:20 -0000 ----==_mimepart_59d7bf331a9ca_ea83ffb8cc38f301047f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable @mnot @yoav I'm _not_ suggesting we rebase the entire opt-in mechanism ag= ainst FP =E2=80=94=C2=A0it's also not sufficient on its own because, as y= ou pointed out, it's missing ACHL semantics amongst other things. Rather,= I'm suggesting that we should separate these concerns: = - Accept-CH + Accept-CH-Lifetime define a mechanism for origins to advert= ise their hint and hint lifetime preferences for subsequent visits; these= two primitives are used to negotiate what hints will be made available t= o the origin. - With above in place, delegation is =E2=80=94 I claim =E2=80=94 a separa= te and complex enough problem that deserves its own treatment. As it happ= ens, that's what FP is solving, and we should leverage that. = - We _can_ still make a default double-keyed recommendation for 3P opt-= in. - We _can_ define default hint policies in terms of FP primitives. Yes, we are coupling two mechanisms here, but delegation is not an easy p= roblem and I'd much rather we reuse mechanisms than try to blaze yet anot= her trail here. Also, it's true that FP is designed with browser in mind,= but there is no reason why it can't or shouldn't work with other types o= f clients. -- = You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-3348219= 06= ----==_mimepart_59d7bf331a9ca_ea83ffb8cc38f301047f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@mnot <= a href=3D"https://github.com/yoav" class=3D"user-mention">@yoav I'm <= em>not suggesting we rebase the entire opt-in mechanism against FP =E2= =80=94=C2=A0it's also not sufficient on its own because, as you pointed o= ut, it's missing ACHL semantics amongst other things. Rather, I'm suggest= ing that we should separate these concerns:

  • Accept-CH + Accept-CH-Lifetime define a mechanism for origins to adve= rtise their hint and hint lifetime preferences for subsequent visits; the= se two primitives are used to negotiate what hints will be made available= to the origin.
  • With above in place, delegation is =E2=80=94 I claim =E2=80=94 a sepa= rate and complex enough problem that deserves its own treatment. As it ha= ppens, that's what FP is solving, and we should leverage that.
    • We can still make a default double-keyed recommendation for = 3P opt-in.
    • We can define default hint policies in terms of FP primitive= s.

Yes, we are coupling two mechanisms here, but delegation is not an eas= y problem and I'd much rather we reuse mechanisms than try to blaze yet a= nother trail here. Also, it's true that FP is designed with browser in mi= nd, but there is no reason why it can't or shouldn't work with other type= s of clients.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

=
= ----==_mimepart_59d7bf331a9ca_ea83ffb8cc38f301047f3-- From nobody Fri Oct 6 10:40:49 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 06 Oct 2017 10:40:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507311627; bh=Lp9V10yEaxF2Ru/ajKld5534MOVuft/HyJhgTGsfD8U=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BDstNjZ/qGpdZIzv3Q0ppx8PHnC4Qz5JC5r00Ro3punKqCUJAz3Mioid2kt/PmVBS t+U6dkqNz2mQL4f8pLLoFFYMSMADbm0gsbQyY9tGnTAVD2VIp/RaAXZJDBvS24o8PE Z36g8C2nUyiWNB6/6UUhCELqqsTVbHO66digxOzc= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7c00ba0c36_5ec53fa26b6d4f28292f9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:40:48 -0000 ----==_mimepart_59d7c00ba0c36_5ec53fa26b6d4f28292f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > @@ -101,9 +102,9 @@ A Client Hint request header field is a HTTP header field that is used by HTTP c ## Sending Client Hints -Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these header fields altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. +Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. The client and server, or an intermediate proxy, can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content adaption. Ack, removed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143253398 ----==_mimepart_59d7c00ba0c36_5ec53fa26b6d4f28292f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

> @@ -101,9 +102,9 @@ A Client Hint request header field is a HTTP header field that is used by HTTP c
 
 ## Sending Client Hints
 
-Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these header fields altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging.
+Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. The client and server, or an intermediate proxy, can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content adaption.

Ack, removed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7c00ba0c36_5ec53fa26b6d4f28292f9-- From nobody Fri Oct 6 10:52:43 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=jU81yXKP4/bwMx2xR68CPUao0cI=; b=XI73IPyp5skWEKp+ ylpTS6tYzFk2/W9Swd+UGqTAxkF1Fb9kCWWUIrsZpp+ldI5vglRZ5W5fX9RoCGoJ LrWQhQHc+40f9E+zqMG6JQnLUBV3u5qHS7ZUFsHlfPXVgrzGYRrgGsVX+SLJp2sV UBlV3aLOsphi3Hd6ypIRaNjs3aQ= Date: Fri, 06 Oct 2017 17:52:18 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7c2d2e99f_7aba3fa808deaf2c995bd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:52:43 -0000 ----==_mimepart_59d7c2d2e99f_7aba3fa808deaf2c995bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > @@ -127,28 +128,28 @@ For example: Accept-CH: DPR, Width, Viewport-Width ~~~ -When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the application is interested in receiving specified request header fields that match the advertised field-values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values. +When a client receives Accept-CH from a potentially trustworthy origin ({{SECURE-CONTEXTS}}), or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values. Ack, updated. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143256247 ----==_mimepart_59d7c2d2e99f_7aba3fa808deaf2c995bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

> @@ -127,28 +128,28 @@ For example:
   Accept-CH: DPR, Width, Viewport-Width
 ~~~
 
-When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the application is interested in receiving specified request header fields that match the advertised field-values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.
+When a client receives Accept-CH from a potentially trustworthy origin ({{SECURE-CONTEXTS}}), or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.

Ack, updated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7c2d2e99f_7aba3fa808deaf2c995bd-- From nobody Fri Oct 6 11:23:19 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 06 Oct 2017 11:23:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507314194; bh=AwbB6aMqgORIG1JoitLUPUmspvp5su8T+ZxWA1pZKiU=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=l7oK+2W8P2hkxq00OY3pr5u/nne+QbIzNbrb6sMnibuRO9Ws/4WfTX5plZ2j5Nl03 vtj6exl4lvipzw/LdwrCB41GSEaWK9cf2qQzpzvaoC405vd1ByE0SOYBSdCpXg9gah c/yal8ilyun0D3+WQAEM6+7MWycq69I+HU5BBS1c= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7ca125d2e9_54913fcb5a8f4f344704c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:23:17 -0000 ----==_mimepart_59d7ca125d2e9_54913fcb5a8f4f344704c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > ~~~ abnf7230 Accept-CH-Lifetime = #delta-seconds ~~~ -The field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds. +When a client receives Accept-CH-Lifetime from a potentially trustworthy origin ("opt-in origin"), the field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds, and if applicable, persisted as a double-keyed preference that combines the values of the opt-in origin and the potentially trustworthy origin of the resource that initiated the request that received the opt-in preference. Ack, took a run at rewriting this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143263089 ----==_mimepart_59d7ca125d2e9_54913fcb5a8f4f344704c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
 ~~~ abnf7230
   Accept-CH-Lifetime = #delta-seconds
 ~~~
 
-The field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds.
+When a client receives Accept-CH-Lifetime from a potentially trustworthy origin ("opt-in origin"), the field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds, and if applicable, persisted as a double-keyed preference that combines the values of the opt-in origin and the potentially trustworthy origin of the resource that initiated the request that received the opt-in preference.

Ack, took a run at rewriting this.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7ca125d2e9_54913fcb5a8f4f344704c-- From nobody Fri Oct 6 11:28:58 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=nt+Ephcgc7DNQpyVUdvhRXYbL6Y=; b=i6hfZwdAk8Pzlnkw vgKe/sA1sIt5Aw6oc4bWZVuiKp4Guec1aOQASdof1c0iy5OaHf7NGuR5LABL/BpS pTaV1by3gCw/6hgxh0QCIniuUYsA1zXw86h01lTHaWJQkXgkIekjNYWwnIwZi26s 0JPMXA+uWV+ql0iOqAoXqWibDYA= Date: Fri, 06 Oct 2017 18:27:49 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7cb25182b9_1ed83f8504730f28972b4"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:28:56 -0000 ----==_mimepart_59d7cb25182b9_1ed83f8504730f28972b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. Ack, updated. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143264089 ----==_mimepart_59d7cb25182b9_1ed83f8504730f28972b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

Ack, updated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7cb25182b9_1ed83f8504730f28972b4-- From nobody Fri Oct 6 11:34:48 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=mpwTJ1sv8K9JbfbUKVP5o7jn+Po=; b=ctVSsDmjoLhGygfB HOx+ujLBb8LPMGRL9yGLXLKaY9IQ/XFB5e8b5weO83s3uwbK5EZGPsM7WBhJl/Nn g5ocI4mt+8vXQvM+JYMLs2FT6AnW/YbqEqfT2A7csZ99q65KVAoNsiukgJBZ6XsR nfiu8pmGpYARUHn4plixHOep1Uc= Date: Fri, 06 Oct 2017 18:25:44 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7caa84bacb_389a3f9d0ebecf2c31458"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:34:46 -0000 ----==_mimepart_59d7caa84bacb_389a3f9d0ebecf2c31458 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting. +Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting as well as reduce possibility of unnecessary cache fragmentation. Ack, updated. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143263613 ----==_mimepart_59d7caa84bacb_389a3f9d0ebecf2c31458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting as well as reduce possibility of unnecessary cache fragmentation.

Ack, updated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7caa84bacb_389a3f9d0ebecf2c31458-- From nobody Fri Oct 6 11:38:15 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=V85KW8UUGxjZ9f4+65yTB2HvAz4=; b=wu12rXVaQenqQWvF VLQVKqPgYzmrDDSF26aXQdCTmlws5SFsVO3py34+Zonrlffo4jCErQlUdP2oYLWr zicSHW7nxJqmHdCnY6SP/bGz5PAOt5A9T6/RsISpxYH48/fjKFmAUJGI+8Hb9GSv tO6t8+B83reOI+cIw242EFAbfqU= Date: Fri, 06 Oct 2017 18:37:59 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7cd8434cb9_d7033ff5a119ef348078"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:38:14 -0000 ----==_mimepart_59d7cd8434cb9_d7033ff5a119ef348078 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. + - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data. + +Following the above recommendations should significantly reduce the risks of linkability and passive fingerprinting. Ack, dropped. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143266277 ----==_mimepart_59d7cd8434cb9_d7033ff5a119ef348078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data.
+
+Following the above recommendations should significantly reduce the risks of linkability and passive fingerprinting.

Ack, dropped.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7cd8434cb9_d7033ff5a119ef348078-- From nobody Fri Oct 6 11:38:30 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 06 Oct 2017 11:38:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507315085; bh=nv5n8uKChCchoyRB3gzCMBmYovxRyPiLkkTtfndPOwY=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rDGa+l7mh8pY+13j76WCdaMuJTlji6fxMpW7oSNKryTsTPyI4bDtZxPkg+7N279Qr zbHnXsId2XewyM5u8ODLQvUyC/F0543unw4CfV/zSgSEvwrJGCSc1F6Kgz/yp++yed qhqfZLVTftGzPp5ekAVNiXoqvOxMVAJE//oJfbqc= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7cd8b307c9_e983ff6e152ef282944b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:38:29 -0000 ----==_mimepart_59d7cd8b307c9_e983ff6e152ef282944b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. + - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data. This is a tricky one. Took an attempt at rewriting it -- ptal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r143266289 ----==_mimepart_59d7cd8b307c9_e983ff6e152ef282944b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data.

This is a tricky one. Took an attempt at rewriting it -- ptal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7cd8b307c9_e983ff6e152ef282944b-- From nobody Fri Oct 6 11:52:10 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=Z8z96iKDwxxrV3usPftnhFDDQdY=; b=JT0KPr0maBq+ZemC +AxMzExSTD8gJ36Yn+Xt78f3nhO4GH9Q97v791Q2xZKocvmr7hto7T6AWV5O5Rww AZ5fkm1OE63qlmdOsrxn+V0mQrHEtnJbr3Jx5DD7Pa8P/78lmxPpn2gR1jUcw7ME TJP8beoQBIQIX6jA8AnrOWUwHpU= Date: Fri, 06 Oct 2017 18:51:15 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7d0a2e1975_46673ff295d16f38379ee"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:52:08 -0000 ----==_mimepart_59d7d0a2e1975_46673ff295d16f38379ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @martinthomson @mnot thanks for the feedback! Updated, ptal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#issuecomment-334839975 ----==_mimepart_59d7d0a2e1975_46673ff295d16f38379ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@martinthomson @mnot thanks for the feedback! Updated, ptal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59d7d0a2e1975_46673ff295d16f38379ee-- From nobody Fri Oct 6 11:57:28 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=+aQIZ3XfnXjKyrcII+s06QKQmnY=; b=bRAg2F7X2+31Yelw ijwtrF7moYcTql51IVt67WRW7wU4yB62V2IJsiJMm7oyX9r9IoDAssk5DTR2rLgl FO1oIF/ayIhyPu27vy1tO/zg9ayZ+iGayYzhdqJ5hrZw1M82SBrzFos5eqvpeiaG y5+B2TJ0TU79wX4v4/Dn0Ga9CXU= Date: Fri, 06 Oct 2017 18:56:43 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59d7d1eb7aed4_227c3fda21d4af2c711e1"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:57:27 -0000 ----==_mimepart_59d7d1eb7aed4_227c3fda21d4af2c711e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updated https://github.com/httpwg/http-extensions/pull/373 with outstanding= feedback =E2=80=94 ptal.=20 As a quick recap, with #373 we have: - Accept-CH and Accept-CH-Lifetime are the mechanisms to advertise support= and lifetime prefs. - Both are scoped to secure transports. - Preference is bound to the origin / double-keyed. Current update does _not_ address delegation. As proposed above, I'm sugges= ting we solve that part of the problem via Feature Policy. If that sounds r= easonable, I can add some language in #373 to outline how/where this should= be defined. WDYT? --=20 You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-334841244= ----==_mimepart_59d7d1eb7aed4_227c3fda21d4af2c711e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Updated #373= with outstanding feedback =E2=80=94 ptal.

As a quick recap, with #373 we have:

  • Accept-CH and Accept-CH-Lifetime are the mechanisms to advertise suppor= t and lifetime prefs.
  • Both are scoped to secure transports.
  • Preference is bound to the origin / double-keyed.

Current update does not address delegation. As proposed above, = I'm suggesting we solve that part of the problem via Feature Policy. If tha= t sounds reasonable, I can add some language in #373 to outline how/where this should be d= efined.

WDYT?

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or <= a href=3D"https://github.com/notifications/unsubscribe-auth/AORpyO_BeI32chU= N5OZF0JbZYLDsSwaVks5spnfrgaJpZM4Oc7TI">mute the thread.3D""

= ----==_mimepart_59d7d1eb7aed4_227c3fda21d4af2c711e1-- From nobody Mon Oct 9 16:41:12 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=OiQOCC4WTluIwIrL5cEMne9nX78=; b=aKv6zG/f9vlKqBi+ DVfTImYU1cnFIwGNYRqNSvnMG8WDlutwOpk6CiNcaFxZ74lc9zafkWy7gbbUO/20 3bIRR9Psrc1cCoZF/5mFnWZF9g5DiL6FynbFl0ynNVo4nCFGfdL3zbEmm0nXO3Et uBaViuHdjm5kKsM3bx3fx1mSobo= Date: Mon, 09 Oct 2017 23:41:09 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] fix list rule reference (#376) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59dc0914f3b3c_2b8143fb7ad690f387222"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:41:12 -0000 ----==_mimepart_59dc0914f3b3c_2b8143fb7ad690f387222 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #376. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/376#event-1285084174 ----==_mimepart_59dc0914f3b3c_2b8143fb7ad690f387222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #376.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59dc0914f3b3c_2b8143fb7ad690f387222-- From nobody Mon Oct 9 17:19:11 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 09 Oct 2017 17:19:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507594747; bh=LJv92iCfvO4BwCydvhh4SCx9+Z8TUte17wZdmMYEzNI=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zvdkWf0M1ryEJ9SMO2y7wYGjJEyoG1amxif/dig7pk3U6R4RF6avfIZCC5Dml9m1L Ih2onQ9tl+PT+SwlK6eUVOSAHg7hYRgxlcmOlQlStTdQwHzl1mJATJ+SWzFnGL6Uy7 K/nINW2DtfGV8JS4NuGoSyeZhkIjZnKsc7S99lUc= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59dc11fb493e3_1a23ff96052af2871742"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 00:19:09 -0000 ----==_mimepart_59dc11fb493e3_1a23ff96052af2871742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Looks better. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#issuecomment-335323667 ----==_mimepart_59dc11fb493e3_1a23ff96052af2871742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Looks better.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59dc11fb493e3_1a23ff96052af2871742-- From nobody Mon Oct 9 21:08:23 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Mon, 09 Oct 2017 21:08:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507608496; bh=K8cRgJmh4q72WF0/7KjBFCNSg1R2diOf4tbX3woP/N8=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xU3TWCg5+eWSCSjeRPZLrVOb1lYv2y3tqSGD+wQjH2S05I4WH7P4beOB/UgotWFs7 fWJwO2qnHYGPvrCwbiCSO+RlqqjzJ22oCROZXLehtEFtIhztMVniRipVd2T6Rs2rm5 uSdTFnKB/sg0kZK2Txed0cD6QdRFko8zWy60Hm+I= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59dc47b06aa32_4dae3fdb13f14f2c24873"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 04:08:21 -0000 ----==_mimepart_59dc47b06aa32_4dae3fdb13f14f2c24873 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit martinthomson commented on this pull request. > @@ -127,28 +127,28 @@ For example: Accept-CH: DPR, Width, Viewport-Width ~~~ -When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the application is interested in receiving specified request header fields that match the advertised field-values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values. +When a client receives an HTTP response, over a secure transport, that contains Accept-CH header field, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values. This sentence needs to be split up for readability. I think that you have many clauses here. Client hints can be carried in HTTP headers. The client will only send client hints if the origin explicitly indicates that it supports them. The server indicates support using the Accept-CH header field. Support can be indicated using Accept-CH that is carried in meta-equivalent tags in HTML. The client will only send client hints for requests with an https scheme. > ### The Accept-CH-Lifetime Header Field {#accept-ch-lifetime} -Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin ({{RFC6454}}), and on any requests initiated as a result of processing a response from the origin. +Servers can ask the client to remember sent Accept-CH preference for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server's origin ({{RFC6454}}). "sent Accept-CH preference" is an odd grammatical construct. How about simply "the set of client hints that the server supports (or prefers)"? > ~~~ abnf7230 Accept-CH-Lifetime = #delta-seconds ~~~ -The field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds. +When a client receives an HTTP response, over a secure transport, that contains Accept-CH-Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be considered stale after response's age ({{RFC7234}}, section 4.2) is greater than the specified number of seconds. Same sentence structure as before. Easier to read this time, but why not just come right out and say it? A server's preferences regarding client hints MUST NOT be persisted for an origin that isn't HTTPS. > ~~~ example Accept-CH: DPR, Width Accept-CH: Viewport-Width Accept-CH-Lifetime: 86400 ~~~ -For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day). Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR, Width, and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin. +For example, based on the Accept-CH and Accept-CH-Lifetime example above, which is received from bar.com in response to a resource request initiated by foo.com, both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to foo.com, for requests initiated to bar.com from foo.com, for up to 86400 seconds (1 day); this preference SHOULD NOT extend to requests initiated to bar.com from other origins. Use origins rather than names. Also, foo.com is a real name and you should use foo.example.com instead. > @@ -257,11 +257,15 @@ The Content-DPR response header field indicates to the client that the server ha # Security Considerations -The request header fields defined in this specification expose information that is already available to Web applications in the browser runtime itself (e.g., using JavaScript and CSS). For example, the application can obtain viewport width, image display width, and device pixel ratio via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled. However, servers that gather this information through such mechanisms are typically observable (e.g., you can see that they're using JavaScript to gather it), whereas servers' use of the header fields introduced by this specification is not observable. Section 2.1 discusses potential mitigations. +The request header fields defined in this specification, and those that extend it, expose information about the user's environment to enable proactive content negotiation. Such information may reveal new information about the user and implementers ought to consider the following considerations, recommendations, and best practices. I don't think that the word "proactive" is correct. "Proactive content negotiation" would involve the server taking extra action (like ringing your high school music teacher) to find out what you might prefer. For example, "proactive" might be used to describe what the advertising industry does to ensure that you are provided with relevant advertising. > -For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting. +Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation. SHOULD NOT? Also "via other means, such as using HTML, CSS, or JavaScript" > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. The cache clearing thing appears here as an aside. I think that you want a complete paragraph on this. (And a MUST). > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. Again with the ", delivered over secure transport,". > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. The server opt-in isn't really a security mechanism. The adversary here is the server. I would remove this item from the list. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. + - Implementations specific to certain use cases or threat models may avoid transmitting some or all of Client Hints header fields. For example, by limiting them to authenticated sessions only that already carry identifying information, such as cookies or referer data, and/or avoid transmission of header fields that carry higher risks of linkability. This doesn't really work. We don't regulate the use of cookies, so it is trivial for your adversary (the server) to construct a cookie if that causes the client hints to be sent to it. If we scratch this and the second item, that reduces the entire set of protections to "ask the user", which isn't very satisfying. Maybe there is something here that could be extracted, but this text doesn't do it. Take one sort of coincidental signal that the user might generate: they actively choose to send a password to the server. This might be argued to indicate that further identification is acceptable to that user. But passwords are - if the user follows good practices - origin-specific, and so the act of sending a password does not inherently create linkability. What you want to look for is a signal that the user is OK to link their activity here with activity elsewhere. That's a whole lot harder, especially since we try really hard to avoid creating inadvertent or secondary signals like that. > -For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting. +Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation. This is better, but it fails to recognize that some information can leak, even when attempts are made to obscure it. I would add a note saying something like "Reducing the set of values that can be expressed in client hints can improve privacy by ensuring that the same value is sent by multiple users, but this can be insufficient for some types of data, especially data that can change over time." That would address my concern regarding the possibility of a Geolocation header field that is a client hint. (I would retain a host of other concerns about such a proposal, but you can't be expected to address all of those here.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-68143056 ----==_mimepart_59dc47b06aa32_4dae3fdb13f14f2c24873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@martinthomson commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

> @@ -127,28 +127,28 @@ For example:
   Accept-CH: DPR, Width, Viewport-Width
 ~~~
 
-When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the application is interested in receiving specified request header fields that match the advertised field-values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.
+When a client receives an HTTP response, over a secure transport, that contains Accept-CH header field, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.

This sentence needs to be split up for readability. I think that you have many clauses here. Client hints can be carried in HTTP headers. The client will only send client hints if the origin explicitly indicates that it supports them. The server indicates support using the Accept-CH header field. Support can be indicated using Accept-CH that is carried in meta-equivalent tags in HTML. The client will only send client hints for requests with an https scheme.

In draft-ietf-httpbis-client-hints.md:

>  
 
 ### The Accept-CH-Lifetime Header Field {#accept-ch-lifetime}
 
-Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin ({{RFC6454}}), and on any requests initiated as a result of processing a response from the origin.
+Servers can ask the client to remember sent Accept-CH preference for a specified period of time, to enable delivery of Client Hints on subsequent requests to the server's origin ({{RFC6454}}).

"sent Accept-CH preference" is an odd grammatical construct. How about simply "the set of client hints that the server supports (or prefers)"?

In draft-ietf-httpbis-client-hints.md:

>  
 ~~~ abnf7230
   Accept-CH-Lifetime = #delta-seconds
 ~~~
 
-The field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds.
+When a client receives an HTTP response, over a secure transport, that contains Accept-CH-Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be considered stale after response's age ({{RFC7234}}, section 4.2) is greater than the specified number of seconds.

Same sentence structure as before. Easier to read this time, but why not just come right out and say it? A server's preferences regarding client hints MUST NOT be persisted for an origin that isn't HTTPS.

In draft-ietf-httpbis-client-hints.md:

>  
 ~~~ example
   Accept-CH: DPR, Width
   Accept-CH: Viewport-Width
   Accept-CH-Lifetime: 86400
 ~~~
 
-For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day). Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR, Width, and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin.
+For example, based on the Accept-CH and Accept-CH-Lifetime example above, which is received from bar.com in response to a resource request initiated by foo.com, both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to foo.com, for requests initiated to bar.com from foo.com, for up to 86400 seconds (1 day); this preference SHOULD NOT extend to requests initiated to bar.com from other origins.

Use origins rather than names. Also, foo.com is a real name and you should use foo.example.com instead.

In draft-ietf-httpbis-client-hints.md:

> @@ -257,11 +257,15 @@ The Content-DPR response header field indicates to the client that the server ha
 
 # Security Considerations
 
-The request header fields defined in this specification expose information that is already available to Web applications in the browser runtime itself (e.g., using JavaScript and CSS). For example, the application can obtain viewport width, image display width, and device pixel ratio via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled. However, servers that gather this information through such mechanisms are typically observable (e.g., you can see that they're using JavaScript to gather it), whereas servers' use of the header fields introduced by this specification is not observable. Section 2.1 discusses potential mitigations.
+The request header fields defined in this specification, and those that extend it, expose information about the user's environment to enable proactive content negotiation. Such information may reveal new information about the user and implementers ought to consider the following considerations, recommendations, and best practices.

I don't think that the word "proactive" is correct. "Proactive content negotiation" would involve the server taking extra action (like ringing your high school music teacher) to find out what you might prefer. For example, "proactive" might be used to describe what the advertising industry does to ensure that you are provided with relevant advertising.

In draft-ietf-httpbis-client-hints.md:

>  
-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation.

SHOULD NOT? Also "via other means, such as using HTML, CSS, or JavaScript"

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

The cache clearing thing appears here as an aside. I think that you want a complete paragraph on this. (And a MUST).

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

Again with the ", delivered over secure transport,".

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

The server opt-in isn't really a security mechanism. The adversary here is the server. I would remove this item from the list.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting some or all of Client Hints header fields. For example, by limiting them to authenticated sessions only that already carry identifying information, such as cookies or referer data, and/or avoid transmission of header fields that carry higher risks of linkability.

This doesn't really work. We don't regulate the use of cookies, so it is trivial for your adversary (the server) to construct a cookie if that causes the client hints to be sent to it.

If we scratch this and the second item, that reduces the entire set of protections to "ask the user", which isn't very satisfying. Maybe there is something here that could be extracted, but this text doesn't do it.

Take one sort of coincidental signal that the user might generate: they actively choose to send a password to the server. This might be argued to indicate that further identification is acceptable to that user. But passwords are - if the user follows good practices - origin-specific, and so the act of sending a password does not inherently create linkability.

What you want to look for is a signal that the user is OK to link their activity here with activity elsewhere. That's a whole lot harder, especially since we try really hard to avoid creating inadvertent or secondary signals like that.

In draft-ietf-httpbis-client-hints.md:

>  
-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation.

This is better, but it fails to recognize that some information can leak, even when attempts are made to obscure it. I would add a note saying something like "Reducing the set of values that can be expressed in client hints can improve privacy by ensuring that the same value is sent by multiple users, but this can be insufficient for some types of data, especially data that can change over time." That would address my concern regarding the possibility of a Geolocation header field that is a client hint. (I would retain a host of other concerns about such a proposal, but you can't be expected to address all of those here.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59dc47b06aa32_4dae3fdb13f14f2c24873-- From nobody Thu Oct 12 19:23:12 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=3ilBoaVj2okJMuFYqUR9DCJ1/cU=; b=HZ9ukyYGt63Zahs/ 5pFnUqhLQkTryHRLTNpl1N15P05fw0jBr6fcu/9nn4L8owFGHXGzP0Kq9rDz6wQG 6WRwiFOaNjNszThqQTY8lXYyQNmZzvZfDbnIPPqCawT71gGh7+D8rUH5PzSOCU8g K8x3oyFdMCQe0yMX6+z4COPh3Bo= Date: Fri, 13 Oct 2017 02:23:08 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Contributing (#362) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e0238cacad6_14c823fb034a66f34349b9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 02:23:11 -0000 ----==_mimepart_59e0238cacad6_14c823fb034a66f34349b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #362. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/362#event-1291490220 ----==_mimepart_59e0238cacad6_14c823fb034a66f34349b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #362.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e0238cacad6_14c823fb034a66f34349b9-- From nobody Fri Oct 13 13:54:43 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 13:54:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507928079; bh=ZI81ANqkl+1Ug6wzdPz783nD/JnvDJnwp6HBW1OHRHE=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rwhGOXUiaUV5tndi5qQwlLNQC+D4PCq2yNiGaXsfchEMbdL6tPDDGepwKPXXpDlaD ek7A5wzBcqZQqfi07G5vNxlfpvEkYIbJPfmmHWeo2ZChLttfxSFBqgY0xN3+JwNOqv tu+uzmSk/yIxfe1LzIbw05GXC+jenLq0uxybLjJ4= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e1280f4d8dc_617a3fa1b07daf283098d"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 20:54:42 -0000 ----==_mimepart_59e1280f4d8dc_617a3fa1b07daf283098d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > @@ -257,11 +257,15 @@ The Content-DPR response header field indicates to the client that the server ha # Security Considerations -The request header fields defined in this specification expose information that is already available to Web applications in the browser runtime itself (e.g., using JavaScript and CSS). For example, the application can obtain viewport width, image display width, and device pixel ratio via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled. However, servers that gather this information through such mechanisms are typically observable (e.g., you can see that they're using JavaScript to gather it), whereas servers' use of the header fields introduced by this specification is not observable. Section 2.1 discusses potential mitigations. +The request header fields defined in this specification, and those that extend it, expose information about the user's environment to enable proactive content negotiation. Such information may reveal new information about the user and implementers ought to consider the following considerations, recommendations, and best practices. I believe we use "proactive" and "server-driven" interchangeably, so current language is OK. That said, I'll defer to @mnot and @mcmanus. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r144655023 ----==_mimepart_59e1280f4d8dc_617a3fa1b07daf283098d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

> @@ -257,11 +257,15 @@ The Content-DPR response header field indicates to the client that the server ha
 
 # Security Considerations
 
-The request header fields defined in this specification expose information that is already available to Web applications in the browser runtime itself (e.g., using JavaScript and CSS). For example, the application can obtain viewport width, image display width, and device pixel ratio via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled. However, servers that gather this information through such mechanisms are typically observable (e.g., you can see that they're using JavaScript to gather it), whereas servers' use of the header fields introduced by this specification is not observable. Section 2.1 discusses potential mitigations.
+The request header fields defined in this specification, and those that extend it, expose information about the user's environment to enable proactive content negotiation. Such information may reveal new information about the user and implementers ought to consider the following considerations, recommendations, and best practices.

I believe we use "proactive" and "server-driven" interchangeably, so current language is OK. That said, I'll defer to @mnot and @mcmanus.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e1280f4d8dc_617a3fa1b07daf283098d-- From nobody Fri Oct 13 13:55:48 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 13:55:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507928144; bh=BPxx3ZBXoJ2PrWazYLg9SJt2bTfSRoq7ZNmDHRSJGyQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vzY8W5W0DI7k56GozHUTpsrxj9O7FMQQqgEFHKyWosZY/HLR7tYjO1KfFXD+5qMAn Qn4Dy3Gm2xYK9K2D/ctxC7Bg8hyorkeGutih5QTJDzhEJE9hQ3i71lk7FjdgN2CKyl 8AV2H01u9lruiyc8ZiglHymDJDwuMQmQrTDVC0Oc= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e12850d6243_1f5b3ff5ff7c0f301042a9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 20:55:47 -0000 ----==_mimepart_59e12850d6243_1f5b3ff5ff7c0f301042a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting. +Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation. ack -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r144655221 ----==_mimepart_59e12850d6243_1f5b3ff5ff7c0f301042a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation.

ack

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e12850d6243_1f5b3ff5ff7c0f301042a9-- From nobody Fri Oct 13 14:03:08 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=VCnLJjGvYdmr4WR0AEJ3iuETIX4=; b=UKh6gHoO0IXe+5hB 60YTqdqzhzd48w3zpcDxOs788T/h47v+oxvektjuYYzQXt8gL7wCg62Hb7bcGFsC epq5cj91yr/aFO+t3UoSxr8CBkfjIHEQ4/0GsJeRzzPV0/deTrLeePBNwUZGQ9Xd mE0VSwOVVDgVYCpZrrxZiY1McB0= Date: Fri, 13 Oct 2017 21:02:57 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e129fdf3570_2578c3fecafb1ef28191a2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:03:08 -0000 ----==_mimepart_59e129fdf3570_2578c3fecafb1ef28191a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting. +Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation. Thanks good suggestions, tried to rewrite and work this into current text. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r144656473 ----==_mimepart_59e129fdf3570_2578c3fecafb1ef28191a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the advertised value is close but is not an exact representation of the current value, can help reduce the risk of such linkability as well as reduce possibility of unnecessary cache fragmentation.

Thanks good suggestions, tried to rewrite and work this into current text.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e129fdf3570_2578c3fecafb1ef28191a2-- From nobody Fri Oct 13 14:08:16 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 14:08:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507928893; bh=4UufKw9h73TEMEB1VtDa80mtRPxanJCHcLnDeunKAf0=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C//t8R5rJXU3iyvtbdUsXOigDs4phS9D6bxaDeGniLx/R/Z7sXzPcS0Eg+6Q/YIbG rBQNn2xxcrg4jN9e7maiVef8E3sSSTQCi1wEEutl95FyJZPXTRnd1l6iy10X1LG/zR IWHfyrtuRhpVCuqAXvz6fYf/v/kZ8oaIWXvqeG+o= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e12b3d7d580_351b3fcce64eef38912a0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:08:15 -0000 ----==_mimepart_59e12b3d7d580_351b3fcce64eef38912a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. Good call, mixing may/must's here.. Moved it into a separate section. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r144657398 ----==_mimepart_59e12b3d7d580_351b3fcce64eef38912a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

Good call, mixing may/must's here.. Moved it into a separate section.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e12b3d7d580_351b3fcce64eef38912a0-- From nobody Fri Oct 13 14:27:58 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=zVVP8ceYomN+OvUWakc7IWOz4BQ=; b=KCL/l8SB8Yj5z1k3 4y34urwesT0ibUPaHv2TSKIu3X8rRddd56zaj9xHd2Ro0AY1goiCrwIAGaEnu6jc FrP3n+flHoIVREmuxTLct56p+LUiRz+CFJuSmTt2gihO1xAfG1Md4FOZ0CNOvszi sBv4/Nb395YDJj18QpBRzw4Lzhc= Date: Fri, 13 Oct 2017 21:27:40 +0000 (UTC) To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e12fcc64aa4_48463fac8af12f2c93847"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:27:56 -0000 ----==_mimepart_59e12fcc64aa4_48463fac8af12f2c93847 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @igrigorik pushed 3 commits. 7d738c9 rework accept-ch / accept-ch-lifetime text 29065eb use origins in example b4ef4d0 integrate Martin's feedback for security section -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/373/files/4f046666a573a6fa7cf4d663f0ad07543afd19c3..b4ef4d00fe450fc09332332f25fb014bfa1fda7f ----==_mimepart_59e12fcc64aa4_48463fac8af12f2c93847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik pushed 3 commits.

  • 7d738c9 rework accept-ch / accept-ch-lifetime text
  • 29065eb use origins in example
  • b4ef4d0 integrate Martin's feedback for security section

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59e12fcc64aa4_48463fac8af12f2c93847-- From nobody Fri Oct 13 14:28:02 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.02 X-Spam-Level: X-Spam-Status: No, score=-7.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 14:27:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507930061; bh=pBevPAednQuwwCiBoeN4KmweVwlbqBKWBQ762EH9yH8=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EWdgHXAAflB1z3JcEdb4t6u9HnUdBFtqyRSuvkb2DQVzzWmAaRNieqAa9UPHOvCWB 010WCbu5NaYNhYikVE77kl4vunDzYZ1y13Ua/GVb/ur8zxOzlkBQdpjI9+kBRZJvtB ilq1pEPKE1VyXb5M58x3Kr7vtuYUNtqafrvweHyI= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e12fccf2bf8_1871a3ff9bf366f3417676"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:27:57 -0000 ----==_mimepart_59e12fccf2bf8_1871a3ff9bf366f3417676 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. +Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised: + + - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging. + - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared. + - Implementations specific to certain use cases or threat models may avoid transmitting some or all of Client Hints header fields. For example, by limiting them to authenticated sessions only that already carry identifying information, such as cookies or referer data, and/or avoid transmission of header fields that carry higher risks of linkability. The HTTPS requirement we're adding in this update helps scope down our list of adversaries: before we were also considering passive observers, now we're scoped to the response server. With that in mind, good point on regulating cookies: with server as adversary it's not a meaningful protection. That said, I think the broader "may avoid transmitting some or all of CH header fields" can be a valid recommendation. I'll drop the cookies and referrer text. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r144660500 ----==_mimepart_59e12fccf2bf8_1871a3ff9bf366f3417676 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support Client Hints opt-in, delivered over secure transport, as advertised by Accept-CH and Accept-CH-Lifetime header fields, and must clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting some or all of Client Hints header fields. For example, by limiting them to authenticated sessions only that already carry identifying information, such as cookies or referer data, and/or avoid transmission of header fields that carry higher risks of linkability.

The HTTPS requirement we're adding in this update helps scope down our list of adversaries: before we were also considering passive observers, now we're scoped to the response server. With that in mind, good point on regulating cookies: with server as adversary it's not a meaningful protection.

That said, I think the broader "may avoid transmitting some or all of CH header fields" can be a valid recommendation. I'll drop the cookies and referrer text.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e12fccf2bf8_1871a3ff9bf366f3417676-- From nobody Fri Oct 13 14:28:50 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 14:28:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507930127; bh=O6NyH3mu/m5+clRud6YrCO5YxQLMYMvCQlwOeRaobJU=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Omhvm3lG71HQ90YqhYF/To4kkKnECB42LohnctZ9/M3P23BTXfm5JF46ngJC0cmCv PY0vJrINE/Wn+xy9hlWCr/u1AibwGmjOO+Ua1T/aYp/sjtWY0bBl7pJJDvNe2+t75Z q0NvKA4YZFUtUsRnwnDbN1fpwYOVR3j3s29QDQ5g= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e1300ef3b27_190da3ff9bf366f3419512"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:28:49 -0000 ----==_mimepart_59e1300ef3b27_190da3ff9bf366f3419512 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @martinthomson thanks for the thorough review (and patience :)), again! Updated, ptal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#issuecomment-336571988 ----==_mimepart_59e1300ef3b27_190da3ff9bf366f3419512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@martinthomson thanks for the thorough review (and patience :)), again! Updated, ptal.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e1300ef3b27_190da3ff9bf366f3419512-- From nobody Fri Oct 13 14:31:01 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -8.182 X-Spam-Level: X-Spam-Status: No, score=-8.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 13 Oct 2017 14:30:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507930257; bh=mhW5L1EG6Ldf5kR8gx2otvF+SrAhWX4tEexBG/jotiA=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xsy+rU23poWxiuKIXMyjDptdrryB5biTBm9g8qibHpnhuYFq/pY0Cpeu9jbzXL/qU CRl/r5LF5TyBXQs6SHVPo+pPEiZw/7B6QXolmHKKUu6v3Jkaw00H+hpdKE2YiAD9uh q3mzWAQygLCBGYrOqk7iXD90wzPQaxQTZYs6B9XQ= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59e13091b2eb1_fdd3fb85ef76f3870956"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:31:00 -0000 ----==_mimepart_59e13091b2eb1_fdd3fb85ef76f3870956 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @arturjanc @mnot @yoavweiss friendly bump.. :bowtie: -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-336572366 ----==_mimepart_59e13091b2eb1_fdd3fb85ef76f3870956 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@arturjanc @mnot @yoavweiss friendly bump.. :bowtie:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59e13091b2eb1_fdd3fb85ef76f3870956-- From nobody Mon Oct 23 21:40:05 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=/71gYR6o7wsvNVISCUNOmlB5qaA=; b=n4RlP4QtnDgbyQdR yVHMI04gG7kTZYMfLav+PleHumCmK7DL7627BbwK6LGBm5ncyn3+kRvVe1vKubMq yOUb0wKwg63mn9AOfem0u6Hv30iJ2G/AuxhJGMisklbgknoFsm+8ghU3b9Rgv0PY etMPuD3TYx9fyGQKldyokK/4vi4= Date: Tue, 24 Oct 2017 04:40:01 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed Subject: [httpwg/http-extensions] Single / Multiple headers? (#412) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59eec420ba0a4_3de23fc37c5ccf2c1225f3"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 04:40:04 -0000 ----==_mimepart_59eec420ba0a4_3de23fc37c5ccf2c1225f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Should we allow splitting common structure data over multiple headers ? Pro: Avoids size restrictions, easier on-the-fly editing Contra: Cannot act on any such header until all headers have been received. We must define where headers can be split (between identifier and dictionary ?, in the middle of dictionaries ?) Most on-the-fly editing is hackish at best. _from the draft_ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/412 ----==_mimepart_59eec420ba0a4_3de23fc37c5ccf2c1225f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Should we allow splitting common structure data over multiple headers ?

Pro:

Avoids size restrictions, easier on-the-fly editing

Contra:

Cannot act on any such header until all headers have been received.

We must define where headers can be split (between identifier and dictionary ?, in the middle of
dictionaries ?)

Most on-the-fly editing is hackish at best.

from the draft

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59eec420ba0a4_3de23fc37c5ccf2c1225f3-- From nobody Wed Oct 25 09:32:19 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=lSGkKTK5udMuaE98GCVei4zh+RQ=; b=rSVUnguZrtoeLCmW uRsCJiZY4cOb3mCFRm5xdj6E912vyRlm8r/C7bkQGkIrtR536aRz8aDiGbHOJQ0f e7vskDR3mtrhUmnuPMXObYGGddWVdGbo86tSPvihH0sAni0GZnkwT2W8cL/FEznv kGMimfxfgnhp002zEIiShDdJoNI= Date: Wed, 25 Oct 2017 16:32:15 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f0bc8f4fc6e_2dddd3ff493bdcf28352152"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:32:18 -0000 ----==_mimepart_59f0bc8f4fc6e_2dddd3ff493bdcf28352152 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Is this fixed? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-339390225 ----==_mimepart_59f0bc8f4fc6e_2dddd3ff493bdcf28352152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Is this fixed?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59f0bc8f4fc6e_2dddd3ff493bdcf28352152-- From nobody Wed Oct 25 17:25:45 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=yjZp3w2iGwjYEaIe0AUYYzg+Ap0=; b=MVzJTzQ3PfJC3yPC 7RXc2NSEAoaPTBAi9tP6mKIDXoW8I6E8bNLLPUhKzgZQ/MwMwn7zr87M6bWxQy1s OXpLwqhQaERYgH13dPuBzZwEiWCBExtRUSN0cDgCPunwLk2KbrRGGG2Z3jEB4+nY nXp4DmR0MuktWiSeUqpoIZ+2+xw= Date: Thu, 26 Oct 2017 00:25:41 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f12b84d8e6d_281b3f9aec528f34155974"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 00:25:43 -0000 ----==_mimepart_59f12b84d8e6d_281b3f9aec528f34155974 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think it'd be good to see #373 in situ; from what I see in the patch, I think it's strictly better. No guarantees that there aren't other issues, or that this isn't completely covered, but personally I think it's better. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-339513412 ----==_mimepart_59f12b84d8e6d_281b3f9aec528f34155974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think it'd be good to see #373 in situ; from what I see in the patch, I think it's st= rictly better. No guarantees that there aren't other issues, or that this i= sn't completely covered, but personally I think it's better.

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or <= a href=3D"https://github.com/notifications/unsubscribe-auth/AORpyAyC6irJv4v= -4oboYq2ULmrGafofks5sv9GEgaJpZM4Oc7TI">mute the thread.3D""

= ----==_mimepart_59f12b84d8e6d_281b3f9aec528f34155974-- From nobody Wed Oct 25 23:39:06 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Wed, 25 Oct 2017 23:39:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1508999943; bh=xrV1gskdkJrhfr8rPl+NUYJyV/+wiUCe0FleY2gwj1A=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bF+N0hikRBUyi1PHD03w9fUcq7HsjVpSavYDsFiLyUFF2MHtztG5zBhduvgmoTEd8 FqLjeYUZQwNIPUKDnbyjtotl+xhrBwNOb/GAgO5ewLi8UjdKwlncqIIETaKqH4wPXk 68OsBkbZm4dsc8VTi75itFWPpNoKxIGsMaagpGrI= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f183074042_64da3fca6bf9cf34486897"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 06:39:05 -0000 ----==_mimepart_59f183074042_64da3fca6bf9cf34486897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit yoavweiss commented on this pull request. Overall looks good. IIUC, the opt-ins are limited to secure transport, but the actual hints are not. Is that correct? If so, should we change it? > -The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption. +Implementers should be be aware of the passive fingerprinting and network information disclosure implications when implementing support for Client Hints, and follow the considerations outlined in "Security Considerations" section of this document. Nit: s/be be/be/ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-72088958 ----==_mimepart_59f183074042_64da3fca6bf9cf34486897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@yoavweiss commented on this pull request.

Overall looks good. IIUC, the opt-ins are limited to secure transport, but the actual hints are not. Is that correct? If so, should we change it?

In draft-ietf-httpbis-client-hints.md:

>  
-The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption.
+Implementers should be be aware of the passive fingerprinting and network information disclosure implications when implementing support for Client Hints, and follow the considerations outlined in "Security Considerations" section of this document.

Nit: s/be be/be/

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59f183074042_64da3fca6bf9cf34486897-- From nobody Fri Oct 27 11:16:01 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 27 Oct 2017 11:15:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1509128158; bh=SY0h0Tld9lEroweGLbACFRLpH1FiqhEOOxjFQZG9R4c=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=S56vb4CU8rtWiupf9N4nFYTiHrCCKTW4ok39Sp6I3cD9t+1Wh4pZMuPN2IvLwUfZt 4b+Obz0A7ULrF19wdrTGzpK1tZ/O0jSw9QA9Bzc+zhd9QNdEYsNRsXGqsI6RQmTRX1 oa6s8ch8FMOYr82LxtqfFfW2zwUhgKKBfTLh088s= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f377debc52_41973f92dcc4af282753f8"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:16:00 -0000 ----==_mimepart_59f377debc52_41973f92dcc4af282753f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit igrigorik commented on this pull request. > -The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption. +Implementers should be be aware of the passive fingerprinting and network information disclosure implications when implementing support for Client Hints, and follow the considerations outlined in "Security Considerations" section of this document. Ack. Good catch. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#discussion_r147481229 ----==_mimepart_59f377debc52_41973f92dcc4af282753f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik commented on this pull request.

In draft-ietf-httpbis-client-hints.md:

>  
-The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for efficient content adaption.
+Implementers should be be aware of the passive fingerprinting and network information disclosure implications when implementing support for Client Hints, and follow the considerations outlined in "Security Considerations" section of this document.

Ack. Good catch.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59f377debc52_41973f92dcc4af282753f8-- From nobody Fri Oct 27 11:23:00 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 27 Oct 2017 11:22:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1509128576; bh=ic58w6fqKZlBXaop08H7PPhM9N4y2O7SNo/vgfnf7u0=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vzlAdhD9InVAaxL2FB3WCkZ3KN4v6kmVX9eYdhTkNkKHocjvhgduCn3d3mH8fQobx IJdHd92PWdRSnDHyq4KYtVqQBO9GKHajQYWRaPF6Y3+bcjFARwhA7NQj4SJEwJE3rY DoY5pShBSJOvD9cIMFl/Z28eEnc1idvHAFWeEX2Y= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f3798031989_78dc3fc9a40fcf28628933"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:22:58 -0000 ----==_mimepart_59f3798031989_78dc3fc9a40fcf28628933 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > the opt-ins are limited to secure transport, but the actual hints are n= ot. Is that correct? If so, should we change it? I don't think that's necessary. This is implicit due to requirement for o= pt-in over secure transport =E2=80=94 i.e. only secure origins can opt-in= to receive hints and HTTPS-only is the new default policy for all hints.= -- = You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#issuecomment-340047817= ----==_mimepart_59f3798031989_78dc3fc9a40fcf28628933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

the opt-ins are limited to secure transport, but the actual hints are = not. Is that correct? If so, should we change it?

I don't think that's necessary. This is implicit due to requirement fo= r opt-in over secure transport =E2=80=94 i.e. only secure origins can opt= -in to receive hints and HTTPS-only is the new default policy for all hin= ts.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub= , or mute the thread.

= ----==_mimepart_59f3798031989_78dc3fc9a40fcf28628933-- From nobody Fri Oct 27 11:27:56 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 27 Oct 2017 11:27:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1509128868; bh=msZnNqmHxuPiSaffTJy4BGk0xLWqjI5dMucidNPZnow=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=cluj5rZTDewMxyI59EeK3Eb/oBijUZ3Um+PswXpSPfTHIHRcLMFUkPH/CMm06hgCv UeXEyfYukfrwZRI59ux3rwURFuD6GpyLqei7oKv3XLUZvu0wvuxMqG8emeu7axAryz jVyVgp/I7sO6tbcVhamtlfkeiC+CuPYzi2pgFI4Y= To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f37aa4c02de_7b633fbe4cb7af306498"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:27:55 -0000 ----==_mimepart_59f37aa4c02de_7b633fbe4cb7af306498 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @igrigorik pushed 1 commit. 79e372c fix typo -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/373/files/b4ef4d00fe450fc09332332f25fb014bfa1fda7f..79e372cdde49f724f22091f08d7a7100c4b838dd ----==_mimepart_59f37aa4c02de_7b633fbe4cb7af306498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik pushed 1 commit.

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59f37aa4c02de_7b633fbe4cb7af306498-- From nobody Fri Oct 27 11:31:32 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=nwV/zZfIJYHCLKzvp6uYtnFHNfo=; b=F5P2hJVKWgcjMdpu 8tYUvNvpACX4tR58eGww2wxEis33yT1V6574H8RiP6Tq1fGglXYggrtDWKWnkWul 3bej3AEdSYAltdYrclI2QSRpWBQ3RuoUndOehNbd89NfS1qs+9vZAkiOI4bug98b xsyh4JiIZKtmmddQEefwyGYj348= Date: Fri, 27 Oct 2017 18:31:28 +0000 (UTC) To: httpwg/http-extensions Cc: Push In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f37b7fc9264_7b363fbe4cb7af309462e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:31:30 -0000 ----==_mimepart_59f37b7fc9264_7b363fbe4cb7af309462e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @igrigorik pushed 1 commit. 0caa654 update 05 changelog -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/httpwg/http-extensions/pull/373/files/79e372cdde49f724f22091f08d7a7100c4b838dd..0caa65480bc3011b5c44f46ebd0b60223d72f22a ----==_mimepart_59f37b7fc9264_7b363fbe4cb7af309462e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@igrigorik pushed 1 commit.

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_59f37b7fc9264_7b363fbe4cb7af309462e-- From nobody Fri Oct 27 11:47:54 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=/DYoBNukRSquvvHvyialfhpZkfc=; b=j61bU3xfu+Lbc6e/ KjMbqG/QNfSMxWqxYnFISUCCJambaTRistjFhFntUYzDA/Q9L60HKhztaqG8rq1s +6KLEp1bF6Nz5FjU9aLKR6EhtsJn7uAvazdHVLb+qYKUUsXng9LEgPlINUIYZVtD t66XgKhh3JL1oo9y8EDERXgk3RY= Date: Fri, 27 Oct 2017 18:47:51 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f37f55b3654_3e693f96588aef342647b5"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:47:53 -0000 ----==_mimepart_59f37f55b3654_3e693f96588aef342647b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #373. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#event-1314489843 ----==_mimepart_59f37f55b3654_3e693f96588aef342647b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #373.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_59f37f55b3654_3e693f96588aef342647b5-- From nobody Fri Oct 27 11:50:19 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Date: Fri, 27 Oct 2017 11:50:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1509130212; bh=8hLOXFHiWmuwsa7eCymObzqXJ5503uGqRS1h9MxR0I4=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hIOJ0A0RYX5ZOuD5tLzTBNfFDdcEnpifo1Mw2d/sYvr4Xe1BYiGjVsb5NC2wn4gnp NQddKUaUkaK6X0iljszrdiKNLYqeBUudl6Oy+alcM71AlxZ67a4RD0Zh7KgykmI9N3 vCkZlzkuZdYmdOjac0XD+Z73fay8efsdoEfJP1Z4= To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f37fe4b8b98_5edd3ff9b8cccf30196024"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:50:17 -0000 ----==_mimepart_59f37fe4b8b98_5edd3ff9b8cccf30196024 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > @mnot I think it'd be good to see #373 in situ; from what I see in the patch, I think it's strictly better. No guarantees that there aren't other issues, or that this isn't completely covered, but personally I think it's better. - https://github.com/httpwg/http-extensions/issues/372#issuecomment-339513412 Squashed & merged. @martinthomson thanks for your help here and let me know if there is anything else I should address (in a separate PR :)). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/pull/373#issuecomment-340055219 ----==_mimepart_59f37fe4b8b98_5edd3ff9b8cccf30196024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@mnot I= think it'd be good to see #373 in situ; from what I see in the patch, I think i= t's strictly better. No guarantees that there aren't other issues, or tha= t this isn't completely covered, but personally I think it's better. - #372 (comment)

Squashed & merged. @martinthomson thanks for your help here and let= me know if there is anything else I should address (in a separate PR :))= .

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub= , or mute the thread.

= ----==_mimepart_59f37fe4b8b98_5edd3ff9b8cccf30196024-- From nobody Fri Oct 27 12:21:45 2017 Delivered-To: http-issues@ietfa.amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=FWOMfMMDNw/j8Zd0LDErlqDvEiA=; b=GNMrhmzalDf1zVqA ZTu8fvcw8BvcU02BA1Tdak2tfEFvusqaaJdpeFGGKGn+2KnDRS405lLuC9olEVTZ MH8GNyv3PNd+xiU2DnuWY2oR+izctfBQUO0W1nRdWXinUYtsP3HnlYAan1vI9ZkA h4MOavBJnHsOqP/EBCpfTycRxNg= Date: Fri, 27 Oct 2017 19:21:37 +0000 (UTC) To: httpwg/http-extensions Cc: Subscribed In-Reply-To: References: Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_59f38740d86ce_8433fd68f382f343712f9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list Archived-At: Message-ID: From: HTTP issue updates Reply-To: http-issues@ietf.org X-BeenThere: http-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: HTTP issue updates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 19:21:42 -0000 ----==_mimepart_59f38740d86ce_8433fd68f382f343712f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've landed #373. As a tl;dr on substantive changes:=20 - Accept-{CH,CH-Lifetime} opt-in is scoped to secure transports - Opt-in preference is bound to opt-in origin In effect, this update makes Client Hints HTTPS-only and opt-in preference = is double keyed against opt-in origin. We've also updated [security conside= rations section](http://httpwg.org/http-extensions/client-hints.html#securi= ty-considerations) to reflect these updates. --- The one remaining thread raised in this issue is around "hint delegation": = if origin A is loading a subresource from origin B, can A control if B is a= llowed to opt-in to receive hints? As it stands today, the answer is "yes",= and CH does not define a mechanism to control this. I do think this is a valid use case, but I don't think we should be solving= it within CH directly. Rather, we should be reusing client specific infras= tructure to address this.. e.g. in a context of a browser that's [Feature P= olicy](https://wicg.github.io/feature-policy/), which provides a mechanism = to selective enable/disable features and defines relevant delegation mechan= isms =E2=80=94 e.g. policy based, frame-level control, cascading logic, etc. So, my proposal here is: - @arturjanc I believe we addressed your original concerns via #373.=20 - We can resolve this thread - Publish new 05 draft with updates in #373 - Pursue delegation discussions in context of Feature Policy. @arturjanc @mnot does that sound reasonable? --=20 You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/httpwg/http-extensions/issues/372#issuecomment-340062604= ----==_mimepart_59f38740d86ce_8433fd68f382f343712f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I've landed #373= . As a tl;dr on substantive changes:

  • Accept-{CH,CH-Lifetime} opt-in is scoped to secure transports
  • Opt-in preference is bound to opt-in origin

In effect, this update makes Client Hints HTTPS-only and opt-in preferen= ce is double keyed against opt-in origin. We've also updated s= ecurity considerations section to reflect these updates.

The one remaining thread raised in this issue is around "hint delegation= ": if origin A is loading a subresource from origin B, can A control if B i= s allowed to opt-in to receive hints? As it stands today, the answer is "ye= s", and CH does not define a mechanism to control this.

I do think this is a valid use case, but I don't think we should be solv= ing it within CH directly. Rather, we should be reusing client specific inf= rastructure to address this.. e.g. in a context of a browser that's Feature Policy, which provi= des a mechanism to selective enable/disable features and defines relevant d= elegation mechanisms =E2=80=94 e.g. policy based, frame-level control, casc= ading logic, etc.

So, my proposal here is:

  • @arturj= anc I believe we addressed your original concerns via #373.
    • We can resolve this thread
    • Publish new 05 draft with updates in #373
  • Pursue delegation discussions in context of Feature Policy.

@arturja= nc @mnot= does that sound reasonable?

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or <= a href=3D"https://github.com/notifications/unsubscribe-auth/AORpyFYe9L6vM7w= cc227fzeDDnEki_hBks5swi1AgaJpZM4Oc7TI">mute the thread.3D""

= ----==_mimepart_59f38740d86ce_8433fd68f382f343712f9--