A Geek With Guns – Page 10 – Chronicling the depravities of the State.

Moving Up in the World

If anybody is still checking this feed, I want to let you know that I finally escaped the Twin Cities region. The misses and I bought a house on a few acres of land out in the country. While I wouldn’t necessarily advise buying a house at the moment (with the way things are going you’ll probably get some stellar deals in a few months if you’re willing to buy during a time of major economic uncertainty), the housing and land prices out in the country aren’t nearly as insane as they are in the metro area.

The only downside is that my Internet is much slower. Since this site is still hosting on a server in my home, the site’s performance will probably be terrible, but I’m not making any money off of this site so I don’t really care. With that said, that single trade-off is well worth all of the benefits (especially if shit keeps going downhill, I don’t really want to deal with civil unrest in a major metropolitan area).

Now that my biggest project is crossed off of the list, I hope to get back to writing more frequently.

Getting a Static IP Address with a Cheap VPS and WireGuard

I prefer to host my own infrastructure. This website site is on a server in my home as are my e-mail, Nextcloud, and Gitlab servers. I also encourage those interested to do the same. However, many Internet Service Providers (ISP) are reluctant to issue static IP address to residential customers and often block commonly used ports (especially port 25, which is needed if you want to self-host an e-mail server). While Dynamic Domain Name System (DDNS) mitigates the static IP address problem, it’s not perfect. Moreover, it won’t open ports that your ISP is blocking.

Fortunately, there’s another option. Many Virtual Private Server (VPS) providers happily issue static IP addresses for VPS instances. They also tend to be much less apt to block ports (although port 25 is commonly blocked and often requires submitting a support ticket and jumping through hoops to get unblocked). Wouldn’t it be convenient to use a VPS as a front end for your self-hosted network?

One of the things I played around with a lot recently is WireGuard. WireGuard is a new Virtual Private Network (VPN) technology that is both easy to setup and performant. In this guide I will explain how to use WireGuard to bridge your self-hosted network with a VPS (in my case I’m using this setup with one of my servers through a $5 per month DigitalOcean droplet) so that you can access your servers from the VPS’s static IP address.

This guide will not explain how to install WireGuard or the specifics of WireGuard since that information is better provided by WireGuard’s official website. What this guide will explain is how to create a WireGuard configuration file that can be used via the wg-quick command to forward traffic received via the VPS’s static IP address to individual servers on your self-hosted network.

As a quick aside, the reason I opted to use a configuration file and the wg-quick command instead of setting up a WireGuard interface and iptables on the Linux system directly is because one of my goals is portability. It’s a trivial matter to spin up a new VPS, install WireGuard, upload your configuration file, and run wg-quick. This way if you lose access to your VPS, you can get everything up and running again by spinning up a new VPS and updating your DNS records.

Once your VPS is up and running and WireGuard is installed, go to the /etc directory and, if it doesn’t already exist, create a wireguard directory. This is the directory where your configuration file will be store.

You will need a private and public key, which can both be generate via the wg command. First issue the umask 077 command. This will provide read and write access only to the user account creating the files (which is likely root). Now issue the wg genkey | tee privatekey | wg pubkey > publickey command. The first part of this command generates your private key and pipes it into the tee command, which outputs the key into a file named privatekey and pipes it into the wg pubkey command, which derives a public key from the private key and writes that public key to a file named publickey.

At this point you should have two files in /etc/wireguard, privatekey and publickey. Now it’s time to create your initial configuration file. Open your text editor of choice and save the file as wg0.conf (the file name doesn’t have to be wg0, but the extension has to be .conf). You’ll start by adding the following lines:

[Interface] Address = 172.16.1.1/16 SaveConfig = false ListenPort = 65000 PrivateKey =

[Interface] indicates that the lines that follow are related to the creation of a WireGuard interface.

Address indicates the IP address that will be assigned to the WireGuard interface. Note that you can assign multiple IP addresses to a WireGuard interface so if you also wanted to give it an IPv6 address you could add the line Address = fd00:cafe:dead:babe::1/64. If you’d rather have a single line containing all of the assigned IP addresses you can use a comma separated list such as Address = 172.16.1.1/16, fd00:cafe:dead:babe::1/64 (personally I find adding a single item per line more readable so I will stick to that convention for this guide). Also note that the subnet of the WireGuard interface’s IP address should differ from the one you use on your home network. In this example I’m using a 172.16.x.x address because 192.168.x.x and 10.x.x.x addresses are the ones I most commonly encounter on home and corporate networks.

