Security is Not an Elective

Here’s my slides from my talk at WordCamp NYC!

Security Is Not An Elective

On the FDA and E Cigarettes

DISCLAIMER: While I may enjoy a rare cigar or pipe of tobacco perhaps once or twice per year, I don’t regularly consume tobacco products or nicotine. This post is more my musings on the bureaucracy and workings of the federal government.

Yesterday, the Food and Drug Administration (FDA) expanded its regulation authority to include “Vaporizers, vape pens, hookah pens, electronic cigarettes (e-cigs), and e-pipes are some of the many types of Electronic Nicotine Delivery Systems (ENDS)”.

I have concerns.

According to their press release,

Examples of components and parts of ENDS include, but are not limited to:

  • E-liquids
  • A glass or plastic vial container of e-liquid
  • Cartridges
  • Atomizers
  • Certain batteries
  • Cartomizers and clearomizers
  • Digital display or lights to adjust settings
  • Tank systems
  • Drip tips
  • Flavorings for ENDS
  • Programmable software

So, in short, it’s regulating all of the paraphernalia associated with vaping, and not merely the nicotine itself.

This is concerning to me.

Back in my college days, I used to smoke a (tobacco) pipe and cigars on a weekly basis with other students.  It was a communal event, and I learned to blow smoke rings.  As I’ve grown in the decade since then, I’ve lost the inclination to smoke, and really have no desire for nicotine.  I’ll occasionally smoke a pipe socially with friends once or twice a year, but I do enjoy blowing smoke rings.

As such, I own an electronic cigarette, and I purchased a quart of food-grade USP Propylene Glycol — the base liquid that most suppliers use when making liquid for vaping — and I’ll occasionally use it to blow smoke rings in my office.  No nicotine, no flavorings.

By my understanding, the FDA’s regulation of E-liquids has no limitation to “We only regulate E-liquids that contain nicotine” — in fact, they even state explicitly that:

If the tobacco product manufacturer submits a self-certification statement to FDA that the newly-regulated tobacco product does not contain nicotine (and that the manufacturer has data to support this assertion), then an alternate statement must be used on product packages and advertisements:

“This product is made from tobacco.”

Keep in mind that they are also broadly defining “Tobacco Product” to include all ENDS including all E-liquids and cartridges, atomizers, and even certain batteries. They must be labeled (falsely) that it is made from tobacco?

This feels like a significant overreach.

It strikes me that a similar regulatory effect could be accomplished, simply by exclusively regulating exclusively substances that contain nicotine. What is gained by having the Food and Drug Administration regulating the batteries that power vaporizers? Regulate the nicotine. If someone’s selling electronic cigarettes that come preloaded with nicotine? Sure, regulate that.  But leave the rest alone.

Two Weddings, One Family

I attended two weddings in the family this past weekend.  Two cousins, both on my mom’s side, tied the knot.

Saturday was a beautiful outdoor wedding at a farm in the countryside.  It was about a four hour drive away, which made it into a bit of an interesting day trip, but mostly uneventful.

Road trip time! 4 hours (each way) with two wee ones…no problem, right? 😳 #roadtrip #wedding #kids #halp

A photo posted by Katherine Stephanis (@katherinestephanis) on

Sunday was a much easier affair to make it to.  A scant fourteen minute drive from our house, a “come as you are” ceremony.  Much easier to pull off with a seven month and three year old in tow.

And yet some members of the family chose not to attend.

Some members of the family who just drove eight hours round trip to attend another cousin’s wedding didn’t attend.

Why?

It was a gay (or, more specifically, lesbian) wedding.

❤️❤️❤️ #emandaud

A photo posted by »«erin»« (@xtristatex) on

And it ranks up there in one of the most charming weddings I’ve ever attended.  The schedule on the program was titled “The Gay Agenda,” and they made jokes about “If this isn’t your first gay wedding, please keep the Bernie chatter to a minimum,” “Now that you’re all attending a gay wedding, congratulations, you’re all gay too,” and even “By the authority vested in me by Obergefell v. Hodges

