Recently my TLS certificates from Let's Encrypt expired.
Usually they send me an automated email when this is about to happen, but for whatever
reason no email was to be found this time.
So my website briefly served an expired certificate for a few hours until i noticed it and renewed it.
I want to prevent this from happening again, so maybe it's time to set up automatic renewals.
I could just add certbot renew && systemctl reload nginx to /etc/cron.monthly
but i'm not certain how frequently to run it, so let's check the offical documentation and see what they recommend.
If you poke around the certbot website, eventually you'll find a link to the
official documentation, and from there you can probably find the section on
Automated Renewals.
Which mentions:
On Linux and BSD, you can check to see if your installation method has pre-installed a timer for you. To do so, look for the certbot renew command in either your system’s crontab (typically /etc/crontab or /etc/cron.*/*) or systemd timers (systemctl list-timers).
On my system at least (Fedora), there's nothing in my crontab but lo and behold there is a timer.
But it turns out we don't even have to do that — we can simply drop a shell script in /etc/letsencrypt/renewal-hooks/deploy and it'll be run as a deploy hook.
#!/bin/bash -eu
systemctl reload nginx
/etc/letsencrypt/renewal-hooks/deploy/nginx.sh
Cool. The last step is to enable and start the timer:
I guess in 3 months i'll find out whether it worked or not. 🤪
UPDATE 2022-11-08:
Six months later, i haven't thought about certs at all.
A quick grep through the logs (journalctl -u certbot-renew.service)
shows that it has been running every day, and performed a renewal thrice
(in July, September, and November — every two months).
Cool!
autogynephilia
Julia Serano wrote a paper in 2010 (which i just came across) debunking the "autogynephilia" theory of transsexualism.
If you're not familiar with it, this is the theory that a large category of trans women are actually acting out a 'heterosexual' attraction to women that has 'misfired' back on themselves and thus they aren't really trans.
Serano does a detailed review of the literature and dismantles the core arguments point by point.
The whole paper is worth reading, but this particular point near the end really clinches it for me (citations omitted for clarity).
We also live in a heterosexual-male-centric culture, where female bodies and feminine gender expression and presentation are routinely objectified and sexualized to a far greater extent than their male/masculine counterparts.
This might account for why both androphilic and nonandrophilic MtF transsexuals experience far higher levels of arousal in response to cross-dressing than their FtM counterparts.
This would also explain why a significant percentage of nontranssexual women who have been administered questionnaires similar, or virtually identical, to Blanchard’s Core Autogynephilia and Autogynephilic Interpersonal Fantasy surveys display autogynephilia.
The fact that nontranssexual women exhibit patterns of arousal similar to those seen in transsexual women indicate that autogynephilic fantasies are neither transsexual-specific nor paraphilic (as paraphilias are purportedly extremely rare or nonexistent in natal women.)
Given this, there is no valid reason why Blanchard’s term autogynephilia should be used to single out MtF transsexual’s fantasies and desires.
The premise of "autogynephilia" is that trans women have abnormal fantasies that motivate their transition.
But, no: it turns out that if you survey cis women, cis women experience similar fantasies at a similar rate.
This is the bit that kicks the final leg out from under the table for me.
Even ignoring all the other problems with the theory,
if this is true then it loses all predictive power:
"autogynephilia" is more predictive of being a woman than being trans.
Any explanation or insight the theory purports to provide about trans people must be recast to apply to cis people too.
It would be a double standard to claim that a behaviour is normal in cis women but pathological in trans women.
It's like if you were studying lottery winners, noticed that some of them eat fast food,
and you built an elaborate theory about how this unhealthy obsession with cheap food by such "psuedo-rich" people exposes some sort of inherent poorness, that they don't really deserve to be wealthy and are just pretending
-- and then someone discovers that people who inherited their wealth also like fast food.
Poof, there goes the theory.
Like, sure, maybe there's a correlation there that deserves study but your theorizing is built on a false premise, the causality is all backwards, and your dichotomy is classist nonsense.
The bow on the top is that of course this is rooted in society's sexualization of women.
We coerce women into wearing revealing clothes & make-up for the pleasure of men, then pretend that they have no sex drive of their own.
Some fool notices that trans women don't conform to this narrative and invents a pathology around it.
In other words, to sum it up in a tweet,
society: *sexualizes women*
(trans/cis) women: *sexualize themselves*
society: no not like that
Today, her account is locked, and her profile says, "Taking a mental health break. Don’t talk to me about Minecraft".
What does it say about Twitter, (and the modern internet in general), that something so positive - a feel-good story about digital preservation - could lead to someone needing to take a break from the internet for their mental health? I don't know, but it doesn't seem good.
unwritten rules
thinking about how i have weird unwritten rules like "don't boost too often / don't linkspam", which sucks because i run into cool things all the time that i want to share and i have nowhere to share them.
i guess i have this idealized version of myself that i want to live up to. i don't want to be someone who boosts all the time and never says anything, because i don't like following people who do that. but maybe that's okay? maybe different people follow people for different reasons. maybe i don't have to hold myself to that made-up standard.
sharing random links is a perfect use case for microblogging, and yet i won't let myself use it that way.
why am i artificially limiting the way i use social media to ways that don't work for me?
On the modern web, everything must be encrypted. Unencrypted websites are treated as relics of the past with browsers declaring them toxic waste not to be touched (or even looked at) and search engines de-prioritizing their content.
While this push for security is good for protecting modern communication, there is a whole web full of information and services that don’t need to be secured and those trying to access them from older vintage computers or even through modern embedded devices are increasingly being left behind.
[...]
Now that your entire website is being offered to legacy browsers over HTTP,
modern browsers can still be directed to connect over HTTPS for added privacy by
responding to the
Upgrade-Insecure-Requests
header. [...]
today i learned about the Upgrade-Insecure-Requests header.
sounds useful, at first glance — a way to upgrade to HTTPS, but only for clients that support it?
so legacy clients on low-powered devices can still browse my site? heck yeah!
but after digging in, there are some weird details.
first off, it's a request header, not a response header.
so the client sends a request with the header,
and then the server has to have the smarts to recognize the header and redirect if it is present, or if it's not then just serve the requested page.
(the blog post linked above has an example of how to do this in nginx).
this seems backwards to me.
i would do it the other way around — as a response header.
the server would passively send a header saying "i support secure requests",
or maybe even "here's an alternate url for this page that uses a secure connection",
and the client would decide whether to re-request the page using the new url or not.
secondly,
according to the spec, it exists to signal to the server "the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive" [1].
yeah that's right - there's actually a whole other spec that the client has to support in order to send the header.
speaking of which — today i learned about Content-Security-Policy: upgrade-insecure-requests.
this one actually is a response header (and you can even use it in a <meta> tag, meaning you can set it even if you don't control the server config!)
it's, uh, also a bit odd.
it doesn't have any effect on whether the requsted page is loaded over HTTP or HTTPS,
but any links in the page will be upgraded to HTTPS by the client.
(example here, if you want to try it out).
okay, but hold on.
given that the server should have complete control over the page it sends and therefore over the links in that page,
why would it need a mechanism to tell the client to upgrade them? couldn't they just be HTTPS links in the first place?
the answer is that that's not really what the Content-Security-Policy header is for.
its purpose is to be a line of defense against XSS attacks,
so that even if an attacker is able to inject malicious code into the page,
the server can still set some ground rules about e.g. what domains scripts the page is allowed to load scripts and fonts from.
in that context, upgrade-insecure-requests kinda makes sense —
it's setting a boundary around the page, saying, effectively,
"we only interact with secure sites, so... if you see any insecure urls then pretend you didn't".
conclusion: Upgrade-Insecure-Requests (and its related Content Security Policy directive) look interesting at first,
but after examining them more closely, i don't think they're for me.
i'll stick with my current strategy: an HTTPS-only site with legacy HTTP redirects.
while it would be nice to support clients that can't open secure connections,
i don't actually care that much, and Upgrade-Insecure-Requests
doesn't seem like the right mechanism to do it.
i think what i really want is something like Strict-Transport-Security, but non-strict.
Optional-Transport-Security?
cleaning up
I've decided that this page has gotten much too cluttered with old posts
(some of which i'm not very fond of),
so i'm removing everything and starting fresh.
There are links below to archives of all the posts.
For now, anyway.
I don't know if i'll keep them around forever -
i might go through them and just pull out favourites to keep, and toss the others -
or maybe not.
But that probably won't happen for a while, so they're safe for now.