<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: A declaration of war on the HTTP of Shit</title>
	<atom:link href="http://thetarpit.org/2017/https-war-declaration/feed" rel="self" type="application/rss+xml" />
	<link>http://thetarpit.org/2017/https-war-declaration</link>
	<description>"Now I feel like I know less about what that blog is about than I did before."</description>
	<pubDate>Tue, 07 Apr 2026 13:25:39 +0000</pubDate>
	<generator>http://thetarpit.org</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: spyked</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-7028</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sat, 27 Dec 2025 11:14:06 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-7028</guid>
		<description>I'll grant you that: the whole thing is full of hyperbolae and it sounds all grandeuristic without providing any solid grounding on how to &lt;em&gt;solve&lt;/em&gt; the issue of clean WWWs. For what it's worth, &lt;a href="http://thetarpit.org/2019/cl-www-summary" rel="nofollow"&gt;I tried&lt;/a&gt; and &lt;a href="http://thetarpit.org/2020/adding-a-new-socket-option-to-sbcl-or-common-lisp-is-the-death-of-me" rel="nofollow"&gt;failed&lt;/a&gt;. Some probably still hold that that's utterly due to my incompetence; I don't know, you're free to form your own opinion. 

But since you brought this up, I must confess, I have one itching curiosity: does Chrome still support plain HTTP? I bet it does, doesn't it? In fact you've probably used it to comment on this blog. Which goes to show that for all of Google's yapping about "making the web more secure", &lt;em&gt;they've&lt;/em&gt; also failed.

From what I can tell, it pretty much went this way: first they told everyone that SSL is required as a catch-all for web content authentication -- and encryption, but that's besides the point. Then they (and Let's Encrypt or whatevs) lowered the bar to SSL certificates, so that everyone and their dog could avoid being labeled as "not secure", but at the cost of some terrible UX, employing warnings and whatnot, including for sites such as this one. Meanwhile, naturally, the bad guys also designed their sites using the same PKI mechanism. So then the PKI peddlers made a two-tier system, which would only show &lt;em&gt;some&lt;/em&gt; sites using the green padlock. So then the bad guys got really smart -- which no one could have predicted, amirite? 'cause y'know, researchers aren't paid to think, they're paid to research -- and they made sites that perfectly replicate the originals, using similar domain names to the originals.

So from what I've heard, since nowadays the average folks can no longer tell the originals from the scams, and to turn things into a true Kafkian nightmare, Google has employed... blacklisting. Which I bet uses all that AI sauce behind the scenes for classification, so when you're opening a new site, it will be blacklisted by default. True story bro, I'm really not talking from my ass.

So then tell me, what have Google succeeded in this period of almost eight years? They sure as hell haven't made the web safer; they haven't even managed (as I thought back in 2017) to co-opt the field, since here I am still using HTTP &lt;b&gt;1.1&lt;/b&gt; to deliver whatever version of HTML/CSS content which, as you said, just renders. The only thing that they're sorta managing, from what I can tell, is to make people flock towards LLMs, making that and a couple of other sites their only gateway to the internet.

