A Poem (of sorts)

Once upon a midday sunny, while I pondered nothing funny,
Over many a quaint and curious man page of forgotten lore—
    While I angered, nearly snapping, suddenly there came a bad ping,
As if LVS was napping, napping though it knew the score.
“’Tis just upstart,” I muttered, “napping; i’ll give it what for—
            sudo service keepalived restart.”
Posted in jokes, software | 1 Comment

NIH, Developer Infantilization, and Motivations

I recently read about the new face of NIH syndrome, and after sharing and discussing it with some coworkers (Hi, John!) I had some thoughts about how NIH (or what Freeman calls NPF) comes to be, and what it means about an organization.

For the uninitiated, NIH stands for “Not Invented Here,” and refers to the inclination of some development organizations to avoid third party tools at all costs, because there’s some sort of vague FUD (fear, uncertainty, doubt) around using anything that our developers haven’t written. Maybe it won’t work, maybe it won’t work *well*, maybe it will stop being supported, etc, etc. Freeman argues that the software industry has, by and large, rid itself of NIH syndrome, but it has done so mostly through word policing and social mores, and developers still do roughly the same thing, only in the form of what he calls NPF: Not a Perfect Fit syndrome. The symptoms are the same, more or less: sure, this software works, but we realllly need X feature, and no one else does that. Or, yea, that works, but do we really want to deploy a JVM on our wiki box? why not just write our own? Or, etc. Same symptoms, same cause, different name — because saying “we can’t use that, we didn’t write it” doesn’t work anymore, you need a plausible-sounding justification, however thin it may turn out to be.

So I was reflecting on all this and chatting with John, who is a wonderful sounding board and generally a thoughtful person, and I mentioned that I have basically no vulnerability to NIH, at which he looked slightly surprised. Upon further thought I have come to think it is because I don’t find all that much joy in writing code. Sometimes it’s fun, and certainly the feeling of solving interesting problems is always rewarding, but I am much more motivated by delivering value to customers than by just the raw act of implementing things. I’m currently really excited about an upcoming project at work because I had spent a while worrying that it would turn out to be frustrating and difficult for customers to use, but after some recent discussion I realized that we have the opportunity to turn it into something that customers will really like. That is so much better of a motivator for me that I can’t imagine slowing down the time to get that feature out to customers by banging out a proprietary form validator or whatever.

And so now I come to my main point: many developers in many companies are basically not permitted to have the kinds of motivations that I have, the ones that supersede the mere technical challenges. Many organizations silo off their development teams, both from the business and, often, even from each other. They are handed feature requests from the business, largely devoid of context, with little idea who they benefit or what the underlying goal is. I consider this a form of infantilization, honestly: the only reason to do this is because you think developers need insulation from the scary business types that poor nerdy coders can never figure out how to interact with effectively. They can play in their little sandbox while the adults gather requirements and decide what to have them do. In this environment — and, actually, I have worked in conditions like this, although not for long — it’s easy to see why someone would develop NIH syndrome. If your job is to do context-free drudge work updating some winforms or CRUD app or whatever day in and day out, and you don’t see customers loving it or understand why anyone would need it, of course you’d make up any excuse to do more interesting work. If the only motivation you’re allowed to have is “for the love of the code,” then the best you can do to keep yourself interested is to work on more interesting code, since you’re not allowed to help solve more interesting business-related problems. Given that the only tool I have for working on an interesting problem is telling someone who wants me to work on a boring problem that there are important prerequisites to it, and that none of the existing solutions to those prerequisites will work for our special snowflake case, I am going to use that tool constantly. If my choices are “write a Django clone” or “write an intranet CRUD app in Django,” I’m going to choose the former every single time.

I am lucky enough that those are not my choices. First of all, no one I work with would dream of letting me write a Django clone, thank god. Secondly, and more importantly, my choices are more like “work on this feature to help customer X” or “work on another feature to help customer Y.” I’d rather do either of those things than write a Django clone! I’ve talked to our customers, I know the pain they feel, and I know the value they can get out of using our product, and helping them is great. Creating a product that I can feel good about giving to customers is a much better feeling that knowing I’m capable of writing some tricky library from scratch.

