Author: George Stephanis

Cooking, Code, Carpentry, Letterpress.

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.

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.

View this post on Instagram

❤️❤️❤️ #emandaud

A post shared 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.

Two-Factor in the Real World

I’m locked out of my Apple account.

I know my password. I still have my cell phone number that is set as a recovery number.

So how could I be locked out?

Several months back, I changed my cell carrier to Project Fi — the Google amalgamation of T-Mobile, Sprint, and WiFi networks to provide better coverage at lower cost. I’ve been thrilled with the service (like, seriously ecstatic), but there are some odd issues that have cropped up.

For one, it seems that text messages from SMS ‘short codes‘ don’t go through.  This has been a known issue for some time now with Project Fi. I first found out about it when trying to set up Google Wallet with USAA — which runs through an automated SMS short codes system. Many automated texts do work without issue — Dropbox, for one.

At this point, it should be noted that Project Fi is not listed on the list of carriers that Apple officially supports for sending out two-factor login codes.

So I just spent a full hour (I clocked it at the end) on the phone with a very empathetic and understand customer service rep from Apple.  Unfortunately:

  • I don’t have any iOS or OSX devices currently logged into my iCloud account (I had just voluntarily switched my primary computer to Windows for work)
  • I can’t receive txt messages from their automated system at the phone number I have on file (despite the fact that I called them from that number and they can call me back at that same number)
  • I don’t have my recovery key (it was about three years back when I first turned on two-factor authentication, and I have absolutely no idea where I would have stored it)

So there is absolutely nothing that they can do for me, it seems.

I mean, I understand this to a point. The rep I had on the phone was very apologetic, but the system that they built just doesn’t account for the fact that perhaps sometimes phone numbers lose the ability to receive text messages.

They knew I was who I said I was — I was calling from my number on file, I had all my credit card information, I could authenticate the first step of logging in.  They could even call me at the phone number they have on file.  But because they couldn’t text me, they couldn’t — not wouldn’t, but actually couldn’t — help me.

But this isn’t meant to be a sob story, or a tirade against Apple. Okay, maybe a little bit of a gripe, but I’d like it to be more a focus on the importance of considering edge cases in development.

The customer support reps are incredibly constrained. They knew without a doubt that I could receive calls at the phone number in question. But they weren’t empowered to do anything about it. They escalated the issue, and it seems no-one was about to do anything, apart from offering their condolences that I won’t be able to log into my account.

If there is one take-away from this, I suppose it’s to enable your customer support reps to actually do their jobs. I know Apple has gotten burned in the past on hackers gaming the system, but it’s the importance of being judicious when dealing with requests, not barring the doors against any.

—

As a semi-related note, I’m heading up the group working on bringing Two-Factor support to WordPress core.  Two-Factor is something that I believe in deeply, I just also believe in the importance of carefully building out the systems that serve as back ends to such methods of authentication.

—

Update: I’m learning that it’s possible to get some short codes unblocked for a single account specifically … maybe.  Apple authentication texts seem to come from a number `50472` and I’ll be reaching out to Project Fi support tomorrow to see if I can get them to manually unblock that number for my account.

Perfect Faro Shuffles

Faro Shuffling is a technique where two packets of cards are pressed together and stitch themselves together, one to one. It takes a goodly amount of practice to actually pull it off reliably, but if you can, it’s a tremendously fun skill to have.

There are two primary kinds of faros performed on a 52-card deck, that being an ‘In’ and an ‘Out’ faro.  An ‘Out’ faro is one where the top and bottom cards of the deck are preserved on the outside of the deck, an ‘In’ is where they are moved to the interior of the deck.

If the user can perform perfect cuts and faro shuffles, it will take 26 ‘In’ shuffles to completely reverse the deck of 52 cards, and another 26 shuffles to return it to original order. However, by performing ‘Out’ shuffles, the full deck will be returned to the original sequence in only eight shuffles.

I’m working on mastering this, because it’s dang fun and appeals to my brain.  And, as a predictable way of reordering decks and can be rolled into some fun illusions.

