<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Machines on tsvinc</title>
		<link>https://tsvinc.dev/tags/machines/</link>
		<description>Recent content in Machines on tsvinc</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Fri, 14 Feb 2025 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://tsvinc.dev/tags/machines/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>HTC Desire Z browsers: what still loads HTTPS on Android 2.3</title>
				<link>https://tsvinc.dev/posts/gingerbread-browsers/</link>
				<pubDate>Fri, 14 Feb 2025 00:00:00 +0000</pubDate>
				<guid>https://tsvinc.dev/posts/gingerbread-browsers/</guid>
				<description>&lt;p&gt;This was going to be a browser review. The research gave me five candidates for Android 2.3 and a column for how each one does HTTPS. One of the five ever ran on the phone, not in the version at the top of the list, and the most thorough part of the exercise turned out to be reading release notes. I have reviewed worse things more favourably.&lt;/p&gt;&#xA;&lt;p&gt;The phone is an HTC Desire Z, a 2010 slider with a hardware keyboard, running CyanogenMod 7, which is Android 2.3 with an older web stack than any site I visit expects. The question for this part is narrow: which browsers on that phone can still open a modern HTTPS site, and why those and not the others. The answer has nothing to do with rendering. It is decided by where the TLS handshake happens.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
