Category: Ramblings

News Flash: The FBI doesn’t want you to encrypt your data.

So, yesterday FBI Director James B. Comey criticized Google and Apple for deploying encryption on smartphone operating systems that they wouldn’t be able to bypass, even when presented with a valid warrant by police. (source)

Does he not grasp that the reason people want this extra security is because of government surveillance overreach and secret warrants?  They’ve literally brought this upon themselves.  When you deny people their privacy in everyday things, they feel it necessary to go to further extents to maintain it.  Were it not for NSA overreach, lying before congress, secret FISA courts and the like, this recent push to encryption likely would never have happened.

So, well done. I’m personally delighted that folks are opting to encrypt things.  Thanks for giving them that push towards it by being something of an overly attached significant other.

nsa-memes-2

On Jetpack and Auto-Activating Modules

Hopefully, this is the last time that I’ll have to answer this question.

Frankly, it’s been answered dozens of times before. Now, I’m hoping to use this as a canonical ‘Answer Link’ that I can refer people to.  I’ll keep up with comments, so if anyone would like to ask

So, why does Jetpack auto-activate features?

Well, to start off, I should probably clarify what we currently do on this. We don’t auto-activate every new module that comes in.

We never auto-activate features that affect the display or front-end of your site — or at least not unless a site administrator explicitly configures them to.

So, for example, something like Photon, which would swap all your content images to CDN-hosted versions, doesn’t auto-activate. Our comments system doesn’t auto-activate either, as that would swap out your native comment form. Our sharing buttons do, but they don’t display unless you take the time to drag down some sharing buttons to the output box under Settings > Sharing.

However, modules like Publicize, Widget Visibility, and the like — they just give you new tools that you can use, with no risk to affecting your everyday visitors. When users upgrade, we give them a notification of what just happened, and point out some new features we’ve built in that they may want to activate themselves.

One thing we’ve recently expanded on, perhaps six months ago, is a ‘plugin duplication list’, for lack of a better phrase. These aren’t plugins that have an actual code-based conflict with a module, they’re ones that may be … duplicating effort. Previously, we were just scanning for plugins that would output OG Meta Tags, and short-circuit our own provider. However, since Jetpack 2.6, which shipped in November 2013, we’re actually doing it via a filter for all modules. For example, if you’ve got Gravity Forms or Contact Form 7 installed and active, our internal Jetpack Contact Form won’t auto-activate. If you’ve got AddThis or ShareThis active, our sharing buttons module won’t even kick in.

Now, obviously, we can’t catch every single plugin that may be similar enough to one of our modules to give cause to negate auto-activation. So there’s a filter, `jetpack_get_default_modules`, that can be used in any plugin to cancel auto-activation on any module.


add_filter( 'jetpack_get_default_modules', 'my_jetpack_get_default_modules' );
function my_jetpack_get_default_modules( $modules ) {
    return array_diff( $modules, array( 'module-slug' ) );
}

But I don’t like auto-activation of new features!

Okay.

You’re totally allowed not to.

We’re going to continue using our discretion to auto-activate select modules by default, but if you’d like to turn it off permanently for yours or a client’s site, we’ve made it ridiculously easy to do.


add_filter( 'jetpack_get_default_modules', '__return_empty_array' );

That’s it.

We believe that judiciously enabling new features is a win for users, especially considering 1) how low-impact most features are when ‘active’ but not actually implemented by a site owner, 2) how awkward it is for a site owner to have to enable something twice — for example, enabling the Custom Post Formats bit, and then having to visit Settings > Writing in order to actually enable the Portfolio custom post type.

We’ve spoken to many, many users who find a default feature set convenient, and resent having to make a bunch of ‘decision points’ if they had to manually activate each and every module. Good software should run well out of the box. So we’ve set up the defaults as we have. Yes, some people disagree and are vocal about not wanting anything to auto-activate. That’s okay. We try to design for the majority, with the best user experience we can provide.

If you have clients, that you’d like to be active in the relationship with, and customize the Jetpack experience for — that’s terrific. You’re the type of people that we add bunches of filters for. We’re all about empowering you to override our decisions, we just prefer to keep the default user interface free of a thousand toggles.

Decisions, not options — no?

The ABC’s of Travel for Techies

