Be sure to read The Future of Reading (A Play in Six Acts).  

If you think that DRM for books is no more scary than DRM for music and movies, this persuasively chosen selection of old and new quotes from Jeff Bezos, George Orwell, Newsweek, and Richard Stallman might change your mind.

I agonized over various choices for my next phone, and finally decided on the Blackberry Curve based on some advice from Christian.

After a few weeks, I’m pleased with my decision. The Curve is significantly smaller and lighter than the Blackberry 8800 it replaces, yet the keyboard is actually more usable. While light, the phone feels solid and well built. Voice quality is excellent.

A few random notes:

Gmail: I found it painless to link my Blackberry with my Gmail account; I just entered my credentials and I was good to go.  The experience of sending and receiving email doesn’t feel like a step down from BES and Exchange.

Contacts: What is a step down is handling of contacts– the Blackberry doesn’t sync with my Gmail contacts. I did a one-time import of contacts, and so forth from my old Blackberry using RIM’s handy device migration wizard, but my contacts are growing progressively more stale.

Notifications: Notification icons on the home page can be extended by applications, which is really useful–  when I installed the Facebook app and received a Facebook message, I saw a Facebook-branded new message indicator on the home page.

Instant Messaging: Instant messaging is as a first-class action in the UI– anywhere I can call or SMS someone, I can also IM them.  (Not that this has made me a rampant user of phone IM, by the way.)

Wifi: This phone supports wifi, and can place voice calls over wifi.  If your cell reception at home is bad (as mine is), you will notice better quality in voice calls  and faster/more reliable data connections. 

Unlike with the IPhone you won’t see a meaningful increase in browsing speed when a strong cell signal is available; hopefully this is something Blackberry will improve in later releases.

My first personal experience with Facebook Beacon was viscerally negative.

After playing the flash game Super Crazy Guitar Maniac Deluxe 2 on Kongregate, I was surprised to see that my secret longing for guitar superstardom was splashed across my Facebook homepage.

That’s none of Facebook’s business! The information was shared with Facebook without asking my permission or even telling me that it was going to happen. Does Facebook get to use this information to tailor their marketing to me?

What’s worse, Facebook was about to tell all of my friends, with a convoluted opt-out UI. Where’s the No thanks button?!! (Note that this is Facebook’s improved UI in reaction to user complaints; I’m glad I didn’t see the first one.)

I’m not a designer, but I’d like to propose the following alternate UI which might better accomplish Facebook’s goals for Beacon (with apologies to Mike Collins.)

Contrast Facebook with Google. 

Sure Google gathers and aggregates your searching, browsing, and purchasing behavior across the internet.

But they don’t tell other sites about it, and they don’t your friends about it. That significantly better than Facebook (so long as Google’s hacker and anti-government defenses remain strong!) And in case you might have any lingering privacy concerns, Google also doesn’t share their knowledge about you with you, granting us all the refuge of blissful ignorance.

Google has been enlightened enough to provide a GreaseMonkey API for Gmail; this message describes how I was able to use this same API from a Firefox toolbar authored using XUL.

The API provides methods and events that allow authors of Greasemonkey scripts to customize the GMail user experience. (See userscripts.org/tag/gmail for a number of useful GMail extensions.)

Because of security restrictions on the interactions allowed between trusted toolbar “chrome” and untrusted web pages, you’ll receive a scripting error if you attempt to simply call gmonkey.load() on the document object of the enclosed web page

Instead, I used the techniques described on developer.mozilla.org to allow the chrome and the webpage to interact. (If there’s a better/simpler way to make this work, please let me know!)

1. I used a "javascript:" URL to cause the gmonkey script to be loaded in the context of the GMail web page.

window.content.document.location =
"javascript:window.gmonkey.load('1.0', " + ML_GmailCallback + ")";

2. I dispatched a custom event to communicate information from the web page back out to the chrome:

foobar="something interesting";
var element = document.createElement("MyElement");
element.setAttribute("foobar", foobar);
document.documentElement.appendChild(element);

var evt = document.createEvent("HTMLEvents");
evt.initEvent("MyEvent", true, false);
element.dispatchEvent(evt);

3. I listened for this event in the chrome:

function ML_GmailListener(evt) {
    doSomethingCool(evt.target.getAttribute("foobar"));
}

doc.addEventListener("MyEvent", function(e)  { ML_GmailListener(e); },
    false, true); 

XUL is a cool and rapid way to develop toolbars in Firefox, and a vast improvement over Internet Explorer’s model.

I was surprised, however, to discover that there a surprisingly low degree of namespace and object isolation between toolbars. I discovered this when I included prototype.js in my project, and found that I had broken the Facebook toolbar. 

Why?  Prototype.js adds additional methods to the array prototype, and this breaks the Facebook toolbar, which uses the "for (x in a)" idiom to iterate through the elements of the array, which now include the newly added functions.  The Facebook toolbar doesn’t expect these and blows up.

I hacked around this for the moment by modifying prototype.js to only add the special array extensions when I ask it to via the $A function. 

(Sadly, the prototype folks in the forums don’t think this more conservative behavior will ever be incorporated as an option in the main code line;  their philosophy is that no one should use the bad idiom or have to coexist with anyone who uses it.)

Even this is a total fix since there is a chance that some random toolbar author will reuse one of the same global variable names that prototype or I do. 

I mention this primarily so that other’s don’t fall into the same gotcha; hopefully future versions of Firefox will have a better toolbar isolation model for reliability and security reasons.