Category: Technology

My OpenID Shitlist, Hitlist and Wishlist for 2008

OpenID hitlist

Update: I’ve posted an update to these lists, giving props to Yahoo, Google, PBWiki and Drupal for embracing OpenID.

I believe in the power of community to drive change, and I believe that peer pressure can be a great motivator. I also believe that shaming can be an equally powerful motivator, if used lovingly and when an “out” is provided.

In this case, that “out” is adding support for consuming OpenIDs, not just being an identity provider.

With that in mind, I thought I’d throw out my OpenID Shitlist, Hitlist and Wishlist with the hope that a little sunlight might cause the previously planted seeds to finally sprout. Since OpenID 2.0 is now out, these folks really have very little excuse not to get on board and make this happen (limited developer resources notwithstanding).

So, without further ado:

My Shitlist

Last February, at the Future of Web Apps in London, there was an orgy of OpenID announcements.

The point of my Shitlist is to publicly shame folks who have previously promised (or strongly indicated an intent) to adopt and add support for OpenID but who have failed, thus far, to do so. I invite them to redeem themselves by making good on their promises. I won’t hold it against them, but hey, it’s their word on the line.

  • Digg.com. I’d consider myself personal friends with the Digg folks. I like Daniel, Kevin and Owen. I think they do great work and that Digg is one of the most influential synaptic centers of the net. But Digg tops my shitlist because of a very important 10 seconds of speech that Kevin offered on stage, and which was covered by Om and TechCrunch. He said, and I quote: And then we also want to announce today, uh, support for OpenID. So we will be, uh, rolling out OpenID here in the next few months. That’s gunna be cool. Listen to it yourself. Did this ever happen? Nu uh. Still waiting. Hmmph!
  • NetVibes. NetVibes remains one of the more innovative, more “open source like” rich internet desktops out there. Tariq‘s a friend. But, like Digg, when you make promises (scroll down to Tariq Krim) to do something and months and months later you haven’t made good on your word, well, you end up in my shitlist.
  • Last.fm. Now, I’m going out on a limb here. I have a strong recollection that Last.fm was the third company to promise OpenID support at FOWA, but for the life of me, I can hardly find a reference (besides this: “So what was the buzz at this years FOWA London? Two things resonated to me more than anything in the conference. OpenID and attention data. All of the key players from digg to Netvibes, Last.FM to Arrington touched on, commented or made announcements in these arenas.” — hat tip to JP), and in the recording of their session, they make nary a mention. Now, I’m pretty sure they said something about it, but I don’t have proof. Last.fm needs OpenID regardless, so if someone can backup or discredit my memory, I’m happy to move them to a more appropriate list.
  • PBWiki. I’m a fan of PBWiki, the hosted wiki service. They’re a good friend to the BarCamp and Twitter communities and are my first choice when I need a wiki and don’t want the hassle of setting up and maintaining my own. The oldest email I could find when I first approached David, Nathan and Ramit with a request to support OpenID was July 30, 2006. I’ve badgered them consistently since then, receiving various assurances that they’d work on it. And without directly calling bullshit, I do wonder why their own Auth API hasn’t been made to be OpenID compliant when there have been so many other significant improvements made. I know that nerds aren’t their top priority (nor their biggest money-makers by a long shot) but maybe we can hack it in at the next SHDH?
  • MyBlogLog. I suppose things change when you get absorbed by a massive corporation that requires a consistent terms of service. Or else it seems plausible that the early indications of support for OpenID might have blossomed into full fledged support. Alas, it was not to be.
  • Technorati. In October of 2006, Technorati announced support for blog claiming with OpenID. They also became an OpenID provider. So technically, they don’t deserve a full shaming. However, it’s lame that they allow you to claim your blog if it’s an OpenID, but for reasons that confound me, don’t let you actually sign in to Technorati using the same OpenID. This seems ludicrous to me and frankly, I expect more from Technorati. (And can I point out that it’s a bad sign that when I search your blog for OpenID using your search engine, nothing comes up? Huzzah!)
  • Wikipedia. Well, everyone loves Wikipedia right (that’s an uncorroborated generalization)? Well, they still belong on my shitlist. Wikipedia said they’d support it in a Google Video as early as June of 2006. They might be able to define the protocol, but they certainly don’t support it. (Reprieve: open source to the rescue! Evan Prodromou wrote the OpenID extension for Mediawiki. Now Wikipedia simply needs to adopt it!)

Hitlist

