Google site index bookmarklet

The bookmarklet first, for anyone who wants to opt out of the verbiage: I call mine @site, which fits snugly in my bookmarks toolbar. It searches Google for any page Google has indexed on the site you are presently visiting, and presents them in Google's usual interface which you learn how to navigate once, and can then use for the rest of your life, pretty much without ever thinking about it.

I am well aware that one of the things that made the web so hugely popular with content producers, is its very anarchic non-standardization of the user facing interface. Yes, your graphics and interaction designers are at full liberty to devise pretty much any user interface and interaction scheme they damn well want to, and they happily do so, too. The same applies to DVD menus too, though, thankfully, the dvd consortium at least recognized that their medium was one of entertainment primarily (or, through dumb luck) and somewhat constrained the technical possibilities a little.

Web sites are fairly unconstrained about their navigation (im)possibilities, though, and as every web site ever made is a country of its own with conventions of their own (most -- thankfully -- even shared with or at least inspired by others, modeled from similar components, and so on), so lots of features you might want the medium to provide, like "show me the most popular pages of this site" have to be found, when they exist, identified as such, and learned, before you can use them, once per site, or even once per content producer and site, when shared between several.

That most of the web imitates most of the rest doesn't change the fact that visitors still have a level of interface burden that is not associated with media like books, where every language has a common convention for which order you flip the pages, where to start reading, and so on, and, even across languages, most agree on left to right, top to bottom. The web could have conventions like these, but has not evolved to that stage yet (and might never do). There is some consolation in that browsers have a set of basic functionality for finding text within a page, scrolling it and the like, which is rarely intruded upon by web pages (but little prevents them from doing so).

While I don't know the particular sort criteria Google uses for open searches like the one this bookmarklet does, it often does seem to list the more popular pages first, at least on web sites like Alertbox, some of the first hits are the basic sections of the site. Reading Jacob Nielsen's top-10 application-design mistakes, how many perceive the web as one application? I do. I think most naïve, non-technical users who could not care less about the detail inner life workings of the web, do too.

And I think you should, too, despite knowing a lot more about it than that. Your web sites and design thoughts will surely benefit from it. I am rarely happier than when taming the web to behave more like one single, internally consistent, application, that responds to my actions in the same way, regardless of whichever of its zillion dialogs I happen to interact with. Try not to waste their brain power on working your part of that application, if you can. Yes, it is more fun for your own ego to have them adapt to your whims than you to their expectations and there are counter-examples to every rule, but those account for miniature fractions of a percentage, and it is pretty safe to assume that your application is not one of them.

That said, most of my web sites and hacks venture far into the territory of doing things backward, one way or another. I can assure you that the visitor appeal of said hacks, measured in raw numbers, are inversely proportional to their obscurity. The same is true of my obscure writing.

JSEnv live XPath visualizer

I've had some productive hack weekends recently -- last weekend, among other things, I took a plunge into the Firebug 1.1 beta, both to re-apply a rather useful feature patch I submitted upstreams a year ago (which was lost, and found, and lost and found again -- might make 1.2) and to add some handy keyboard shortcuts to the HTML view (deleting nodes with delete and backspace, and both folding/unfolding and stepping up/down the DOM tree with arrow left and right).

Anyway, I ended up excavating Firebug's highlight-a-node code to turn it into a tiny lib and then use that lib for beefing up Jesse Ruderman's jsenv bookmarklet with a live edit XPath field highlighting all matches in the page as you type:



It tells you what the expression matches in the title bar of the jsenv window, and signals some additional colour coded info via the XPath input field's border:

• red for illegal expressions,
• green for matching nodes,
• gray for 0 matched nodes,
• yellow for a string,
• blue for a number and
• magenta for a boolean value.

Ah, one more feature -- you move the focus node you see with arrow up and down in the input field, or scroll wheel up/down when hovering it.

The ideal spot for this feature would probably be as an extra feature to toggle on and off in Firebug's HTML view -- to filter the view by, for instance. The more I think of it, the more useful this feature would be in that shape. I hope the Firebug Working Group is as open to additional community developers as it seems to aim for.

Anyway, here is the XPath jsenv; enjoy!

Google safing passwords

Apparently, lots of places on the net, prominently including all WordPress blogs, use unsalted hashes for password verification, i e you get to log in if hash(given password) == hash stored in the password database; commonly using cryptographic hash functions like MD5 or SHA1. If that password database leaks, people can fairly effortlessly use Google as an O(1) lookup function from hash to plaintext, for most weak passwords.

The problem is easily avoided by using salted passwords -- i e hashing the password concatenated with a random component, say 32 bits long, and storing this salt next to the hash, in plaintext. Net effect: your password database, if compromised, will not be susceptible to the same attack, as the search space is 4,294,967,296 times as large, making it less likely that Google knows how to reverse map the hash for you.

I whipped up a quick tool to see whether a password is susceptible to the Google lookup or not (for MD5 and SHA1, and optionally, whether the plaintext password itself is found on the web too, though I discourage using it for reasons of potential snooping of your traffic). The hack uses some neat client side tools to query Google's Searchmash, using Yahoo! Pipes to decorate its JSON result with the JSONP callback they apparently lack (Google unfortunately still rarely gets that right), and some micro-libraries I've started accumulating recently:

Sample Google for a password dictionary attack on:

Check the checkbox to query google for the plaintext version of your prospective password, and not just cryptographic hashes of it. (Anyone snooping your, Google's or Yahoo's network traffic, will see it.)

User scripting new GMail messages

With the recent change in how GMail works, lots of prior user scripts improving the service, like a small hack that removes <font size="+1"> tags from mails broke, in the wake of the DHTML improvements (which make the site more difficult to augment via user scripting).

The GMail developers, generously, were not very far behind to release a smallish Greasemonkey API, somewhat alleviating the problem -- but it still is less than trivial to target mail bodies with your user scripts.

I took a stab at it the other night, to figure out what would go into it, and managed to come up with a new font manhandler (it targets a rather local nuisance on the Greasemonkey mailing lists). As I have been trying out MailPlane for a while for reading my mail I decided to see if I could make the script run both in Firefox on Greasemonkey and Safari/WebKit/MailPlane on the GreaseKit user script manager. That turned out quite doable. The script, in its entirety:

// ==UserScript==
// @name           Gmail - deBill:ifier
// @namespace      http://code.google.com/p/ecmanaut/
// @description    Manhandles all font size tags to stop all the yellin'
// @include        https://mail.google.com/*
// @include        http://mail.google.com/*
// ==/UserScript==

window.addEventListener("load", loader, false);

function loader() {
  var api = typeof unsafeWindow != "undefined" && unsafeWindow.gmonkey ||
    (frames.js ? frames.js.gmonkey : null);
  if (api) api.load("1.0", init);
}

function init(gmail) {
  function viewChanged() {
    var view = gmail.getActiveViewType();
    if ("cv" == view) {
      var div = gmail.getActiveViewElement();
      div.addEventListener("DOMNodeInserted", deBill, false);
    }
  }
  gmail.registerViewChangeCallback(viewChanged);
}

function deBill(event) {
  var font = event.target.getElementsByTagName("font");
  for (var i = 0; i < font.length; i++)
    font[i].removeAttribute("size");
}

Feel very free to base your own hacks on the recipe. I recommend starting out with an action function that does something basic like setting event.target.outline = "1px solid red", to see where it does what it does -- since the callback runs for every conversation view change, including updates to the ad pane on the right, not only when expanding mails you read.