Always Be Charging.  A mantra that I held to long before I heard it codified in a catchy A-B-C slogan.

For me, it’s about efficiency.  If I’m sitting near a power outlet, and I have a cord handy, there’s not much of a reason to not plug in.  It’s there, I’m there, let’s top off.

Think about it this way — how often do you hit the critical low battery light on your devices when traveling, and think “Gah, life would be so much easier, if only I had an extra (10 minutes|20 minutes|hour) of battery life!” — well, you can!  Just charge, even when you don’t need it.

Sure, it’s a minor inconvenience to be tethered to an outlet instead of milling about with your phone, but even that can be negated with a travel battery.  The Anker Astro line has some terrific models to pick up, normally for under $50.  With a single Micro-USB cable, I can charge my tablet, my phone, my Karma wifi hotspot, and even HP’s Chromebook 11.

In the end, it’s a hedge.  Will it be needed?  Not every time, no.  But is the minor inconvenience of charging better than a major inconvenience of your battery dying on you?  Well, that’s up to you.

My Dopp Kit

Dopp Kits are wonderful things, and I highly encourage anyone who does much traveling to look into putting one together.  It easily saves me an hour or more on each trip — both on the front-end of collecting everything, as well as scrounging for anything I’ve forgotten once I arrive at my destination!

So here’s what I’ve got:

dopp-kit-contents

It’s served me well thus far, but what do you think? Am I missing anything critical?

Reign Soundtrack

So, it’s no great secret that my taste in TV shows isn’t always the classiest. I pick fun shows that happen to catch my interest, often just to be mocked for it by my wife.

One of the shows I picked up this season is the CW’s Reign. It’s very akin to The Tudors and its ilk, but with less nudity, cursing, and safer to watch around the baby. After all, it’s on a broadcast channel.

My favorite thing about it so far is actually the soundtrack. So I’ve started compiling the songs into a Google Music playlist (I’ve given up on Spotify a bit ago).

Here it is:

https://play.google.com/music/playlist/AMaBXykQFyGaiuOQy4U2qS_vkFQa5sqWrSGhzb4rYeUr7WP7PFGYD17ZEidsr9qKt8X_-lMvErCBGvC8yzAyVHefdPop0fCN5Q==

Very acoustic-folk sort of ambiance. I really dig it, and you might too!

Here’s the sources I normally gather the track lists for each episode from:

http://www.cwtv.com/music/reign
http://www.entertainmentoutlook.com/2013/11/02/reign-season-1-soundtrack-song-list/

P.S. Pressgram Violated Kickstarter’s Own Rules

So, last night I was able to finally realize what it was about Pressgram that bothered me so much.

Just to be clear, I have absolutely no objections to companies getting bought. It’s part of the natural business cycle. I’m a bit iffy on companies who are started for the sole purpose of being bought out for piles of money (and have been approached by several trying to hire me on and offer me a stake), but that’s tangential to the point.

Normally, when someone starts a company, they get funding in exchange for a stake in the company, and then have to pay out to their stakeholders if they get purchased. Totally fair — the stakeholders make an investment, and get a payout.

With Kickstarter, folks pay in, to typically get something out of it. A product, some stickers, a big thank you, whatever it happens to be. It front-loads a lot of the funding, and lets the creators build something awesome, which is then dispensed to the backers, and the creators can then go on to continue with it on their own, or build something else.  The expected pay out is known going in.

My concern (that I really hope I’m wrong on) was that Pressgram was trying to juice the system on both ends. Get the capital influx from Kickstarter by portraying itself as a product that folks would be able to use when it launched so that they didn’t need to put their own skin in the game to get launched, force people to sign up and build a user base, and then get bought out for ‘piles of cash‘ as an exit strategy. Basically trying to reap where one had not sown and profit with zero risk?

When I mentioned my concern that Pressgram had run its Kickstarter as though it were offering a standalone app (which, based on folks reactions to my posts, it certainly came across that way), John Saddington replied:

Respectfully, you didn’t read far enough! The social network was a part of the original design, from Day #1 of the campaign!

I couldn’t put my finger on just why that bothered me so much, or why he had made the references to a social network so vague and hard to catch.

