The Talos Principle was released in December 2014 and attempted to answer the AI alignment question at a time where the existence of AI alignment as a field was a foreign concept to the vast majority of the population, including technologists. It was ahead of its time.

Nearly a decade later, in November 2023, The Talos Principle 2 was released, and Croteam pulled it off again.

This post contains heavy spoilers about both The Talos Principle and The Talos Principle 2. However, in the author's opinion, both of these games are highly enjoyable even if you go in knowing their plot full well; the value of the experience lies in puzzle-solving, exploration, and unironically contemplating the different life philosophies both games present you with.

This is an image-heavy post.

I love Zachtronics. One of their games is Infinifactory (Trailer), a 3D puzzle game where you assemble blocks to form a certain product.

One of the later levels of the game is called "The Big Blowout" (Resistance Campaign → The Heist → The Big Blowout) in which you assemble a bomb-like device that looks like a hollow cube. It's quite difficult to assemble.

I had stopped playing the game a while ago, but someone in my Steam friend list recently asked to see my solution for this puzzle, so I recorded some GIFs using the game's built-in GIF recording feature. This made me re-discover the solution and I thought it was pretty cool so I'm posting it as a blog post.

Solution stats: 327 cycles, 309 footprint, 386 blocks. This is not the best. Here's someone smarter than me doing it in 276 cycles.

Mozilla has recently announced that Firefox will block mixed "active" content by default in Firefox 23, after Chromium and even Internet Explorer implemented similar measures. "Mixed content" refers to content being served over HTTP (i.e. plaintext) from within an HTTPS (i.e. HTTP-over-TLS) webpage. "Active" content refers to content which can modify the DOM of a webpage, i.e. any resource which, once loaded, modifies the way the page it is included in is rendered. Blocking mixed content is an attempt to solve multiple problems:

• Web developers implementing HTTPS incorrectly or half-assedly.
• Avoiding non-HTTPS-only cookies, referer headers, user-agent, and other sensitive data from leaking more than they need to.
• Encouraging HTTPS to be more widespread – certainly a good thing despite HTTPS's shortcomings.

The purpose of this post is to explain why browsers are moving in this direction, why it is a good thing, and why HTTPS Everywhere goes further in that direction.

With the recent announcement that Ubuntu would be switching to Canonical's new Mir display server, Ubuntu is increasingly distancing itself from other Linux distributions on various levels. In order to approach the subject, we first need to define what a Linux distribution really is.

Most people agree that Android is not a Linux distribution. Sure, it may run the Linux kernel, but that is only secondary to the overall Android system. Most of its applications run in a Java virtual machine, and the system does a lot of things differently than most Linux distributions do (e.g. its graphics stack, input management, power management, software management, etc.). Most of these subsystems have drifted far apart from most Linux distributions, as a result of Android being targeted at mobile devices (low-power, touch-centric, etc). There is nothing inherently wrong with this approach, but it means that said subsystems cannot easily be incorporated back into regular Linux distributions, for various reasons. Some systems may not make sense in a non-Android environment (e.g. the Google Play Store), some of them make assumptions that a general-purpose distribution cannot ("there will be a touch screen"), some of them depend on other Android-specific code, etc. However, those systems can be used (and are being used) in Android distributions such as CyanogenMod or ParanoidAndroid.

Therefore, divergence of core software creates a new ecosystem, rather than contributing to the one it originated from. This distinction is important in order to give credence to the following definition of "Linux distribution":

*A Linux distribution is an operating system along with a set of software contributions which benefit the overall Linux software ecosystem.

By this definition, does Ubuntu still qualify as a Linux distribution? Let's find out.

MAC addresses are a unique identifier associated to every network interface, wired or wireless. They are used to identify devices on a physical network.

Usually, a network interface comes with a fixed MAC address called the burned-in address. This address cannot be changed, as it is stored in the interface's hardware itself. Because of their fixed nature, they make it pretty easy to use for tracking purposes. This has some some pretty useful applications, such as being used as the matching criterion for a DHCP server to give a static IP address to a given device, or in order to target a "dormant" interface as required for Wake-on-LAN.

MAC spoofing is the technique to effectively change the MAC address that your network interface appears to have. It doesn't change the burned-in address, it merely changes what other devices think your interface's MAC address is. It can be used for some legitimate and not-always-legitimate purposes:

• Appearing as a legitimate device on a network which employs MAC address whitelisting (useful when your last network interface dies, and for certain types of network attacks)
• Avoiding tracking: Different MAC addresses means no device on the network can tell if it has already seen this device on this network before, or on another network. For example, Starbucks may wish to maintain a list of all MAC addresses accessing their WiFi access points and use this information to figure out someone's movements or simply to identify who their best customer is (or at least which one is that guy always hogging all the bandwidth). Think they would never do that? Think again.
• Appearing as a different device to a network you've previously been on. (Hey, remember those "time-limited" free WiFi access points at the airport?)
• Avoiding profiling: The first three bytes of the MAC address identify the manufacturer of the device. Thus, the burned-in address gives away which company made the chip. Sometimes that's not important, but perhaps a hardware exploit exists in all network interfaces manufactured by $MANUFACTURER, thus changing your MAC address gives you a bit of security by obscurity. Or, more mundanely, perhaps you don't want a thief to be able to see that you have a shiny, new, and very expensive iThingy at your house simply by standing outside and looking all the MAC addresses broadcasted by all your WiFi devices.
• Bypassing futile roadblocks, and unjustly getting prosecuted to death over it.
• Wireless access points use MAC spoofing in order to provide multiple wireless networks with a single wireless interface. Recent routers often have this "guest network" feature which, when turned on, makes your router show up twice in the list of available access points: The regular network, and the guest network. This is a good thing, as it gives you some network-level isolation between machines. This way, even if your guests don't practice healthy security practices on their computing devices, at least they won't spread any nasty stuff through your LAN.