(Hopefully unnecessary disclaimer: some developers are more motivated by the writing of tricky libraries than the helping of customers. This is totally fine and I don’t mean to deride it in any way. I’m talking about the developers who are like me but not given the freedom to work on projects that would be interesting to them)

There are obviously other reasons an NIH mentality can take over a dev team. “Job security” is a shitty reason people might do this, a feeling of fear that we either can’t implement what we need to or don’t know what we need to implement is a much-less-shitty reason. But I think this explanation explains a lot of the organizations that get taken over by NIH syndrome, and I think it’s a particularly pernicious reason.

It’s pernicious for two main reasons. The obvious one being that you’re wasting your developers’ time, or rather letting them talk you into wasting their own time. That’s just an unnecessary inefficiency in your organization: you would literally be better off firing them.* The second one is that this kind of environment is only appealing to developers who are happy just hacking out code without caring about the business. Engineers who do have any interest in being an active part of helping your customers are going to be frustrated and leave, and the only ones left will be incompetents who can’t find another job and ones who only care about technical chops and have no qualms about crying NIH constantly in order to scratch that itch.

Do you really want that? I mean, empirically, the answer is yes, a lot of companies do want that, because they choose to infantilize their engineers. But you can do so much better! You can get feedback from intelligent, knowledgeable parties, constantly. You can motivate engineers by introducing them to the customers they’re going to solve problems for. You get everyone more involved and more motivated! And you don’t have to constantly fight with your developers if you treat them as grown ups; they won’t constantly scramble to justify NIH tendencies because they’re engaged in their work, and they’ll get more done, and they won’t be incentivized to bullshit you about what can or will get done, and everything is just so much nicer.


In the end, my point is basically just “treat everyone in your company like an adult,” which seems like it should not be controversial enough to say nor rampant enough to break down into sub-categories of infantilization. Unfortunately we do not live in the best of all possible worlds.


*They would probably be better off if you fired them, too! Imagine a person who develops an internal bug-tracking tool because Jira is “not a perfect fit.” Now imagine that person works full time on this Not-Jira, or, say, full time for 3 months and then ~20hrs/wk indefinitely. Let’s say you don’t fire them: you’re wasting ~half of this dev’s salary (half of their salary – a monthly Jira subscription), and this dev is wasting half their time on non-transferable skills that will get them nowhere in their career and severely limit their job opportunities moving forward. Or don’t imagine it: I have seen this exact situation transpire, maybe you have too.

Posted in software | Leave a comment

Users and Accounts in Swift

(This will eventually be published on the SwiftStack blog)

Preface: I am a developer at SwiftStack, where we work with Swift, which is in this context an open source distributed object storage engine, not the Apple language of the same name (which is also pretty cool, tbh, even if the compiler was a piece of shit when I was playing with it). Anyway, people who interact with Swift frequently run into trouble understanding the distinction between users and accounts (and for good reason; it’s quite confusing for the neophyte); so frequently, in fact, that I wrote up this blog post in order to have something to point people to.

This is written from the perspective of a SwiftStack developer to a SwiftStack customer, so it will sound somewhat odd appearing on this blog. When reading, I advise you to imagine yourself as a SwiftStack customer.

On a welcome rainy day not so long ago, I was sitting in the SwiftStack office and ruminating over how best to communicate with one of our valued customers about a feature said customer was interested in us implementing. In the course of coming to a more complete understanding of what was needed to fulfill this customer’s desires, I realized that I was having communication troubles as a result of the confusion between Users and Accounts in Swift. In addition to this already difficult terminology — people are often used to saying “user account” in the context of other software, which leads them to (not irrationally!) misunderstand the crucial distinction inside of Swift — there is also the extra level of indirection of the fact that you yourself are a SwiftStack user!

Note: I will be using bold text for User and Account throughout when they refer to the concepts in Swift. If you see either term unbolded, it is being used to some other purpose.

So to start off with, I am going to indulge in some unbearable pedantry in the form of terminology.

  • Swift UserSwift has a concept of users which are tied to authentication and authorization. A Swift User does not, on its own, provide any access to the storage engine. Instead, it is a way to take credentials from a client and allow Swift to recognize that, yes, indeed, I am aware of this user, and if they continue to make other requests, I have the means to authorize (or refuse to authorize) those requests.
  • Swift Account — An Account, on the other hand, is simply the top-level namespace for storage inside Swift. An Account may have many Containers, each of which may have many Objects, as you are no doubt aware. However, an Account is not necessarily tied to a Swift User.
  • SwiftStack User — This is your identity on the SwiftStack Controller, which is in no way connected to your or anyone else’s Swift user (or Account, of course!)

