George Stephanis

Code monkey get up, get coffee…

Category: Ramblings

  • 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.

  • Legislation DB Dump

    Still not quite the final DB structure I’d like, but this is available for data mining and trying to build something awesome out of.

  • OpenDataDay Hackathon DC!

    So I went down to DC this weekend to participate in the Open Data Day Hackathon!  There were some tremendous projects proposed, but the one that caught my eye from the start of the day was one proposed by Jim Harper of the Cato Institute to track down the genealogy of legislation put forth in congress.

    Basically, the goal is to programatically find similar passages in multiple bills.  This can be used for many purposes, including looking at sections in large omnibus bills and getting an idea if the things that get shoehorned in it have been proposed previously, and what happened then.

    So, our team largely consisted of  myself, Alexander Furnas of the Sunlight Foundation, and John Bloch of 10up, with guidance from Jim Harper (previously mentioned, of the Cato Institute), Molly Bohmer (also of the Cato Institute), and Kirsten Gullickson providing some clarification on the way the XML data we were working with was structured.

    I spent my time building a MySQL database and a PHP import script that could map all the relevant data from the XML files in to it.

    Alexander worked in Python primarily fleshing out a way of doing Latent Semantic Analysis on the data we’ve extracted to sort out what is similar to what, and where can we find meaning in it.

    John spent his time working on a front-end for the final dataset, to help end-users get something useful out of the data we’re building.

    The data that we were pulling from can be readily accessed by anyone through the Library of Congress at the following URLs:

    I’m currently putting some finishing touches on the DB structure, but when that’s done, I’ll be releasing that and the import script in a subsequent post, as well as a SQL dump for the final accumulated and sorted data — ripe for data mining.  As the day was wrapping up, I had someone come to me inquiring about data mining for references to money allocated in appropriations bills and the like, and I was able to very quickly do a MySQL query along the lines of

    SELECT * FROM `resolution_text` WHERE `text` LIKE '$%'

    to find anything that started with a dollar sign and then listed an amount over a very limited data set of three million rows or such.  The final data set will be much larger.

  • Interview featured on the Optimizely Blog

    I was featured in an interview with Cara Harshman for the Optimizely Blog in 2013.

    While the original post isn’t live any longer, Archive.org comes to the rescue. It can be seen here:

    https://web.archive.org/web/20140719173814/http://blog.optimizely.com/2013/02/13/how-does-an-ab-test-affect-my-page-load-time-and-other-important-questions/

    Full article

  • Jonathan Coulton, Baby Got Back, Glee, and Copyright

    Disclaimer!  I am not a lawyer!  These are just my musings, if you ARE a lawyer, I’d love to hear back from you as to whether I’m on track.  Also, I call myself a Code Monkey.  That’s also a song by JoCo.  It’s awesome, and you should listen to it.

    If you’re here, I’m going to assume you’ve heard some details on the current situation of Glee ripping off Jonathan Coulton’s cover of Baby Got Back.  If not, read JoCo’ summary first.

    My understanding of the general consensus is that as the “cover” is a licensed cover, he doesn’t have any specific rights to protect it from Glee using it.

    The musical arrangement that the covered lyrics were set to was 100% original, and JoCo released a Karaoke track that omits all of the covered lyrics.

    It is my contention that the Karaoke track is not a cover, and is instead a wholly original work, and as such, JoCo owns rights to the melody to which his cover was set.

    Let me rephrase it another way:

    If I write a little tune that I find to be catchy, and release it, I would own the rights to it.  If, later, I purchased the rights to cover a song, and put the lyrics of the song to my completely unrelated tune, would I still have rights to my original tune?  Or would the fact that I happened to combine the two rob me of the rights to my original tonal creation?

    If you believe I would lose my rights, then I licensed my tune non-commercial Creative Commons (as JoCo did) and a third party took it and did a non-commercial cover version of a different song to said tune, would that then rob me of by rights to the tune?  The actions of a unrelated third party licensing it can rob the original rights-holder of his rights to the licensed tune?

    If you have a different answer to each of the last two questions, I’ve gotta ask why.  Because, for me, both of them seem to be a firm “Yes, I should keep the rights to the tune”

    In fact, that is why the law reads:

    A compulsory license includes the privilege of making a musical arrangement of the work to the extent necessary to conform it to the style or manner of interpretation of the performance involved, but the arrangement shall not change the basic melody or fundamental character of the work, and shall not be subject to protection as a derivative work under this title, except with the express consent of the copyright owner.

    As such, I question whether the portion of JoCo’s Baby Got Back that was a wholly new melody (that was ripped off by Glee) would suffer the same shackling to the original rights holder, when I would consider that melody to not be a derivative work, and the ‘cover’ to in fact be a derivative work (as it has a wholly new melody).

    The law says that it can’t be a derivative work if it keeps the original basic melody.  JoCo didn’t.  So — derivative work?

  • The best phrased response to the current GPL spat between WordCamps and Envato

    As stated by Chip Bennett:

    I will preface my comments by saying that I disagree completely with the approach the WordPress Foundation is taking here. The problem is a disagreement between the WPF and Envato, and developers are merely caught in the crossfire.

    This approach makes developers choose between putting food on the table and being a persona non grata to the WPF, or else risking their legitimate revenue stream, and be in the WPF’s good graces. Unfortunately, for Jake and thousands of developers like him, the WPF’s good graces don’t put food on the table.

    And while the tactic may ultimately work, there are only so many times you can turn the 50-mm barrels on the rank-and-file in the community itself, and not have adverse affects.

    That said, I take issue with Envato’s stance, as well:

    To my mind, it doesn’t make sense that a regular license sold on ThemeForest should give such a buyer the right to on-sell a creator’s work at that volume – if only for the simple reason that volume reselling can significantly reduce demand for the original work.

    You are arbitrarily restricting the ability of your marketplace suppliers to offer their work under the license of their choice. The way I read this, your real concern is that Envato would lose commissions if Themes in their marketplace were offered as 100% GPL, and led to downstream distribution. If that is the real concern, it may or may not be valid, but it is disingenuous to couch such concern as concern for your marketplace sellers.

    If that is *not* the real concern, then I don’t see how any real concern exists. Just let your marketplace sellers *choose* to offer their works under 100% GPL. Put up huge banners decrying the risks of doing so. Strongly suggest that they don’t do so. Rail against the GPL all you want. Make them click through 3 “are you sure?” dialogue boxes.

    But offer the choice.

    I guarantee you that the WordPress Theme developers who opt-in to offering their works under a 100% GPL license do so under full understanding of the license terms, and either disagree with your risk assessment, or have evaluated the risk-reward differently. You don’t need to “protect” them from the license.

    Just offer them the choice.

    This.  A thousand times this.

  • Draw Something Cool

    So I’ve had a lot of awesome feedback for the “Draw Something Cool” bit that I’ve added to my Contact Form.  It’s in actuality just the Signature add-on for GravityForms!

    That being said, here are some of the best images that I’ve had people submit through it thus far:

    1211108976534