My mind is just utterly blown at trying to comprehend the mindset that feels it’s more important to not attend a non-religious marriage ceremony.  If you’re Catholic, would you also refuse to attend the wedding of a cousin who was previously divorced and is now getting remarried?  Or do you only attend religious wedding ceremonies presided over by your own church?

I mean — what’s the thinking behind this? “If only I don’t attend their wedding, they’ll recognize the error of their ways, and abandon their sinful plan to marry the person that they want to spend the rest of their lives with?”

(btw, I’m pretty sure the bible doesn’t say anything about gay marriage, all the verses deal with the consummation, and I’m pretty dang sure you’re not invited to that part)

In the end, if I’m going to screw up in this life, I want it to be for loving and accepting people, not making them feel unwelcome or judged.  That’s my Pascal’s Wager. And that’s what I believe the message of the gospel is. The message of the Christ who dined with prostitutes.

Don’t approve of gay marriage?  That’s cool, don’t get gay married. 👍

But to not attend feels spiteful and unkind and wrong.

And I’m left feeling disappointed.

On Anti-Transgender Bathroom Bills

I’ve found myself now writing the same (or fundamentally similar, at least) responses to several individuals on Facebook.  To save myself time and frustration in the future, I’m just stashing it here, so I can copypasta it out as needed.

This specific variant of the response was inspired by someone posting an article from thefederalist.com by a rape survivor.

Okay, so the impetus for the recent transgender bathroom legislation is the idea that without it, a cisgendered man could claim to be a transgendered woman and enter the women’s restroom (or vice versa) for nefarious purposes, yeah? And this legislation will prevent it by assigning additional penalties for their entering that restroom, in addition to the already illegal ‘nefarious purposes’ they entered to conduct?

Well, post-legislation, what is to prevent that same cisgendered man from entering a women’s restroom, asserting that they are in fact a transgendered man, having been born a woman (again, or vice versa) and are therefore compelled by law to use the women’s restroom?

How exactly would you propose resolving that situation? Show ID to Pee? Must they also provide an original birth certificate, which you know everyone carries with them when they’re out and about, because gender can be changed on your drivers license (and just hope that they didn’t get their gender changed on their birth certificate)? And then, will you also make them wait to pee while you phone it in to the state to confirm their birth sex, because they could have photoshopped and printed a forged birth certificate?

For all the conservatives oppose new gun laws saying that they won’t stop criminals and only impede the rights of legal gun owners, why are so many in favor of these bathroom bills, that — again — will not stop determined criminals, and just impede the rights of transgender individuals?

What, apart from making transgendered individuals lives a pure hell, does this legislation actually accomplish? Add on a second charge as a potential deterrent? What rape or assault would that possibly prevent?

Yes, the author of the article in question is a rape survivor. Okay. Was her rapist pretending to be transgendered to gain access to her? Was she raped in a public restroom? Because many Trans individuals are harassed and attacked in public restrooms. And this legislation increases that — as well as increasing the likelihood that they are going to be raped in turn.

Laws should be to secure the safety of the most vulnerable of society. And if you look at the statistics, those are transgendered individuals, who are raped and assaulted and killed at rates far exceeding the general population.

And this legislation makes it worse.

If anyone would like to offer suggestions or additions to “The Blurb” please feel free to leave a comment below.  If anyone would like to use “The Blurb” on social media, please feel free.

I’m Learning the Core Media Modal.

Disclaimer: This is basically me stream-of-thought’ing things as I’m learning the Core Media Modal’s codebase.  It’s my scratchpad, and I’m merely making it public in the hopes that it may be useful to someone else at some point in the future.  Some things are probably very wrong.  If I catch it, I’ll likely come back and edit it later to be less wrong.  If you see me doing or saying something stupid, please leave a comment, so I can be less stupid.  Thanks!

The media is written in Backbone, using the `wp.template` wrapper around Underscore templates for rendering.  If you want to really dive in depth, but don’t yet have a really solid understanding of Backbone, I’ve had several people recommend Addy Osmani’s book “Developing Backbone.js Applications” to me.  As luck would have it, it’s available for free online.