Smashing MonitorThe last of these is fairly easy to understand as separate from the others, and is generally confusing because of sloppy terminology when speaking about it (in particular, the fact that our auth system for Swift is called SwiftStack Auth, thus necessitating at times the phrase “SwiftStack Auth Swift User” to wholly disambiguate from a SwiftStack Controller user). I thought it was worth calling out explicitly if only to explain that I’m not going to be discussing what a SwiftStack user is.

On the surface, the concepts of User and Account seem fairly easy to distinguish between: a User represents a human (or maybe an automated service), who “logs in” to Swift and then has permissions to see various things. An Account is sort of like a folder, in that you can put Containers in it and then Objects in those Containers. So what’s the problem?

Well, I think the problem comes from a few things. The primary two are:

  1. Simple bad pedagogy and sloppy language on the part of Swift experts, and
  2. The fact that Accounts are, in many auth middlewares, auto-vivified per user.

Problem 1 is something that I myself am guilty of. When talking with other developers and people immersed in Swift, if I slip up and say “user account” when I mean “user” or similar, my colleagues have no difficulty in translating it within context to whatever I actually meant. However, in letting such imprecise language slip into conversations where I’m trying to understand a problem a customer is having, I only create more confusion for both of us.

Cause 2, however, is not something I can label a problem on its own. It’s actually quite a convenient thing! It would be more difficult to get started using a Swift cluster if you had to not only create a User, but then also explicitly create an Account for that User (or perhaps give them permissions to create their own Account). However, people often just start using Swift without ever being taught about the distinction between Users and Accounts, and so the lines get blurry because, in many people’s experiences, there’s a tight one-to-one correspondence between Users and Accounts.

So let’s talk first about the way many people interact with Swift, which leads to most of the confusion, and then we’ll get into other aspects of Accounts in general. When you authenticate with Swift using your username and password, you get back a response that includes, among other things, a Storage URL. This Storage URL is nothing but a link to the default Account that your User has access to. For example, in SwiftStack Auth (our auth system for Swift, not for the SwiftStack Controller), if you authenticate as User “Alexander”, you’d get back a storage URL that looks like http://swift.example.com/v1/AUTH_Alexander. That last bit, the AUTH_Alexander, is the name of my Account! In this case, it was automatically created for me by SwiftStack Auth, which by default creates an account for each User, and gives that User full ownership of the Account. Now, if I make a request to that Storage URL, I get back a fairly bland response; I have no objects and no Containers. But I am free to change that – this is my Account, after all!

On the other hand, what if I try to request a similar URL, but with a different final segment; that is, try to access a different Account? Well, when I try to access the account AUTH_Brenda, I get back a 403 Forbidden error response, because I do not have access to Brenda’s data.

Superman LegoNow let’s briefly talk about superusers. If you’re using SwiftStack Auth to create Swift Users, you’ll notice there is a checkbox for making a user a superuser. A superuser has access to all data inside the Swift cluster. If I created a new User named Superman for my cluster, and had Superman set up and authenticated as a superuser, I would be able to see I would be able to see all of Alexander’s or Brenda’s data.

In fact, I can go ahead and outright delete Alexander and Brenda’s Swift Users, so that it is no longer possible to authenticate using their credentials, and Superman will still be able to see and act upon any data that either of them had put in the cluster!

Superusers are not the only way to access Accounts other than the one your User implicitly has ownership of; you can also set up what are called Access Control Lists (ACLs) on Accounts and Containers, for example. This post is already quite long enough without going into detail on other ways to divorce Users and Accounts, though!

I hope this helped you understand a little bit better the difference between Users and Accounts in Swift. The takeaway is that the two are not closely tied together except by convention and for your convenience.

Posted in pedantry, software | Leave a comment

An Intuition On Why Teaching Is Hard

There are some things that are very difficult to teach. For example, nobody has really figured out how to teach programming yet. Many people are pretty good at teaching calculus, but nobody has a 100% success rate, and it’s never easy. Etc, etc.

