Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: oped

  • Trust No One

    Trust No One

    A constant refrain for my security reviews of plugins and themes is to sanitize everything. And sometimes my pedantic nature of sanitizing everything leads people to ask me why I don’t trust users.

    The short answer is “Because I am one.”

    The longer answer is that I believe in three types of users, and I’m aware of their character flaws.

    Users

    Most people on the internet fall into this category. They know how to log in and check email and read a blog post. Maybe they leave comments, maybe not. These people are the most basic of them all, but that isn’t a bad thing at all. Users do what they want and don’t often think about the consequences, because for them there really are none except saying things they didn’t mean or wanting a comment deleted.

    These users are dangerous because they don’t think about what they’re doing. They trust, blindly sometimes, that the websites they visit won’t hurt them. That means that data they input has to be sanitized and validated because they may not realize what they’re doing. They may put a URL in the email field of your comment form, and they should be warned about those things.

    You can’t trust the users because they don’t know any better.

    Experienced Users

    This is actually not the most dangerous category. You might think they would be, because they know enough to be dangerous. Instead, I’ve found these users know enough to be cautious. They know what they don’t know, and they’re careful about what they’re doing. They check six or eight times before they paste in data, and they read error messages. Oh yes, these people. You know them, don’t you? They send screenshots of errors a test out theories before telling you “This is broken.”

    We like those people, though you may be wondering what about the experienced users who don’t do the legwork. To me, they’re users. There’s nothing wrong with being a user, but it changes my expectations on what they do and who they are. If someone is experienced, though, they’re going to play with things and that means they might break things when they try to recreate the problems.

    You can’t trust the experienced users because they mean well.

    Admin Users

    These are the users who terrify me the most, and sadly, this is where most WordPress users actually are. Because if you’ve installed your own version of WordPress, you are an admin user. God save your soul. And here’s why they scare me: they have more power the an the experience user but the skill of a user. They’re kind of like toddlers.

    This is not meant as an insult. The problem is that, unchecked, they can destroy their own sites. They copy and paste code or content into the post editor. In fact, that’s the biggest problem. Many years ago, my friend John and I spent five days debugging a crash, all because we didn’t know that no one who knew what they were doing would ever enter that data format into a field, and since we were admins, the check was overridden.

    You can’t trust the admin users because they have phenomenal cosmic powers.

    Trust No One

    Not to sound all Fox Mulder on you, trust no one’s data. Especially not your own. Don’t assume you know what you’re doing, that you never typo, that you’re always right. You’re not. No one is. And we don’t trust data because we could be wrong. It’s just that simple.

  • You Are Not Psychic

    You Are Not Psychic

    The other day I hear someone mention that they were securing software that they didn’t even have the words for 5 years ago. That reminded me of how fast technology moves. Things that didn’t exist last year are vulnerable today, and the discovery of those things only happens faster as we invent weirder and weirder ways of reinventing the wheel.

    The Myth of Perfection

    A well known saying is that the perfect is the enemy of the good. We take that to mean that if we wait until a thing is perfect, we will never feel it is done enough and ready enough for the world. In Open Source technology we’re fond of releasing and iterating, accepting the lack of perfection and aiming instead for the minimum. What is ‘good enough’ to let people use our work and improve on it?

    Perfection doesn’t exist. There is nothing on the planet that is perfect and there never will be. But accepting this doesn’t mean we allow imperfection and danger into our lives.

    The Balance of Reality

    Everyone screws up code, no matter how awesome a professional you are. Accept it 🙂

    I said that nearly three years ago, and I’ve argued before that it’s okay to screw up. I really do believe that making mistakes isn’t a bad thing. But at the same time, many people understood that to mean I was alright with shipping code that I knew was bad. This is not at all the case.

    If you know your code is bad or insecure, you fix it. Period. You don’t let things you know are bad out the door. But you do release things that work and perhaps lack all the features you want. There’s a difference between releasing bad code and releasing imperfect code.

    The Attack of Security

    To turn this on its ear a little, if someone comes up to you and says “This code is wrong, you should do this other thing.” then you have a choice. You can listen and believe them and study if they’re right and test it and fix it, or you can ignore it.

    When someone you respect tells you those things, you’re inclined to believe them. But at the same time, your heart takes a hit because “this code is wrong” sounds a lot like “this code is bad.” And that sounds like “you wrote bad code” and that feels like “you’re a bad coder.”

    That slope slipped right down, didn’t it? It’s a reality. It’s in our nature to take admonishments of our work as a personal attack, even if they are rarely meant that way. I can count on my hands the number of times I’ve actually told someone they were a bad coder. I can count on one hand the number of times I’ve told someone who wasn’t me that they’re a bad coder. I’ve certainly said it to myself a lot. I believe I’ve told one person directly that I thought they were a bad coder.

    I don’t think they actually understood what I meant… Which says something.

    The Shield of Arrogance

    We are not psychic. If you are, please let me know who to bet on for the World Series. Being humans, and therefore fallible, we cannot be so arrogant as to presume we know all the possible ways our code might be vulnerable. Technology moves so fast that what looks safe today may turn out to be terrible dangerous tomorrow.

    Knowing this, knowing we are imperfect, we know that our fellow humans are also imperfect. The greatest danger to our security is ourselves. And that means, as developer writing code to be used by others, it’s incumbent upon ourselves to protect our fellow humans from innocent mistakes.

    You are not psychic

    You don’t know what will be insecure next. You can’t. So secure your code as best you can and secure it better if people point out your shortcomings. Learn. Improve. Protect.

  • A Day Without Me

    A Day Without Me

    For the first time in over three years, there will not be a post about tech or tech adjacent items today.

    Today, March 8, 2017, is International Women’s Day. And today I do no work.

    Read more about A Day Without a Woman.

  • A Day Without Women

    A Day Without Women

    I am writing to inform you that I will not be working on March 8th.

    The Women’s March organized this day in the same spirit of love and liberation that inspired the march on January 21, 2017. Today, A Day Without A Woman, is a recognition of the value that women of all backgrounds add to our socio-economic system. It is to raise awareness and remind us all of the pervasive and systemic gender-based inequalities that still exist within our society, from the wage gap, to vulnerability to discrimination, sexual harassment, and job insecurity.

    I am one woman. On any given weekday, I read a thousand lines of code. I review between 30 and 60 plugins. I write at least 2,000 words on WordPress.

    But not March 8th.

    On that day, I will review no plugins.

    On that day, I will answer no questions in the forums.

    On that day, I will not work on WordPress.

    I’m one person, and I do shy away from the political on this blog, but now, this year, this time is different.

    I understand if you can’t, we can’t all afford to do this, we can’t all risk this. But I can. And I will. Because I am one person, but my family taught me to care about everyone, not just myself. I am one person, but together we are a nation. I am one person, but I am not alone.

    So on March 8th, there will be no WordPress for me.

    I hope you will stand in support of me, and any of my friends and colleagues. I hope that everyone will give women workers today off without retribution. I hope you will all stand with me and others.

    I know this is a big ask, and I know a lot of you can’t. I understand that, I respect that, and I support that. We need to eat.

    I am dedicated to my work. I am dedicated to WordPress and DreamHost. I respect them, the work we do, and their values. And I am grateful my company does support me when I chose to do these things. I am lucky and thankful and grateful I won’t be fired for taking this day off.

    At an increasingly insecure time for the rights of women and other minority groups, it is important to me that I also stand for the value of equality.

    I hope you, the people who read this, will support me in my decision. I hope you will join me if you can.

  • REST API – Democratizing Reading

    REST API – Democratizing Reading

    Democratize Publishing.

    We say that a lot in WordPress. We boldly state that the goal of WordPress is to democratize publishing through Open Source, GPL software.

    I’d like to turn that on it’s ear for a moment.

    The purpose of the REST API is to democratize reading.

    Democratize Discovery

    One of the myths of websites is that if you build it, people will come. If that was true, we’d never need plugins like Yoast SEO and we’d never need to self-promote. The reality is that we have to work hard and make our content good. WordPress helps us make it look good, and makes it easier to get it out there, and usually the rest is up to us.

    There’s another aspect to discovery, though, and that is the ease of findability. We already address this in WordPress to a degree with RSS, but as much as I’d love to say that was that, it’s not. It’s 2017. People don’t want RSS, they want email and they want the information on social media immediately.

    And? They want apps on their phones that alert them to new data.

    Democratize Consuming

    Reading data with WordPress is easy. We go to a webpage, we see the data, we consume, we move on. With emails and social media, people usually have to click to come to your site and read. While this is good for your traffic, anytime a person has to click you’re running a risk they might not click. That’s why Tweetstorms are more consumable than blog posts. While they are far more transient, they’re accessible in an immediate way.

    Making the consuming of data more direct, a more one-to-one relationship, improves the chances that someone will actually read the information. Much of this can be achieved with a good lede, but readers are well to aware of click-bait today. “She tried this blogging software. You won’t believe what happened next!”

    Right. You get the point. In order to get people to read, you have to make it easier for them to read. Converting WordPress posts to something an app can read needs to be easier for the blogger, or they won’t be able to have success.

    Democratize Reading

    The REST API does just that.

    It makes the discovery and consumption of your website easier by simplifying your output.

    When you look at a website you see the design and the layout and the wonderful beauty. When an app reads your data, however, it doesn’t want or need any of that. An app needs the raw data. And the REST API does that. It outputs the data in a super basic and simple way. Furthermore, it lets you add on to this and output specific data in special ways.

    Democratize Publishing

    You can publish your data in multiple ways. Today, we all know about the blogging aspect of WordPress. But here are some other ways you could share your data:

    • Allow users to download a CSV with all the products on your site and their costs
    • Create a plugin that calls custom data, allowing others to have a widget with the data
    • Power a mobile app without loading your theme

    Could you do all that without the REST API? Of course.

    Does the REST API make it easier and thus help you democratize faster? Yes. It does.

    The REST API can change your life, if you’d only let it.

  • A Case for REST API

    A Case for REST API

    WordPress 4.7.1 and 4.7 were vulnerable via the REST API. Any unauthenticated user could modify the content of any post or page on a site. Since the release of the information, a surprisingly large number of users failed to update to 4.7.2 and, thus, were hacked.

    I say surprisingly because WordPress enabled automatic updates quite a while ago (WordPress 3.7), which will automatically secure your WordPress install. There have been 18 automated releases since then (which is why we have 3.7.18) and the vast majority have addressed security in one way, shape, or form.

    But this post isn’t about the reasons why someone might need to disable the automatic updates. No, this is about the argument I saw stem from the vulnerability, whereby people said it was proof the REST API should be disabled by default.

    And to them I say “No.”

    The REST API Probably Has More Vulnerabilities

    Look, I’m not going to lie to you. The odds are high that the REST API, which is a very new feature, probably has some serious issues still. But, as my friend Helen pointed out to those arguing for it to be disabled by default.

    Why should this be treated differently from XML-RPC? Have you gone through the history of the XML-RPC setting?

    While the REST API may introduce new vulnerabilities to WordPress, and even ones that are horrifyingly accessible to non-logged in users, it is not the first nor the last feature WordPress has added that puts a site at risk. The API, being brand new and not used or tested as much as other aspects of WordPress, is going to be dangerous to exist, but realistically not more or less than any other part of WordPress.

    Go through the list of all WordPress security releases. A lot of issues have been fixed. This is just the first one for the REST API.

    In 2008, XML-RPX in pre-2.3.3 systems allowed remote attackers to edit posts of other blog users, if registration was enabled. That’s a long time ago, and since then the majority of the exploits have revolved around DDoS and pingbacks. But yes, back in the day, this new feature was also problematic.

    Do You Trust WordPress?

    Everyone makes mistakes. Every code has bugs. Everything is vulnerable. The question you have to ask is not “Why did WordPress let this happen?” nor “Why did they put me in danger?” but “Did they handle this well?”

    The heart of the matter is not if you trust WordPress not to screw up, but that you trust them to react responsibly, quickly, and with the appropriate concern. Some security issues are massive. Others are not. With over 26% of the internet using WordPress, fixing the security issues quickly and properly is a huge concern.

    So you have to ask “Do I trust WordPress to fix security issues?” And “Do I trust WordPress has my best interests, with regards to security, at heart?”

    I do, but it’s a question of risk.

    Risk = {si, λi, xi}

    My father, a risk analyst, asks three important questions:

    • What can go wrong?
    • How likely is it?
    • What are the consequences?

    Obviously a lot can go wrong. So much, in fact, that it can be impossible to wrap your head around the vastness of the possibilities and subsequent probabilities. Even just listing the things you think might go wrong is incomplete. You know you’re not thinking of everything, so you have to start with the big picture.

    Most of us aren’t capable of calculating the risk and reliability of WordPress. Those Six Sigma experts aren’t either. There’s no way I could actually explain well enough how to determine the risk of using WordPress. If I could, I’d start with asking people “What can go wrong if I disable automatic updates?” and “What can go wrong if I don’t disable automatic updates?”

    The likelihood of the REST API being vulnerable is a little higher than other aspects of WordPress core, but much lower than plugins and themes. The consequences are generally higher than that of plugins and themes, but there’s an extra factor you must consider.

    • How quickly can it be fixed?

    If you leave WordPress auto-updates on, then the answer is “As quickly as humanly possible.” And that, I feel, lowers the overall risk.

    Planned Disclosure

    To those arguing WordPress should have told everyone sooner, this is not the first time WordPress waited a while before announcing a security issue. Take, for example, The Case of the Trojan Emoji. That’s not a Sherlock Holmes mystery, that’s the true case of where WordPress hid a major security fix inside the additions of emoji support.

    There’s a big difference between the Trojan Emoji in 4.2 and the RESTless Backdoor we faced in 4.7, and that is the exploitability. The vulnerability fixed with emojis was hard to do. The one in the API was super easy. In both cases, however, the moment the vulnerability is disclosed, a ticking clock begins to see when people get hacked.

    Sometimes folks tell me I’m hyperbolic or exaggerating when I say ‘attacks will begin within minutes.’ I think that my claim was proven valid, considering how many sites were hacked, and how quickly it happened. Within days of the announcement,

    Remember, security is nuanced. It’s never as simple as “Hey, I found a vulnerability! Patch it!” It requires testing, validation, more testing, and more testing. A good patch doesn’t introduce worse problems (yes, that’s happened before).

    Rarely Used Code Is More Vulnerable

    I bring this guy up every time people argue why WordPress turns on features by default. The WordPress argument is that if they don’t turn it on, people won’t use it. The reason that matters can be found in the works of Herbert Hecht.

    Hecht wrote papers about rare conditions and their effect on software failures. The tl;dr summary for you is this: Rarely used code fails more often.

    Now, Hecht specially was referring to the early days of software use, which the REST API certainly falls under, but the basic philosophy is valid. The less the code is use, the more at risk it is, specifically because it’s used so rarely. People are less familiar with it, they don’t know how to fix it or even test it for all the possibilities, because they don’t yet know what they are.

    Are those reasons to not use the REST API? Not always. You have to consider the risk of using it for yourself. Will your site go down? How bad is that if it happens? Are you doing everything you could to protect yourself?

    Should You Disable The REST API?

    No. Unless you’re certain you’ll never use it, ever, leave it on. It will be fixed, and as long as you apply security patches promptly, you’ll be fine.