SaveConfig = false will prevent WireGuard from automatically saving additional information to the wg0.conf file. I prefer this because otherwise WireGuard has a habit of generating a new fe80:: IPv6 address and saving it to wg0.conf every time the interface is brought up with the wg-quick command. Moreover, if SaveConfig is set to true any comments you add to the wg0.conf file will be erased when the wg-quick command is called (I tend to heavily comment my files so this is a big issue to me).

ListenPort indicates what port you want the WireGuard interface to be accessible on. The default listen port for WireGuard is 51820. However, I actually have my VPS’s WireGuard interface setup to foward traffic received on port 51820 to another WireGuard server on my home network so I’m using a non-default port in this example.

PrivateKey indicates the interface’s private key. Paste the private key stored in the privatekey file here (note that you have to enter the private key itself, not the path to the file containing the private key).

Now you need to configure WireGuard on one of your self-hosted servers. First, generate a private and public key pair on your self-hosted server the same way you generated them on your VPS instance. Then create wg0.conf and enter the following information:

[Interface] Address = 172.16.1.2/16 SaveConfig = false PrivateKey =

There are two changes to note. The first change is the IP address. The IP address of the WireGuard interface on your self-hosted server should be different (but in the same subnet) than the IP address of your VPS’s WireGuard interface. The second change should be obvious. You will enter the private key you generated on your self-hosted server.

Now both your VPS and your self-hosted servers should have WireGuard configuration files. The next step is to tell them about each other. This is done using the [Peer] directive in the configuration file. Let’s open the wg0.conf file on your VPS and add the [Peer] information for your self-hosted WireGuard interface. The file should look like this:

[Interface] Address = 172.16.1.1/16 SaveConfig = false ListenPort = 65000 PrivateKey =

[Peer] PublicKey = AllowedIPs = 172.16.1.2/32

PublicKey indicates the public key for your self-hosted server. This should be the key stored in the publickey file on your self-hosted server.

AllowedIPs serves two purposes. The first purpose is to inform the VPS what IP addresses can be used as source addresses when communicating with the peer. The line AllowedIPs = 172.16.1.2/32 indiates that the address 172.16.1.2 is the only source IP address allowed to encrypt traffic that can be decrypted with provided public key. The second purpose is to act as a routing table. Traffic destined for 172.16.1.2 will be encrypted with the provided public key so it can be decrypted by the WireGuard interface on your self-hosted server.

Depending on your goals, you may wish to use less strict values for AllowedIPs. However, I prefer to keep them strict when setting up a WireGuard connection to bridge between a VPS and my self-hosted network because I actually configure multiple peers and forward different traffic to different peers.

Now edit the wg0.conf file on your self-hosted WireGuard server so it looks like this:

[Interface] Address = 172.16.1.2/16 SaveConfig = false PrivateKey =

[Peer] PublicKey = AllowedIPs = 172.16.1.1/32 Endpoint = :65000 PersistentKeepalive = 25

The PublicKey directive should obviously have the public key generated on the VPS and AllowedIPs directives should have the IP address of the VPS’s WireGuard interface. However, there are two new entries.

Endpoint tells the WireGuard interface the IP address to which it should communicate. This should be set to the static IP address assigned to the VPS. Why wasn’t the Endpoint directive needed in the VPS’s configuration file? Because WireGuard has a neat feature, which enables roaming. When a WireGuard interface receives a packet, it notes the source address and uses that address when sending replies. This means that should the IP address of your self-hosted network change (which can happen periodically on networks not assigned a static IP address) the VPS WireGuard interface will note the new source address and use it as the new destination address.

PersistentKeepalive indicates how frequently the WireGuard interface should send keep alive messages to its peer. WireGuard is a pretty quiet protocol by default. It abstains from sending unnecessary traffic. While this makes for a more efficient protocol, it causes issues with peers behind a Network Address Translation (NAT) device. When a peer behind a NAT device connects to an external server, the NAT device keeps track of the connection. If no traffic is observed on the connection for a while, the connection is timed out and the NAT device forgets it. Setting PersistentKeepalive ensures traffic is periodically sent (once every 25 seconds in the case of the above configuration) across the connection and thus will not be forgotten by a NAT device middle man.

