+1. I think this is a fantastic idea for improved web performance optimization.

Potential overlap with "noreferrer"?

I thought of adding this behavior to an existing rel value, but then the nomenclature would be a little misleading (since cookies and referrers are not related).

That said, the general idea of bundling this behavior with other ones triggered by the same attribute would be fine, so long as they're all things that a developer would want together, and not individually.

Maybe we should have something like "anonymous" (similar to AnonXMLHttpRequest) which kills credentials, Referer, and Origin.

Indeed.

It would be great if it could *replace* noreferrer, but that ship probably has sailed.

A rel="anonymous" would probably fit the bill perfectly (restricting cookies, HTTP auth, SSL certs, referrer, and origin). (Though according to this source, the origin header should only sent with script requests of the 3 types of requests I originally mentioned: https://wiki.mozilla.org/Security/Origin)

I'm in the CMS business, and I'm thinking here of all the content we generate (particularly image thumbnails for individual news stories, etc. which would not be appropriate to make into sprites). Our product typically drives pretty large web sites, and the ability to use this flag globally in page output would probably have a dramatic effect across the board. Removing credentials and extra headers from these requests is an improvement, and would become an asset for security as well.

I've definitely been in favor of this proposal, especially the suppressing of cookies.

I ran it by Billy Hoffman (http://zoompf.com) and he brought up a good point that we need to consider.

There are apparently some servers/applications that are intentionally configured to log out a user session if a request is received that has no cookies. Honestly, I'm not actually sure how that would work, because I'm not sure how the server knows which session to kill if there was no cookie to identify to the server who the request came from. But, nevertheless, apparently this is a reality out there.

So, the obvious point is, anyone who used such a functionality in their application (for whatever reason, intentional or not), they couldn't use this rel="anonymous" to suppress cookies, without logging out users.

On the surface, my reaction was to say that such strange setups would just be unable to use this rel feature.

But Billy pointed out that such things can be used in a DoS attack. For instance, evil.com can have an <img> tag on it that points to an image on bank.com, and uses rel="anonymous" to force the user to be logged out. Now, in my opinion, this type of DoS is rather benign, but I guess it's real nonetheless.

So, this is what I propose:

We restrict the behavior of rel=anonymous to only work (at least in terms of cookies) if the resource is on the same domain (exactly) as the page domain. It would be silently ignored for requests to resources on other domains.

This should be fine for CDN usage, because CDN's in general are not sending out cookies. Or, rather, the issue we're trying to solve is much more about all the global cookies that are set on a local domain (like analytics tracking cookies, etc) that are unnecessarily bogging down static resource requests. So, the far majority of those requests will be to the same page-domain, which would benefit from the rel=anonymous behavior being discussed.

Thoughts?

--Kyle

If that is a real problem that would be a problem with XMLHttpRequest as well. Could you raise that on public-webapps@w3.org?

I think the mitigation of XHR is that normal XHR only works same-domain, and even CORS requires the server to handle the pre-flight authorization before a real cross-domain request can come in, whereas <script>, <link>, <img> etc can all freely make cross-domain requests.

Nevertheless, I'll check out that list. Do I need to join that WG before I can post?

No need to join. And you are wrong as to how cross-origin XMLHttpRequest operates. It makes the request directly for simple GET requests. And this already works in Firefox/Safari/Chrome. And also works in Internet Explorer when using XDomainRequest. So I sort of think that vulnerability is already inherent to the platform.

I agree that the problem described is a real one: that images, scripts, and style sheets are often served from separate domains to avoid sending cookies and that doing so is hard in some cases such as that described in comment 0. However, rel="" can't fix this  since neither images nor scripts have a rel="" attribute. It would have to be something like a "nocookie" attribute or some such.

The usual solution is to just use an entirely separate domain (e.g. yimg.com).

Is this really common enough to warrant new syntax features in HTML?

(In reply to comment #11)
> I agree that the problem described is a real one: that images, scripts, and
> style sheets are often served from separate domains to avoid sending cookies
> and that doing so is hard in some cases such as that described in comment 0.
> However, rel="" can't fix this  since neither images nor scripts have a rel=""
> attribute. It would have to be something like a "nocookie" attribute or some
> such.
> ...

*If* we decided to add new attributes, we of course *could* add @rel to img and script.

I can't comment on how common usage of an attribute like this would be across the web in general, but I can briefly describe the effect I would anticipate from such a feature in the content management world, which is what prompted me to file this request.

I work on a large scale CMS in education. Looking at a typical client, there are images (most frequently thumbnails accompanying news stories, event listings, galleries, etc.) that appear often in list format on a large number of pages throughout any given site. It is not a situation where yimg would be desirable, as there are several reasons why our custom image manipulation/deployment tools are used by our clients on their local servers as opposed to remote hosting, and other reasons why these particular clients may not wish to use third party remote hosting to store their image media in general. Using Google Analytics alone, which is a distinct commonality, you're looking at a large chunk of cookie data being transmitted to the server per image request. (The same is true for script and link tags which the CMS embeds in templates.) These are high traffic sites, and the CMS often powers more than one site running on the same machine (I have one client that has chosen to drive six sites with the CMS on one server).

In other words: frequent usage of script, link, and especially image tags throughout a web site, multiplied by at least the large chunk of Google Analytics cookie data per unique request, multiplied by the volume of users of a high traffic site, multiplied by the number of sites on that server, translates to a lot of time spent receiving data from the end user, which as you know is much slower than sending data to them. Since it would be trivial to modify our codebase in order to apply a new attribute to content we generate, it would be an equally trivial process to cut bandwidth usage and server response time for users of our CMS, across the board. I would imagine adoption by Wordpress, etc. would result in a similar story, as well as sites which simply display a large quantity of resources. The benefit here is that it provides a painless option to reduce bandwidth usage and resource load latency when the alternatives (which have been noted here) are either impossible or incompatible, or simply inconvenient.

It's not clear to me that HTML is the right place for a solution for this. For instance, whatever solution we used you'd still want to be able to control whether images or fonts in a style sheet had cookies or not, you'd still want to be able to control what happened to resources imported by scripts (including those without underlying DOM nodes, like Worker and EventSource objects), and you'd want it to cover a whole raft of features even just within HTML, like <video src>, <source>, <object>, <iframe>, etc.

My recommendation at this stage would be to approach browser vendors and encourage them to experiment with different ideas for addressing this, so that we gain implementation experience.

I guess you're right that an HTML attribute would be too limiting in regards to controlling this functionality in all aspects of web browsing. But where would such an approach, with the larger scope you're describing, be implemented exactly?

I assume you're not talking about browser settings, since this is something a web developer would want to control on a case-by-case basis (since some requests require cookie transmission to maintain logins, for example.). I suppose you could send a header along with the main resource that instructs the browser how to behave in respect to different kinds of future subresource requests on the page, but that would get tricky if it was the sole source of instruction about so many different types of requests. Otherwise, I could imagine HTML being the right place for controlling this so long as there's an equivalent solution(s) that applied to the additional cases you mentioned (i.e. a request in the generic sense knows how to be anonymous, but the HTML attribute is just one of several ways to switch that flag on).

I'd be happy to approach some browser vendors, once I'm clearer on where the possibilities lie for implementing this, if not just an HTML attribute.

I agree that more thought would need to go into all the possible resource requests which would benefit from this type of functionality.

But it still seems like having `rel` as an attribute for all those different containers, with a value that said "suppress cookies", would be sufficient. If any of those containers don't yet support the `rel` attribute, it wouldn't seem too onerous to extend rel to those containers.

Even if we're discussing sub-requests (like a script loads more scripts), those requests are always done via dynamically creating one of the containers in question, in which case setting the `rel` property should suffice, right?

I think the only other concern would be if XHR requests should support a way to suppress in the same way, and I think that it should. I'm not sure `rel` for XHR would make much sense, but perhaps something like "sendCookies" or whatever.

I don't really know what a good solution would be, unfortunately. Maybe some sort of API or declarative solution where you can whitelist URL prefixes that don't get cookies and so on?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: none yet
Rationale: For administrative purposes I'm going to mark this one "LATER" until we have more implementation experience.

mass-moved component to LC1

This bug was cloned to create HTML WG bug 19028.

Have any browser vendors experimented with this in the past few years?

Anne, is this something in scope of the fetch spec?

I still don't think HTML is the right place to address this, but I don't know if we should address it at all.

Fetch will have flags to turn this behavior on or off. I think in the end we want to allow control over cookies and authentication to reduce request overhead for each request, but how exactly we go about that I don't really know yet.

 It's not clear to me that HTML is the right place for a solution for this. For instance, whatever solution we used you'd still want to be able to control whether images or fonts in a style sheet had cookies or not, you'd still want to be able to control what happened to resources imported by scripts (including those without underlying DOM nodes, like Worker and EventSource objects), and you'd want it to cover a whole raft of features even just within HTML, like <video src>, <source>, <object>, <iframe>, etc.

http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0096.html

W3C Bugzilla is closing down, and as such we're closing all feature request bugs against HTML as "WONTFIX", at least wontfix-in-this-bugtracker.

If you still think this feature is valuable, please feel free to open a new issue against https://github.com/whatwg/html/issues ; the community has gotten much more active and involved since the Bugzilla days, and you might get a more useful dialogue there. The webappssec group, or the whatwg/fetch issue tracker, are also a good venue, depending on how general you think the problem is.

I will say that this general idea of adding "fetch options" to various fetches has occurred in lots of forms over the years, nobody has quite figured out a solution. So I remain hopeful that a new discussion might make progress.