This site/thread by Robin Sloan is a treasure

I really enjoyed this thread by Robin on Rosegarden. Enough that I’ve been remembering it and thinking about it for 3 days now.

Among several gems—and general creativity of presentation, there’s this:

What we hear from companies like T—— and F——- and Y—— is that monitoring communication at this scale, preventing that harm, is an unprecedented technical challenge.

That’s correct. However… no one asked for communication at this scale!

Robin Sloan – platforms.fyi

I also appreciate the idea that “no reasonable human needs more than 10,000 other humans to read their words within twenty minutes of writing them.”

Of course, I did learn about this from a tweet sent out to 43,000 people. 🙂

Script toggles for DNS over HTTPS on public Wi-Fi

DNS over HTTPS has been fun to try out. I’ve been using Cloudflare’s command line client/service/proxy configuration and working through some of the quirks with day to day use.

In a nutshell: A DNS proxy is setup on your local machine that makes DNS over HTTPS requests to Cloudflare’s 1.1.1.1 and 1.0.0.1 servers. Your configured DNS server is 127.0.0.1, and lookups are encrypted between your local machine and 1.1.1.1. With this data encrypted, your service provider (home ISP, coffee shop, hotel, airport, etc…) does not see the domain name requests that are made.

This works great until you join a wireless network with some kind of captive portal requiring you to either login or accept some kind of terms. At that point, the network’s DNS is usually used to provide the address for that captive portal and no other network activity is allowed until that process completes. In many cases, this will not be compatible with a DNS over HTTPS configuration.

There are a handful of steps required for switching back and forth, which could be a pain if you’re frequently bouncing between locations.

  • Enable or disable the cloudflared service
  • Enable or disable the dnsmasq service (if using that to capture local .test lookups for example)
  • Change the DNS configuration to either 127.0.0.1 or a default config to allow the network to serve its own DNS.

To handle this, I wrote a couple quick bash scripts that I can use to reduce my annoyance and toggle things back and forth.

The doh-enable script turns on cloudflared, turns on dnsmasq, and sets the local IP as a DNS server:

# doh-enable: enables the DNS over HTTPS config
sudo launchctl setenv TUNNEL_DNS_PORT 54
sudo launchctl load /Library/LaunchDaemons/com.cloudflare.cloudflared.plist
sudo brew services start dnsmasq
networksetup -setdnsservers Wi-Fi 127.0.0.1

The doh-disable script turns off cloudflared, turns off dnsmasq, and empties the custom DNS server config to accept the network default:

# doh-disable: disables the DNS over HTTPS config
sudo launchctl unload /Library/LaunchDaemons/com.cloudflare.cloudflared.plist
sudo brew services stop dnsmasq
networksetup -setdnsservers Wi-Fi empty

Now when I encounter a captive portal situation, all I need to do is type one command, sign in, then type another.

If you’re interested in trying out DNS over HTTPS, I found the Cloudflare documentation well written and this article helpful for getting dnsmasq running alongside it.

Restricted XML-RPC methods for WordPress mobile app support

For a long time I’ve had the path to xmlrpc.php blocked completely on a handful of sites so that I didn’t have to worry about Things. One thing that this messes with, if you don’t have Jetpack installed, is the WordPress mobile app. Without a WordPress.com connection, the mobile application relies on the XML-RPC API provided by your WordPress.

So I made a couple plugins.

First, the one you shouldn’t use in production, Log XML-RPC Requests, does exactly what it implies: logs incoming XML-RPC requests to a WordPress site as a custom post type.

I activated this on a site and then went screen by screen through the WordPress Android application to determine what XML-RPC methods were absolutely required in order for things to work.

That data was then used in the Restricted XML-RPC Methods plugin. This rejects any XML-RPC request that is not one of those required by the WordPress Android application. And pingbacks, because they’re underused and will always have a special place in my heart. 🙂

Any extra methods required by the WordPress IOS app are not enabled, but only because I don’t use an iPhone as my primary device. I’m happy to add those in if somebody passes me the list. It’s also possible that it just works!