With these configurations in place, we can bring up both WireGuard connections. On the VPS issue the command systemctl start wg-quick@wg0 then issue the same command on your self-hosted server. From your VPS you should be able to ping 172.16.1.2 and from your self-hosted server you should be able to ping 172.16.1.1. If you can’t ping either peer, there’s likely an error in one of your configuration files or a firewall hindering the communications.

If both peers can ping each other, congratulations, you’ve successfully setup a WireGuard connection and are done with the self-hosted side of your configuration. There remains one last thing to do on your VPS though. At the moment traffic received on the VPS’s static IP address isn’t forwarded through the WireGuard interface and thus will never reach your self-hosted server.

To correct this, you first need to enable packet forwarding on your VPS. On most Linux distributions this is done by adding the lines net.ipv4.ip_forward=1 and, if you want the capability to forward IPv6 packets, net.ipv6.conf.all.forwarding=1 to the sysctl.conf file then issuing the sysctl --system command. Once packet forwarding is enabled, you can start adding packet forwarding capabilities to your WireGuard configuration file.

wg-quick recognizes a few useful directives. Two of them that we will use here are PostUp and PostDown. PostUp executes commands immediately after your WireGuard interface is brought up. PostDown executes commands immediately after your WireGuard interface has been torn down. These are convenient moments to either add port forwarding information or remove it.

To start with enable port forwarding by adding the following lines under the [Interface] section of the VPS’s wg0.conf file (as with the Address directive, the PostUp and PostDown directives can appear in the file multiple times so you can split up a lengthy list of commands onto separate lines):

PostUp = iptables -A FORWARD -i eth0 -o %i -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT; PostUp = iptables -A FORWARD -i %i -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

These two lines enable packet forwarding from interface eth0 to wg0 and from wg0 to eth0 for established and related connections. Once a connection has been established, all packets for that connection will be properly forwarded by WireGuard to the appropriate peer. Do note that the interface name of your VPS’s network connection may not be eth0. To find the name use the ip address list command. The interface that has your VPS’s assigned static IP address is the one you want to put in place of eth0. %i will be replaced by the name of your WireGuard interface when the wg-quick is run.

If the WireGuard interface isn’t up, there’s no reason to keep forwarding enabled. In my configuration files I prefer to undo all of the changes I made with the PostUp directives when the interface is torn down with PostDown directives. To do this add the following lines:

PostDown = iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT; PostDown = iptables -D FORWARD -i %i -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

These commands look almost identical except they use the -D flag (delete) instead of the -A flag (append).

Now we need to tell the VPS to change the source address of all forwarded packets to the IP address of the WireGuard interface, which can be done by adding the following line:

PostUp = iptables -t nat -A POSTROUTING -o %i -j MASQUERADE;

If the source address isn’t changed on forwarded packets, the responses to those packets won’t be properly forwarded back through the WireGuard interface (and thus will never reach the client that connected to your server). To undo this when the WireGuard interface goes down, add the following line:

PostDown = iptables -t nat -D POSTROUTING -o %i -j MASQUERADE;

Now that forwarding has been enabled we can start adding commands to forward packets to their appropriate destinations. For this example I’m going to assume your self-hosted server is running a Hypertext Transfer Protocol (HTTP) server. HTTP servers listen on two ports. Port 80 is used for unsecured traffic and port 443 is used for secured traffic. To forward traffic on ports 80 and 443 from your VPS to your self-hosted server add the following lines:

PostUp = iptables -A FORWARD -i eth0 -o %i -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT; PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 172.16.1.2;

PostUp = iptables -A FORWARD -i eth0 -o %i -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT; PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 172.16.1.2;

The first command will forward all packets received on port 80 of eth0 through the WireGuard interface. The second command changes the designation IP address to the self-hosted WireGuard peer, which will ensure the packet is properly routed to the self-hosted server. Lines three and four do the same for traffic on port 443. To undo these changes when the WireGuard interface goes down, add the following lines:

PostDown = iptables -D FORWARD -i eth0 -o %i -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT; PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 172.16.1.2;

PostDown = iptables -D FORWARD -i eth0 -o %i -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT; PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 172.16.1.2;