Some things are not difficult to teach, of course: it is relatively easy to teach someone facts: water weighs 1 g/ml, John Lennon was born in 1940, the sky is blue.

What’s the difference? Well, I think the major difference is that teaching static facts is easy, while teaching things that require some sort of integration is hard. For example, teaching someone the straightforward formula: \frac{d}{dx}x^{n} = nx^{n-1} is actually not very hard, assuming they have a decent understand of algebra. Getting someone to understand what the derivative is, in a general sense, is very hard. Similarly, we have things like Codecademy, which do the equivalent of teaching you formulae and no integration, because it’s not hard to tell someone to copy some text, but it is hard to teach someone how to write programs.

The intuition I had about this the other day is that you cannot transfer knowledge via language; you can only transfer serialized forms of knowledge. Facts like “John Lennon was born in 1940” serialize very well. Integrations between ideas, understanding processes, etc – these things serialize poorly. Have you ever tried to get directions from someone who has lived in the same place their whole life? Their brain understands the terrain at too deep a level to serialize it, and since they rarely need to communicate that issue in language, they have no intermediate forms to serialize for you. They literally cannot advise you as well as someone who is still learning the territory, because that person still has ready access to all the serialized forms of knowledge (“go a mile down First street”, etc).


This might be obvious or well-known, but I thought it was interesting, anyway!

Posted in language, pedantry | Leave a comment

Why I Don’t Care About Bernie Sanders

Two main reasons I don’t care about Sanders:


  1. He’s not going to win the election. He’s not even going to win the primary. And he’s not doing a great job, from what I can see, of forcing the candidates who might win the primary into taking his issues more seriously.
  2. I have long been cynical about politics. I understand why politicians lie, why political progress is slow, why extremism or idealism in a leader won’t get us anywhere (and probably wouldn’t be a net positive anyway); it’s not a cynicism borne of thinking they should do better, it’s about knowing they can’t and not falling for it. I got duped, once: I bought into the whole Obama idea, the hope he was selling, etc. And he — of course, and inevitably — did not bring that to bear. Not that McCain would have been better: he probably would have been worse. But, I think that it’s intellectually dishonest to think both “all politicians are [perhaps necessarily] liars or double-talkers” and “Bernie Sanders has morals and ideals and would stick to them if elected president.”
Posted in politics | Leave a comment

All Security Is Security Theatre

In light of the Ashley Madison leak, I wanted to tell, or perhaps remind, you that all security is bullshit. This applies to physical (e.g. home) security as well as digital security. The moral of this post will be: please do the bare minimum, or slightly above it, required for “reasonable” security; do not worry about going beyond that because you basically can’t.

Physical Security

Physical security, like home security or how to be safe when going somewhere, is mostly about not doing the stupidest possible thing. As long as you’re not doing the stupidest possible thing, you’re getting most of what you can out of security.

Consider home security. Presumably, you don’t want people breaking into your house. You don’t want them to hurt you or steal your possessions. So you try to prevent them from doing so: you close your door, you lock it, maybe you even deadbolt it; you close your windows, maybe you take the time to lock them too, usually. This is all you need to do.

I’m going to make up some numbers here, but they should be fairly representative. Let’s say 100 people walk by your house: how many of them are going to break in and steal your jewelry?

  • If the door is open, maybe 5 people will be tempted by how easy it is
  • If the door is closed, but unlocked, maybe 1 or 2 people will try it, at worst
  • If the door is locked, we’re way below 1%; you’d expect maybe 1 in 1000 people, at worst, to try a number of doors, find them locked, and then look for further ways of entry.

At this point, you’re basically protected from crimes of opportunity. Everything past this point is only protecting you against people who are willing to, both psychologically and physically, expend nontrivial amounts of resources breaking into your home. They can’t just break in right then, because you could come home at any minute, and that’s an extraordinarily high risk. So they have to case the joint, which requires coming back at least a few times, and then they have to scout around for vulnerabilities: an unlocked window, a lock that’s easy to jimmy, etc.

