Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • Poor Support Experience

    Poor Support Experience

    I broke my watch. I have an Apple Watch with the Sapphire glass screen, and I broke the glass.

    For reasons that are frustrating, I don’t have AppleCare+. The short version is that I didn’t realize I didn’t have AppleCare until September. The Watch was a present in May (June). I was deemed ineligible, which is annoying, but I appealed and pointed out I couldn’t know I didn’t have it until it was way too late. But I was declined. I didn’t have a receipt, I didn’t have proof, they couldn’t believe me. Fine. I acutally understand that and, were it me, I’d probably reject the claim as well. That meant I knew I was going to have to shell out if I ever needed a repair for a crack. And February 2016 was that time. I took it to the Apple Store and had one of the shittier repair experience of my life.

    I did not schedule an appointment since they had nothing until Monday anyway, and I knew this would be a “We can’t fix it, we’ll send it in.” sort of thing. I got there and was told that they don’t have a walk-in repair for the Apple Watch like that. They do for the iPhone, and the iPad, but not the Watch. Okay. Stupid. Fine. I set a Walk In appointment for an hour away, and went to run an errand. When I got back, the appointed time came and went. So I asked a nice person in an Apple Shirt how that worked.

    This was the first rude person I’ve ever dealt with an an Apple store. I wish I’d gotten his name. He was condescending, brusque, and unsympathetic. He said I should have known that the time was an estimate (sure, I did) and that it could be up to another 90 minutes. I stared at him. How the hell should I have known that? I asked if there was a different line for repairs, he said not and then chided me for not making an appointment. Sorry, make an appointment for four days out when I broke something today that will need to be mailed to a repair center? I did not say that, I looked at him and said “I see. So when you said ‘Around 1:55’ what you meant was ‘Between 1:55 and 3:30’? The guy who checked me in didn’t say that.” He shrugged and I walked off.

    It took another 45 minutes to get to check in. Once I did, they just said ‘Sit at any open stool.’ This is poorly planned, but okay. I sat and after a few minutes, a fellow asked for my name. He tapped on his iPad, found my appointment, looked at the words on it, looked at my watch, and promptly apologized.

    “I’m sorry you had to wait so long for what’s about to be a really fast case.”

    I’d already taken the watchband off and nodded. I knew it had to be mailed in. They can’t replace a screen at the store. He filled in a form, the AppleCare+ conversation was had, and we left being told a link would be sent to me.

    No. Actually I got a receipt for the work order (fine) and no link. I logged into my Apple ID account at https://supportprofile.apple.com/ and was surprised to see my Apple Watch not listed. I added it and went to the ‘repairs’ link (which said I had 1 repair) only to have this:

    Apple could not locate any repairs for the Apple ID: [Me]. Please try again with a different Apple ID or look up a single repair on this page.

    Since the work order had the Repair ID, I put that in and the serial and got a pretty useless status page:

    Screenshot of my apple repair status which only says 'service requested'

    Step 1 | Request – February 10, 2016 : Service requested

    That’s it. Step 2 is Service and Step 3 is Return, but there’s no information like an estimated date or even verification it was sent out. At the store I was quoted 3 to 5 days. Now here’s the thing. I know what’s going to happen. They will get my watch, go “Oh, it’s broken, look at that!” and send me a refurb. I will not get my watch back, I’ll get a new one (a new used one) and it sucks, but there it is. I accept this. It’s a watch. Then they will send that watch back to the store and I will pick it up. And I was told 3-5 days (I asked ‘business?’ since it was about to be a long weekend, and the fellow said they were working Monday), and that I would get notified of status changes.

    But after a few days of nothing, I called Apple and asked two things:

    1. Why doesn’t it show up on my open cases for my Apple ID?
    2. What actually is the status?

    The guy on the phone and the woman at the store were helpful, if disappointing. The Watch had not been shipped out right away. The Dispatch Center did not have it. The store claimed to have sent it and received a sign off, though the shipping folks said that was not the case and status on that repair page still said ‘Service requested.’

    The phone tech said to call back in two business days days if I didn’t get any emails or any information, and he added the case to my account. No not the repair, the case. And the direct link to the repair works, but it’s still not associated with my account. I did what any neurotic would do, and I left the page open, hitting refresh once in a while.

    Three hours later the status zoomed to step 3: Returned.

    February 13, 2016 : Product replacement pending

    So why do I call this a bad service experience?

    It should have been much shorter. Apple could have a simple hardware check. Is it really broken? Yes it is, we’ll send it to repair. And this would be for things that are sent in only. If you want to try and trade it in for a fixed one then and there, it’s separate. But if you just want to express mail in your broken whatsit, why not make this easier? The front gate person can ask two questions: Is it really broken? Do you want to send it in for repair/replacement or trade it in today?

    I also never once got a single email from Apple about this.

    Well that’s not true. I got the first email but that was it. I never got a single status report, like they swore I would. I have root access to my server, I run my own email server, and I checked for every single email with ‘apple.com’ in it for the last 7 days. I found one from bounces@email.apple.com and none from GR_R###@APPLE.COM (I’ve removed the identifying numbers). I checked and yes, they were sending to the right email. The one email I did get was from donotreply@apple.com.

    But. Why were none of these emails recorded in my profile or my repair ticket? Why did I never get the promised texts? Why was there no communication? Why, when I contacted Apple, did they actually say their ticket system still said the device was ‘submitted’ and nothing more? They had to contact other teams to find the information which I was never able to see in my profile.

    As much as I deride my ticket system at the office, the fact that every email is logged twice (once as email and once in the ticket) means I can always go back and see exactly what was sent, by whom, and when. Clearly they have multiple systems, and none talk to each other.

    I did get my Watch back. On day 5. I could have had it back on day 2 if they’d learned how to properly communicate.

    And guess what? The new watch was broken. It wouldn’t vibrate.

  • Baby Steps Security

    Baby Steps Security

    It’s a simple question. How do I make my site login secure?

    My answer is simple. Use https for your admin dashboard and use a strong password.

    Your username is not a secret

    My gmail user ID is ipstenu@gmail.com

    My WordPress.org username is Ipstenu. So is my Twitter handle. Facebook? Yep. GooglePlus even.

    And my username here on this site is Ipstenu.

    I hear a lot of people telling folks that their username on their WordPress blog should be a secret and, for the life of me, I can’t understand the logic. Your username is not a secret. It never really has been. It never will be. We used to log in everywhere with our emails, then it became our commonly used nicknames, and based on Twitter and Peach and whatever social network comes next, that’s where it’s going to remain.

    But… Admin?

    But why do people tell you not to use ‘admin’ as your username, then? Well it’s the same reason you have a top lock and a knob lock on your door. The knob lock is your username. Everyone has one, and they have roughly the same level of protection. If you only use a knob lock and don’t have a good top lock, the brute force of someone kicking your door in is pretty easy.

    The top lock, the bolt and chain, that’s your complex password. Not everyone uses them. You should, but some of us are lazy. When we do use them, we make our lives more secure and safe.

    Back to admin as a username. Using admin is like using the same key for all the doors in an entire apartment building. If you’re the apartment owner, that sounds great. But if you’re the resident, you’re probably not super happy about that idea, right?

    Changing your username to something unique to you makes your lock safer. Reusing it means you have the same master lock for all your accounts. It’s better for you, you can remember it, and it’s sneakily helpful for your branding. Yeah, I slipped SEO in there.

    But your passwords are a different matter. You don’t want to reuse your passwords for a simple reason: If you do reuse your passwords, then once someone gets one password, they can get access to all your accounts.

    All. Your. Accounts.

    Your bank account.

    Two Factors

    A lot of this is mitigated by something called Two Factor Authentication, which gives you the ability to have a username (publicly known), a password (private and secret), and a one-time-use password (generated by an app and only good for 60 seconds or so). Now you have three locks! One of which you don’t even know how to open until you’re actually opening it.

    The current issue with Two Factor Authentication is its usability. It can be confusing to people to set up. You need a smart phone, which are not universal quite yet, and you need to be able to take a picture of your screen for most of them. Even once you have it set up, you need to read and enter a code.

    I’ve found mixed information regarding how well this works, or doesn’t, for people who are visually impaired. For the most part, I suspect these tools are only barely accessible. They’re probably a nightmare for the blind to use. If you have to rely on getting a text message to log in, then you’re absolutely fucked if you’re overseas or out of range or have no bars.

    And then there’s the issue I see faced by everyone, and that would be what happens when you lock yourself out. If you [get locked out of Apple](George’s link), it’s a headache but survivable. But if you get locked out of your own site, what do you do? Who do you call? Your webhost? Why? It’s not their responsibility to unlock you. And don’t ask WordPress.org to unlock you.

    No, you have to know how to do ‘something’ to fix this. Be it disable a plugin without being logged in, or be it editing a file, you will need access to your system and some technical chops to pull this off. And no, folks, the majority of WordPress users don’t have it.

    Security in Steps

    We cannot all become secure tomorrow without possibly alienating the user base. WordPress has a 26% market share these days, and that’s a non-insignificant number of people. For them, we absolutely must consider the cradle to grave usability of our products. How useful are they? How safe are they? How easily can someone untangle their site?

    Two Factor is one of the ways to go, but it’s only one possible future. It has a higher hurdle than many people understand. Even Google has a less than 10% adoption rate for 2FA. Facebook probably has less, and if I was asked which user base most matches the skill level of the average Wordpress user, it would be Facebook.

    WordPress faces a hurdle of its own creation. It’s too popular with too many people of questionable technical ability to just switch on two factor authentication and force it for everyone. Much like multisite, it requires an understanding of some technical aspects of the web, not WordPress, to use safely.

    Or as my friend Jan puts it: You must be this tall to ride.

  • Apple Does the Right Thing

    Apple Does the Right Thing

    People died. While we can easily get lost in the implications of preventing deaths and understanding why a mass killing happened, there is one fact we’re left with.

    The FBI have asked Apple to write a backdoor into the iPhone code to allow the FBI to brute-force entry into an iPhone.

    What is Brute Force?

    Quite simply, it means trying passwords over and over again, until the right one is determined. At its heart, it’s trial and error, and you can program it into another computer. We call it brute force because rather than trying to intellectually deduce a password, it’s done via direct effort.

    Why does this involve Apple?

    You can set your iPhone to, after 10 incorrect passwords, wipe itself out. After three (3) wrong passwords, the iPhone makes you wait a little. I’ve set my phone to wipe on 10 incorrect passwords since if someone has my phone and can get in, they can also get access to my banking information.

    With a 4-digit passcode, there are 10,000 possible permutations. With 6, this increases to 1,000,000.

    The Ten most common passcodes have probably been already tried. And if you want a fun read, check out Why repeating a digit may improve security on your iPhone’s 4-digit lockscreen PIN.

    What did the FBI actually ask?

    I have read a copy of the summary (this is not the full 40 page ruling) and many of the news articles. The best I can summarize is this:

    Tuesday February 16th, 2016, a magistrate judge in Riverside, California ruled that apple had to provide “reasonable technical assistance” to the government to recover data from an iPhone 5c. This includes bypassing the auto-erase function (the one that happens after 10 bad passwords) and allowing them to submit an unlimited number of passwords. In order to do this, the FBI wants a special version of iOS that only works on the one iPhone.

    Apple has five days to respond if they believe that compliance would be “unreasonably burdensome.”

    Yes, it says that the FBI is asking to break into one iPhone, but the only way to do that is to write a system that could be used to backdoor any iPhone. This is because Apple intentionally wrote their code so that they couldn’t get at your data. Apple has no way to dismantle or override the 10-tries-and-wipe feature. Only someone with the passcode can do it.

    Is that technically possible?

    Of course. There’s no real question about that. It won’t be easy (so ‘unreasonably burdensome’ may or may not apply here). And to be honest, the technical possibility of this is not the issue either.

    Does this mean ‘anyone’ could do this? Yes, but it’s unlikely. This sort of hack is an OS-level one, which means the software needs to be signed by a key only Apple knows, unless there’s some other vulnerability in the phone. You can introduce a vulnerability by jailbreaking the phone, of course, but for the most part we don’t know if you can hack it from the outside like that. Signs point to this not being probable. But if it was going to happen, Apple would be the best company to try. They’re the ones who would know best.

    I want to stress: I believe anything is technologically possible. Human cloning? You bet! Hacking my iPhone? Sure thing. I do not believe these things are easy, or even probable, but they are in the realm of possibility.

    Why did Apple Say No?

    Apple did say no. They said it publicly in a Customer Letter on their website. And they said no, not because these things are hard, but because they are dangerous.

    Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.

    […]

    Rather than asking for legislative action through Congress, the FBI is proposing an unprecedented use of the All Writs Act of 1789 to justify an expansion of its authority.

    The government would have us remove security features and add new capabilities to the operating system, allowing a passcode to be input electronically. This would make it easier to unlock an iPhone by “brute force,” trying thousands or millions of combinations with the speed of a modern computer.

    The implications of the government’s demands are chilling. If the government can use the All Writs Act to make it easier to unlock your iPhone, it would have the power to reach into anyone’s device to capture their data. The government could extend this breach of privacy and demand that Apple build surveillance software to intercept your messages, access your health records or financial data, track your location, or even access your phone’s microphone or camera without your knowledge.

    You can read the whole thing for yourself, but in essence Apple is saying that by allowing the FBI to insist on this, they can use it as leverage to demand anyone’s phone be unlocked similarly. Keep in mind, while this case is certainly above board, do we really trust our government to always have our best interests in their hearts? Where can we draw a line between a known criminal act and a suspected one? Do you think they will never apply this to a case with tenuous links to an actual crime? We’ve already had wiretapping issues (Watergate, need I say more), and frankly the US government hasn’t gotten much better. And once the US has managed to allow this, many other countries will use this as their reasons to do so.

    Also you can’t uncork the lamp. Once the genie is out and this is possible, it will be given out to other agencies and someone will reverse engineer how this works. Other countries will get their hands on this. They will use it against innocents. We know this is truth because it already happens now.

    Privacy and Freedom

    I’m going to give you the quote you’re expecting. The Ben Franklin one:

    Those who surrender freedom for security will not have, nor do they deserve, either one.

    From a technical aspect, the hurdles faced to hack into a cell phone make me feel safer as a user. It makes me feel better to know that the FBI are failing to break into my little iPhone.

  • Mailbag: No More Contact

    Mailbag: No More Contact

    On Monday the 8th I deleted my contact form from this site and my personal one.

    That means this may be the end of the mailbag.

    Why did it happen? Well, looking back on the last 7 months of messages I got, I can group them as follows:

    • Requests that were meant for plugins@wordpress.org
    • Password reset requests for the forums
    • Requests to delete forum posts (we don’t do that by the way)
    • Requests to be hired (even though the page said no)
    • Solicitations to write for people for ‘exposure’
    • Questions people should have asked in the forums
    • A ‘quick’ question that’s an essay
    • Complains that I suck
    • Complaints that I blocked someone on Twitter/Facebook
    • Spam

    The legitimate messages that were interesting and thought provoking were few and far between. If I got 4 a month, then it was less than 10% of what my inbox was seeing. And worse, blocking someone via the comment blacklist didn’t stop them from submitting a contact.

    After someone informed me, via the contact form, that a post I commented on in the WordPress forums over a year ago was out of date, I said enough was enough, and removed it.

    How do you contact me?

    Why do you need to?

    Look, my family and close friends already have my email. Anyone from WordPress who absolutely has to get a hold of me knows how to (they can view my email in my forum profile after all). And the random masses of humanity who just want to ask me something for a quick fix?

    You really don’t need to contact me. At all. You just want to because you think it’s faster and cheaper. I value my time more than that these days. I simply cannot spend my time helping everyone. Not with everything else on my plate for WordPress and for work and for life.

    Of course if you post in the plugin forums for my plugins I’ll help (maybe not as fast as people might like, but hey, you’re getting free help). Of course if it’s work related I’ll be there.

    But I’m not for hire. I’m not here for a ‘quick’ email (which by the way, most of you send me essays). And I’m definitely not here for your abuse.

  • What’s In a Plugin Name

    What’s In a Plugin Name

    Not terribly long ago, we stopped letting people use someone else’s trademark or company/plugin name as the first term in their submitted plugin.

    Example:

    “Girl Scout Cookie Tracker by Mika” would no longer be accepted.

    However “Mika’s Girl Scout Cookie Tracker” would be just fine.

    The point we try to make here is that your name, your product name, should be first.

    Of course, that second name is pretty poor, and I’d be more inclined to name it “Cookie Order Hunter” with the description of “Hunting down Girl Scouts to buy your next hit of Thin Mints has never been easier!” Yes, I know you can buy them online, not the issue here.

    This new name is sort of neat. It’s got a kick to it and it has a distinct name. Suddenly I have a sort of branding all my own and this is good! I am now unique and I will stand apart from the other similar plugins.

    Of course there are times when you don’t want to do this. I wrote a plugin called “EDD – Prevent EU Checkout” and I submitted it as “EDD Prevent EU Checkout” because it was a “Prevent EU Checkout” plugin only for Easy Digital Downloads. If I was doing my normal thing, where I pick a fun name, then I would have used the dev name: “EDD – Sucks to be EU.”

    Here, though, I started the plugin with EDD – a search term often used – and ended with a description of what the plugin was. The fact that I keep the name as I do just means I haven’t finished the new version. I will soon be rebranding it to “Prevent EU Checkout with Easy Digital Downloads” because that’s a better SEO friendly name.

    But here I’ve pointed out two things. The display name and the submission name are two different things for a reason. The display name is what people see, and the submission name is what sets your URL in the repository. Had I used “Prevent EU Checkout with Easy Digital Downloads” then my URL would be https://wordpress.org/plugins/prevent-eu-checkout-with-easy-digital-downloads and that’s not a friendly URL to anyone.

    Submit a plugin with the ‘name’ you want for your URL.

    Let’s take an example just for fun. Commoji – A plugin that lets you reply to comments with emoji reactions. No it’s not real. Yet. I would submit this as ‘commoji’ (all lowercase) and in the description I would put only the short description, leaving the readme to be read on it’s own. Remember: The readme is vital, so every pertinent piece of information that a user should have must be in that readme.

    Within my plugin code, and that readme, the plugin’s display name would be “Commoji – Reply to comments with Emoji” (and if I’m feeling puckish, I’d add ? at the end).

    Now I have my cake and Edith too! A short plugin slug, a descriptive plugin name, and a unique name that people will remember. I’m not stomping on Emoji’s trademark, such as it is, and I’m demonstrating my own individuality.

  • Chickens, Eggs, and MVP

    Chickens, Eggs, and MVP

    There’s a lot of weight to shoulder for the WordPress REST API project. It has a lot of hurdles to overcome and a lot of doubters to win over.

    I’ve been silent about it, thoughtful about it, and questioning about it. I personally want the REST API if, for no other reason, than once it’s in-core, we can set the XMLRPC on fire. Which means…

    My MVP – Parity with XMLRPC

    That’s right. If the REST API can do everything that XMLRPC can do today, I think that part of its code needs to be in Core today. Get it in. Get people using it. I don’t think the measurements of how many plugins are using the REST API are a valid argument, since you get these numbers (roughly):

    • 115 plugins use XMLRPC
    • 25 plugins use V1 of the REST API
    • 21 plugins use V2 of the REST API

    Now, this is not the right measurement because looking at both XMLRPC and the REST API, we are not clocking the number of plugins but the number of sites – non WordPress sites even – that are calling these features. And that is a number that cannot be measured. There’s no way on the planet to really know for sure how many people use those features because, for the most part, they’re not doing it within WordPress. All the plugin scans will tell you is people who are extending it, for the most part. WooCommerce, Advanced Custom Fields, those are plugins adding their own endpoints and hooks.

    And those, yes, are important. But more so is the real-world.

    Can we detect how many WordPress sites are using the JSON API? Not really. Sure we could probably violate trust and get a list of every site that’s asked for an upload or install of the plugin, that wouldn’t tell us who has it active and who is using it.

    We’re Not Ready (Until We Leave Beta)

    We’re not wrong to be cautious about this. There’s a freedom a plugin has that a core feature does not. Once the REST API is in core, it’s done. I don’t mean development or innovation stops, I mean we can no longer make breaking changes.

    While we believe the API is now stable enough for public testing, we may continue to break the API in the future as we improve it further. Only use the API in development, and do not use version 2 in production environments.

    That’s what the documentation for Beta 1 says. And when I look at the changelog for 2.0 Beta 12.0 (released February 9, 2016) I count six changes labeled ‘breaking change.’ That’s bad. I hesitate at saying it’s deplorable, as I understand why it’s happening. They’re iterating fast and hard and trying to get to a place where they’re ready.

    That said, this is a real world problem, as Eric Mann expressed in a series of Tweets:

    My client installed the REST API before it included post meta. We had to build a bunch of custom work to support meta.
    Then the REST API updated to include meta and broke our integration. I spent a chunk of hours refactoring to compensate so we could update.
    Now, apparently, the REST API is pulling that meta support out and putting it in a separate plugin …
    Yet people still criticize me for saying I’m wary of placing too much dependency on the stability of the API …

    Eric’s point is a good and valid one, and it actually supports both ends of the argument.

    The REST API is too much right now. It’s too much of all the things, and pulling meta out and letting it iterate quickly is a good choice. That said, the rest of the API needs to consider the same things. What’s done? What’s ready and locked and will not be ‘breaking’ changes? That should be ‘stable release ’ and that goes into core.

    From that moment on what’s in core cannot not receive any breaking changes. Lock down: These are done and will not be broken. Give the developers your promise in blood that this is what it is.

    WordPress is backwards compatible for a million miles and frankly the REST API has not been. So make it. Put it in stone. But the REST API plugin itself is really too big to continue developing as it has been, and that’s to it’s detriment. It’s simply not sustainable the way it has been because it’s trying to serve two masters.

    On the one hand, it wants to grow rapidly. On the other, it wants to be secure and safe and solid and ready for code.

    But right now we’re stuck in Beta, and that hurts the perception. Also we’re still breaking things, and that hurts adoption. No one wants to start using a beta product that changes things in a way that breaks their sites. No one wants to use this for clients yet.

    I Propose a “Release Candidate”

    Go back to my first point.

    Parity with XMLRPC. That’s all the REST API core plugin should be right now. Pull out everything else and slap the designation “Release Candidate” on there. You do not break things in Release Candidates. This candidate is your candidate for core inclusion. When it’s good, that goes into core and we close the existing plugin. Of course we do one final update to notify people ‘Hey, this is included in core now! Woohoo!’ It’s called ‘disabling’ the plugin, and anyone who has a feature plugin thats been moved into core, if you want it disabled, contact the plugins team. We will be happy to retire you plugin.

    What about everything else? They get punted out into their own mini plugins. Like meta, they can be iterated and they can break all they want until they hit Release Candidate.

    You see, that Release Candidate is your promise that you believe you are ready to go. Everything works the way you want it to, everything is ready for real-world testing. No more breaking changes.

    In Hindsight

    Looking back, I think the REST API is a perfect example of why the Featured Plugin system is both perfect and problematic. We are trying to simultaneously treat development like a plugin (fast, light, and iterative) and like core (adaptive, backwards compatible, and reliable). The whole reasons we started breaking out things like MP6 into Feature Plugins has come home to roost and shown that the idea is solid, but the methodology needs to be more set in stone as to what they should and should not do.

    For a Featured Plugin, Beta is the time for breaking. RC is the time for testing in the real world. We need to be more firm about what we will include in our Featured Plugins and what we will not. We need to be harder on adding new features. We need to say ‘No’ a little more, and let things be developed outside of the plugin.

    We need a plan that includes the retirement of the plugin when it’s job is done.