Then I realized it, about a half hour ago. From the Kickstarter Guidelines as to what may and what may not be Kickstarted:

Kickstarter cannot be used to fund e-commerce, business, and social networking websites or apps.

Of course the original Kickstarter campaign couldn’t explicitly say that it was funding the creation of a social network. Those are explicitly forbidden!

So there’s two situations that remain: Either John Saddington kickstarted an app, or he kickstarted a social network. If it was an app, he should deliver on the Kickstarter and let the app work solo — without the requirement of being connected to the Pressgram social network (even if it results in a couple fewer users if he tries to get bought out). If it was a social network, then it was in direct violation to Kickstarter’s own rules.

Or, y’know, just say that he decided not to deliver the product that he kickstarted, and built this other product (that happens to have the same name) instead — but that’s a really dangerous precedent, and would kinda kill any future trust.

So, which is it?

Pressgram Terms of Service

NOTE: This is the second of two posts looking at problems I see with Pressgram. The first, looking at security concerns, can be read here.

First, a bit of history.  No, it is too long, let me sum up:

Pressgram was first spawned as a Kickstarter as a reaction to the Instagram Licensing debacle where there was an addition to their Terms of Service which implied that Instagram had the right to resell your photographs without payment or notification.

The Pressgram Kickstarter made some awesome claims:

You see, I want to build an independent publishing platform that isn’t beholden to strange and changing Privacy Policies, Terms of Service, or Licensing agreements […]

I suppose another way you could say it is… it’s your filtered photos published directly to your WordPress-powered blog, when you want, where you want, how you want.

You see, you now get more creative control over your content than ever before. You won’t have to “license” your photos from the app or the company – they are yours forever and you’ll never see them anywhere else except your own profile and blog.

This is a boon for the artist, the creative, the independent content creator who doesn’t need to worry about digital agreements or where they may end up seeing their own handiwork.

It’s yours, for goodness sake. No worries here.

You see, we believe that true creative control is not just about act and process of creating but also publication, especially in today’s digital economy.

Gee, that’s pretty slick.  It’s all about letting me keep the rights to my own content!

Well, no.

If you read their Terms of Service, you’ll see this section, reproduced in full:

User Content Submitted Or Made Available For Inclusion On The Service

TL;DR: Your photos are YOURS, now and forever! We do not hold ANY rights or intellectual property related to your content except for those that allow us to provide the Pressgram app and service to you. Also, your photos will preserve whatever copyright they had before uploading to this site and we will seek to protect that copyright and will not sell your photos without your permission!

By posting any User Content on the Service, you expressly grant, and you represent and warrant that you have all rights necessary to grant, to Pressgram a royalty-free, sublicensable, transferable, non-exclusive, worldwide license to use, reproduce, modify, publish, list information regarding, edit, translate, distribute, syndicate, publicly perform, publicly display, and make derivative works of all such User Content and your name, voice, and/or likeness as contained in your User Content, in whole or in part, and in any form, media or technology, whether now known or hereafter developed, for use in connection with the Service and Pressgram’s (and its successors’ and affiliates’) business, including without limitation for promoting and redistributing part or all of the Service (and derivative works thereof) in any media formats and through any media channels. You also hereby grant each User of the Service a non-exclusive license to access your User Content through the Service, and to use, reproduce, distribute, display and perform such User Content as permitted through the functionality of the Service and under this Agreement.

Well, if you read it fully, the TL;DR: section at the top certainly seems to be misleading.  An easy summary that makes you want to gloss over the fine print that — remember — by the Kickstarter, Pressgram wasn’t meant to be “beholden to strange and changing Privacy Policies, Terms of Service, or Licensing agreements.”

By the summary, Pressgram doesn’t hold any rights except those needed to provide the service and app.  Which would be awesome.  But it’s not what the terms actually say.

You are granting Pressgram the royalty-free rights to do the following:

  • Reproduce your images
  • Publish your images
  • Modify your images
  • Edit your images
  • Syndicate your images (which means to publish or broadcast in newspapers or TV)
  • Publicly display your images
  • Make derivative works of your images
  • Use your name, voice, and likeness as well, in any of the aforementioned ways

… and they can sublicense and sell/transfer those rights any way they like!