So let’s consider that you now have a small number of people who see your house, which has an appropriate “not-extremely-stupid” level of security, and decide that it still looks worth robbing. Let’s say 100 people reach this stage:

  • If all your windows are locked, that will prevent maybe half of them
  • If all your doors are deadbolted, that will prevent many more
  • If all your doors have difficult-to-pick locks, that will prevent a few more (no lock is that hard to pick)

To get any further than this, you have to start doing things like barring your windows (which makes your day to day life less pleasant and reduces property values), installing alarm systems (which are of dubious effectiveness), build a moat, etc.

Let’s assume my numbers are vaguely right: locking your doors and closing your windows stops >99% of all robbery attempts. At that point, you have to start trading off the cost of implementing further security with the actual effectiveness. Locking your windows every day is annoying and easy to forget, and prevents, based on our givens, less than 1% of all robberies. Probably much less. Is it worth it? Is it worth barring your windows? Certainly not.

Even if you do go through these steps, anyone who really wants to get in is not going to be stopped. If someone wants to hurt you and is willing to take the risks (or, perhaps, wants to hurt you and is the government), they will get in. Most doors I’ve seen in my life would be trivial to break down with a solid kick. Most of the rest would take maybe 30 seconds with a sledgehammer. After that you’re getting into concrete doors, and you don’t want to live that kind of life. These attempts, obviously, expose the perpetrator to much greater risk of consequences, but who cares? their goal is to get in and hurt you: you cannot stop someone from doing that if it’s important enough to them. Kings and presidents have been assassinated, you’ll recall: you do not have half the ability to protect yourself that they do.

Lesson: Lock your doors, close your ground floor windows, and accept that you’ll get robbed if anyone really wants to rob you. They probably don’t: one of your neighbors will forget to lock their door one day, and that’s all you need.

We can also consider personal physical security. Do you need to go to the store? Do it during the daytime if you can. If you can’t, avoid bad neighborhoods on your way to the store. If you can’t do that, stay in well lighted areas as much as possible. Walk upright, don’t have headphones in, don’t play on your smartphone. Bam, you’re golden. Nobody who’s out for easy opportunities to rob or hurt someone is going to fuck with you. Only people who are much more dedicated to their crimes will, and the steps to prevent those people from doing so are as likely to backfire as not: carrying a knife or a gun is likely to end up escalating things and getting you hurt worse.

Online Security

Online security is also mostly about not doing the stupidest possible thing, although I think people are less educated as to what the stupidest possible thing is when it comes to digital, rather than physical, security.

For reference, the stupidest possible things in digital security are: using the same password for your email as everywhere else; clicking on links from strangers without observing where they point to; entering sensitive information (passwords, SSNs, etc) into any website that is not over HTTPS, and, of course, giving out your passwords.

What do you want digital security for? The main thing you have to protect against is what we often call “identity fraud,” which is usually in the form of someone grabbing your credit card information and making some purchases with it. This actually usually doesn’t matter; it’s happened to me two or three times and the remediation in all cases has been calling my bank, explaining that, no, I did not order $3,000 worth of audio equipment shipped to Ohio, can you cancel those charges, please? Okay, thanks! and then having to wait a few days for a new bank card. It could, of course, end up worse than that, but your bank takes these things very seriously, so it’s likely to be fine.

What is actually much worse is someone getting into your email account. Your email account is, to a stunningly large degree, who you are online. If I can log into your email, I am you for all intents and purposes. I can intercept all your personal and professional correspondence, obviously, which is horrifying to think about and potentially damaging to one’s career or reputation if, for example, you have otherwise-hideable medical conditions, or you are into wacky sex things, or having an affair, you say mean things about your boss/friends in confidence, or whatever. Beyond that, though, I can sign you up for anything I want, I get all your bank information, I get complete access to all your accounts. I can go reset your password on everything. I can transfer $500 from your bank account to mine, acknowledge it, and delete the email. I can blackmail you by holding hostage those sexy pictures you sent your SO.

That is why you do not, I repeat do not use the same password for your email as for anything else. Find an email provider with a reasonable history of security, always navigate directly to their website when you need to sign in, and use a different password everywhere else.

