What I got from this piece is that TBL's top priority is to not want to "break the web." His beef seems to be that, for a variety of reasons, "transmit this con

What I got from this piece is that TBL's top priority is to not want to "break the web." His beef seems to be that, for a variety of reasons, "transmit this content securely" was codified into part of the URL for a resource. So if someone made a hyperlink to http://www.example.com http://www.example.com, and as owner of the www.example.com website tomorrow you switched to HTTPS only to "secure" the contents of www.example.com, that all those old http:// http:// style hyperlinks will break. TBL talks about how, if security was implemented on top of HTTP, instead of being a separate protocol, then deciding "use security for this" would not break hyperlinks. This seems like a pedantic argument to make and it pushes the burden on users, who consistently make terrible choices regarding security. TBL's idea that content owners should not define that something must be accessed security, but that the users should seems to fly in the face of security best practices. Additionally, there are severe technical challenges in upgrading an insecure communications channel (http) to a secure one (https). Look at the problems with STARTTLS. You need some extra data or side channel or configuration so the client know when it should not keep using a channel, unless it is secure. Otherwise you are screwed. So you are back to the problem of how does an owner communicate to a client, in a hyperlink, to access something only with security. TBL also ignores that shifting to HTTPS does not necessarily "break the web". There are many mechanisms that can be used to the hyperlinks don't break, and redirect you where you need to go.