I for one don't mind, so long as I stay as far away as possible from all this garbage.</description>
		<content:encoded><![CDATA[<p>I'll grant you that: the whole thing is full of hyperbolae and it sounds all grandeuristic without providing any solid grounding on how to <em>solve</em> the issue of clean WWWs. For what it's worth, <a href="http://thetarpit.org/2019/cl-www-summary" rel="nofollow">I tried</a> and <a href="http://thetarpit.org/2020/adding-a-new-socket-option-to-sbcl-or-common-lisp-is-the-death-of-me" rel="nofollow">failed</a>. Some probably still hold that that's utterly due to my incompetence; I don't know, you're free to form your own opinion. </p>
<p>But since you brought this up, I must confess, I have one itching curiosity: does Chrome still support plain HTTP? I bet it does, doesn't it? In fact you've probably used it to comment on this blog. Which goes to show that for all of Google's yapping about "making the web more secure", <em>they've</em> also failed.</p>
<p>From what I can tell, it pretty much went this way: first they told everyone that SSL is required as a catch-all for web content authentication -- and encryption, but that's besides the point. Then they (and Let's Encrypt or whatevs) lowered the bar to SSL certificates, so that everyone and their dog could avoid being labeled as "not secure", but at the cost of some terrible UX, employing warnings and whatnot, including for sites such as this one. Meanwhile, naturally, the bad guys also designed their sites using the same PKI mechanism. So then the PKI peddlers made a two-tier system, which would only show <em>some</em> sites using the green padlock. So then the bad guys got really smart -- which no one could have predicted, amirite? 'cause y'know, researchers aren't paid to think, they're paid to research -- and they made sites that perfectly replicate the originals, using similar domain names to the originals.</p>
<p>So from what I've heard, since nowadays the average folks can no longer tell the originals from the scams, and to turn things into a true Kafkian nightmare, Google has employed... blacklisting. Which I bet uses all that AI sauce behind the scenes for classification, so when you're opening a new site, it will be blacklisted by default. True story bro, I'm really not talking from my ass.</p>
<p>So then tell me, what have Google succeeded in this period of almost eight years? They sure as hell haven't made the web safer; they haven't even managed (as I thought back in 2017) to co-opt the field, since here I am still using HTTP <b>1.1</b> to deliver whatever version of HTML/CSS content which, as you said, just renders. The only thing that they're sorta managing, from what I can tell, is to make people flock towards LLMs, making that and a couple of other sites their only gateway to the internet.</p>
<p>I for one don't mind, so long as I stay as far away as possible from all this garbage.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nonanme</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-7026</link>
		<dc:creator>Nonanme</dc:creator>
		<pubDate>Fri, 26 Dec 2025 13:49:58 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-7026</guid>
		<description>&#62; The Tar Pit will remove all support for Chrome: the HTML dialect will probably be limited to around version 4, the CSS decorations will go away and the so-called "web fonts" will have to hit the proverbial dirt as well.

Sounds stupid. Google Chrome does support HTML version 4 &#38; absence of CSS or downloadable fonts will not prevent Google Chrome from displaying HTML page.</description>
		<content:encoded><![CDATA[<p>&gt; The Tar Pit will remove all support for Chrome: the HTML dialect will probably be limited to around version 4, the CSS decorations will go away and the so-called "web fonts" will have to hit the proverbial dirt as well.</p>
<p>Sounds stupid. Google Chrome does support HTML version 4 &amp; absence of CSS or downloadable fonts will not prevent Google Chrome from displaying HTML page.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spyked</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-6878</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sun, 26 Oct 2025 12:28:30 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-6878</guid>
		<description>By the way, it seems that nowadays browsers try to enforce HTTPS on &lt;b&gt;http&lt;/b&gt; links. Sorry, folks, it's not me, it's them.

&lt;b&gt;LE&lt;/b&gt;: I tried some htaccess voodoo that should hopefully fix the issue. Until next time, I'm sure.</description>
		<content:encoded><![CDATA[<p>By the way, it seems that nowadays browsers try to enforce HTTPS on <b>http</b> links. Sorry, folks, it's not me, it's them.</p>
<p><b>LE</b>: I tried some htaccess voodoo that should hopefully fix the issue. Until next time, I'm sure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spyked</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-4492</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Sun, 03 Sep 2023 19:55:21 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-4492</guid>
		<description>Meanwhile, it looks like even the big actors on the web start seeing HTTPS for what it is: a tool for levelling the playing field in a way that now allows even scammers to get the green padlock. What it doesn't do however -- and one can only wonder why it took them so much to place this problem under scrutiny -- is defend the web server from malicious clients, such as, say, DDoSers and spammers. Pretty sure machines are going to outperform humans in solving captchas, if they haven't already.

So now everyone is sorta kinda filling the "tech space" with this discussion on &lt;a href="https://archive.ph/rnjU6" rel="nofollow"&gt;attestation&lt;/a&gt;, meaning, in short, that in order to access Google or Apple or some other big fish, your browser should no longer be yours. In other words, it should perform an incantation based on some inputs that are controlled by the vendor and which attest that said software comes from a "trusted source". In practice, this means that the browser will have to rely on some chain of trust originating in the hardware, much like DRM does for example.

On one hand: boss, didn't you have like, client-side certificates for that?

On the other hand: do you see how this is a shoddy reimplementation of the WoT, with Google and Apple as top nodes?

On yet another, third, alien hand: do you see how this creates a system of agreements between these corporations, a la "I'll suck yours if you suck mine", since now everyone is going to keep a whitelist of vendors they like, which will come from Inca itself. For example, good luck using a Huawei phone in the US if or when this is implemented.

I guess the bottom line is, let 'em have their HTTPS and their attestation and whatnot. We can do well without them wonders of modern technology, with our retrograde HTTP implementations from times now gone, and with our other various super sikrit tools.</description>
		<content:encoded><![CDATA[<p>Meanwhile, it looks like even the big actors on the web start seeing HTTPS for what it is: a tool for levelling the playing field in a way that now allows even scammers to get the green padlock. What it doesn't do however -- and one can only wonder why it took them so much to place this problem under scrutiny -- is defend the web server from malicious clients, such as, say, DDoSers and spammers. Pretty sure machines are going to outperform humans in solving captchas, if they haven't already.</p>
<p>So now everyone is sorta kinda filling the "tech space" with this discussion on <a href="https://archive.ph/rnjU6" rel="nofollow">attestation</a>, meaning, in short, that in order to access Google or Apple or some other big fish, your browser should no longer be yours. In other words, it should perform an incantation based on some inputs that are controlled by the vendor and which attest that said software comes from a "trusted source". In practice, this means that the browser will have to rely on some chain of trust originating in the hardware, much like DRM does for example.</p>
<p>On one hand: boss, didn't you have like, client-side certificates for that?</p>
<p>On the other hand: do you see how this is a shoddy reimplementation of the WoT, with Google and Apple as top nodes?</p>
<p>On yet another, third, alien hand: do you see how this creates a system of agreements between these corporations, a la "I'll suck yours if you suck mine", since now everyone is going to keep a whitelist of vendors they like, which will come from Inca itself. For example, good luck using a Huawei phone in the US if or when this is implemented.</p>
<p>I guess the bottom line is, let 'em have their HTTPS and their attestation and whatnot. We can do well without them wonders of modern technology, with our retrograde HTTP implementations from times now gone, and with our other various super sikrit tools.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: spyked</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-4465</link>
		<dc:creator>spyked</dc:creator>
		<pubDate>Thu, 17 Aug 2023 18:28:28 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-4465</guid>
		<description>Meanwhile, &lt;a href="https://blog.chromium.org/2023/08/towards-https-by-default.html" rel="nofollow"&gt;in other lulz&lt;/a&gt;...</description>
		<content:encoded><![CDATA[<p>Meanwhile, <a href="https://blog.chromium.org/2023/08/towards-https-by-default.html" rel="nofollow">in other lulz</a>...</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: On intellectual feudalism &#171; The Tar Pit</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-3003</link>
		<dc:creator>On intellectual feudalism &#171; The Tar Pit</dc:creator>
		<pubDate>Sun, 18 Sep 2022 16:16:51 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-3003</guid>
		<description>[...] them so far. I can't help but notice that the author doesn't even mention the wreckage wrought by HTTPS and I'm willing to bet that his web0 should also come with TLS and PKI preloaded, because that's [...]</description>
		<content:encoded><![CDATA[<p>[...] them so far. I can't help but notice that the author doesn't even mention the wreckage wrought by HTTPS and I'm willing to bet that his web0 should also come with TLS and PKI preloaded, because that's [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Work plan for M11 2019 &#171; The Tar Pit</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-418</link>
		<dc:creator>Work plan for M11 2019 &#171; The Tar Pit</dc:creator>
		<pubDate>Wed, 14 Oct 2020 06:43:24 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-418</guid>
		<description>[...] version and gotta choose the proper one, and because the remote end of this PIP thing requires HTTPS to work, and well, add one or two more items to this pile of bring-up work and I easily get close [...]</description>
		<content:encoded><![CDATA[<p>[...] version and gotta choose the proper one, and because the remote end of this PIP thing requires HTTPS to work, and well, add one or two more items to this pile of bring-up work and I easily get close [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Introducing Gales Linux, a cross-bootstrapped, do-it-yourself, fully-static, discriminatory distribution &#171; Fixpoint</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-178</link>
		<dc:creator>Introducing Gales Linux, a cross-bootstrapped, do-it-yourself, fully-static, discriminatory distribution &#171; Fixpoint</dc:creator>
		<pubDate>Fri, 29 Nov 2019 20:57:44 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-178</guid>
		<description>[...] despite a claimed focus on security, its package management tool was written in C and "secured" by HTTPS. Next I tried the experimental "Gentoo hardened musl" project, using its "stage3" binary as a base [...]</description>
		<content:encoded><![CDATA[<p>[...] despite a claimed focus on security, its package management tool was written in C and "secured" by HTTPS. Next I tried the experimental "Gentoo hardened musl" project, using its "stage3" binary as a base [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JWRD Computing: The why, how, what and way forward. &#171; Dorion Mode</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-168</link>
		<dc:creator>JWRD Computing: The why, how, what and way forward. &#171; Dorion Mode</dc:creator>
		<pubDate>Sat, 16 Nov 2019 03:52:45 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-168</guid>
		<description>[...] the Key Management front, the fast food model of weak passwords over insecure protocols falls away as operators come to understand secure key [...]</description>
		<content:encoded><![CDATA[<p>[...] the Key Management front, the fast food model of weak passwords over insecure protocols falls away as operators come to understand secure key [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: yrc, a Unix IRC client: genesis &#171; Fixpoint</title>
		<link>http://thetarpit.org/2017/https-war-declaration#comment-165</link>
		<dc:creator>yrc, a Unix IRC client: genesis &#171; Fixpoint</dc:creator>
		<pubDate>Thu, 14 Nov 2019 18:44:21 +0000</pubDate>
		<guid isPermaLink="false">http://wp.thetarpit.org/2017/https-war-declaration#comment-165</guid>
		<description>[...] things that it does NOT intend to support include Unicode and SSL. Notable missing features it ought to have, quoting the manual, [...]</description>
		<content:encoded><![CDATA[<p>[...] things that it does NOT intend to support include Unicode and SSL. Notable missing features it ought to have, quoting the manual, [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
