I have to admit that some might take issue with the title - but the latest proposal to ban HTTP Cookies is from the development team of Blink, the layout engine at the core of Chrome. It may not come to anything, but it is another example of the browser makers attempting to set standards which suits them.

Browser makers have a lot of power because what their creations do sets the defacto standard for the web. Forget W3C or WhatWG, if a browser maker opts to put something in then its the standard - well it is if the browser has enough users. This is the problem. Once Firefox and Chrome were on a par, but now Chrome has the upper hand and by sheer weight of numbers it can set the standards by simply implementing things.

Put this power together with Google's ability to control web traffic by stating, or even just hinting at, what makes them downgrade a site. That's how they managed to strong-arm a lot of websites to adopt HTTPS and are trying to apply the same tactic to AMP, but not as hard and not with as much success. However, they could push harder.

The latest in this tendency has been triggered by a thread on the Blink developers group and has resulted in a GitHub "request for comment" that reads more like an intent irrespective of comment from Mike West whose Twitter page says:

"Making the web marginally less insecure, one deprecation at a time. I work on Chrome's security team, but my tweets are my own, etc, etc."

So this isn't just "some guy" with a bee in his bonnet.

The argument is Cookies-over-HTTP-Bad:

"Cookies sent over plaintext HTTP are visible to anyone on the network. This visibility exposes substantial amounts of data to network attackers (passive or active)"

It is clear that Chrome cannot single-handedly stop servers sending cookies over HTTP, but it can expire said cookies as soon as possible:

"When building the Cookie header for an outgoing request to a non-secure URL, let's first check each cookies' creation date. If that date is older than some arbitrary cutoff (let's start with twelve months), let's not add the cookie to the outgoing Cookie header. Instead, let's delete the cookie. Over time, that cutoff could be reduced to something suitably small (say, a few days)."

Which translates to: let's break the HTTP web, but let's do it slowly. After arguing this isn't going to make much difference, because cookies are fragile, the breakage is conceded:

"On the other hand, services that use long-lived non-secure cookies are likely to be unhappy, which is good. There are distinct risks to sending cookies over non-secure channels, especially when done at scale as part of an advertising network."

All of this sounds very reasonable, and you have to agree that if a cookie is to be sent then HTTPS is better, but ... and this is an important but, breaking the cookie mechanism on HTTP is another pressure to make sites move to HTTPS and not all sites need to. Recently it has been pointed out that HTTPS makes sites less accessible because of latency and the difficulties of caching encrypted web pages - see Securing web sites with HTTPS made them less accessible. In addition, HTTPS is more costly in terms of server load and not all pages need this level of security, cookies or no cookies.

It is true that the proposal is a very reasonable request for comments, and as such not an imposition of any decision, but the implication is that it might well be in the future. This is not the way the web should be run. Even if you agree with the idea of making cookies over HTTP fairly useless, you need to see the danger in allowing Google to even put forward such requests for comment.

Credit:Jonathunder

Who could deprecate a cookie!

More Information

Cookies-over-HTTP Bad

Intent to Deprecate: Nonsecurely delivered cookies.

Securing web sites with HTTPS made them less accessible

Related Articles

Today Chrome Marks HTTP As Not Secure

Intent To Deprecate HTTP

Google Launches Fast Web Page Technology AMP Early

When cookies leak data

Evercookie - the cookie you can't kill

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info