With the shitlist out of the way, I can get on to those folks who haven’t necessary made promises before, but are ripe candidates to be lobbied to add support for OpenID.

  • Satisfaction. Satisfaction has long since planned on offering OpenID (and more recently OAuth) and they tell me that it’s coming soon. With co-founders (and my friends!) Thor and Amy recently getting into a new startup they’ve named Tesla Jane, I think I can be patient for a while longer. 😉
  • Twitter. If you’re aware of the backstory of OAuth, you’ll know that it was my advocacy of OpenID for Twitter that revealed the need for a delegated authentication protocol that was compatible with OpenID. And, now that OAuth has gone 1.0 (and while we’re waiting for Twitter to roll out support for the final spec) it’d be great to also see movement on the OpenID front. I know you’ll get right on that. Heh.
  • Drupal. Bonus points go to Drupal and James Walker for rolling in support for OpenID into core for Drupal 6.0, and maybe we have to wait for the upgrade, but it’s too bad that there isn’t support on the drupal.org website. Should be an easy fix, and with the brilliant way the community devoured my recent feedback, I hope that this request is met with equal enthusiasm!
  • Plazes. Well, I’m with Tara and am pretty disappointed with where Plazes is today. Felix and Stefan are great, but the new Plazer sucks. It’s like they took a bunch of VC and lost focus. Then again, maybe I’m projecting. Anyway, it’d mean something to me if they went ahead and added support for OpenID. Better late than never.
  • Pownce. Pownce has been rocking the portable social network stuff, along with sister-site Digg (yes, the same Digg on my shitlist). The logical next step is for them to provide OpenID consumption to make the circle of portability complete!
  • Ning. Well, they already have NingID, but I really question the wisdom of proprietary authentication schemes at this point. I mean, if they’re all about niche-social-networks, wouldn’t consuming OpenIDs make so much sense to further reduce barriers to outsides coming in to play?
  • LinkedIN. These guys have been doing some great work widely adopting microformats and becoming more social-network-like. People seem to use LinkedIN as an identity aggregation point; shouldn’t they also be able to prove that they own a certain LinkedIN profile elsewhere and then verify their accounts elsewhere by logging in to LinkedIN with their other OpenIDs?
  • Slideshare. Given that Slideshare probably has the greatest collection of OpenID related presentations on the net, it’s kind of a shame that you can’t login to the site using the protocol. I know Rashmi and Jon have their hands full, but it’d be sweet to see them add support.
  • TripIt. TripIt’s awesome. Tara and I did a day of consulting with them and have been constant users ever since. What’d be great is if you could use your OpenID to login between Dopplr and TripIt — it might sound insane to them — but they really are complementary services. Tying my identity between them would save me such a hassle of having to go back and forth between them — and they’d both win!
  • Blip, Viddler, YouTube et al. This might be a pipe dream, but I do think that we could win over Blip and Viddler. YouTube, not so much. But if we lobbied each independent and got one to go, the others might follow…
  • WordPress.com. So WordPress is a funny one. They serve as an OpenID provider but don’t currently consume. If you want to enable OpenID consumption, you have to run your own blog (as I do) and use Will Norris‘ excellent plugin. This isn’t necessarily a problem, but with Drupal 6.0 getting support and Blogger offering limited consumption of OpenIDs, I would have hoped that WordPress would have made the move first.
  • Pandora. Finally, and this one might just be a vanity request, but I think it’d be cool if Pandora supported OpenID, if only because it would make OpenID seem cooler.

Wishlist

So, with the more likely candidates out of the way, I’d like to turn my attention to what would be big wins for OpenID, but that are an order of magnitude harder to win over, not so much because of technology issues but because of the complexities of terms of service and other business-level issues. In any case, if we see support from these folks for OpenID in 2008, we know we’re making serious ground.

  • Facebook. I asked the question on Twitter whether people would use Facebook as their OpenID provider if they could. The overwhelming response was no. Still, of anyone, Facebook could, if they actually rebuilt people’s trust and extended the reach of their strong privacy controls with best practice OpenID support, I think it’d be a net positive thing to see Facebook official adopt OpenID. There are already two Facebook apps that enable it, so clearly someone’s interested!
  • Yahoo and its various properties: Flickr, Delicious, Upcoming. I know they’re interested, but it will take more than interest and developer intentions to make this one happen. If Yahoo gets on board, game over man, cat’s in the bag.
  • Google. With their enthusiasm for OAuth and the recognition of the problem of widespread password scraping, I think Google is realizing that their avoidance of OpenID is not paying off. With Blogger toying with support for OpenID, I think (hope!) that’s it’s only a matter of time.
  • Microsoft. Well, Bill already promised. And they’ve even shipped code, even if it’s kind of a weird approach. Like most brushes with the embrace of openness, Microsoft is probably at war with itself once again, on the one hand having elements within that want to do the right thing and on the other, for some reason, being heavily influence by holdouts from the evil empire. We’ll see what comes of this, but I’m not holding my breath, even if InfoCard is the right interface metaphor for OpenID.
  • Mozilla. I don’t know if you noticed, but Mozilla has quite a few properties strewn about. Practically every week there’s a new property launched to promote some new campaign, not to mention all the myriad community sites that crop up (i.e. UserStyles.org, thankfully an OpenID consumer!). In leiu of a top-down single sign-on solution, why not just support OpenID and get it over with and enable portable reputation within the Mozilla universe? And — once you do that — maybe start looking at integrating support into Firefox, as I asked earlier this year?
  • Trac/SVN. With OAuth, support for OpenID on the command line becomes much more feasible, even if there’s little support today. Imagine being able to use your OpenID credentials to login to any SVN repository. Being able to federate whitelists of identifiers would make cross-collaboration much more facile and I think would be a boon to independent open source development.
  • MySpace, Hi-5, Bebo, Orkut et al. I mean, we now know that is basically an overhyped widget distribution platform, but that doesn’t mean that it won’t turn into something more. Eventually the limits of siloed identities are going to run up against the cross-pollinating design of OpenSocial and logging in to Bebo with your MySpace account is not only going to make sense, but will be expected, just like I can send email from my Gmail account to Hotmail and Yahoo email users. OpenID 2.0, with directed identity, is perfectly suited to handle this particular use case and I’d love to see the early OpenSocial partners get on board sooner than later.
  • Adobe. Not even sure why this one’s in the list, but so long as I’m thinking big, it’d be sweet to see support not only on Adobe’s site for OpenID, but also in Flash apps (which I think would possibly require OAuth). Adobe has Adobe IDs already, and, as I suggested before, proprietary protocols for identity on the web make less and less sense.
  • TechCrunch. This one’s for fun. I know Mike’s a fan of big ideas and making things better, so it seems strange that, given his use of WordPress, he hasn’t demanded support for OpenID commenting yet. Perhaps we can dream.

