We've all gone mad (HTTP/2)

Back in the late 1980's I was learning about the TCP/IP stack. This is a wondeful peice of engineering made during a time of paranoia and fear of war and sabotage leading to the worlds most popular and renowned (indeed the only true) internet protocol.

Now, for those who are newe to the TCP/IP stack, heres a quick reminder what it means:

1. Application Layer - aka Browser (managed final presentation to user, e.g. understanding data)
2. Presentation Layer - aka TLS/SSL encrption and security layer 
3. Session Layer - aka OS / Conversational concerns (e.g. information grouping, abstraction allowing it to appear that a single conversation is happening per use) 
4. Transport Layer - aka OS / Error Recovery and Flow Control
5. Internet Layer - aka Network Card
6. Data Link Layer - aka Router Concerns
7. Physical Network Layer - aka Network Cabling and Infrastructure concenrs

The TCP/IP stack recognises there are different operational needs and concerns as the network traffic is translated between the User understood information into a form which is optimal for transmision over the involved hardware, by employing these abstractions it makes it possible for each sub-area (as listed) to work to its own particular concerns without involving the other layers (since each layer knows how to "speak" the the layer above and the layer below.

This wondefully simple idea is the core of good design. Each element can specialise as is best for its clients and as a server for the layers below and above.

Now, most people should be able to spot the implication here, but I feel I need to call it out explicity because it very much feels like people in general don't. The implication is, efficiency is ensured by each layer dealing with the complexities to which its best suited. Let me just list what those are:

1. Application Layer - Manipulation of server data to be best visualised and understood by the user
2. Presentation Layer - Encryption, Compression
3. Session Layer - Maintains the conversational abstraction (e.g your Data vs My Data)
   
4. Transport Layer - Efficiency Based Encoding, Reliability
5. Internet Layer - Conversion, Division, Reconstruction
6. Data Link Layer - Transmission, Integrety
7. Physical Network Layer - Hardware Specific Represntation and Receipt

As you can see, the Transport layer is best suited for dealing with Encryption and Compression. Though really each layer below the application layer may want or need to re-encode or compress its data to get the best performance based on intimate knowledge of the layer below.

The core take away here is that layers 2 to 5 are the best layers at which to acheive compression and encryption for the following reasons:

• The Application layer shouldn't need to be aware of anything except the concerns of the user and passing to the Transport layer what it needs to function. The application layer has become unnecessarily complex and companies are leveraging the complexity as a means of defence of profit and control.
• The Presentation layer, being a part of the operating system ideally, is very well placed to give a consistant behaviour across the board and can be simply standardised across all the internet. Recall that the application layer is should be most concerned with the user, and the user is least concerned with how, and most concerned with things being easily understood
• When the Application layer deals with Compression and Encryption what happens very quickly is incompatibility between internet devices. Since the availability or not of some service is dependent on the tools running on the device. In this case the browser. This position has been soundly abused by large corportations to great success for profit and exclusion (ensuring their "product" is the only one suitable to access some resource).
• The application layer reducing the data sent to the transport layer is of course largely desirable, but this should be done by the simple axiom of "what is the minimum I need to send to complete my goal" and not how can I, after not having considered the prior, reduce the size of what I have sent. When the Application layer (browser or other internet client) becomes complex it decreases the ability for people to engage with the application (in other words it leads to 'owners' and 'users' rather than people, or putting that another way, it leads to a class system).

What has effectively happened is large organisations have focused souly on their goals, which I will state for the record:

• Profitability
• Reduction of Costs
• Control of Media (DRM)
• Exclusion of others, removing the potential for competition (e.g. owning the money space)
• Reliable monitoring and tracking of potential paying customers

I state publicly and for the record this is against the interest of humanity in general and supports the worst kinds of patterns of behaviour and hampers advancement.

I opinion that HTTP/2 was designed largely to meet the above 4 aims It offers little or nothing not intended in HTTP/1.1. Though it does offer alot to aid the current abuse of cookies as a tracking mechanism. For the record, cookies should be a simple short peice of data to disambiguate one user from another and also, potentially as a mechanism for the short term reliable tracking of a understanably secure transaction (e.g. money movement). What cookies have sadly become is a catch all way to store information about end users, keep a good part of that storage on the end users machine and improve the profitability of advertising (e.g. we are advertising to these people, as proved by this cookie data).

So, that is the problem. I don't know what can be done about the problem because what is needed is proper governance and what has happened since my youth is government is the new profitable business! Meaning the government is often sharing the above aims sadly.

To make this more positive, I wish to point out that it's not too late. Innovation in the Transport and below spaces is perfectly possible and in a way which is both financially and ethically profitable. So this is a call to hardware manufacturers to up the game and make the encodings and encryption in the Application layer pointless and a bit of a thing of the past only existing for very specialised cases.

One closing thought, the transport layer needs to be fairly dumb, meaning it should "just work" to the perspective of the layer above. For this reason there may always need to be some encodings or encryptions occuring in the application layer, since another function of the application layer is to be "smart" in dealing with the layers below on behalf of the user. The types of understandable encryptions and compression on the application layer and things like photo compression and video compression, which can be done far better for understanding the nature of the medium than any generalised compression which the Transport and below layers may be able to acheive (in other words lossy compression is the bread and butter of the application layer). The problem with HTTP/2 is that it looks to compress the HTTP headers, these firstly are important in Application layer routing but secondly are readily compressable by the transport layer efficiently. Therefore reencoding and encrypting of them just harms the overall operation of the internet (excepting that the Application layer manages that).