At this point the configuration file on your VPS should look like this:

[Interface] Address = 172.16.1.1/16 SaveConfig = false ListenPort = 65000 PrivateKey =


PostUp = iptables -A FORWARD -i eth0 -o %i -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

PostUp = iptables -A FORWARD -i %i -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;
PostUp = iptables -t nat -A POSTROUTING -o %i -j MASQUERADE;
PostUp = iptables -A FORWARD -i eth0 -o %i -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT;

PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 172.16.1.2;
PostUp = iptables -A FORWARD -i eth0 -o %i -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT;

PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 172.16.1.2;
PostDown = iptables -D FORWARD -i eth0 -o %i -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;

PostDown = iptables -D FORWARD -i %i -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT;
PostDown = iptables -t nat -D POSTROUTING -o %i -j MASQUERADE;
PostDown = iptables -D FORWARD -i eth0 -o %i -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT;

PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 172.16.1.2;
PostDown = iptables -D FORWARD -i eth0 -o %i -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT;

PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 172.16.1.2;

[Peer] PublicKey = AllowedIPs = 172.16.1.2/32

After the changes are made you’ll need to restart your WireGuard interface on your VPS. Do this by issuing the systemctl restart wg-quick@wg0 command. You may also need to restart the WireGuard interface on your self-hosted server (I’ve had mixed luck with this and usually restart both to be sure). Now you should be able to access your self-hosted HTTP server from your VPS’s static IP address.

I prefer not having to manually start my WireGuard interfaces every time I restart a server. You can make your WireGuard interfaces come online automatically when you system starts by issuing the systemctl enable wg-quick@wg0 command on both your VPS and your self-hosted server.

Maintaining a Currency

I like the idea of cryptocurrencies for several reasons. With the exceptions of ones started by governments or their cronies, they exist outside the direct control of governments. If designed properly, they can also enable anonymous transactions, which hinders the efforts of governments to use transaction information to oppress individuals. However, there is a lot of criticism aimed at cryptocurrencies. Some of the criticism is valid, but much of the criticism is idiotic when considered in the context of currencies in general.

One of the most common criticisms I see regarding cryptocurrencies is their energy consumption. Consider Bitcoin. There is a website dedicated to tracking the estimated power usage of the Bitcoin blockchain. As of this writing the site estimates the blockchain’s energy consumption at 73.12 TWh, which it says is roughly equivalent to the power usage of all of Austria. Consuming the power usage of an entire country to maintain a blockchain appears horribly inefficient… until you compare it to the resources used by other currencies.

Consider the United States dollar. It’s easy to make the mistake of assuming the dollar is a comparatively efficient currency since pieces of paper with pictures of dead tyrants don’t consume electricity. But there’s so much more involved in manufacturing an maintaining dollars. To start with you have the obvious raw materials needed to manufacture dollars. Ink, paper, printing machinery, etc. are needed to make every dollar. Not only is printing machinery used to print dollars, it also requires routine maintenance. Once the dollars are printed they must be stored so you need warehouse facilities. But not any warehouse facility will do. Being a highly sought after good, dollars must be stored in a warehouse that is secure against thieves. These secure storage facilities require hardened materials, security devices, electricity, manpower, etc. Then you have the issue of transporting dollars between storage facilities, which must also be done in a secure manner (armored trucks aren’t exactly fuel efficient vehicles).

The resources needed for manufacturing, storing, and circulating dollars is only a small percentage of the overall resources needed to maintain dollars. A fiat currency quickly becomes worthless if nongovernmental counterfeiters are able to practice their trade unhindered. There are two majors steps to thwarting counterfeiters: hardening the currency itself to make counterfeiting more difficult and punishing counterfeiters once they’re captured.

A dollar can have a lot of built-in security measures. Each of these measures requires resources for both development and implementation. Research and development is needed first to come up with measures that make dollars harder to counterfeit, then manufacturing machinery capable of implementing those measures must be developed, purchased, powered, and maintained.

Then you have the task of punishing captured counterfeiters. The first step in this process is writing and passing legislation, which can be an incredibly inefficient process. The legislation itself is meaningless though, it merely authorizes the allocation of resources for law enforcers. Dollars are probably the most common target of currency counterfeiters, which means the amount of law enforcement effort needed to find and capture counterfeiters is significant, especially when you consider the fact that such efforts must be global in scale. Once captured the counterfeiters must then be tried and, if found guilty, imprisoned. The court system isn’t designed for efficiency and prisons, like the previously mentioned secure warehouses, require a lot of resources to build, operate, and maintain.

