- From: Roman Danyliw via Datatracker <noreply@ietf.org>
- Date: Tue, 19 May 2020 11:52:22 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-client-hints@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, mnot@mnot.net
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-client-hints-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 4.1. Per “Therefore, features relying on this document to define Client Hint headers MUST NOT provide new information that is otherwise not available to the application via other means, such as existing request headers, HTML, CSS, or JavaScript”, would this text allow for a shift in permissiveness if the references specs changed? For example, if something was not permissible in Javascript/HTML/CSS “vX” today, but it was in “vX+1”, would that mean that additional data could be sent as hints? I’m exploring the value of assigning version numbers to HTML, CSS and Javascript to freeze the security assumptions. ** Section 4.1. Per “User agents need to consider the value provided by a particular feature vs these considerations, and MAY have different policies regarding that tradeoff on a per-feature basis”, IMO more is needed to handle these tradeoffs. User agent implementations SHOULD expose this policy creation process through a rich set of configuration/tuning options and with an API to enable privacy-minded, third party software to assist the user in making choices. ** Section 4.1. Per “Implementers SHOULD restrict delivery of some or all Client Hints header fields to the opt-in origin only, unless the opt-in origin has explicitly delegated permission to another origin to request Client Hints header fields”, how does this delegation happen?
Received on Tuesday, 19 May 2020 18:52:37 UTC