My G+ Profile
« April 2010 | Main | June 2010 »
May 31, 2010
Getting Quotes and Comments Right
Poor decisions in language design are tough to hide because fixing them is akin to changing the API of your library. You can hide all kinds of sins below the covers, but errors in the syntax and semantics can only be fixed by confessing those sins to the world. Consider this a confession.
One of the niggling little details of Kynetx Rule Language has been comment treatment. The parser we user, Parse::RecDescent, does not include a lexer--tokens are specified as regular expressions in productions. That works fine for everything but comments. Because there's no lexer, you can't flag a token as a comment and then throw it out. There are a number of ways around that; the method I've used is to strip comments from the source using a regular expression before they go into the parser.
Comments in KRL are like those in Javascript: a double slash starts a comment and it goes to the end of the line. If I were designing KRL over again, I'd definitely rethink that because it makes stripping comments from code that contains URLs problematic. The regular expression for matching comments is not trivial. Nevertheless, Javascript-style comments are what we're stuck with for now.
The problem of stripping comments from code without stripping code was made even tougher by a poor decision I made regarding extended quotes a few years ago. (Extended quotes in KRL start with << and end with >>.) For some reason, I decided that stripping newlines from the material inside an extended quote was the right thing to do. It's not. Quoted material ought to be left alone. That's why the developer quoted it; they want it to stay the way they wrote it.
Lately there have been some problems that have caused me to dive into this and rework it. Consequently, starting with the next code release, we will no longer strip newlines from extended quotes and not remove anything--even things that look like comments--from inside them. When material in an extended quote is used for a Javascript emit, it will be emitted unchanged. When it is turned into a Javascript string we will escape quotes and newlines so that they remain in place when Javascript evaluates them.
This will normalize some things in KRL, but there may be code in applications that relies on the fact that we've been stripping newlines. In particular, Javascript won't let you split strings across lines. Since we're escaping material that gets turned into string, there shouldn't be any problem there. But emitted Javascript that hasn't been careful about this will break.
Another fallout from this change is that any Javascript comments you've been putting in your emits will remain whereas before they've been stripped. That means you shouldn't be putting company secrets in your Javascript comments since they might be seen by users. On the positive side, the fact that were now leaving newlines in the Javascript source will make single stepping through your code more fruitful.
As always, we're happy to work with you to help you through this transition. I anticipate that this code will roll out Tuesday afternoon. We'll put notifications in the appropriate places beforehand.
9:03 AM | Comments () | Recommend This | Print This
May 26, 2010
Starting a High Tech Business: The Dark Side of Using a PEO
Image via Wikipedia
I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the twenty-third installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!
At Kynetx we use a professional employee organization (PEO) to reduce the overhead we have with managing all the details surrounding having employees. The way it works is that your employees officially work for the PEO and you "lease" them back. This works very well and takes most of the hassle out of employee HR for a small business...except when it doesn't.
Kynetx used a company called Workforce Solutions (WFS). I say used because we now use someone else. On Apr 2, the IRS seized Workforce Solutions assets, including bank accounts that contained money we'd paid WFS that they were to pass on to our health insurance. I don't know what beef the IRS has with WFS, but I do know that we've got employees now that for all intents and purposes weren't covered for the month of April. Imagine having had major surgery in April that isn't covered even though you thought it was. That's not hypothetical.
We're working multiple angles to try and solve the problem, including sending this letter to Rep. Chaffetz (PDF) (and a similar one to Senator Hatch).
This is the dark side of using a PEO. You're in bed with them and things that affect their company can drastically affect yours. You can do all the checking you want, but we didn't uncover anything wrong in our due diligence. These kinds of things can be hard to discover. When you use a PEO, understand that you aren't just contracting for services. You are entering into a very close partnership.
The good news is that this isn't a problem that threatens our company and it's hard to imagine a PEO scenario that would. We'll work through it and I'm confident that in the end everyone will be made whole. But it takes it's toll.
2:41 PM | Comments () | Recommend This | Print This
May 25, 2010
Forms, Events, and Dialoging in KRL
As part of the push for Impact, I released a preview functionality of using KRL with Web forms and demonstrated it at the conference. The ability to interact with forms is built on KRL's new event capabilities. In my previous blog post on this, I hinted at primitive events beyond pageview, but didn't go into much detail. In this blog post, I introduce three new primitive events in the web event domain: change, click, and submit.
The change event is based on the change event that most browers support. The event fires whenever a form element changes. You set it up using the watch action like so:
rule setup is active {
select when pageview ".*" setting ()
watch("#form-keys", "change");
}
When this rule fires, it says to "watch" the form element with id #form-keys for any change. The following rule responds to that event:
rule respond_change is active {
select when web change "#form-keys"
pre {
text = "Thanks!!!";
}
prepend("#userLogin", text);
}
In this case whenever the form element with id #form-keys changes, the message "Thanks!!!" will be prepended to the element with id #userLogin.
A note about watch. Our goal is to remove the need to do this. The rule respond_change above has all the same information in it and we ought to be able to automatically issue the "watch" action when needed with just a little more information (like what page to watch). That functionality will be added in a future release. For now, you have to explicitly "watch" something.
A click event is similar, although it applies to any element, not just form elements. Again we issue an explicit watch on the right page or pages:
rule setup is active {
select when pageview ".*" setting ()
watch("#breadcrumb", "click");
}
Then we can respond to the click:
rule respond_click is active {
select when web click "#breadcrumb"
pre {
text = "<li> Stop clicking me!!!!</li>";
}
append("#breadcrumb", text);
}
Again this is a silly example of just appending some text, but the action could be anything that KRL is capable of.
The most powerful of these new primitive events is submit. Suppose that setup paints a form on the page and issues the watch action like so:
rule set_form is active {
select when pageview ".*" setting ()
pre {
a_form = <<
<div id="my_div">
<form id="my_form" onsubmit="return false">
<input type="text" name="first"/>
<input type="text" name="last"/>
<input type="submit" value="Submit" />
</form>
<ul id="mydata">
</ul>
</div>
>>;
}
{
notify("Tell us your name...", a_form)
with sticky=true;
watch("#my_form", "submit");
}
}
This rule places a simple form asking for a first and last name on the page along with an empty ul element named #mydata. The watch action watches that form for a submit event. The following rule responds to this event:
rule respond_submit is active {
select when web submit "#my_form"
pre {
first = page:param("first");
last = page:param("last");
text = "<li>Your name is #{first} #{last}</li>";
}
append("#mydata", text);
}
The rule is selected when a submit event from the form named #my_form happens. It grabs the first and last name from the parameters and places them in a list item inside the list #mydata. After it's run a few times, this looks like so:
Events provide a very flexible foundation for extending KRL to operate in areas that have previously been off limits. The model is not limited to the Web, of course, although that's the first place we're using it. My current work is in getting events for email built into the system. Stand by...
4:21 PM | Comments () | Recommend This | Print This
May 20, 2010
The Future of Internet Identity: Data Access and Modeling
In my previous blog post, wrapping up IIW X and discussing what wasn't discussed, I talked about what was missing at IIW: discussions about authentication. What was hot at IIW were discussions about authorization and personal data. OAuth, UMA, and PDX talks were happening in every corner this time and these topics (with data access and modeling as their unifying theme) will be a major area of focus as IIW continues.
Back in the dark days of the Web, if you wanted access to data in your account in someone's system via an API, you had to pass along your login credentials. This is fine as long as the developer is the only person using the app, but when I use Tweetdeck, or more to the point a Web site that uses the Twitter API, I don't want to give the app my credentials. When I do, the app might misuse them. What's more, if I want to change them to revoke access from one app, I have to update every other app so they know about the new credentials. Unsafe and unscalable.
Unsafe, unscalable and yet the whole idea of cloud computing rested on the idea of authorized access to APIs. Take that away and the cloud becomes just a more efficient way of managing servers. Along came OAuth. In a world where APIs are gaining traction OAuth was a (relatively) simple answer to some hard problems and it took off. This is why authorization is such an interesting topic. Authentication is technically difficult, but ultimately pretty dry. But figuring out who gets to do what and when they get to do it is the stuff of drama and intrigue.
But OAuth isn't enough. OAuth is fine as far as it goes, but there are even larger problems that OAuth isn't designed to handle.
I believe that access to data, ever more personalized, is a trend that will shape our world--online and off--for the coming decade and lead to changes more profound and comprehensive that anything we've seen yet. This is the idea behind David Siegel's book Pull (read my blog post on the Power of Pull or listen to the podcast for more). David's book paints a compelling picture that is breath taking in its scale and scope; there is no aspect of our lives that won't be impacted by these changes. I think it's impossible to overstate their importance.
But before any of that can happen we have to overcome the limitations of OAuth.
- OAuth creates one to one relationships. In OAuth there's no distinction between the authorization manager and the data host. The data host runs an OAuth server. A user has to manage each relationship independently at the host. There's no user-centric repository of access policy and activity.
- OAuth has a very course access granularity; it gives access to the entire API. Once I've authorized a client to access the Twitter API on my behalf, it's me for all intents and purposes. OAuth isn't designed to tease out specific functions or elements and give them different access rights. OAuth 2.0 has some weak scoping concepts, but they're not based on generalizable policy principles.
UMA, or User Managed Access, is a project designed to overcome these shortcomings. UMA, for all intents and purposes is OAuth with one more level of indirection. UMA splits off the authorization management function and creates a place where users can manage access to resources they control on UMA-compliant hosts (places that have data). This solves the problem of one-to-one relationships. (Here's an excellent diagram that describes how UMA works.)
But this architecture is a two-fer. Because there's an authorization manager, there's a place to store policy and policy gives us the ability to control access in a more fine-grained manner. Want to give an app access to your friend list in Twitter but keep it from posting updates? Create a policy for that. All this policy stuff could be a user experience nightmare, but the UMA people are paying a lot of attention to use cases and usability.
UMA, as a protocol, goes a long way toward creating a world where fine-grained access to API-mediated data is possible. But there's another, related area that needs work before the vision of a fully functional, data-driven world of pull can become reality: personal data.
I wrote a post last month about Personal Data, Freedom, and Value Creation. The post was about the values that drive personal data and derive from personal data. Mediating access to data from APIs is fine, as far as it goes, but ultimately individuals will be the source of more and more data (what's called "volunteered personal information" or VPI) and will need to be able to manage that data, authorize it's use, and choose what gets done with it.
Imagining a world where your golf clubs automatically register your strokes, power, and so on; your toilet automatically analyzes your waste and registers the results; or your purchases (even those made offline) are collected and collated is fine, but done wrong or even poorly it's not a very nice world to live in. That's where the work of what's being called the PDX (personal data X -- the right noun hasn't been invented yet) comes in. Can we build systems that not only let us authorize the use of the data we have at various services but also put us in control of all our personal data? On the answer to that question hang our future privacy and security. Now we've got drama and action. No wonder people are excited!
PDX is not really about authorization (that question is orthogonal and rightly so). PDX is more about the models that will allow data sharing, synchronization and exchange. The area of authorization that PDX does touch on is in describing policies. If you have the right models for data, then you can also more easily create the policies that govern it's access. Modeling, understanding, and desribing our personal data is a necessary foundation to a future data-driven world.
On day two of this IIW, Steve Gillmor told me we ought to quit and declare victory. There's an appealing logic to that, but ultimately I think the questions that haven't been answered yet are even more interesting than the ones that have. And I think IIW has a continuing role in serving as a gathering place where the people working on the answers to those questions can meet, debate, and build the future Internet. Come to IIW XI on Nov 9-11, 2010 and join us.
3:45 PM | Comments () | Recommend This | Print This
IIW Wrap-Up: Moving Past Login...Sort Of
The 10th iteration of the Internet Identity Workshop wrapped up yesterday in Mountain View, CA. Since Kaliya, Doc, and I started IIW in 2005, we've always wondered when (or if) there would be a "big bang" when internet identity just took off. If this IIW wasn't the big bang, it was certainly a great indication that we're headed toward one. There were about 240 people at IIW this time, 80 more than the highest past attendance. There were companies represented that you'd not think of as "early adopters" in internet identity. And the discussion has finally, mostly moved on from login.
I say "finally" moved on because one of the most notable features of this IIW was the absence of discussion around Information Cards. InfoCards are largely dormant at this point. Kim Cameron, the father of InfoCards, has abdicated to France. I don't say this pejoratively, but he is clearly out of the fight. Microsoft has released server code that is incompatible with their client code. And Microsoft's 2-3 year release cycle guarantees that they won't be able to release anything fast enough to respond with the agility that the current, rapidly changing identity landscape requires--even if they wanted to, which I'm not sure they do.
The only other player with any hope of responding to market, Azigo, isn't releasing updated selectors either and won't until the end of summer. If Azigo had released a native, cross platform selector based on AzigoLite a year ago there would be some hope, but the continuous release delays have left others unsure of what the future holds for Azigo and InfoCards. No one can base their plans on the uncertain future releases of small companies. Working code speaks louder than anything else. All of this adds up to a situation where no one would be comfortable adopting InfoCards.
Harsh words perhaps, but I think they accurately describe the situation. Don't get me wrong, I think InfoCards are still an important piece of the overall identity landscape. The ideas and concepts embedded in Kim's identity metasystem are still the most complete and philosophically sound. The technology solves problems that OpenID is still trying to work out. And yet, the execution has been herky-jerky leaving InfoCards unusable by almost everyone. I said "dormant" and not "dead" in the last paragraph because I believe that InfoCards will still be important--if only by example--as this all continues to play out.
I say "mostly" because OpenID continues to thrash towards becoming a viable solution. The politics surrounding OpenID are worthy of a soap opera. I don't pretent to understand it all, so I won't try to explain it. I largely try to stay neutral and out of it all. I can do that because I have great respect for the players and know that they've weathered these storms before. The result will likely be a better, more functional protocol. The good news is there's workable code now from multiple vendors and the protocol wrangling isn't going to break what's working now.
As a consequence of all this the 220 people at the conference who don't live and breathe the promised OpenID changes were left to discuss other things. You can read the depth and bredth of it in the notes on the IIW wiki. But there was one topic that represented a big trend that is going to dominate the discussions on identity for some time. That's the subject of the next blog post: The Future of Internet Identity: Data Access and Modeling.
11:47 AM | Comments () | Recommend This | Print This
May 11, 2010
Switch to XMission
Image via Wikipedia
You might remember that I am lucky enough to live within the boundaries, of Utah FTTH project, UTOPIA. UTOPIA is a wholesale service, so you don't buy connectivity from them, you buy it from one of several retail providers on the network. Since I first signed up in 2007 I've been using MStar, a service from Prime Time Communications. They were pretty good at first, but recently I've had lots of short duration network outages (5-10 minutes each). I decided it was time for a change.
I've been a big fan of Pete Ashdown's company XMission for a long time. In fact, I first met Pete and heard about XMission at an event on "the Internet" at Park City in 1995 when people were first trying to figure out commercial Internet ventures. It's a long story why I didn't go with XMission from the start that I won't repeat here.
I had a great experience with the switch over because even though there were a few problems getting it done, the customer service was great. I was talking to real human beings who cared. They respond to email. They call back. I'm confident I'm going to be much happier here.
I couldn't resist signing up for the 50Mb symmertric service. I essentially have a DS-3 line to my house. That kind of bandwidth from home is simple amazing. Here's the speedtest graphic of a recent test I ran:
Jealous?
7:04 AM | Comments () | Recommend This | Print This
May 7, 2010
What's Facebook Thinking?
Image via CrunchBase
Jesse Stay knows more about social networking and Facebook than anyone else I know. And I'm fortunate that he's a friend and lives close by. So this week Scott and I sat down with him to record a Technometria podcast on Facebook's latest moves. We talked about the recent changes and issues with Facebook and other networking sites and discussed the relevance of Twitter, data availability, and privacy.
