Repository: sbingler/hsts-tracking-prevention-spec
Pull request #1: Create the ID
Author: login: sbingler
Created: 2025-03-07T22:37:36Z | Merged: 2025-03-13T16:27:23Z

Create the Internet draft


Diff:
diff --git a/draft-bingler-hsts-tracking-prevention.md b/draft-bingler-hsts-tracking-prevention.md
new file mode 100644
index 0000000..57e7959
--- /dev/null
+++ b/draft-bingler-hsts-tracking-prevention.md
@@ -0,0 +1,241 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: independent  # also: "IETF", "editorial", "IAB", or "IRTF"
+date: {DATE}
+consensus: false
+v: 3
+area: sec
+keyword:
+ - HSTS
+ - tracking prevention
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6797:
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6797}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6797}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6797}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6797} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6797}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention could take one of a few forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6797
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+the user from setting HSTS data {Section 8.1.1 of RFC6797} should be changed
+as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+### Prevent Servers From Retrieving Tracking Data.
+
+To allow user agents the option of preventing hosts they believe are tracking
+the user from retrieving HSTS data {Section 8.3 of RFC6797} should be changed
+as follows:
+
+~~~
+   1.  Extract from the URI any substring described by the host
+       component of the authority component of the URI.
+
+   2.  If the substring is null, then there is no match with any Known
+       HSTS Host.
+~~~
+
+should be modified to include
+
+~~~
+   1.  Extract from the URI any substring described by the host
+       component of the authority component of the URI.
+
+   2.  If the UA has reason to believe this host intends to retrieve tracking
+       data then the UA MAY abort this algorithm.
+
+   2.  If the substring is null, then there is no match with any Known
+       HSTS Host.
+~~~
+
+### Make Correlating Data Between Sites Infeasible
+
+Making data correlation infeasible for tracking servers could be implemented a
+number of ways, but a straightforward design would be to keep the HSTS policies
+of different sites separated, so that even if tracker.example is embedded into
+both site.example and othersite.example it cannot easily track users between
+those sites. Doing this is frequently referred to as partitioning.
+
+This can be allowed by modifying the storage and indexing requirement of
+{Section 5.3 of RFC6797} to allow for partitioning of the HSTS policy Store.
+
+~~~
+   UAs store and index HSTS Policies based strictly upon the domain
+   names of the issuing HSTS Hosts.
+
+   This means that UAs will maintain the HSTS Policy of any given HSTS
+   Host separately from any HSTS Policies issued by any other HSTS Hosts
+   whose domain names are...
+~~~
+
+Should be modified to include
+
+~~~
+   UAs store and index HSTS Policies based strictly upon the domain
+   names of the issuing HSTS Hosts.
+   
+   Note: UAs MAY decide to partition their HSTS policies by other inputs such
+   as the top-level site the agent has been navigated to. In this case the UA
+   should store and index HSTS Policies within that partition based strictly 
+   upon the domain names of the issuing HSTS Hosts.
+
+   This means that UAs will maintain the HSTS Policy of any given HSTS
+   Host separately from any HSTS Policies issued by any other HSTS Hosts
+   whose domain names are...
+~~~
+
+{Section 8.2 of RFC6797} should receive a similar change
+
+~~~
+   A given domain name may match a Known HSTS Host's domain name in one
+   or both of two fashions: a congruent match, or a superdomain match.
+   Alternatively, there may be no match.
+
+   The steps below determine whether there are any matches, and if so,
+   of which fashion:
+~~~
+
+Should be modified to include
+
+~~~
+   A given domain name may match a Known HSTS Host's domain name in one
+   or both of two fashions: a congruent match, or a superdomain match.
+   Alternatively, there may be no match.
+   
+   Note: If the UA has decided to partition its HSTS Policies then the
+   following algorithm MUST be performed only on HSTS Policies within the
+   applicable partition.
+
+   The steps below determine whether there are any matches, and if so,
+   of which fashion:
+~~~
+
+# Security Considerations
+
+Depending on the tracking prevention technique employed the UA may risk
+reducing the security of HTTP requests. Many UAs however implement some form
+of mixed content blocking and upgrading along with automatic upgrades of
+navigations to https top-level sites. These behaviors help limit any potential
+security decreases.
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+
+--- back
+
+# Acknowledgments
+{:numbered="false"}
+
+TODO acknowledge.
+
diff --git a/draft-todo-yourname-protocol.md b/draft-todo-yourname-protocol.md
deleted file mode 100644
index fa51372..0000000
--- a/draft-todo-yourname-protocol.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-###
-# Internet-Draft Markdown Template
-#
-# Rename this file from draft-todo-yourname-protocol.md to get started.
-# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
-#
-# For initial setup, you only need to edit the first block of fields.
-# Only "title" needs to be changed; delete "abbrev" if your title is short.
-# Any other content can be edited, but be careful not to introduce errors.
-# Some fields will be set automatically during setup if they are unchanged.
-#
-# Don't include "-00" or "-latest" in the filename.
-# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
-# the tools to refer to the current version; see "docname" for example.
-#
-# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
-# You can replace the entire file if you prefer a different format.
-# Change the file extension to match the format (.xml for XML, etc...)
-#
-###
-title: "TODO - Your title"
-abbrev: "TODO - Abbreviation"
-category: info
-
-docname: draft-todo-yourname-protocol-latest
-submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
-number:
-date:
-consensus: true
-v: 3
-area: AREA
-workgroup: WG Working Group
-keyword:
- - next generation
- - unicorn
- - sparkling distributed ledger
-venue:
-  group: WG
-  type: Working Group
-  mail: WG@example.com
-  arch: https://example.com/WG
-  github: USER/REPO
-  latest: https://example.com/LATEST
-
-author:
- -
-    fullname: Your Name Here
-    organization: Your Organization Here
-    email: your.email@example.com
-
-normative:
-
-informative:
-
-
---- abstract
-
-TODO Abstract
-
-
---- middle
-
-# Introduction
-
-TODO Introduction
-
-
-# Conventions and Definitions
-
-{::boilerplate bcp14-tagged}
-
-
-# Security Considerations
-
-TODO Security
-
-
-# IANA Considerations
-
-This document has no IANA actions.
-
-
---- back
-
-# Acknowledgments
-{:numbered="false"}
-
-TODO acknowledge.