Now that I’ve got those lists out of the way, I wanted to give summary props to folks who have already gone ahead and implemented OpenID (this is not an exhaustive list; check out the OpenID Directory for more):

Make sure to stop by these folks’ sites and try out their support for OpenID. Heck, they’ve pioneered the way forward, might as well both give them some patronage and see what user experience lessons can be had from their implementations.

And, this is by no means a finished list. It’s just a start. If you’ve got your own Shitlist, Hotlist and Wishlists, please do share them. Not only have I probably missed some folks (Amazon anyone?), but there are probably services and sites more dear to your hearts that should be embracing citizen-centric web protocols that I don’t even know about yet.

So, let me know what you think and if you want to start doing some lobbying, the best place to start is with the OpenID site itself.

Slow, steady and iterative wins the race

Consider this a cry for anti-agile, anti-hyped solutions for delivering the open social web.

I read posts like Erick Schonfeld’s “OpenSocial Still “Not Open for Business”” and I have two reactions: first, TechCrunch loves to predict the demise or tardiness of stuff but isn’t very good at playing soothsayer generally and second: there’s really no way Google could have gotten the launch of OpenSocial right. And not like my encouragement will make much difference in this case, but I’m with Google this time: just keep trucking, we’ll get there eventually.

On the first point, I’d like to jog your memory back to when TechCrunch declared Ning RIP and that Mozilla’s Coop was bad news for Flock. Let’s just say that both companies are both alive and kicking and looking better than ever. I don’t really care to pick on TechCrunch, only point out that it often doesn’t really serve much purpose to try to predict the demise of anyone before they’re really gone or to lament the latency of some brand new technology that holds great promise but has been released early.

On my second reaction, well, I have some sympathies for Google for releasing OpenSocial prematurely, before it was fully baked or before they had parity with the Facebook platform. We suffered a similar coal-raking when Flock 0.2 launched. It was literally a bunch of extensions and a theme baked on to the husk of Firefox and when people asked “hey, where’s the beef?!”, well, we had to tell them it was in the future. You can imagine how well that went over.

The point is, we kept at it. And after I left, Flock kept at it. And so just over two years after we’d released 0.2, Flock 1.0 came out, and the reviews, well, were pretty good.

Had we not released Flock 0.2 when we did and gone underground, there’s a chance we would have had more time to prove out the concepts internally before taking them to a wider and less-forgiving audience and would have avoided the excessive media buzz we unnecessarily spun up and that blew up in our face. I learned from that experience that enthusiasm isn’t enough to convince other people to be patient and to believe that you’re going to deliver. I also learned the hard way how long good technology development actually takes and that typically whatever you come out with first is going to have to be radically changed throughout the testing and iterations of any design process.

To look at what Google’s attempting to do, I can see the same kind of awe shucks, we’re changing the world kind of technical development going on. But unlike Flock’s early days, there wasn’t the same political and economic exposure that I’m amazed to see Google taking on. It’s one thing for Facebook, with its youth and bravado, to force its partners to toe whatever line it sets, and to have them build to their specifications. After all, if they don’t, their apps won’t work.

Google’s doing something slightly different and more dangerous, in that, not only are they basically building a cross-platform operating system that runs on the web itself, but they’re also having to balance the needs and passing fancies of multiple business partners involved in actually implementing the specifications to greater or lesser degrees, with varying amounts of attention and wherewithal.