Then, it goes on so that you’re giving every other user of the service a license to use, reproduce, distribute, display your images as well.

Now, this is all very odd considering this is giving Pressgram the very same rights that it was created to protest Instagram trying to claim!

In fact, let’s take a look at the Instagram Terms and Conditions as they were when the whole ruckus came about (not their current terms, the more objectionable ones that they eventually backed down from).  You can view them here.

Instagram does NOT claim ANY ownership rights in the text, files, images, photos, video, sounds, musical works, works of authorship, applications, or any other materials (collectively, “Content”) that you post on or through the Instagram Services. By displaying or publishing (“posting”) any Content on or through the Instagram Services, you hereby grant to Instagram a non-exclusive, fully paid and royalty-free, worldwide, limited license to use, modify, delete from, add to, publicly perform, publicly display, reproduce and translate such Content, including without limitation distributing part or all of the Site in any media formats through any media channels, except Content not shared publicly (“private”) will not be distributed outside the Instagram Services.

As a reminder, these are the original Instagram Terms of Service, the ones that got the internet in a huge fuss, and Pressgram rode the wave of frustration with to over $50,000 of funding.

Now, that reads nearly identically to the Terms of Service that Pressgram has listed above!  You’re giving them a non-exclusive, perpetual, royalty-free license to do … well … pretty much anything they want with it.

Pressgram had some pretty noble ideals.  However, by claiming transferable and sublicensable rights to publish and create derivative works of your images, it’s showing that all the attractive talk about how “you get to control any and all commercialization of your content and work, how it always should have been” really is just gilding the lily, as it’s utterly negated in the small print in the terms of service, which Pressgram started out by saying  that it was entirely opposed to.

If Pressgram were built as just an app, instead of a Social Network (and we totally need another social network clogging up the internet), it wouldn’t have these Terms and Conditions, as you would be using it to modify your own images.  No service to store your images and share them on your behalf.  No server to distribute your images for you.  You’d send your own images directly to your own site, no messy, needless intermediate service to get in the way.  Which is much simpler.

But instead, what was built as Pressgram is functionally indistinguishable from Instagram, except that it publishes to your WordPress blog, and stores your WordPress credentials on their server.  It still claims the same rights to your images that Instagram did when it was initially conceived, and far more rights than Instagram claims in their current Terms of Service.

However, there is hope.  It sounds like John Saddington is taking these concerns to heart and looking into them over this weekend.  Here’s hoping the fine print clarifies itself to match Pressgram’s initial noble ideals, or the Pressgram app opens up and makes the service, and therefore its Terms of Service, opt-out.

—

UPDATE: Pressgram has updated their Terms of Service, making clear that it’s taking fewer rights to your content, and that those rights are only to be used for displaying your content, and it is no longer claiming the rights to sublicense or transfer those rights.  Hurrah!  It’s now in line with Instagram’s current Terms of Service.

Unfortunately, now it added this little blurb:

You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Content, use of the Content, or access to the Content without the express written permission by Pressgram.

I’m assuming that’s a typo, meant to read “without the express written permission of the original author and owner” — will update when that gets clarified.

Pressgram Security Concerns

NOTE: This is the first of two posts looking at problems I see with Pressgram. The second, addressing the Terms of Service can be read here.

Hi, folks. Gather round, and let’s have a little chat about password security and transparency.

So Pressgram just released, after a rather successful Kickstarter campaign, and lots of excitement by the community. Hurrah, congratulations, folks! Getting a public release actually shipped is the toughest part of any project, and you’ve got that out. Well done!

I installed the app last night, kicked the tires, and examined how it operates a bit, and I’ve got some concerns that I’d like to voice.

First, though, a bit of background. On the official WordPress Mobile Apps, there’s only so much security that can be reasonably achieved via the XML-RPC API that they (and pretty much all apps) use. With XML-RPC, there are no authentication tokens, you need to send your password in plaintext. Which is normally totally fine, as the password is just stored by your local phone (the security of which you are responsible for yourself), and then stored in a double-hashed and salted form on the server.