What I’ve presented is an incomplete summary of the resources needed to maintain a fiat currency. It’s easy to see that they’re not a resource efficient as many people suspect. Criticizing cryptocurrencies for being inefficient without comparing such inefficiency to their biggest competitors, fiat currencies, is disingenuous and meaingless.

Mostly Harmless Opinions

I’m of the opinion that actions speak louder than words. Opportunities for people to turn their talk into action always interest me because it shows me whether somebody is honest about their stated intentions. Needless to say, yesterday’s Trump rally in Minneapolis was such an opportunity.

When the rally was announced I immediately thought of two expressed beliefs. The first is that Trump is the second coming of Hitler and his supporters are Nazis. The second is that Nazis must be destroyed with violence. If one drew a Venn diagram of people who express these beliefs, there would be a lot of overlap. Trump and his supporters coming to town provided the opportunity for the people in that overlap to demonstrate their beliefs.

I was fairly certain that the rally would pass by with minimal violence and from the linked story it appears that my prediction was accurate. There was only one arrest by 23:00 and I have found no serious injuries or deaths reported. If the overlap group was at all sizable and the people composing it were truthful about their beliefs, shouldn’t there have been blood in the streets? Shouldn’t there have been hospitals packed with combatants? Why wasn’t there? I’ve come up with three potential explanations.

The first is that the overlap group is actually quite small. While this is possible, my personal experience leads me to believe this explanation is the least likely.

The second is that the people in that overlap who opine that Nazis must be destroyed with violence don’t actually believe that Trump and his supporters are Nazis. If they believed that, they would have used a significant amount of violence against them.

The third is that the people in that overlap who opine that Trump and his supporters are Nazis don’t actually believe that Nazis must be destroyed with violence.

Regardless of the explanation, yesterday reinforced my belief that a lot of people hold mostly harmless opinions. When the opportunity to act on their words presented itself, they back down faster than Apple after being given the stink eye by China.

Go Be Homeless Somewhere Else

Remember Minneapolis’s Hooverville? As usual the overlords of the city wanted to sweep their homeless problem under the rug but were hampered by the fact that the media was giving heavy coverage to the camp. So instead of the usual tactic of sending the police in under the auspice of “public health” to breakup the camp, Minneapolis’s overlords had to go through the work of setting up a homeless shelter. Now that the media coverage has subsided, the homeless individuals who were brought to the shelter are being kicked to the curb:

On Monday, officials in Minneapolis capped a yearlong effort to clear the state’s biggest homeless encampment by closing the temporary emergency shelter on Cedar Avenue, where they had forced residents of the camp to move roughly five months ago.

Won’t this result in another Hooverville popping up? Of course it will and the city official know that:

Officials are aware of plans for another tent settlement this year and are working on a plan for responding to it.

I’m betting the plan involves nipping the Hooverville in the bud before it gets national coverage. Nobody involved in the Minneapolis government wants a repeat of last year’s embarrassment (which wasn’t the existence of the Hooverville but the media coverage that prevented the government from sending in law enforcers to confiscate the tents and crack some homeless skulls in the hopes of convincing them to go be homeless somewhere else).

Corporate Control

Gun restriction advocates haven’t enjoyed much recent success in their political efforts so they’ve switched gears. They’ve been leaning on corporations to lean on gun retailers. This has resulted in banks refusing to do business with gun retailers and other such nonsense. Now Salesforce has decided to cave to the unwashed masses and is telling gun retailers to either stop selling modern firearms or abandon its platform:

SAN FRANCISCO — On its website, Salesforce.com touts retailer Camping World as a leading customer of its business software, highlighting its use of products to help sales staff move product. A Camping World executive is even quoted calling Salesforce’s software “magic.”

But behind the scenes in recent weeks, the Silicon Valley tech giant has delivered a different message to gun-selling retailers such as Camping World: Stop selling military-style rifles, or stop using our software.