Worst of all, between Facebook and Google’s platforms, we’re quickly heading down a path that leads us to a kind of stratefied Internet Explorification of the web that we haven’t seen since Firefox 1.0 came on the scene. Already we’re seeing inconsistencies between the existing OpenSocial containers and it’s only going to get worse the more adopters try to work to the unfinished specs. As for Facebook apps, well, for every Facebook app built to run inside of Facebook, that’s one less app that, today, can’t run on the Open Web and then God kills another kitten.

So the moral here is that slow and steady isn’t as sexy for the media or VCs but it typically wins races in terms of technology adoption and deployment. So I guess I can’t fault Google for releasing a little too early, but it’ll be interesting to see if it actually helps them get to a stable OpenSocial sooner. Whether it matters when they get there is a matter of debate of course, but in the meantime, hell, there’s plenty for us to do to improve the web as it is today and to solve some tricky problems that neither OpenSocial or Facebook have begun to consider. So, I’m with Doc. And I’m in it for the long haul. I’ll keep my eyes open on OpenSocial and frankly hope that it succeeds, but in the end, I’m interested developing on the best citizen-centric technology that’s going to shape the next evolution of the web.

So long as it’s open, it’s free, non-proprietary, and inclusive, well, even if it’s slow going getting it done, at least we’re not treading back in time.

OAuth 1.0, OpenID 2.0 and up next: DiSo

OFFICIAL OAuth logoIIW 2007b is now over and with its conclusion, we have two significant accomplishments, both the sum of months of hard work by some very dedicated individuals, in the release of the OpenID 2.0 and OAuth Core 1.0 specifications.

These are two important protocols that serve as a foundational unit for enabling what’s being called “user-centric identity”, or that I call “citizen-centric identity”. With OpenID for identity and authentication and OAuth for authorizing access to portions of your private data, we move ever closer to inverting the silos and providing greater mobility and freedom of choice, restoring the balance in the marketplace and elevating the level of competition by enabling the production of more compelling social applications without requiring the huge investment it takes to recreate even a portion of the available social graph.

It means that we now have protocols that can begin to put an end to the habit of treating user’s credentials like confetti and instead can offer people the ability to get very specific about they want to share with third parties. And what’s most significant here is that these protocols are open and available for anyone to implement. You don’t have to ask permission; if you want to get involved and do your customers a huge favor, all you have to do is support this work.

To put my … time? … where my mouth is (I haven’t got a whole lot of money to put there) … Steve Ivy and I have embarked on a prototype project to build a social network with its skin inside out. We’re calling it DiSo, or “Distributed Social Networking applications”. The emphasis here is on “distributed”.

In his talk today on Friends List Portability, Joseph Smarr laid out an import set of roles that help to clarify how pieces of applications should be architected:

  • first of all, people have contact details like email addresses, webpage addresses (URLs), instant messaging handles, phone numbers… and any number of these identifiers can be used to discover someone (you do it now when you import your address book to a social networking site). In the citizen-centric model of the world, it’s up to individuals to maintain these identifiers, and to be very intentional about who they share their identifiers with
  • Second, the various sites and social networks you use need to publish your friends and contacts lists in a way that is publicly accessible and is machine readable (fortunately does well there). This doesn’t mean that your friends list will be exposed for all the world to see; using OAuth, you can limit access to pieces of your personal social graph, but the point is that it’s necessary for social sites to expose, for your reuse, the identifiers of the people that you know.

With that in mind, Steve and I have started working on a strawman version of this idea by extending my wp-microformatted-blogroll plugin, renaming it to wp-contactlist and focusing on how, at a blog level, we can expose our own contact list beyond the realm of any large social network.

Besides, this, we’re doing some interesting magic that would be useful for whitelisting and cross-functional purposes, like those proposed by Tim Berners-Lee. Except our goal is to implement these ideas in more humane HTML using WordPress as our delivery vehicle (note that this project is intended to be an example whose concepts should be able to be implemented on any platform).

So anyway, we’re using Will Norris’ wp-openid plugin, and when someone leaves a comment on one of our blogs using OpenID, and whose OpenID happens to be in blogroll already, they’ll be listed in our respective blogroll with an OpenID icon and a class on the link indicating that, not only are they an XFN contact, but that they logged into our blog and claimed their OpenID URL as an identifier. With this functionality in place, we can begin to build add in permissioning functionality where other people might subscribe to my blogroll as a source of trusted commenters or even to find identifiers for people who could be trusted to make typographic edits to blog posts.

With the combination of XFN and OpenID, we begin to be able to establish distributed trust meshes, though the exposure of personal social graphs. As more people sign in to my blog with OpenID and leave approved comments, I can migrate them to my public blogroll, allowing others to benefit from the work I’ve done evaluating whether a given identifier might be a spam emitter. Over time, my reliability in selecting and promoting trustworthy identifiers becomes a source of social capital accrual and you’ll want to get on my list, demonstrating the value of playing the role of identity provider more widely.