Reviews:
user: login: miketaylr
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-11T17:57:28Z
user: login: miketaylr
body: (will review the actual content in a bit)
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-11T18:34:39Z
user: login: Ladankhamnian
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-12T14:03:39Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T18:29:38Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T18:30:54Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T18:31:14Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T18:31:29Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T18:32:12Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:22:29Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:22:37Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:22:57Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:23:54Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:25:17Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:25:52Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:29:14Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-12T19:29:42Z
user: login: miketaylr
body: I'm just gonna rubber stamp this, because we can make incremental improvements as people file issues.
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-13T15:01:32Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-13T15:17:10Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-13T15:17:41Z
user: login: sbingler
state: COMMENTED
author_association: OWNER
submitted_at: 2025-03-13T16:25:21Z
user: login: Ladankhamnian
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-13T16:25:30Z
user: login: Ladankhamnian
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-13T16:26:42Z

Review comments:
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
path: draft-hsts-tracking-prevention.md
user: login: miketaylr
body: ```
*** bad section normative: "RFC6767"
/usr/lib/ruby/gems/3.3.0/gems/kramdown-rfc2629-1.7.24/lib/kramdown-rfc/command.rb:361:in `block in xml_from_sections': undefined method `each' for an instance of String (NoMethodError)
```

Looking at https://github.com/cabo/kramdown-rfc/blob/master/lib/kramdown-rfc/command.rb#L358-L361

Is this barfing because of the empty string for `informative`? Is it valid to just delete that key?
created_at: 2025-03-11T17:57:28Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
path: draft-hsts-tracking-prevention.md
user: login: miketaylr
body: Can we follow this format? Something like `draft-sbingler-hstt-tracking-preventing.md`.
created_at: 2025-03-11T18:13:51Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
path: draft-hsts-tracking-prevention.md
user: login: miketaylr
body: Let's add March 2025 (or whatever the right format is)
created_at: 2025-03-11T18:15:51Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
path: draft-hsts-tracking-prevention.md
user: login: miketaylr
body: What's this for?
created_at: 2025-03-11T18:20:52Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
path: draft-hsts-tracking-prevention.md
user: login: miketaylr
body: Can we put in the WG we hope that would adopt this?
created_at: 2025-03-11T18:22:07Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
path: draft-hsts-tracking-prevention.md
user: login: Ladankhamnian
body: nit: tracking/tracking the user
created_at: 2025-03-12T13:40:14Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
path: draft-hsts-tracking-prevention.md
user: login: Ladankhamnian
body: nit: from setting HSTS data {/from setting HSTS data, {
created_at: 2025-03-12T13:53:54Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+{Section 2.4.1.1 of RFC6767} step 4 may also need to be rewritten in a similar
+fashion.
+
+### Prevent Servers From Retrieving Tracking Data.
+
+To allow user agents the option of preventing hosts they believe are tracking
path: draft-hsts-tracking-prevention.md
user: login: Ladankhamnian
body: nit again: tracking/tracking the user
created_at: 2025-03-12T14:00:58Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: After a lot of digging I found this
https://www.rfc-editor.org/rfc/rfc7991.html#page-96

This is the "stream" that the document has been accepted into. After some reading I think this is better as "independent" for now.
created_at: 2025-03-12T18:29:38Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: I'm not sure which WG would be the best fit for this change atm, RFC6797 was originally part of the `websec` group which has concluded.
created_at: 2025-03-12T18:30:54Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: That seems reasonable, worth a shot.
created_at: 2025-03-12T18:31:14Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: sgtm
created_at: 2025-03-12T18:31:29Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: The template mentions that "some" fields will be set by the tooling. Unclear to me if this is one of them
created_at: 2025-03-12T18:32:12Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Seems reasonable, let's try it.
created_at: 2025-03-12T19:22:29Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: sgtm
created_at: 2025-03-12T19:22:37Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Looks like there is a {Date} variable
created_at: 2025-03-12T19:22:57Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Eventually found https://www.rfc-editor.org/rfc/rfc7991.html#appendix-A.2 which describes this as the "stream" that the document belongs to.

It seems like independent is the best choice atm.
created_at: 2025-03-12T19:23:53Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: I'm not sure ATM which WG would be the best option for this. RFC6797 was originally in the websec WG but that has since concluded.

Removed this section for now.
created_at: 2025-03-12T19:25:17Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Done.
created_at: 2025-03-12T19:25:51Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: What do you mean?
created_at: 2025-03-12T19:29:14Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+{Section 2.4.1.1 of RFC6767} step 4 may also need to be rewritten in a similar
+fashion.
+
+### Prevent Servers From Retrieving Tracking Data.
+
+To allow user agents the option of preventing hosts they believe are tracking
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Done.
created_at: 2025-03-12T19:29:42Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,245 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: independent  # also: "IETF", "editorial", "IAB", or "IRTF"
+date: {DATE}
+consensus: false
+v: 3
+area: sec
+keyword:
+ - HSTS
+ - tracking prevention
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6797:
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6797}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6797}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6797}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6797} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6797}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6797
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+the user from setting HSTS data {Section 8.1.1 of RFC6797} should be changed
+as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+{Section 2.4.1.1 of RFC6797} step 4 may also need to be rewritten in a similar
path: draft-bingler-hsts-tracking-prevention.md
user: login: miketaylr
body: Not having read it, why is this only a may? Can we just add the monkey patch here to be explicit?
created_at: 2025-03-13T15:00:40Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,245 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: independent  # also: "IETF", "editorial", "IAB", or "IRTF"
+date: {DATE}
+consensus: false
+v: 3
+area: sec
+keyword:
+ - HSTS
+ - tracking prevention
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6797:
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6797}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6797}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6797}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6797} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6797}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6797
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+the user from setting HSTS data {Section 8.1.1 of RFC6797} should be changed
+as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+{Section 2.4.1.1 of RFC6797} step 4 may also need to be rewritten in a similar
path: draft-bingler-hsts-tracking-prevention.md
user: login: sbingler
body: It's because that section, `Detailed Core Requirements`, is setting high level requirements but it's not clear to me if this are meant to be normative `MUST` requirements, or more intended as a "this is what we intend to discuss in the later sections.
created_at: 2025-03-13T15:17:10Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,245 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: independent  # also: "IETF", "editorial", "IAB", or "IRTF"
+date: {DATE}
+consensus: false
+v: 3
+area: sec
+keyword:
+ - HSTS
+ - tracking prevention
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6797:
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6797}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6797}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6797}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6797} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6797}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6797
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+the user from setting HSTS data {Section 8.1.1 of RFC6797} should be changed
+as follows:
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+should be modified to include
+
+~~~
+   If the substring matching the host production from the Request-URI
+   (of the message to which the host responded) syntactically matches
+   the IP-literal or IPv4address productions from Section 3.2.2 of
+   [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
+
+   If the UA has reason to believe this host intends to set tracking
+   data then the UA MAY not note this host as a Known HSTS Host.
+
+   Otherwise, if the substring...
+~~~
+
+{Section 2.4.1.1 of RFC6797} step 4 may also need to be rewritten in a similar
path: draft-bingler-hsts-tracking-prevention.md
user: login: sbingler
body: I think I'm just going to remove that sentence. It's really just me musing outloud rather than anything instructive.
created_at: 2025-03-13T15:17:41Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
path: draft-hsts-tracking-prevention.md
user: login: sbingler
body: Closing, I think the sentence is more clear without the added comma.
created_at: 2025-03-13T16:25:20Z
author_association: OWNER
diff_hunk: @@ -0,0 +1,256 @@
+---
+###
+# Internet-Draft Markdown Template
+#
+# Rename this file from draft-todo-yourname-protocol.md to get started.
+# Draft name format is "draft-<yourname>-<workgroup>-<name>.md".
+#
+# For initial setup, you only need to edit the first block of fields.
+# Only "title" needs to be changed; delete "abbrev" if your title is short.
+# Any other content can be edited, but be careful not to introduce errors.
+# Some fields will be set automatically during setup if they are unchanged.
+#
+# Don't include "-00" or "-latest" in the filename.
+# Labels in the form draft-<yourname>-<workgroup>-<name>-latest are used by
+# the tools to refer to the current version; see "docname" for example.
+#
+# This template uses kramdown-rfc: https://github.com/cabo/kramdown-rfc
+# You can replace the entire file if you prefer a different format.
+# Change the file extension to match the format (.xml for XML, etc...)
+#
+###
+title: "HSTS Tracking Prevention"
+category: info
+
+docname: draft-hsts-tracking-prevention-latest
+submissiontype: IETF  # also: "independent", "editorial", "IAB", or "IRTF"
+number:
+date:
+consensus: true
+v: 3
+area: AREA
+workgroup: WG Working Group
+keyword:
+ - HSTS
+ - tracking prevention
+venue:
+  group: WG
+  type: Working Group
+  mail: WG@example.com
+  arch: https://example.com/WG
+  github: USER/REPO
+  latest: https://example.com/LATEST
+
+author:
+ -
+    fullname: Steven Bingler
+    organization: Google
+    email: bingler@google.com
+
+normative:
+  RFC6767
+
+informative:
+
+
+--- abstract
+
+As mentioned in {Section 14.9 of RFC6767}, it's possible for entities in
+control of multiple hosts to encode arbitrary data within a user agent's HSTS 
+policy store. This data can later be retrieved and could be used to identify
+users.
+
+This document proposes a change to the user agent processing model of {RFC6767}
+to enable user agents to employ tracking mitigation methods.
+
+
+--- middle
+
+# Introduction
+
+HTTP Strict Transport Security (HSTS), {RFC6767}, improves security for users
+by allowing a host to tell the user agent that it should only ever be accessed
+over a secure connection.
+
+However, the design of HSTS allows for servers to abuse its state caching in
+order to set and retrieve arbitrary data, potentially for the purposes of
+tracking a user around the web. {Section 14.9 of RFC6767} warns of this
+possibility but does not discuss prevention.
+
+This document offers some minor modifications to {Section 8 of RFC6767}
+that allows for user agents to implement a way to prevent tracking of the user.
+
+It also touches on potential implementations and their downsides.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# HSTS Tracking Prevention
+
+Tracking prevention can take a couple of forms:
+
+* Prevent servers from setting tracking data.
+
+* Prevent servers from retrieving tracking data.
+
+* Make correlating data between sites infeasible.
+
+The first could be implemented by ignoring Strict-Transport-Security response
+headers from tracking hosts. This requires user agents to ignore otherwise
+valid Strict-Transport-Security response headers if the user agent has reason
+to believe that header would be used for tracking purposes.
+
+The second could be implemented by not upgrading URI for tracking hosts.
+This requires user agents to not upgrade otherwise eligible URIs to
+"https" if the user agent has reason to believe the upgraded URI would be used
+for tracking purposes.
+
+The third could be implemented by partitioning the HSTS policy store by the
+current site the user is on. This would force any server interested in tracking
+a user to set new data on every site, making it infeasible to correlate the
+user’s visits between sites via HSTS upgrades.
+
+## Monkey-Patches against RFC6767
+
+### Prevent Servers From Saving Tracking Data
+
+To allow user agents the option of preventing hosts they believe are tracking
+from setting HSTS data {Section 8.1.1 of RFC6767} should be changed as follows:
path: draft-hsts-tracking-prevention.md
user: login: Ladankhamnian
body: Resolved offline. Ignore this comment please.
created_at: 2025-03-13T16:25:30Z
author_association: COLLABORATOR

PR comments:
user: login: sbingler
created_at: 2025-03-11T16:24:42Z
body: @miketaylr Interesed in your thoughts
author_association: OWNER
user: login: sbingler
created_at: 2025-03-11T16:25:41Z
body: I'm not 100% sure but I believe these check failures should resolve themselves once the new file is submitted for the first time
author_association: OWNER