Twitter oEmbed is Leaking Data

oEmbeds are fun.  They make it easy to embed third-party content on your site, like tweets, status updates, videos, images, all sorts of stuff.

Unfortunately, to do this, third-party code gets injected into your page.  Don’t worry, this is by design, but it does mean that you should only oEmbed from reputable sites.  WordPress Core is very picky as to the providers that it chooses to accept as oEmbed sources.

Twitter is one of these oEmbed providers.  Here’s an example of an embedded tweet:

Neat, isn’t it?

Now, hover over my name.

See that little url that shows on the bottom left corner of your browser (probably)?  It probably looks just like http://twitter.com/daljo628!

Now, click it.  Don’t worry, I’ll wait.

Did the page you landed on have a bunch of extra cruft appended to the end of it?

Maybe it looked something like https://twitter.com/daljo628?original_referer=http%3A%2F%2Fstephanis.info%2F2014%2F05%2F22%2Ftwitter-oembed-is-leaking-data%2F&tw_i=469505591946129408&tw_p=tweetembed?

If you right-click and inspect the element, the URL is just what you expected! If you right-click and open in a new tab — same thing! But if you click normally and let it trigger a Javascript event, it modifies the link before your browser actually processes it.

After you’ve clicked on it normally once, you can come back and re-inspect it, to see that the URL on the link has now changed to the one with the referer data on it — they’re rewriting it inline and intentionally delaying it so when you first click, you wouldn’t realize that the data was being appended.

This can be a problem because some sites employ concealers for the referer http header (No, I didn’t misspell referrer) like href.li for example. By embedding this in a get parameter forcibly, it’s leaking data in a way very difficult to block, by taking advantage of the trust offered via accepting Twitter as an oEmbed provider.

One Year with Automattic

Well, it’s that time.

One year ago today, I started full time at Automattic.

Best. Job. Ever.

I get to work with some of the most brilliant minds I’ve ever known, all of whom, in addition to co-workers, I am proud to call my friends.

I get to contribute to open source software, and still have free time in the evenings for my family.

Each team meetup, company-wide meetup, and WordCamp I attend feels more like a family reunion than a work function.

I have the privilege of leading the team that develops Jetpack, and the ability to improve the workflow and capabilities of millions of users, every day.

For all this, to all my colleagues friends at Automattic and in the WordPress community at large, thank you.

And by the way, we’re hiring.

Decisions

Decisions are never easy.

Even if it’s an entirely trivial matter, it’s still forcing you to do something.

And goshdarnit, I’m lazy.

I also prefer front-loading effort when possible. Ounce of prevention, pound of cure, stitch in time saving nine, and all that.

And I respect other people’s time as much as I value my own. So when I build something, I try to avoid decision points whenever possible. This results in the loss of options occasionally, but I believe a smoother user flow.

Now, occasionally power-users will want to modify functionality. Adding a decision point for all users for the sake of the minority is silly, especially when power-users can leverage other methods — filters, actions, functionality plugins that extend the first plugin — to accomplish their goals.

To each according to their needs. Typical users need a simple, smooth, classy interface. Power users need to get under the hood. Why try to make something that doesn’t work well for either by trying to serve both?

The best middle ground I’ve been able to come up with is offering a secondary ‘under the hood’ plugin that exposes a lot of filters as options. Keep it canonical and clean, but present all the options.

Ideal? Not really. Workable? Probably.

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.