For reference, standard new deck order is A♠️-K♠️,A♦️-K♦️,K♣️-A♣️,K♥️-A♥️.

While performing eight perfect cuts and ‘Out’ faros, if you start with standard new deck order, these are the eight cut cards:

  1. K♣️
  2. A♦️
  3. 7♣️
  4. 4♦️
  5. 9♠️
  6. 5♠️
  7. 3♠️
  8. 2♠️

Or, if you prefer Emoji,

🃞🃁🃗🃄🂩🂥🂣🂢

DIY Halloween Costume Smoke

I’m currently experimenting with possibilities for making a combo halloween costume that I could wear with my daughter this year, and I’d always wanted to be able to add a flair of the dramatic to costumes, and smoke is one of the best ways to do it.  Especially when it’s just a touch here or there.

I want it to be portable, and affordable.  Both of these are kinda requirements, honestly, for a once-per-year halloween costume.

In doing some research online, I saw an offhand remark from someone about e-cigarettes, vaporizers, whatever you like to call them, and the more I thought about it, the cleverer it seemed.  The recent pivot in the nicotine industry had driven down the cost of e cigarettes to the point where I could buy a “V2EX Automatic EX Starter Kit for E-Liquid” for about $12 at my local gas station.

Keep in mind, that this is just the e cigarette, not the ‘e liquid’ or the nicotine-laden stuff that makes it go.  By my understanding, that’s the far pricier bit.

So, e cigarette (rechargeable miniature smoke machine) in hand, I’d need at several more things: the fuel that makes it go (as I have no desire for nicotine or flavoring, I decided to forego the ‘e-liquid’), some sort of pump to operate the ‘draw’ that activates the e cigarette, and some way of getting the smoke from the e cigarette to where I want it.

The primary ingredient in ‘e liquid’ is a fun little compound called Propylene Glycol, and indeed you can buy it without the nicotine or flavorings much cheaper — if you have a Compounding Pharmacy anywhere near you, they normally sell it for probably about $10/pint — far more than you would conceivably need for a little smoke machine, but the point is that it’s cheap.  It’s also available on Amazon Prime.  You don’t need to mix it with anything, you can just pour it directly into the refill area of the e cigarette.  Granted, you may want to get an eyedropper or syringe with a blunt needle to do it with, so you don’t make a mess.

Now, we need a delivery method.

I had initially been envisioning some sort of one way dinky little plastic air pump with some hose on it that I could hide either under an armpit or behind a pushable button somewhere on the costume, but while trawling Amazon, found a great option — a 6′ tube with a siphon pump.  Going by its reviews, it’s made just as cheaply as the price indicates, but for our purposes — a one night costume — the price ($7) is right, and free shipping on Prime.

It is missing one-way valves, and I’ve got a set of those coming — again, Amazon Prime — but I don’t have them in hand quite yet.

In all, it’s come out to just about $30, $35 with the one way valves, and it feels totally worth it to add an incredible effect to a costume.

So, all things considered, I’m expecting to have a pretty fun instant smoke addition to a halloween costume this year.  And with the leftover propylene glycol?  Maybe I’ll just practice making smoke rings.  🙂

One friendly warning, though — you do not want polyethylene glycol.  That’s a laxative.  💩

Safari is the new IE

Read the Tea Leaves

Last weekend I attended EdgeConf, a conference populated by many of the leading lights in the web industry. It featured panel talks and breakout sessions with a focus on technologies that are just now starting to emerge in browsers, so there was a lot of lively discussion around Service Worker, Web Components, Shadow DOM, Web Manifests, and more.

EdgeConf’s hundred-odd attendees were truly the heavy hitters of the web community. The average Twitter follower count in any given room was probably in the thousands, and all the major browser vendors were represented ? Google, Mozilla, Microsoft, Opera. So we had lots of fun peppering them with questions about when they might release such-and-such API.

There was one company not in attendance, though, and they served as the proverbial elephant in the room that no one wanted to discuss. I heard them referred to cagily as “a company in California”…

View original post 1,420 more words