Adrian Holovaty: Why Greasemonkey is good for publishers [via Simon Willison]
I’m looking forward to the next step... where producers insert in hooks designed for extensibility. This could be as simple as agreeing on div class names.
... or as complex as defining MicroFormats.
I’m convinced that Greasemonkey and MicroFormats are destined for each other.
I have long posited that the easiest way for developers to pick “low hanging fruit” new features for upcoming releases is to look at what add-ons third party developers have developed. Once upon a time, Mac OS had no concept of screensavers built into the OS. After Dark, Moire, and a myriad of others were written (often interacting badly with the OS — this was pre-OS X days where extension conflicts were the norm), and they were wildly popular despite the conflicts. Ditto menubar clock (I believe Apple actually bought out SuperClock, a third party menubar clock). Ditto the Windows 3.1 file manager. Ditto the Windows firewall.
The downside is that the new built-in functionality may be inferior to previous third-party attempts, e.g. Watson/Sherlock, ZoneAlarm/Windows XP firewall, and Adaware/Microsoft’s new “malicious application detection” tool. This in turn can stifle further innovation, since the built-in functionality is viewed as “good enough.” And obviously what users want is not always what developers/publishers want to provide, e.g. ad-blocking. There are also licensing issues; usually developers can’t simply integrate the third-party code verbatim without buying them out or agreeing on special licensing terms.
That said, I am naturally cynical and pessimistic about the future of mass customization, and I don’t foresee most web publishers being terribly happy with Greasemonkey. There are precedents of all-out reformatting of sites, like one last year where a third-party set up an accessible version of a site after a particularly craptacular redesign, by scraping all the content and redisplaying it in an accessible fashion. IIRC, they were forced to shut down the accessible site on copyright grounds. The line between that and doing the same via Greasemonkey is a fuzzy grey line, and I expect there will be high-profile cases in the near future of user script authors getting cease-and-desist letters from publishers who don’t like people creating new-and-improved versions of their precious content.
Mark said:
IIRC, they were forced to shut down the accessible site on copyright grounds.
They shut that site down due to security concerns and never threatened copyright infringement. It was a UK movie listing site, right? The issues cited in the cease and desist was that the accessible site, in addition to being accessible, was also taking user/password and possibly even credit card information and passing it along to the original non-accessible site. A pretty obvious no-no when there’s a chance the user thinks they’re using the real site. It echoed around the blogosphere under the guise of a copyright issue but the original cease and desist was sensible IIRC.
Not the point, I know.
I think you’re right though, local modification of content is going to be a hard sell to a substantial portion of content producers. Even people who understand the web like Winer seem to be down on the idea of giving people too much control of their browser.
They shut that site down due to security concerns and never threatened copyright infringement. It was a UK movie listing site, right?
I stand corrected.
I dug up this link that explains the whole debacle: [link]
They shut that site down due to security concerns and never threatened copyright infringement.
The main excuse was security concerns. Yet it was bunk. The accessible interface did not accessify the login sections of the site. There was no personal data being received by the accessible version. The limits of the accessible version were just tracking down times and venues of movies, not online booking.
They did refer to trademark infringements in their complaint - even after knowing and allowing for the site for well over a year. My guess is that the were embarrassed that close to half of their traffic was coming via the accessible site (which was just a proxy with a javascript-dependent tag-soup to accessible HTML transcoding).
Here’s the story from Matthew Somerville, the brains behind the accessible version: [link]
As Mark suggests, the precedent for legal threats against GreaseMonkey improvements is there. I hope that most publishers will take the hint and improve their websites, and realising at the same time that will make both the GreaseMonkey script and legal action unnecessary.
There has been discussions in CSS circles about consistent use of class names. For example [link]