This will lead us towards the development of other DiSo applications, which I’ve begun mapping out as sketches on my wiki but that I think we can begin to discuss on the DiSo mailing list.

Blogger Beta offers OpenID; or, I am mine.

Blogger supports OpeniD!

Dave Recordon (and many, many, many others)points out that the Blogger Beta has added support for accepting OpenID for comments.

This is a watershed moment in terms of OpenID’s brief history as it seems to represent a change in the perception and utility of the protocol by a very significant potential proponent.

For once I can say to someone like Google, “No, you don’t know me, you’ve never let me use my own credentials — my own domain — where I’ve built up my reputation — to login to your system before. To date you’ve only let me use your siloed credentials to sign in against your servers… you never trusted me before. Today you’re starting to say, ‘Well, maybe it’s okay for you to tell me who you are using your own credentials.’”

Now, don’t think me getting wistful here.

OpenID is far from perfect (as Marshall Kirkpatrick has pointed out). But, with Internet Identity Workshop coming next week, we have a great opportunity to discuss the necessary improvements that need to happen around user experience, around security, around finalization of the protocol and around thinking through what possibilities a more “citizen centric web” might bring.

(Oh, and in case you hadn’t noticed, I like to use Pearl Jam song titles in my blog posts.)

Data banks, data brokers and citizen bargaining power

Sell to me

I wrote this this morning in a notebook as a follow up to my post yesterday… and since I don’t have time to clean it up now, I thought I’d present in raw, non-sensible form. Maybe there’s some value in a rough draft:

It’s like giving our money to a bank and having them turn around and sell our data to try to upsell us on loans and all kind of … oh wait, but the key difference is if we do get fed up, we can take our money out and go elsewhere, depriving the bank the ability to both target us with their partners’ ads and the ability to compound interest on our savings.

We need data brokers introduced into the system — organizations who are like safety deposit receptacles for our data — and who speak all APIs and actually advocate on our behalves for better service based on how “valuable” we are — this is necessary to top the scales in our favor — to reintroduce a balancing force into the marketplace because right now the choice to leave means dissing our friends — but if I’m not satisfied but still want to t talk to my friends, why can’t I be on the outside, but sending messages in? hell I’m willing to pay — in momentary access to my brokered personal profile — for access to my friends inside the silo. This is what Facebook is doing by shutting down so many accounts — it’s not personal — it’s protecting its business. They don’t want to become a myspace cesspool, succumb to empty profiles and Gresham’s Law — overrun with spam profiles and leeches and worthless profile data — a barren wasteland for advertisers who want to connect with that 8% of their customers who make up 32% of their revenue.

No it’s in data fidelity, richness, ironically FB took it upon themselves to weed out the bad from the good in their system-wide sweeps. Unfortunately they got it wrong a bunch of times. If Facebook allowed the export of data and became a data broker for its users — provided some citizen agency to its customers — there would be economic — as well as social — benefits to maintaining a clean and rich profile — beyond just expressiveness to one’s friends. For better or worse, FB users have a lot of benefit through the siloed apps of that F8 platform — but the grand vision should be closer to what Google’s marketing department christened “OpenSocial”… still though , the roles of banker and broker have yet to be made explicit and so we’ve leapt to “data portability” for nerds, forgetting that most people 1) don’t care about this stuff 2) are happy to exchange their data for services as long as their friends are doing it too 3) don’t want to be burdened with becoming their own libertarian banker! Dave Winer might want to keep everything in an XML file on his desktop, but I know few others who, IRL, feel the same way.

Thus concludes my rough notes.

So, if Facebook were perceived as a big Data Bank in the sky, how would that change things? Would people demand the ability to “withdraw” their data? Does the metaphor confuse or clarify? In any case, what is the role of data banks and data brokers? Is there a difference if the data container leverages the data for their own benefit? If they sell advertising and don’t provide a clear or universal means to opt-out? And what’s in the way of making more “benevolent” data vaults a reality — or how do we at least bring the concept into the discussion?

I have no personal interest the concept, only that’s a viable alternative to the siloed approach is missing from the discussion. And going back to the business models of OpenID and other identity providers… well, if any, that’s it. It’s like having a credit card with access to no credit — what’s the point? And OpenID becomes more valuable the more data capital it has access to. Or something like that.

Oh, and I’d like to quote something poignant that Anders Conbere said to me today in chat:

I was talking with my friend the other day and I tried to explain to him, that what I fear about facebook that I don’t fear about pretty much any other vendor is it’s continued developement as a competing platform to the web. a locked in, proprietary version and what I see, is just like Microsoft leveraged Windows as a “platform for application developement” facebook is doing that for web developement. what it offers developers is the simplicity and security of a stable developement environment at the cost of inovation because as we’ve seen, as market share grows, the ability to inovate decreases (since your success is tied to the backwards compatibility of your platform) and I see the possibility of facebook becoming a dominant platform for web application developement which will in turn lead to two decades of stagnation

So yeah, put that in your bonnet and smoke it. Or whatever.

Data portability and thinking ahead to 2008

So-called data portability and data ownership is a hot topic of late, and with good reason: with all the talk of the opening of social networking sites and the loss of presumed privacy, there’s been a commensurate acknowledgment that the value is not in the portability of widgets (via OpenSocial et al) but instead, (as Tim O’Reilly eloquently put it) it’s the data, stupid!

Now, Doc’s call for action is well timed, as we near the close of 2007 and set our sights on 2008.

Earlier this year, ZDNet predicted that 2007 would be the year of OpenID, and for all intents and purposes, it has been, if only in that it put the concept of non-siloed user accounts on the map. We have a long way to go, to be sure, but with OpenID 2.0 around the corner, it’s only a matter of time before building user prisons goes out of fashion and building OpenID-based citizen-centric services becomes the norm.

Inspired by the fact that even Mitchell Baker of Mozilla is talking about Firefox’s role in the issue of data ownership (In 2008 … We find new ways to give people greater control over their online lives — access to data, control of data…), this is going to be issue that most defines 2008 — or at least the early part of the year. And frankly, we’re already off to a good start. So here are the things that I think fit into this picture and what needs to happen to push progress on this central issue:

  • Economic incentives and VRM: Doc is right to phrase the debate in terms of VRM. When it comes down to it, nothing’s going to change unless 1) customers refuse to play along anymore and demand change and 2) there’s increased economic benefit to companies that give back control to their customers versus those companies that continue to either restrict or abuse/sell out their customers’ data. Currently, this is a consumer rights battle, but since it’s being fought largely in Silicon Valley where the issues are understood technically while valuations are tied to the attractiveness a platform has to advertisers, consumers are at a great disadvantage since they can’t make a compelling economic case. And given that the government and most bureaucracy is fulled up with stakeholders who are hungry for more and more accurate and technologically-distilled demographic data, it’s unlikely that we could force the issue through the legal system, as has been approximated in places like Germany and the UK.
  • Reframing of privacy and access permissions: I’ve harped on this for awhile, but historic notions of privacy have been out-moded by modern realities. Those who do expect complete and utter control need to take a look at the up and coming generation and realize that, while it’s true that they, on a whole, don’t appreciate the value and sacredness of their privacy, and that they’re certainly more willing to exchange it for access to services or to simply dispense with it altogether and face the consequences later (eavesdroppers be damned!), their apathy indicates the uphill struggle we face in credibly making our case.

    Times have changed. Privacy and our notions of it must adapt too. And that starts by developing the language to discuss these matters in a way that’s obvious and salient to those who are concerned about these issues. Simply demanding the protection of one’s privacy is now a hollow and unrealistic demand; now we should be talking about access, about permissions, about provenance, about review and about federation and delegation. It’s not until we deepen our understanding of the facets of identity, and of personal data and of personal profiles, tastestreams and newsfeeds that can begin to make headway on exploring the economic aspects of customer data and who should control it, have access to it,

  • Data portability and open/non-proprietary web standards and protocols: Since this is an area I’ve been involved in and am passionate about, I have some specific thoughts on this. For one thing, the technologies that I obsess over have data portability at their center: OpenID for identification and “hanging” data, microformats for marking it up, and OAuth for provisioning controlled access to said data… The development, adoption and implementation of this breed of technologies is paramount to demonstrating both the potential and need for a re-orientation of the way web services are built and deployed today. Without the deployment of these technologies and their cousins, we risk web-wide lock-in to vender-specific solutions like Facebook’s FBML or Google’s , greatly inhibiting the potential for market growth and innovation. And it’s not so much that these technologies are necessarily bad in and of themselves, but that they represent a grave shift away from the slower but less commercially-driven development of open and public-domained web standards. Consider me the frog in the luke warm water recognizing that things are starting to get warm in here.
  • Citizen-centric web services: The result of progress in these three topics is what I’m calling the “citizen-centric web”, where a citizen is anyone who inhabits the web, in some form or another. Citizen-centric web services, are, of course, services provided to those inhabitants. This notion is what I think is, and should, going to drive much of thinking in 2008 about how to build better citizen-centric web services, where individuals identify themselves to services, rather than recreating themselves and their so-called social-graph; where they can push and pull their data at their whim and fancy, and where such data is essentially “leased” out to various service providers on an as-needed basis, rather than on a once-and-for-all status using OAuth tokens and proxied delegation to trusted data providers; where citizens control not only who can contact them, but are able to express, in portable terms, a list of people or companies who cannot contact them or pitch ads to them, anywhere; where citizens are able to audit a comprehensive list of profile and behavior data that any company has on file about them and to be able to correct, edit or revoke that data; where “permission” has a universal, citizen-positive definition; where companies have to agree to a Creative Commons-style Terms of Access and Stewardship before being able to even look at a customer’s personal data; and that, perhaps most import to making all this happen, sound business models are developed that actually work with this new orientation, rather than in spite of it.