The pressure Salesforce is exerting on those retailers — barring them from using its technology to market products, manage customer service operations and fulfill orders — puts them in a difficult position. Camping World, for example, spends more than $1 million a year on Salesforce’s e-commerce software, according to one analyst estimate. Switching to another provider now could cost the company double that to migrate data, reconfigure systems and retrain employees.

Not many better examples of corporate mutually assured destruction exist than this one. One the one hand Camp World could fold and decide to stop selling modern firearms. If it did, it would almost certainly incite the wrath of gun owners and, as Dick’s Sporting Goods can tell you, pissing off gun owners can hurt your bottom line. On the other hand Camp World could tell Salesforce to go pound sand, which would cost the company both money and public relations, since it spent so much time touting Camp World as one of its success stores. Either way this move could cost Salesforce many other accounts since I’m willing to bet that Camp World isn’t the only gun retailer using Salesforce.

There is a lesson to be learned here. Becoming dependent on a third-party platform is a liability. If you make your business dependent on a third-party platform, your business is suddenly at its mercy. The third-party might come to you some day and tell you that you need to change your business model or it will pull the rug out from under you. If you’re a business owner that values your independence, then it’s in your best interest to avoid becoming dependent on any single third-party.

Killing Yourself Slowly

Trump is working to take this country back to the good old days of mercantilism when governments decided who would succeed and who would fail. Implementing tariffs was just the first act in his strategy to provide a supposed advantage to American companies. His latest act was far more blatant. He issued an executive order to prohibit Huawei from the United States market. In the aftermath of this executive order Google has revoked Huawei’s use of its services, including its Play Store:

President Trump issued an executive order last week banning “foreign adversaries” from doing telecommunication business in the US. The move was widely understood as a ban on Huawei products, and now we’re starting to see the fallout. According to a report from Reuters, Google has “suspended” business with Huawei, and the company will be locked out of Google’s Android ecosystem. It’s the ZTE ban all over again.

That’ll give a much needed boost to American device manufacturers, right? You know, all of those device manufacturers who manufacture their devices in China, where Huawei is headquartered. Because I’m sure this executive order won’t result in any reciprocation from the Chinese government.

But even if we set aside the likelihood of a Chinese retaliatory response, this executive order sends a rather clear message for companies headquartered outside of the United States. That message is that they shouldn’t rely on products or services from companies headquartered in the United States. Huawei can still use Android since it’s an open source project (a good reason to prefer open source code to closed source code) so it doesn’t have to write an operating system for its devices from scratch. It does have to figure out a replacement for Google’s proprietary bits though. There are several solid third-party clients available for Android that allow access to online calendaring, contacts, and e-mail services. Many of those clients are also open source. Huawei could utilize them in place of apps like Google Calendar, Google Contacts, and Google Mail (Google Maps is the tough one to replace but a third-party client could be written for it). So it would only need to worry about distribution and it has enough funding to build its own app store (it could also use something like F-Droid, but that’s unlikely). It could also make licensing money off of its app store by providing access to other Android device manufacturers who had their access revoked by Google due to an executive order.

Foreign companies aren’t going to stop doing business when the figurehead of the United States puts his signature on a piece of paper. They’re going to either make or buy replacements for everything can no longer use. If this behavior of barring foreign companies from business in the United States continues, companies headquartered outside of the United States are going to become more and more wary of relying on American products and services and instead seek foreign alternatives. American companies like Google will find themselves more and more isolated from the global market. The constantly dwindling market size will cause them serious economic hardship, which will translate into economic hardship for their employees.

Isolating domestic businesses from foreign markets is slow economic suicide.

A First

For the first time in the history of the Minneapolis Police Department (MPD) an officer has been found guilty of murder while operating in an official capacity:

Mohamed Noor became the first former Minnesota police officer found guilty of an on-duty murder Tuesday as a Hennepin County jury convicted him for the fatal shooting of Justine Ruszczyk Damond in 2017.

Jurors reached their verdict after about 10 hours of sequestered deliberations in a case that was closely watched nationwide and in Damond’s native Australia. They convicted Noor of third-degree murder and second-degree manslaughter but acquitted him of the most serious count — second-degree murder.

I’ve been following this case through Lou Raguse’s Twitter account since he was one of the handful of journalists granted access to the trial. The main thing I took away from the trial was the extent to which MPD went to cover up the murder. From body cameras not being turned on at critical moments to Noor’s squad car being washed and returned to service the very next day it was pretty obvious that MPD went as far as it could to cover the up the evidence of this murder. However, the case was so blatant that those efforts ended up being in vain.

