The Need For an Open Online Identity Infrastructure,
published at 3:01am on 01/09/12, with 4 Comments
Any company can own your own identity online, but no one company should own the entire online identity infrastructure.
Right now on the web, there are a number of different companies that claim to own some part of your identity online (or who might lay claim to your entire online identity). LinkedIn would like to own your professional identity, for example. More specifically, LinkedIn would like to own the professional identity ecosystem. They would like to say that if you want to know something about someone professionally, you will need to know about them on LinkedIn. Socially (whatever that means), the gorilla that would claim to own identity is Facebook. Purchasing habits? I suppose that Amazon would own that one. And for a particular company to own what I give it and try to make use of it is fine. What I take issue with is the idea that one company would like to be the de facto identity provider for everyone, with no option for the market to introduce competition into the picture.
In fact, I take offense at the idea that a company would want to have something as valuable as my identity, and would not be willing to compete on quality to earn it. I have no problem with the idea that a large number of my friends may trust Facebook with controlling their personal information on the web. What I have a problem with is that even though I personally do not trust Facebook with that information, I need to hand it over to them in order to function in this new wonderfully connected world known as “the web.”
We don’t have this problem with communications on the Internet. Take email for example. If I want to start a new email service, I can do so and as long as my email service speaks the same protocol as every other email service out there, I can participate, I can offer my service, and I can participate in the communications ecosystem. All of my friends use Gmail, but I choose not to. I can still email them, and I can participate in this wonderful Internet that I have available to me without having to switch over to the same damn thing everyone else is using. And more importantly, the existence of my email server does not necessitate everyone else going out of business in order to be useful.
So why is it that when it comes to identity, we all get a little bit stupid and start thinking that any one company is going to ultimately “own” the overall concept of identity on the web. Sure, there can be a company that owns your identity. Or my identity. But they shouldn’t have to be the same company.
This is not a brand new concept. OpenID tried to do this with authentication but it never really got the traction that I really wish it did. But it was a good start. For the 99% of you who don’t actually use and love OpenID, it’s the idea that your username and password are stored independently from the service that you’re actually trying to log in to. If I want to log into a photo sharing service that supports OpenID, that service would ask my personal login server whether I am really who I said I am, and assuming I am authenticated with my own login server, the photo sharing service would log me in. But the key concept here is that I get to choose my own OpenID provider. If I don’t like the service I’m getting with a particular provider, I can change it easily (especially if I set it up properly). The same goes for email, as noted before, especially if my email address is tied to a domain that I own, and not one that my ISP or email provider owns.
Similarly, then, we should move towards using an identity protocol that can identify us as individuals without tying us to a particular service. If I trust Twitter with my identity, and Twitter speaks this identity protocol, then it should be perfectly happy giving any supporting service information about me. Similarly, if I believe that Facebook is going to be the best provider for my identity, then I should have a Facebook account, and as long as Facebook also speaks this same protocol, the host service shouldn’t need to do anything differently to support either identity. Most importantly however, if I decide that none of these services is serving me well, I should feel confident that I can switch as long as I can find an identity service that speaks this general identity protocol.
Companies today try to provide identity on top of existing data that they already own (your social network, your professional profile, etc). Over time, these services will be made irrelevant as new, better services come online and replace them in the market. If we build on top of an open identity infrastructure, we future-proof the entire system. While service lock-in can provide security for a business temporarily, eventually your customers will get bored, and they will leave for the next shiny new service. In our current system of tying identity to existing services, once a new business gains significant market share, eventually all new services that require identity will start to use this new identity provider. But if everyone is speaking a common identity protocol from the get-go, older identity providers will never lose their utility in that regard. After all, I can still use my old email server now, even though everyone has moved on to Gmail, or Shortmail, or whatever new email service is coming next.
I think this move is inevitable, it’s just a matter of whether the existing identity providers are going to realize that they have to play nicely together and develop this open infrastructure, or if they’re all going to have to go out of business first and let the next crop of identity providers figure this out.
Filed under: Technology, with 4 Comments
How SOPA Will Break the Internet,
published at 12:12pm on 12/22/11, with No Comments
Update: As of January 20th, 2012, PIPA and SOPA have been postponed. That said, please read the rest of this piece to understand why mucking with the DNS system is a terrible, terrible idea and why any similar legislation in the future should not be allowed to pass.
“Well that didn’t take long…” emailed my coworker. “SOPA already doesn’t matter at all.”
He included a link to a Firefox plugin that would bypass the DNS blocking that could be used to enforce SOPA or similar legislation.
The interesting thing about the sentiment that “SOPA already doesn’t matter at all” is that it suggests that once there is a technological workaround to bad legislation then the legislation itself is nothing to be concerned about. Yet the exact opposite is true, especially when it comes to the very narrow piece of legislation that dictates that the mechanism for restricting access to offending sites is to compel US-based DNS providers to drop the offending sites off of the Internet.
You see, DNS is a pretty straight-forward mechanism by which a domain name like “youtube.com” is converted into an IP address like “74.125.226.199.” This works like a big game of telephone, where your computer first asks the name server it knows about whether or not it knows where “youtube.com” lives on the Internet. If it does, it tells you. If it doesn’t, it asks another server up the chain for the answer, and so on until an authorized server returns a response.
The text of SOPA that affects the DNS mechanism reads as follows:
A service provider shall take technically feasible and reasonable measures designed to prevent access by its subscribers located within the United States to the foreign infringing site (or portion thereof) that is subject to the order, including measures designed to prevent the domain name of the foreign infringing site (or portion thereof) from resolving to that domain name’s Internet Protocol address.
This means that when you try to go to a website that the US Attorney General has decided should be blocked, your ISP will respond with a notice that tells you that the site is no longer available (like that page you get when you go to a Starbucks and they tell you that the Internet is being provided free by AT&T). But there’s a catch. The catch is that the website is still online. SOPA (and PROTECT IP) don’t actually have any provisions for taking the sites down. Instead, they just make it so your ISP can’t tell you where they are on the Internet.
I know what you’re wondering now – you’re wondering whether you could just tell your computer to use DNS servers that are outside of the US (where the law can’t dictate what they do) and have the system work exactly the same as it does now.
The answer, my friends, is yes. That is exactly what you can do.
If SOPA is passed, and if the DNS blocking that SOPA legislates starts being put into place, there are going to be numerous blog posts published telling users how to change their DNS servers to ones that are not restricted by the US government.
So why is this so bad?
Well it’s bad because it breaks the technical promise that all DNS servers now make that they will do their best to resolve a name into an IP address for you. You see, most of the Internet is made up of these promises. Nobody passed a law that said that DNS servers should work this way. This is just the mechanism that was developed, and that everyone decided would be a good idea for the good of the network as a whole. In fact, over the years there have been pushes for people to provide alternative DNS systems than the main one that we use today, but they never really caught on because the Internet does not work unless everyone does the same thing. Once people stop trusting that their DNS servers are going to return the same address as someone else’s DNS servers, then the trust in the underlying system breaks down. As a user, I already have the right to change the name servers that my computers use, but I will only do so if I know what I’m doing.
But if a site I’m going to is being blocked, and I know that the information I am looking for is still on the Internet, and I know I can easily get to it by plugging some foreign DNS servers into my computer, I will probably do so. In doing so, however, I have done two things. First, I have opened myself up to potential harm by using DNS servers that may or may not adhere to the original promise I was made in the first place. While my ISP’s name server might have been blocking the foreign blocked entity I was trying to get to, this new server might be blocking other sites and redirecting me to phishing sites without my knowing it. But even more than that, it establishes a world where the underlying DNS service can become fractured. Where service providers can choose what names to resolve and what names not to, because there has been precedent set for this behavior.
The Internet only works because everyone who participates in it agrees on the way things work. You can not break that agreement and still have a functioning Internet.
Filed under: Technology, with No Comments
Writing the Perfect Job Description,
published at 11:12pm on 12/15/11, with No Comments
My company is hiring, and though we’ve been through this process before, this time, I took a step back to look at the hiring landscape in NYC and to figure out how we were going to attract talent. See, Indaba Music has been around for over five years, having launched at the beginning of 2007, but unless you’re in the music industry, you’ve likely not heard of us. But if you’re a musician who has wanted to work with the music of Yo-Yo Ma, Linkin Park, Metric, T-Pain, Peter Gabriel and Snoop Dogg, among countless others, or if you’ve gotten your music licensed for Mercedes-Benz or Grooveshark radio, then you probably have.
So, how do you write a job listing for a company that is not primarily a consumer product with hockey stick growth, does not have the “ooh shiny” appeal of all of the upstart NYC startups, and does not have any of the big name venture capitalists behind it to, uh, do whatever VCs do for a company in that respect? That’s what I was tried to figure out when I sat down to write our most recent jobs page.
See, we had one around for a while, and you can find it in the Wayback Machine if you really want. Like all other startups in New York City, we are always looking for developers, and our last posting very clearly laid out exactly what we were looking for. If you read that job posting, you would know that we were looking for an engineer who “works with team to design user interface, system architecture and database structure” and that we only wanted people who had “3 years Web Development experience.” We had about 12 bullet points in total, and at the end of reading the job description, I’m pretty sure you’d know whether or not you had the skill set we were looking for, but I’m also fairly sure that you wouldn’t know why you’d want the job.
These days, it’s pretty easy to see whether or not someone has the technical chops necessary for a job. Before the interview, you can check out their github page, you can poke around the recesses of the web and dig up all sorts of dirt on your candidate. Or even worse, you can dig around the Internet and find nothing about your candidate, which is probably even worse. And when they set foot in your office, you can have a conversation with them to see whether they speak sufficiently enough nerd to play well with the other nerds in your nerdery.
And once we get people in the door at Indaba, we can sell the company. You can look around the office and see this team of people working hard to change the music industry, working hard to make lives better for musicians, working their butts off to make sure that musicians on the web thrive.
But we need to get them in the door.
And what I realized was that we needed a job description that spent much more time explaining who we are, as a team, and as a company, and by extension, the kind of person you should want to be if you want to join that team and work with us. I wanted to construct a posting that would attract the right kind of people and get them interested in us, that would sell our company as much as the candidates were selling themselves to us.
So this time around, instead of talking about years of ruby experience and a working knowledge of mongodb, we tell people that “Every member of our team is involved in the product development process. We challenge our developers, and we expect people to contribute at every step along the way” and we talk about how “We are a small team, and everyone is expected to exhibit a fair amount of autonomy.” And more than anything else, we lead with our core philosophy, which is that we believe that “the music industry is more alive than ever.” Forget all of those people who think that this industry is in the shitter – we’re just getting started.
In the end, I think that this approach has worked. I think that not only has this posting resonated with the people that we’d like to hire, but I know that it’s also helped our own team to figure out exactly who it is that we’re looking for. Who knows, maybe you know someone who wants to “help change the way that musicians make music in the world.”
Filed under: Technology, with No Comments
The Simple Joy in Making,
published at 2:11am on 11/14/11, with 1 Comment
“Do you want to learn how to sew a little bag?” she asked?
I had stopped in front of the Singer sewing station at the book launch party for BurdaStyle’s new Sewing Handbook and was staring at a stack of material next to a pile of ribbon. I hadn’t touched a sewing machine since high school, but I’ve been considering getting one for a project I’ve got kicking around in my head, so of course I said “yes.”
Machine sewing didn’t really come back to me naturally. It took me a few tries to get the feel for clamping the foot down on the material, and figuring out where the needle was actually going to be darting in and out of the cloth, but it was really a blast using this machine to help me stitch together these seams on a piece of cloth to first make a channel for the eventual drawstring and then to sew closed to two remaining open sides to form the bag itself.
I spend all day playing with a generic, do-anything machine. Over the years, I have learned how to control this machine to search piles of text, to power websites, to edit photos and hundreds of other little tasks. The sewing machine itself does one thing. It it a machine that has been designed to pass two pieces of thread back and forth through a piece of cloth. That is all you can do with a sewing machine. But with that one, single action, you can create almost anything you can imagine as long as it consists of cloth being held together with thread. And the wonderful thing about sewing is that, a the end of the process, you have a one-of-a-kind product that was shaped into being with your own two hands. The name of the game with computing, and with the web specifically, is scale. Repeating the same actions over and over again for hundreds, thousands, and millions of users, with no human interaction, in order to fully realize the benefits of computer technology.
And yet here, we were doing the exact opposite.
Every one of those pieces of cloth was going to have to be turned into a bag by the person who was going to walk out the door with it. Ten visitors to the sewing machines? Ten bags. A hundred visitors? A hundred bags. And while the machines can make short work of turning a piece of cloth into a bag, and while Singer really could have provided every visitor a bag just for walking in the door, the emphasis was notably on having the guests actually go through the process of creating an object for themselves.
I spend all day long building software systems that live on virtual servers on real hardware sitting heaven knows where in the world. I love my work, but it is always important to try to ground ourselves back in the world from time to time, and there continues to be no better way to do so than to make something physical.
Installing image_science on OS X with Homebrew,
published at 9:11am on 11/02/11, with 1 Comment
I just wanted to write about a bug that ate up a large chunk of my day yesterday (and a large chunk of a day in June, as well, but I forgot to write about it last time and therefore forgot how I had solved it before).
This is a bug that’s only going to affect people who:
- Are using OS X
- Are trying to install the image_science gem
- Have installed FreeImage using homebrew
Everyone else can just walk away at this point. Maybe peruse twitter, which always ends up sucking away half my day anyway.
In any event, I installed FreeImage using homebrew and installed the image_science gem without a problem. But when I tried to require the gem in irb, I would get this error:
/Users/jcn/.ruby_inline/Inline_ImageScience_cdab.c:2:23: error: FreeImage.h: No such file or directory
/Users/jcn/.ruby_inline/Inline_ImageScience_cdab.c: In function ‘unload’:
/Users/jcn/.ruby_inline/Inline_ImageScience_cdab.c:8: error: ‘FIBITMAP’ undeclared (first use in this function)
…
CompilationError: error executing “cc -dynamic -bundle -undefined suppress -flat_namespace -fno-common -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -fno-common -pipe -fno-common -I /Users/jcn/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/x86_64-darwin10.6.0 -I /Users/jcn/.rvm/rubies/ruby-1.8.7-p330/include -L/Users/jcn/.rvm/rubies/ruby-1.8.7-p330/lib -o \”/Users/jcn/.ruby_inline/Inline_ImageScience_cdab.bundle\” \”/Users/jcn/.ruby_inline/Inline_ImageScience_cdab.c\” -lfreeimage -lfreeimage -lstdc++ “: 256
and so on. So that first line obviously indicates that image_science (which uses RubyInline to compile inline C code at runtime) was not able to find the FreeImage header file, and therefore couldn’t compile the pieces of itself. The last line shows the directories that the compiler is using to look for headers, and we will note that /usr/local/include (which is where homebrew puts its header files) is not listed.
The first thing I thought was that I needed to pass a -I flag in to the gem as it was being installed, but I realized that this would do nothing since the RubyInline compilation is happening at runtime, not at installation time.
So how do you tell your compiler where to find your include files if you’re compiling a C program? Well, a little “man gcc” led me to this:
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
…
CPATH specifies a list of directories to be searched as if
specified with -I, but after any paths given with -I options on the
command line. This environment variable is used regardless of
which language is being preprocessed.
Perfect! Since image_science just shells out to cc at runtime when it needs its C components built, it should just pick up the CPATH as well. So I dropped the following into my .bashrc, and everything is hunky dory now:
export CPATH=/usr/local/include
So just remember, kids, all those things you learned back in school that you thought you left behind when you discovered Ruby continue to prove useful from time to time. Hooray for man pages and knowing how to read error messages!
(Incidentally, this bug has been fixed in the main repo for the image_science gem, but they never bumped a new version with this fix.)
Filed under: Technology, with 1 Comment
RSS Feed