]>

Prahran Australia mnot@mnot.net https://www.mnot.net/

Internet-Draft This specification collects privacy-enhancing guidelines for Web feed readers. About This Document Status information for this document may be found at . information can be found at . Source for this draft and an issue tracker can be found at . Note to Readers This draft is a quick straw-man; it is intended to assess implementer and community interest in the topic, not to state concrete requirements (yet). Feedback much appreciated.

Introduction Many web sites offer a feed of updates to their content, using or . While they are consumed in a variety of ways and for a variety of purposes, web feeds are often presented to users by dedicated software, colloquially known as a "feed reader." Feed readers use HTML and HTTP, and can be considered as part of the web, but one that is distinct from web browsers. Unlike browsers, feed readers do not easily facilitiate cross-site tracking or behavioural advertising, because their capabilities are more limited, thereby establishing an alternative, more privacy-respecting web platform. At the same time, browsers are protecting privacy in increasingly sophisticated ways; for example, by taking steps to prevent active fingerprinting . This specification seeks to codify these privacy-enhancing distinctions while incorporating browser's privacy advances by offering a definition for "feed reader" in , providing guidelines for how they make requests in , and providing guidelines for their handling of content in .

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Feed Readers A feed reader acts as a user agent (per ) that consumes and presents information from documents in , , and/or similar formats to users. A feed reader might be local software program on a host that the user controls, or a remote service that they access over the Internet, such as through a web browser. Typically, a feed reader will allow the user to subscribe to URIs that identify feeds, and regularly poll those URIs for new content. When a feed entry has already been seen, a reader might keep this state. Feed readers make HTTP requests and parse, render and display HTML content (including some embedded content). Users can also follow links from content in a feed reader.

Making Feed Requests When a feed reader makes a request for a feed document, privacy can be impacted in several ways. This section contains guidelines for such requests; note that they do not apply to requests for embedded content and user-initiated navigation to links in content (see ).

Encryption In HTTP, encryption protects communication from observation and modification, and is used to establish the identity of the server. Feed readers, therefore, are expected to follow best current practice for encryption, as captured in the relevant RFCs and industry practice. This includes implementation of the most recent version of TLS (as of this writing, ), the Strict-Transport-Security mechanism , and Certificate Transparency checking .

Cookies The HTTP Cookie mechanism has aspects that are problematic for privacy; see, eg., . Therefore, when making feed requests feed readers MUST NOT send the Cookie header field, and when receiving feed responses, they MUST NOT process the Set-Cookie header field.

ETags HTTP ETags (see ) are especially useful to feed readers, as they enable more efficient transfers when there have been no changes to a feed. However, they can also be used to track user activity. Therefore, feed readers SHOULD periodically send requests without If-None-Match header fields, to asure that ETags are changed.

User-Agent Feed readers SHOULD NOT include more significant detail than an identifier for the software being used and its version. In particular, detail about libraries used and other aspects of the environment can contribute to the formation of an identifier for the user.

Client IP Address Feed readers SHOULD take steps to prevent servers hosting feeds from using the client's IP address to identify them or track their activity. For example, might be used to this end.

Handling Feed Content When a feed reader displays a feed content (including an individual feed entry) to its user, interaction with the feed's server is limited in several ways to reduce privacy impact. This section outlines those limits.

Requesting Remote Resources Feed readers MAY make requests for remote resources that are explicitly part of the feed or feed entry's metadata. For example, a feed reader might fetch the URL in the atom:logo element (defined in ) in order to present it to the user. Feed readers MAY make requests for remote resources that are embedded in feed content. However, the user MUST be able to control this behaviour.

Executing Scripts When handling feed content, feed readers MUST NOT execute embedded or linked scripts.

Reporting Feed readers MUST NOT trigger reporting mechanisms designed for Web browsers when handing feed content. For example, , .

Following Links When a user explicitly follows a link in a feed reader, their expectation will be that it either opens in their preferred Web browser, or that the resulting functionality is equivalent (e.g., a browser embedded in the feed reader). Once a link is followed, the feed reader is no longer handling feed content; the user's activity is now either in a separate Web browser, or in an embedded web browser that is considered a distinct context. Therefore, the context used to follow a link MUST be separate from that used to make requests for feed documents. In particular, separate underlying connections are to be used, and no state such as cookies is to be shared.

IANA Considerations This document has no actions for IANA.

Security Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Google LLC Mozilla Google LLC Apple, Inc This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK] Google LLC This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. RSS Advisory Board