You can use the same password everywhere else, depending on how much you care. Remembering (or using something like 1password to store) a zillion different passwords sucks, and most of the services you sign up for are hilariously badly secured already, so it’s not like you’re protecting anything. If you use password A at service S, and password B at service T, you’re insulated against S getting hacked and leaking your password for T. But if anyone bothers to hack T, they probably won’t have any real trouble doing it, anyway, so it’s not like you’re buying a whole lot of security. And, anyway, S is hopefully using a salted cryptographic hash for storing your password, so even if you use the same one at both services, it’s unlikely to tip anyone off.

Beyond using at least a couple different passwords and making sure that you only ever sign into things either (a) with one-off credentials not tied to your other accounts or (b) that are HTTPS secured, you’re pretty much set.

You can do things like disabling javascript to prevent clickjacking attempts, using randomly-generated, high-entropy passwords to insulate yourself from rainbow table attacks, encrypting your hard drive, etc, but the cost of those to your daily experience using your computer is pretty high, and buys you very little.

Let’s imagine a situation to put a point on this. Let’s say you’re extremely paranoid: you log out of everything every time you use it; you keep all your passwords in an encrypted password vault which requires you enter your memorized, long, high entropy password every time you use it; you disable javascript in your browser; you never install software except from trusted sources, over HTTPS, and you check the md5sum of each of them; etc. How can I attack you?

Well, if I’m just me, I don’t have a ton of easy options. You’re safe from me. But you already were!

Let’s say I’m a dedicated blackhat hacker. You’re slightly insulated from me, but how hard would it be for me to set up a MITM attack on you? If you’re already afraid of me, fairly. But what if I just invite you over for dinner one night, and contrive to get you to connect to my wifi network?

So say you’re terrified of me; you know I’m an attacker. What if I make friends with your dad, and one day I tell him about a security update he needs to install for his home router? I say I’ll do it for him; it’s easy to mess it up, and I’m pretty well versed in these things. Oops, you’re out of luck.

Or maybe I break into your house and do it from there. That’s not gonna be too hard, either.

Or, like, I pay someone $5000 to sleep with you and steal your laptop while you’re asleep.

Point being, if I have specifically targeted you, and I have any reasonable amount of resources at my disposal, you’re fucked.

There’s also a few more things to consider: It is unreasonable to assume that the NSA does not have full access to all of your information sent over the web, at this point; any credentials or information you sent over the web before the Heartbleed bug was discovered should be considered compromised; anything you send over any website that you cannot guarantee has patched Heartbleed is still getting compromised. And of course there’s probably a thousand more zero-days compromising all your data all the time.

Using a few different passwords, etc, gets you to that >99% security threshold; after that everything else is painful at best and folly at worst.

All this is to say: if there is anything you wish to communicate that you absolutely cannot tolerate having someone else finding out about, don’t say it online. There is no privacy, there is no security, there isn’t even anonymity.

Posted in pedantry, software | Leave a comment

Patricide is a good word

pat·ri·cide: noun

  1. the killing of one’s father.

Patricide is a noun that describes an action. It is also, of course, the name one can give to a person who has killed their own father. In general, when we refer to people based on their actions, we use the active -er form of the word: one who programs is not a “program” (verb: to write computer programs), they are a programmer. And yet, you would never think to call one who has murdered their father a “patricider,” they are simply a patricide.

This is a wonderful grammatical oddity, which is quite enough for me to love the word all on its own. It is also, of course, a subtle linguistic hint that, after killing one’s father, that fact becomes one’s whole identity. There is nothing left of you: you are no longer Alexander, who is a programmer, you are simply Alexander the patricide. Or, in a culture that wishes to basically expunge you from history, just “Patricide,” although that might get complicated if there is a father-killing spree in your town.

So that’s great too. I mean, I actually hate language that boxes people in and represents them as less than their whole selves, but it’s a very powerful idea. I think we should do it with more words. Take the verb form of your occupation and describe yourself as that. Alexander, the program. Embrace your job as your whole identity; it’s what the industry wants!

Note: the word “engineer” already follows this mold, which is hilarious and didn’t occur to me until after i had written this post and was proofreading it.

Posted in language | Leave a comment