It seems that, unlike the WordPress Mobile Apps, the password that you enter in Pressgram isn’t kept private on your own device. Without noting it on a Privacy Policy or in any way notifying you that Pressgram is doing it, your password is stored in plaintext on their server. Which — to be fair — is necessary, if they’re going to be pushing data from the Pressgram Server to your WordPress site, and not going to require having a specialized plugin (like Jetpack) installed on your WordPress site to do it. And I don’t think that Jetpack is necessarily a worthwhile dependency to have for an app like this.

My first concern is that I don’t really like my passwords being stored in plaintext on a third-party server that could be hacked (or for that matter, required to be turned over by an order from a FISA court). Some other applications, such as IFTTT do the same thing, but at least with them, it’s transparent that it’s going to be their server holding your credentials and accessing your WordPress site.

With Pressgram, without further investigation, one would believe that it’s the app directly uploading the files to your WordPress site. After all, that’s what the Kickstarter initially pledged:

I suppose another way you could say it is… it’s your filtered photos published directly to your WordPress-powered blog, when you want, where you want, how you want.

But that’s not the case! For the curious, here’s what I saw when running a test against a honeypot standalone site where I was trapping all the requests sent to it:

Firstly, the App sends two requests to /xmlrpc.php

XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:51 +0000] "POST /xmlrpc.php HTTP/1.1" 200 904 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:51 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>
XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:52 +0000] "POST /xmlrpc.php HTTP/1.1" 200 512 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:52 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>admin</string></value></param><param><value><string>password</string></value></param></params></methodCall>

These two requests firstly make sure that the site is there and is a WordPress install, and secondly makes sure that the credentials work — and if it’s a multisite install, returns the available blogs.

So far, so good. The User Agent strings are clear as to what they are and what they’re accomplishing.

Then, ten requests come in:

YY.YYY.YYY.YYY - - [06/Sep/2013:02:53:27 +0000] "POST /xmlrpc.php HTTP/1.1" 200 1845 "-" "-"
[Fri Sep 06 02:53:27 2013] [error] [client YY.YYY.YYY.YYY] <?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>wp.getTerms</methodName>
<params>
<param>
<value>
<int>1</int>
</value>
</param>
<param>
<value>
<string>admin</string>
</value>
</param>
<param>
<value>
<string>password</string>
</value>
</param>
<param>
<value>
<string>category</string>
</value>
</param>
<param>
<value>
<array>
<data/>
</array>
</value>
</param>
</params>
</methodCall>

and nine others very much like it. If anyone is curious to see them, tweet me, and I’ll post them for folks to review. Checking existing taxonomies, creating new terms, uploading the photo, and creating the post.

XXX.XX.XXX.XXX is the IP address of my phone. YY.YYY.YYY.YYY is the IP Address of the Amazon Cloud Server that Pressgram works off of. I’ve anonymized these just for the sake of privacy. They’re easy enough to find, but it’s not my business to release them. I’ve also removed the base64 encoded image data.

I’ve also captured the request that the Pressgram App uses to send your password up to the Pressgram server — it looks something like this:

URL: https://api.pressgr.am/index.php/Api/postPhotoData
Data:
{
	"social": {},
	"post_content": "Pic",
	"sessionId": "00000000000000000000000000000000",
	"blog": [{
		"title": "Pic",
		"password": "password",
		"login": "admin",
		"url": "honeypot.example.com"
	}],
	"identifier_photo": "0000000000.0000000000"
}

So at least it’s being sent to the Pressgram server over HTTPS.

You’ll notice that the requests coming from the Pressgram Server have no User Agent to identify what they’re there for. They’re all signed with username and password — meaning that the Pressgram servers now have my username and password in plaintext, with not even a notification to me in their Privacy Policy or Terms of Service that this is being transferred up to their servers.

So what does this all mean?

Well, it means that Pressgram is storing your credentials in plaintext (or potentially encrypted alongside a decryption key) on your behalf, without notifying you or doing anything publicly to indicate that this is the case. No matter how high entropy your passwords may be, if you hand it to someone and they get hacked, it doesn’t matter. You are vulnerable — doubly so if you use that password for other accounts as well.

