I have a car and park on the street in San Francisco.  This guarantees me a large quantity of parking tickets and hurried mornings racing the clock to move my car before the ticket arrives.  No more!

Where’s my car? keeps track of where your car is parked and sends email and SMS alerts when you need to move it for street cleaning. It works from your phone or web browser. It will save you money.

Yes, this is San Francisco only right now.

This is magical, tell me more

The world is powered by screen scraping and this is no exception. I’m posting and scraping several pages in San Francisco’s GIS website. It’s a scary and ill-advised activity but it was worth it.

Because the geoscraping is a pretty slow process, it is handled asynchronously. The first step is posting the address you enter, which is just a street number and street name, to SF GIS’s “geocoder.” Whatever. I feel compelled to write it “geocoder” because the numbers returned are not even a little bit like latitude/longitude. Well, they’re numbers but there end the similarities.

After these magic numbers are found, I post again to scrape out the parking data, doing some assuming to remind the computer what side of the street you’re on. The update form reminds you not to choose the corner address of any block because, despite my best efforts, SF GIS disobeys sometimes at the corner and returns parking data for the cross street. Sorry.

The last step is deciding when the next street cleaning will take place, to setup email and SMS alerts. After much trial and error, I found all of the quirks in their expression of the street cleaning schedule and proceeded to walk around the calendar to find the next one. The algorithm goes like this: decide from the list of calendar days in the SF GIS text which comes next, then take that day and the time immediately following it to create a timestamp.

Timestamp? But you’re only using the day part?

That’s right but who knows what the future holds. Alerts one hour before might be nice and since I’ve already got a real timestamp, very easy.

There are tons of other possibliities, too. From showing a map tile of your car’s location for the spatially-challenged to a bona-fide API (mostly so I can play with OAuth from the provider side) for, you know, both of the things you can do on this site.

PS: When you see street cleaning data that is inaccurate, please click the “Report as inaccurate” link. It emails me directly so I can go to the GIS and figure out what went wrong. I’ve not exhaustively tested it across the city. It does work well in the Marina and the Mission.

JSONRequest was born from Crockford’s head more than a year ago, but only this month has it really gotten interesting. Collin Jackson has released a Firefox extension implementing the JSONRequest spec. I was naturally compelled to play with it.

JSONRequest is a proposed new standard that could replace XMLHttpRequest and shed the crippling “same domain policy” that makes it a pain to consume outside APIs in Javascript. It’s secure enough for cross-site-scripting for a couple of reasons. I’m lazy, so here are Crockford’s words:

1. JSONRequest does not send or receive cookies or passwords in HTTP headers. This avoids false authorization situations. Knowing the name of a site does not grant the ability to use its browser credentials.
2. JSONRequest works only with JSON text. The JSONRequest cannot be used to access legacy data or documents or scripts. This avoids attacks on internal websites which assume that access is sufficient authorization. A request will fail if the response is not perfectly UTF-8 encoded. Suboptimal aliases and surrogates will fail. A request will fail if the response is not strictly in JSON format. A request will fail if the server does not respond to POST with a JSON payload.
3. Reponses will be rejected unless they contain a JSONRequest content type. This makes it impossible to use JSONRequest to obtain data from insecure legacy servers.
4. JSONRequest reveals very little error information. In some cases, the goal of a miscreant is to access the information that can be obtained from an error message. JSONRequest does not return this information to the requesting script. It may provide the information to the user through a log or other mechanism, but not in a form that the script can ordinarily access.
5. JSONRequest accumulates random delays before acting on new requests when previous requests have failed. This is to frustrate timing analysis attacks and denial of service attacks.

From this list, #1 and #3 make the most difference. Without sending cookies, it will be very difficult to send requests impersonating a logged-in user. By requiring the application/jsonrequest content type on the response, the standard requires that the API provider take action to allow JSONRequests. This leaves no excuse for lazy API providers who don’t make their API secure.

As for other security holes, I’ve been poking around a bit against the Flickr API. I had to steal an API key, the shared secret for that key and a user’s token that came from that API key before I could do anything nasty. Now, since getting these three pieces of information gives you free reign even without JSONRequest, I don’t see much of a threat here.

As a bit of an aside, OAuth seems to work very much like the Flickr API and so JSONRequest will be equally innocuous for OAuth users.

OK, finally the amendment part

Requiring that all POST requests be sent as well-formed JSON data severely limits JSONRequest’s ability to take web apps to the next level. The inability to send traditional POST payloads isn’t such a big deal, but the inability to send multipart POSTs for file uploads is tragic.

Of course, it isn’t as easy as just lifting the JSON-only restriction on POST payloads. As Mike pointed out to me last night, old sites using GET variables to handle authentication (PHPSESSID anyone?) are pretty much sitting ducks. But there’s always another way.

Allowing traditional or multipart POSTs without some prior setup can be hazardous. Although these will always return an error to the caller, on the server side they may be successful which could really muck up your databases. The solution is simply to require a successful JSON POST immediately prior to accepting the multipart request as a way for the server to say “yes, I want that multipart POST.” In pseudocode, something like this:

JSONRequest.post_multipart = function(url, send, done, timeout) {
  JSONRequest.post(url, {'multipart': 1}, function(requestNumber, value, exception) {
    if (value) {
      // Here we would take params passed to post_multipart and actually
      // send the multipart request.  The result of that would be passed
      // to the function the called passed in the done param.  The
      // intermediate JSON POST is essentially invisible.
    } else {
      console.log(exception.message);
    }
  }
};

With this we will finally have hack-free file uploads in addition to safe cross site scripting. Even Microsoft can’t say no to implementing that.

BarCampBlock was yesterday in Palo Alto and was awesomely nerdy and I actually learned a lot. I’ll spare the play by play of a strange day and night and keep it geeky here.

Mike and I participated in a discussion of our responsibilities with user data led by Leah Culver. We centered on what was public and what was private and this led into a lengthy and educational digression into the legal issues surrounding user data. My conclusion: when I start a company, I will without a doubt break more than few laws.

Next stop for Mike and I was a talk on grid computing, data grids and Hadoop. This was admittedly way over my head. The approaches and software we talked about are probably the future as we generate more data and process it in ever more complex ways. I noticed that grid software, like enterprise web apps before, is starting out in Java. Since I hate Java, I think I’m going to wait for Powerset to get Ruby up to speed.

And the rest of the day had a very OpenID theme. First some SixApart guys, including former SixApart dude and LiveJournal creator Brad Fitzpatrick talked about their plans for abstracting the friending action common to way too many new websites to a lower, more automated level. This will do two cool things: first it will prevent repetitive friending all over the web and second it will create a more complete “social graph.” But most importantly, I can be just a bit lazier next time I dream up a vaguely socially-networked web app.

This segued nicely into a talk about oauth and standardizing authentication for open web APIs. Flickr’s API is pretty cool but would be even cooler with some friends. Lowering barriers to launching a good API is key.