There is currently a pending civil case brought by the family of Justine Damond against the City of Minneapolis. The evidence revealed during Noor’s trial will likely provide a lot of legal ammunition for Justine’s family’s case. I hope the City of Minneapolis gets soaked for the entire $50 million being sought. It’s obvious that MPD and the government tasked with overseeing it are horribly corrupt and they deserve some swift and severe punishment.

Destructive Rights Management

Digital Rights Management (DRM), and oxymoronic term since something ceases to be a right the second it’s managed, has been the bane of digital content consumers’ existence since it was first developed. Why does the single player game I bought need a constant Internet connection? DRM. Why is this audio CD trying to install a rootkit on my system? DRM. Why can’t I watch this movie I purchased from the iTunes Store on my Kodi box? DRM.

However, the greatest danger of DRM lies in the fact that any content protected by DRM can be taken away from you. This is a lesson that people who purchased e-books via Microsoft’s service (I’ll be honest, I didn’t even know Microsoft had an e-book service) are learning right now:

There’s bad news for users of Microsoft’s eBook store: the company is closing it down, and, with it, any books bought through the service will no longer be readable.

To soften the blow, the company has promised to refund any customers who bought books through the store (a clue that there may not have been that many of them, hence the closure. Microsoft did not offer further comment).

But just think about that for a moment. Isn’t it strange? If you’re a Microsoft customer, you paid for those books. They’re yours.

But they’re not yours. Why? DRM.

The upside for consumers is that Microsoft isn’t closing its e-book service because it’s is filing for bankruptcy, which means it’s is in a position to offer refunds (more on that in a moment). This situation makes it an oddity though. Oftentimes when a service shuts down it’s doing so because it has run out of money. If this were a small e-book distribution service, not only would its customers lose all access to the books that they purchased, but they would also receive no refund.

But let’s talk about Microsoft’s refund for a moment. If you go to the announcement page, you’ll see that there are some strings attached:

How do I get my refund?

Refund processing for eligible customers start rolling out automatically in early July 2019 to your original payment method. If your original payment method is no longer valid and on file with us, you will receive a credit back to your Microsoft account for use online in Microsoft Store.

If your original payment method is still valid (i.e. if your credit card hasn’t expired or been stolen) you will get a credit back. That’s actually pretty good but if the original payment method is no longer valid, you get Microsoft Fun Bucks, which you can use to buy more DRM encumbered content that may go away at any moment. That’s not as sweet of a deal.

The service will shutdown in July so if you’re in the middle of reading a book, you better finish it up before it’s taken away from you.

Californians Receive Some Scraps from the Freedom Table

I frequently bitch about the People’s Republic of Minnesota but at least we have decent overall gun laws (although the politicians, not surprisingly, at constantly at work to change that). The denizens of California don’t even have that. However, a federal court tossed those poor saps a few scraps from the freedom table:

SACRAMENTO, Calif. — High-capacity gun magazines will remain legal in California under a ruling Friday by a federal judge who cited home invasions where a woman used the extra bullets in her weapon to kill an attacker while in two other cases women without additional ammunition ran out of bullets.

“Individual liberty and freedom are not outmoded concepts,” San Diego-based U.S. District Judge Roger Benitez wrote as he declared unconstitutional the law that would have banned possessing any magazines holding more than 10 bullets.

This case stems not from California’s original ban on standard capacity magazines, which allowed gun owners to continue possessing magazines they acquired before the ban, but from a 2016 change that demanded Californians surrender their pre-ban magazines. But that 2016 attempt may end up costing California its earlier magazine ban as well:

Chuck Michel, an attorney for the NRA and the California Rifle & Pistol Association, said the judge’s latest ruling may go much farther by striking down the entire ban, allowing individuals to legally acquire high-capacity magazines for the first time in nearly two decades.

This ruling is potentially good news for gun owners across the entire country. It could be used to invalidate magazines bans in other states that have them and prevent states like the one in which I suffer from implementing them.

In other related news, several California gun owners have miraculously discovered their boats full of standard capacity magazines that went under in 2016. This is great news for both those gun owners and the environment since those lost magazines can now be removed from those marine environments.