So, in grandiose terms I suppose, these are the issues that I’m pondering as 2008 approaches and as I ready myself for the challenges and battles that lie ahead. I think we’re making considerable progress on the technology side of things, though there’s always more to do. I think we need to make more progress on the language, economic, business and framing fronts, though. But, we’re making progress, and thankfully we’re having these conversations now and developing real solutions that will result in a more citizen-centric reality in the not too distant future.

If you’re interested in discussing these topics in depth, make it to the Internet Identity Workshop next week, where these topics are going to be front and center in what should be a pretty excellent meeting of the minds on these and related topics.

WP-Imagefit proportionally resizes images to fit your blog template

I’m happy to announce the release of my second ever WordPress plugin called . (My first, which I’ve neglected for sometime, is called WP-Microformatted-Blogroll).

WP-Imagefit is extremely simple and serves one purpose: to get images in blog posts to fit inside the columns that contain them. In fact, this plugin is used on this blog, so if you see ever images load wider than the column and then quickly snap to fit the container’s width, it’s this plugin that’s doing that.

I originally discovered this trick thanks to Oliver Boermans‘ NetNewsWire Ollicle Reflex style. Working together, he extracted the resizing code into a jQuery plugin called jquery.imagefit.js and made it available to me for use in my EasyReader NetNewsWire theme.

I had hacked it to work for my blog theme but decided that I should turn it into a WordPress plugin so I could use it elsewhere (and given that CSS’s max-width attribute not only wasn’t cross-browser, but also shrunk images horizontally, I needed a better solution). So, there you have it.

Go ahead and download it. Installation and setup is standard as long as you have an -compliant theme like K2 or .

I have a WordPress.org project page setup, the source is available (released under GPL), and if you want something to look at it, here’s the official homepage.

Feedback/feature requests/patches certainly appreciated and encouraged!

Apple source code pointing to social features?

PSAuthor.h

File this in the wild conjecture/handy-waving category.

I did some random digging today and stumbled upon something that could be pretty interesting, or, could be nothing more than the equivalent of the human appendix of Leopard: remnants of a good idea that somehow along the way never got completed, but traces of it still exist in the modern state for no apparent reason than to confuse and confound those with too many mental faculties at his disposal.

But let’s go with the what if? take. What with my interest in getting people into software in interesting ways, this one seems, like cave paintings, to point to earlier attempts at some fundamental type of expression of a very contemporary idea.

Anyway, the thing is this. While poking around Articles.js in Leopard’s PubSub.framework (you’ll need to be running Leopard for the Articles.js link), I noted a call to a couple functions having to do with FOAF, in particular function loadFOAF( ) and function receivedFOAF( html ). I talked to Tantek about this and apparently it had to do with some misbegotten effort to bring FOAF support to Safari but that it was effectively stillborn for reasons I can’t recall, but what was interesting was that, tucked away, I discovered a seemingly orphaned file called Friends.html (again, Leopard only).

This got me curious.

I started poking around the PubSub.framework for other clues… (And so you know, the Leopard PubSub.framework is effectively a system-level toolkit for subscribing to RSS and ATOM feeds and maintaining read/unread status universally — something that Windows Vista also apparently has. In any case it’s pretty cool, and it’s also new with Leopard).

So, after poking about, I eventually ended up here:

/System/Library/Frameworks/PubSub.framework/Versions/A/Headers

Within this directory is a file called PSAuthor.h and its contents are quite intriguing. The file describes a class of object called ABPerson (short for “Address Book person”). The various properties of an “ABPerson” are summarily listed, primarily pulled from the ATOM spec: things such as name, email and URL. There is also a conspicuous method at the end of the file called person, which is not listed in the docs, and which is apparently used to associate an author of a web feed with a person from the Apple Address Book. This is huge. Let me pull the method in its entirety:


/*
    @method     person
    @abstract   Returns the Address Book record associated with the receiver.
    @result     The associated record.
    @discussion Currently, associations to Address Book records must be made manually, by calling
                the setPerson: method. In the future, this method may attempt to locate a default ABPerson
                by looking up the email address or URL in the Address Book.
*/
@property (retain) ABPerson * person;

@end

Note the discussion: In the future, this method may attempt to locate a default ABPerson by looking up the email address or URL in the Address Book.