When exploring the code in WordPress, it looks like it’s best to do the investigating in the develop.svn.wordpress.org repository’s src directory (yes, develop.svn matches to core.trac — basically because legacy reasons and not wanting to change core.trac’s url when they changed core.svn over to be the Grunt’d version), before the build tools such as Grunt have a chance to run Browserify on it #.  If you try to read through the code on the GitHub mirror, you’re gonna have a bad time, as that doesn’t have the `wp-includes/js/media/` directory with the source files in it.

Browserify is a slick little tool in Node that bundles up a bunch of files, and puts them into a single file, so you can `require()` them in JS.  This makes them easier to work with in the source, and quicker to load in a browser.  WordPress has been using it to compile the Javascript for media since 4.2 (#28510), when the great splittening happened.  If this intrigues or confuses you, Scott Taylor has a great write-up on that ticket about the whys, hows, and whatnot.  It originally merged in at [31373] halfway through the 4.2 cycle.

Oh, and all the actual templates that are parsed and rendered by the views are in `wp-includes/media-template.php`

Okay, time to dig in.  (So that I’m not inadvertently writing a book, I’m going to split this into a series — but if you’d like to read them all, I’m dropping them in a tag.  You can find them all here.)

On Core REST API Authentication

Having an API is well and good, but if there are no ways for third-party apps to actually authenticate and use the API, it’s not very useful.

Background

While the framework for the REST API was merged into WordPress Core with the 4.4 release, the only means of using any endpoints that currently require authentication are what is known as ‘cookie authentication’ — that is, piggybacking off of the authentication cookies (plus a nonce) that WordPress Core sets in the browser when you log in traditionally to your WordPress site.  Unfortunately, that leaves the REST API as little more useful than the legacy `admin-ajax.php` file.

Fortunately, there are several authentication methods being worked on at the moment, in plugin form, for consideration of merging in to Core.

I’m heading up one of them, called Application Passwords.  In short, it lets a user generate as many single-application passwords as desired — one for each phone, desktop app, or other integration desired — and later revoke any application password whenever desired without affecting other applications or the user’s normal authentication.  The passwords are then passed with each request as Basic Authentication, encoded in the header of each request, as per RFC2617.

The other plugin is OAuth 1.0a authentication (spec).  Most OAuth usage across the internet is actually OAuth 2.0 — however, OAuth 2.0 requires HTTPS on the server side.  Ordinarily for most hosted services, this is not a problem.  However, for a distributed platform like WordPress, this is untenable due to the majority of sites not supporting HTTPS.  So an older, more complex specification — designed to not require HTTPS — had to be used.

For the record, I’m fully expecting to see an OAuth 2.0 plugin be built in the near future for use on sites that have a SSL certificate and support HTTPS.  However, that may not be very useful for app developers that want a ‘build once, run everywhere’ authentication method that will always be available.

Limiting Permissions

One of the discussions that came up with regard to Application Passwords is whether a REST API request that uses Application Password authentication should be able to modify Application Password endpoints.

Now, this is a very interesting question, and it can lead to many more questions — such as if an Application Password shouldn’t be usable to create or delete other Application Passwords, whether they should be allowed to do other user-administrative tasks (providing the relevant user has those permissions).  After all, if we’re preventing them from making a new Application Password, but they can just go and change the user’s actual password or email address, it’s a rather silly restriction.

So, there are several possiblilities.

First, you can just say “Any ways in to your account give full access to everything your account can do.  Be careful what applications and websites you give access to.” — the most basic, relatively easy to understand way.  Honestly, this is my preference.

Secondly, when creating a new Application Password or connecting a new client via oAuth, you could do something like … selecting what ‘role’ you’d like to give that connection.  For example, if your normal user account as an Administrator, but you’re connecting an app that’s intended just for writing blog posts, you may want to downscale your role for that authentication key to either an Author or perhaps an Editor.  An advantage to this is that it would be more cross-API — that is, it would work just as well with the legacy XML-RPC API, as with the new REST API.

This ‘role restriction’ method may be somewhat fragile, as it would need to only filter `current_user_can` and `user_can` — but only when checking the current user’s ID.  However, that may goof up some cron tasks that may run on the same request as the REST API request or other incendtal things.

Thirdly, we could do something REST API specific — either whitelist or blacklist REST API endpoints based on authentication key.  So, when either creating a new Application Password or authorizing a new OAuth connection, you would set rules as to what endpoints it can be used to hit.  Perhaps you’d want to allow all `wp/v2` namespaced endpoints, but no endpoints added by plugins to custom namespaces.  Or you want to only allow it to access core `posts` and `taxonomies` endpoints.  Or even something like allowing it to access anything but `plugins`, `themes`, `users`, or `options` endpoints.

The downside of this is that it won’t work with the legacy XML-RPC API and the user interface for it would likely be far more confusing for users.  It also could get problematic as permissions may vary for who can read `options` endpoints and who can write to them — or the like.  So then it may further complicate to allowing GET requests but not POST, PUT, DELETE requests to certain endpoints.

Your Thoughts?

In the end, I’m not sure what the best path forward is.  Maybe I’ve missed something.  But I am confident that we need to start paying more attention to authentication and permissions for the forthcoming REST API.  If you have any thoughts or remarks, please leave them in the comments.

 

 

Dancing to a Calypso Beat

Sidenote: I wrote this article two months back, at WordCamp US, and am only now getting around to posting it. Sorry for the delay.

A few months ago, the culmination of nearly two years of internal work was open-sourced to the world. A new WordPress admin interface built by Automattic on top of Javascript technologies like Node.js and React, codenamed Calypso.

A lot of folks got excited and a few got scared. Some folks got a bit confused. But I haven’t heard many folks drawing the parallel and writing the explanation that I’ve cobbled together, so here’s my take on it:

For a while now, there’s been a variety of WordPress apps — iOS, Android, and some defunct ones for Blackberry, Windows Phone, WebOS, and the like. They all interact with WordPress via the existing XML-RPC API. They’re not really extensible for plugins — if someone installs “The Events Calendar,” events don’t start showing up in the app as they would in your traditionally PHP-generated WordPress Admin UI.

Calypso currently mirrors those mobile apps more than anything else, just shifted to a wholly different space. Instead of using the legacy XML-RPC API, which is meant primarily as a way to publish content and has a host of issues (sending user passwords in plaintext with every request, for one), it uses a REST API with far better authentication. Instead of running on mobile devices, it runs either in your web browser at WordPress.com or encapsulated in a Desktop app. But at its core, it’s a self-contained administrative application for WordPress sites.

I feel that the biggest win in releasing the Calypso interface, though, is that it can remedy a situation that’s festered for some time now. The current WordPress mobile apps are maintained by a crew of mobile developers that work for Automattic.

Development happens in the open, and community contributions are welcomed, but they are comparatively few and far between — largely due to the fact that the majority of folks who are really passionate about WordPress are primarily familiar with the languages that WordPress is written in — PHP, CSS, Javascript, MySQL, etc. Very few have much interest in leaping into App development. Likewise, most mobile developers have their own set of problems that they are passionate about solving, and volunteering their free time to build and maintain an administrative app for WordPress would ordinarily be low on their list of priorities.

So, it falls to someone to find and hire Mobile developers to maintain the assorted WordPress mobile apps.

With the release of Calypso, though, there is a bit of a paradigm shift. Calypso, being written in Javascript, is already in the skill set of many of the folks who are already passionate about building the core software, as well as those that leverage WordPress to build sites.

This, I think, will mean a significant renaissance of community interest in API-driven apps for maintaining a WordPress site. I also predict that we’ll see a lot of folks passionate about WordPress forking Calypso and tweaking it to make customized apps and distributions for specific clients and use cases — which will only expand further once REST API endpoints ship in WordPress Core, and Calypso migrates to use those, instead of the WordPress.com REST API.