To some folks, this may be a worthwhile tradeoff. But as I look at it, I don’t see it as a necessary tradeoff. Your credentials could just as easily be kept private between the app on your phone, and your WordPress site. Just have your phone upload the photo directly to your WordPress install. It wouldn’t be difficult to do, it’s already making XMLRPC requests to the server. And it fulfills the initial Kickstarter promise of “your filtered photos published directly to your WordPress-powered blog”. It also would provide the added security that if Pressgram is eventually shut down or sold off, the app would still function, as it’s not needlessly dependent on the Pressgram Servers.

To protect yourself, you may want to consider making a seperate account for your WordPress site with the Author role, and using those credentials with Pressgram, and make sure you’re using a distinct password — as well as with any service that you provide a password to.

Conclusion

So in the end, what am I calling for?

Ideally, I’d like to see Pressgram give users the option of simply taking photos, and uploading them directly from the app to their WordPress blog. No servers in the middle with potential vulnerabilities for your data. In short — make the account creation and login optional. Give folks a choice! That sounds a lot more like what the Kickstarter was proposing. If you’d like to build a new social network on top of it (if I had a dime every time a potential client tried building that), make it optional!

Do I see that happening? Well, I hope so, but I’ve found that companies don’t normally like to make themselves less integral to a process. So at the very least, notify your users that their credentials are going to be stored on your servers. To take them as Pressgram has without any such public warning I see as morally questionable, and totally contrary to the values of the WordPress community, which embraces transparency, and not forcing unnecessary service dependencies between you and your site.

—

UPDATE: Pressgram has updated their Terms of Service to indicate that your content may travel through their network to get to your blog.  Unfortunately, it says nothing in the TOS or its Privacy Policy about your username and password being stored on or passing through its servers.

Events Custom Post Type Proposal for Multisite

This is intended for the Make.WordPress.org series of blogs.  There are a number of needs, from weekly chat schedules for some Make blogs, to WordCamps for others.  Each site needs to be able to display their own events, and the main Make site would need to be able to display an aggregate of all (or some) of the sub-sites.

I see the implementation of the output (data structures will be addressed separately) being done via a shortcode, as follows:

[super-spiffy-event-calendar]

which would do stuff roughly like:

$events = Super_Spiffy_Event_Calendar::get_events();
Super_Spiffy_Event_Calendar::render_plugins( $events );

Not really tricky.  That will display any events from the multisite blog that you happen to be on.  However, for the aggregate, I see something more akin to this:

[super-spiffy-event-calendar blog_ids="2,3,4,5,6,13,14,19,22"]

which would be more akin to:

$original_blog_id = get_current_blog_id();
$events = array();
foreach ( $blog_ids as $blog_id ) {
	switch_to_blog( $blog_id );
	$events = array_merge( $events, Super_Spiffy_Event_Calendar::get_events() );
}
switch_to_blog( $original_blog_id );
Super_Spiffy_Event_Calendar::render_plugins( $events );

A couple things we’d need to add in that aren’t noted here:

  • Caching. Shove it in a transient, so we’re not doing an expensive operation with blog switching on every page load.
  • Sorting. After building the aggregate, it’s probably worth sorting the events chronologically.
  • Display. I’d like to use http://arshaw.com/fullcalendar/ or something similar to handle the output.

Automattic!

Starting Monday, April 22nd, I’ll be working full time at Automattic!

When I first started working at Speck Products, I’d remarked to a friend that I thought I’d be there for good.  I loved the environment, I loved the people, and I said the only reason I’d ever leave is if Automattic ever wanted me and I could spend my days working full time on WordPress — more in a joking way, as I never really expected it to happen.

Eight plus months later, I find that to be exactly the situation I’m in.

I can’t find a single thing to gripe about regarding my tenure with Speck.  Everyone there was an utter joy to work with.  Challenges were plentiful to keep me engaged, but never overbearing.  I was kept occupied, but never overburdened.  Everyone was friendly and provided a great atmosphere.

However, now I’ll get to do something that I count myself as incredibly fortunate for.  I get to spend my days  doing the sort of work that I’ve volunteered my time doing for the past year and a half.  The environment that has been my passion, is now my job.  And I couldn’t be happier.

I’ll be spending my days on the Jetpack team for Automattic, increasing the tools available to WordPress.org users through WordPress.com by way of the Jetpack plugin.  I’m very excited by the road map we’ve got going forward, and I can’t wait for some of you to see the features that we’ve got in store.

The best is yet to come.