This means that Apple intends (or at least as far as I can make out from reading the tea leaves) to use the Address Book as a store for feed authors… and that — who knows — you may end up using your Address Book to read feeds from so-called “ABPersons” or, moreover, their interest in FOAF might have been a means to automagically grab your list of friends (say, from LiveJournal) to populate your Address Book — then, using ATOM discovery and the PubSub.framework, could have pulled in feed updates from all your friends, giving you effectively a local social network that could power — who knows what kinds of applications!

Vcard512BaseIn any case, I could be totally off here, but there’s something in this… could it be somehow related to the Mail.app feedreader functionality? I’ll offer one more hint that seems to suggest that my Coverflow for People idea isn’t too far off… If you take a look deep in the QuickLook.framework directory you’ll find a couple of very curious images: Vcard16.png, Vcard32Base.png, Vcard32Border.png, Vcard128Base.png, Vcard128Border.png, Vcard512Base.png and Vcard512Border.png. There aren’t any other filetype-specific graphics in this directory, and yet QuickLook is useful for all kinds of files across the OS. Is it significant then, when I browse the Address Book Metadata that I get cards like this?

QuickLook Contact

Vulnerability in WP Super Cache v0.1

Twitter / Christian Heilmann: OK, supercache has fail. It allows you to even get to the root and create copies of every folder.

Sometime yesterday morning I logged into my TextDrive account to make some more changes to my blog template and noticed two odd folders in my blog root directory called rh4m4.t35.com and www.kolortavil.org. I believe that the folders were empty, but nevertheless, it was clear that someone had broken into my site.

I deleted the suspicious folders and quickly reviewed the changes I’d made the day before and realized that the culprit was probably wp-super-cache, a new WordPress plugin that I’d installed the night before. I went ahead and disabled and then deleted the plugin (taking care to delete the supercache folder in /wp-content/cache/) and notified Joyent customer support (transcript and notes here) and Donncha Caoimh, the developer. I also twittered about the incident.

Sometime later I saw that Stephanie Sullivan had replied to me letting me know that Tiffany Brown was having a similar experience (though with greater consequence) and a report in the WordPress forums. Both Kristie Wells from Joyent and Donncha got back to me, the former confirming my suspicion that it was some kind of PHP Injection vulnerability and the latter asking for additional information.

This morning I found Chris Heilmann’s post on the subject confirming my concerns:

…Checking the folders created I found the same two injection attempts Tiffany mentioned. The caching allowed code injected as txt urls via “i” or “s” parameters to be executed.

In my case I found that half my server was mirrored into the supercache folder in the plugin’s cache folder. Not good.

I was happy to see that my etc folder and other more interesting bits were not reached yet before I deactivated the plugin. Right now I am playing grepmaster to see if there are some injections left. My action: deactived and deleted all caching plugins and their cache folders (best via SSH as FTP is a PITA with so many files).

I’ve now been in touch with Barry from Automattic and have followed up with Donncha, who have both been very patient and helpful in parsing through my logs trying to replicate the vulnerability.

The most likely culprit is an unquoted ABSPATH in v0.1 of the plugin. According to Donncha, “The ABSPATH part of the WPCACHEHOME definition could possibly have expanded when it was being written to the file. Unfortunately it wasn’t quoted so that may have done strange things to other variables like $cache_path. Barry says that the problem, though annoying, is just a bug and was likely just a misdirected attack on potentially vulnerably Drupal sites and that it won’t do more than create some benign directories in a WordPress install. Fortunately v0.3 of the plugin seems to have resolved the problem; meanwhile you can download or checkout the latest development version that corrects the ABSPATH issue.

I’ve written up my experience so far and let others know to watch out for irregularities if they choose to install the wp-super-cache plugin. I’m actually going to give the latest version another go and will report any problems here should I experience any.

While I’m at it, I’d like to point out the important role that Twitter and personal blogs played in tracking this down; and that Joyent support, Barry from Automattic and Donncha himself all played supportive roles in resolving this issue.

Coverflow for People

Address Book Coverflow v1

Ever since Apple bought Coverflow, I thought that it would make an awesome interface for browsing people. In fact, I had previously designed “people in the browser” for Flock to look something like this in the early days:

Friends Feed Reading

Of course, at the time, the design required a few things that we still lack, namely: 1) bigger default personal photos or avatars, 2) ubiquitous universal identifiers for people (this was before OpenID) 3) and free access to public data about people, typically found at the end of those identifiers.

Anyway, CoverFlow for people is something that I think could be a very powerful way of revealing “the ghosts in the machine” — across Leopard — or in interfaces generally. Imagine this kind of view showing up in Mail.app, Adium, iChat… where your friends, family and the rest get to update their own user pictures on a whim, and set their status and contact preferences in a way that visually makes sense. The new integrated Gtalk features in Gmail seem to be prioritizing your “Top 250”, so this is also something that could be added to the People Coverflow API without much trouble in order for the interface to scale accordingly. Anyone able to hack up a demo of this idea?