Interestingly, while MAC addresses have thus far been limited in terms of tracking potential due to being confined to one's local network, this is about to change with IPv6. One of IPv6's addressing models, stateless address autoconfiguration, allows a device to acquire an address for itself by taking the 64-bit prefix of the network it is on, and using the 48-bit MAC address of its network interface to determine the value of the remaining 64 bits. The consequence of this scheme is that any website you connect to can figure out your MAC address from nothing but your IPv6 address. (More on that later.)

As you can see, there are many reasons as to one would want to spoof their MAC address. So how do we get in on the action?

First, some context: There have been quite a few complaints and concerns about Ubuntu's attempt to include advertisements in their operating system, in the form of Amazon-affiliate-tracked results showing up in Unity's Dash interface by default. There has also been some attempts to do some damage control over this PR disaster, including one by Mark Shuttleworth himself, Ubuntu's Self-Appointed Benevolent Dictator For Life (SABDFL).

To his credit, he isn't pulling any punches or dancing around the question:

Why are you telling Amazon what I am searching for?

We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf. Don't trust us? Erm, we have root. You do trust us with your data already. You trust us not to screw up on your machine with every update. You trust Debian, and you trust a large swathe of the open source community. And most importantly, you trust us to address it when, being human, we err.

One of the statements here is pretty ominous at first: "Don't trust us? Erm, we have root." Mark refers to the fact that system updates are all done as root, and they can indeed slip in any code they want in there, which could include a remote-administration trojan or a little script uploading all of $HOME to Canonical's servers... But doing so would go directly against their users and instantly ruin their reputation. It is expectable from users to trust their operating system vendor will not snoop on them. The argument, while technically correct, doesn't hold much water when considering user expectations and Canonical's own business interests.

However, I'd like to challenge one particular passage (emphasis mine):

We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf.

There's a number of issues here.

One of the issues with SSH is the lack of public-key infrastructure. This causes two kinds of potential problems.

Fingerprint verification problem

Fingerprint verification is the technique SSH uses to check if it is connecting to the correct server, to ensure that the connection being not tampered with and not wiretappable.

In practice, this means that when you connect to a new SSH server, you're usually presented with something like this:

$ ssh perot.me
The authenticity of host 'perot.me (2600:3c03::f03c:91ff:fe93:5318)' can't be established.
ECDSA key fingerprint is 87:e2:c8:25:25:ee:a8:a6:ad:c9:2a:a5:2c:ae:8a:cf.
Are you sure you want to continue connecting (yes/no)?

That bunch of random characters called the "fingerprint" is what SSH relies on to correctly authenticate to the server in the future. When you say "yes" to this prompt, SSH will save this fingerprint and the associated hostname in your ~/.ssh/known_hosts so that in the future, SSH can check if the hostname still has the same fingerprint. If it does, then you're pretty safe. If it's not, here's what happens:

$ ssh perot.me
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
6c:78:41:0d:48:29:6c:ec:53:0f:66:04:02:53:02:49.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:linenumber
ECDSA host key for localhost has changed and you have requested strict checking.
Host key verification failed.

This scary message tells you that either the connection is being man-in-the-middle'd, or the server has been rekeyed, which causes the fingerprint to change.

This model is informally called TOFU (Trust On First Use). It raises the following questions:

• How do you know for sure if the fingerprint is valid when you connect to a machine for the first time?
• When the fingerprint changes, how do you know if this happened because of a legit key change, or because the connection is being tampered with?

The SSH fingerprint model by itself does not solve these issues. To stay secure, you need to rely on a secure out-of-band channel to tell you the correct answer to both of these questions.

Client authentication problem

The second problem is related to authentication (logging in to a server). By now you probably know that in order to authenticate to an SSH server with a key, you need to copy the public part of your SSH key (~/.ssh/id_xxx.pub) to the host's authorized_keys file. Then, the private part of your SSH key (~/.ssh/id_xxx) allows you to prove to the server that you possess the private part of the key that the server trusts the public part of. The SSH server doesn't trust you, it trusts *whoever owns the private part* of that key. So what happens when your private key gets compromised, because you accidentally pasted it somewhere, or because your computer got exploited, or because you lost your laptop somewhere?

By then, you will probably have copied your public key in dozens or hundreds of accounts all around, and it can be quite painful to change every single one of them, let alone remember all the places where you've put it. And that's assuming the attacker didn't already break into your servers and deny you access from it.

This is not a big problem if you have one or two personal servers. It is a much bigger problem if you're managing a few dozens or hundreds of servers. The problem scales with the number of servers and accounts that you manage. However, the more servers you manage, the harder it becomes to change them or switch to a different solution. As such, it is better to take measures before the scope of the problem is prohibitively large.

The goal of the Monkeysphere project is to address all of the aforementioned issues. It is a system that extends PGP to other protocols such as SSH and HTTPS. The goal is to leverage PGP's Web of trust and use it for fingerprint-checking and authentication. This allows SSH fingerprint signing (to solve the fingerprint verification problem), and key signing/key revocation (to solve the authentication problem). The best part is that you don't need to get a patched version of OpenSSH or give up SSH-style key authentication to do it; Monkeysphere simply builds upon SSH, it doesn't remove any of its features.

Now that we've established why Monkeysphere is important, let's set it up.

After reliability, security is perhaps the second most important aspect of a mail server. I was looking for solutions to encrypt all incoming emails (that were not already encrypted) with my PGP key as soon as they arrive on my mail server. This way, even if an attacker gains access to the system, (s)he will not be able to read the contents of emails that are already stored on disk.