Words That I Know Exist But Don’t Know The Meaning Of: A List

  • obverse
  • the difference between exaltation and exultation
  • the difference between assume and presume (ass/presuming there is one)
  • sanguine
  • Other words like sanguine that I can’t think of right now but regularly run into and only partially decode based on context clues
  • pansexuality
  • pantheism
  • basically any word starting with “pan”
  • lief (??)
  • counterfactual. i could probably give you something approaching a definition but i have no fucking clue what it really means when people use it.
  • Ionian, Corithian(?) and Dorian columns, the differences between
  • alligator and crocodile (as referents, not references)
  • “referent,” unless I used it correctly in the last sentence, in which case I at least sort-of know what it means
  • option select, apparently, because every time anyone (inc. me) uses it someone else says they’re wrong


this list is incomplete. in case you were wondering. i know a lot more words that i dont know what they mean.

Posted in language | Leave a comment

If Reid Duke Were Your Boyfriend

Inspired by The Toast’s series

If Reid Duke were your boyfriend, you would tousle his long hair when he stretched in the mornings, and he would sheepishly say, “It’s getting too long. I really need to make time to get a haircut,” and you would smile indulgently at him even though you love how boyish he looks with it longer.

If Reid Duke were your boyfriend, you’d sometimes pretend not to know how to do simple things like loading the dishwasher, even though you obviously do know, and he would know that you know how to do it but he’d explain it to you gently and patiently with no hint of condescension, and you’d both know that hearing him explain it was the only reason you’d asked, but you’d never admit it and he wouldn’t want you to feel bad about it.

If Reid Duke were your boyfriend, the two of you would compete viciously at everything: who is better at board games, who picks up the check at dinner, who makes better sandwiches. The competitive spirit would only bring you closer together, though; after all, every victory for either of you is a victory for the relationship.

If Reid Duke were your boyfriend, when he went to Pro Tour Journey into Nyx, he would have been wearing underwear you had written “You’re always top 8 in my heart” on when he went on stage to claim his first Pro Tour top 8.

If Reid Duke were your boyfriend, you could tell your parents you were dating a writer, your journalist friends that you were dating a prolific content creator, and your nerd friends from high school that you were dating a professional gamer, and they would all be true, and no one would question your taste in partners any longer. Reid Duke would be happy to introduce himself as each of these things to the appropriate groups, not just for your sake, and not because he’s ashamed of any of it, but because he’s equally proud of all his accomplishments and is comfortable accepting kudos for any of them.

Posted in dating, fanfic, jokes | Leave a comment

Secure, But Not Encrypted

I’ve been going to the doctor a lot lately (knee problem, boring story), and I had to sign a consent-to-being-emailed form. On this form, which I regrettably forgot to nab a copy of to post here, it was explained to me, the patient, that the practice’s use of email is “secure, but not encrypted.” They labored to assure me that their computers are protected by passwords, but that no content is going to be encrypted.

I, of course, am a software developer and understand what this means: namely, that the information is not secure. Further, I’m not even sure what they’re trying to reassure me about, understanding what I do about computers and security. I’m safe against the other doctors in the practice learning my medical history? Or perhaps the assistants and administrative employees? Those people almost certainly could get access if they wanted it, and I don’t care, because it is their job to know enough to help me.

Sending information unencrypted over email is just letting anyone have it. Sending it through an encrypted protocol is giving it away only to the practice’s email provider, the receiver’s email provider, and (obviously) the NSA. Since you’re a doctor’s office, I have no reason to believe you have spent a single minute thinking about your technological infrastructure, and thus no reason to trust your email provider. I use gmail, and I have good reason not to trust Google. So you’re sending my medical information to at least two parties I don’t trust.

I don’t care about this at all. My perspective on security is that all security is security theatre and if someone wants to break into my house or my email or anything else badly enough, they will succeed. But I know this. I don’t care because I am (somewhat) informed. I know that assuming my data is secure is simply incorrect, so I assume that the entire world can see it instead, and make choices accordingly.

I do, however, care pretty deeply that to an uninformed reader of that consent form, who understands the everyday meaning of the word “secure” and has more or less zero understanding of encryption, or email transport, or anything else related to computer security, it sounds like the practice is taking meaningful precautions. I don’t know if it would stand up in court — I believe there are laws saying that when one party is drastically misleading the other party who is direly uninformed on the material, that isn’t valid — but it still pisses me off. I don’t even think the practice knows they’re misleading their patients. They probably don’t know anything about computer security either. But it’s just all so wrong and sad.

Posted in pedantry, security, software | 1 Comment