Journal tags: email

I got a nice email from someone regarding my recent posts about performance on The Session. They said:

I hope this message finds you well. First and foremost, I want to express how impressed I am with the overall performance of https://thesession.org/. It’s a fantastic resource for music enthusiasts like me.

How nice! I responded, thanking them for the kind words.

They sent a follow-up clarification:

Awesome, anyway there was an issue in my message.

The line ‘It’s a fantastic resource for music enthusiasts like me.’ added by chatGPT and I didn’t notice.

I imagine this is what it feels like when you’re on a phone call with someone and towards the end of the call you hear a distinct flushing sound.

I wrote back and told them about Simon’s rule:

I will not publish anything that takes someone else longer to read than it took me to write.

That just feels so rude!

I think that’s a good rule.

I like reading RSS feeds. I’ve written before about how my feed reader feels different to my email client:

When I open my RSS reader to catch up on the feeds I’m subscribed to, it doesn’t feel like opening my email client. It feels more like opening a book. And, yes, books are also things to be completed—a bookmark not only marks my current page, it also acts as a progress bar—but books are for pleasure. The pleasure might come from escapism, or stimulation, or the pursuit of knowledge. That’s a very different category to email, calendars, and Slack.

Giles put it far better when described what using RSS feeds feels like :

To me, using RSS feeds to keep track of stuff I’m interested in is a good use of my time. It doesn’t feel like a burden, it doesn’t feel like I’m being tracked or spied on, and it doesn’t feel like I’m just another number in the ads game.

To me, it feels good. It’s a way of reading the web that better respects my time, is more likely to appeal to my interests, and isn’t trying to constantly sell me things.

That’s why I feel somewhat conflicted about email newsletters. On the one hand, people are publishing some really interesting things in newsletters. On the hand, the delivery mechanism is email, which feels burdensome. Add tracking into the mix, and they can feel downright icky.

But never fear! My feed reader came to the rescue. Many newsletter providers also provide RSS feeds. NetNewsWire—my feed reader of choice—will try to find the RSS feed that corresponds to the newsletter. Hurrah!

I get to read newsletters without being tracked, which is nice for me. But I also think it would be nice to let the authors of those newsletters know that I’m reading. So here’s a list of some of the newsletters I’m currently subscribed to in my feed reader:

The Whippet by McKinley Valentine:

A newsletter for the terminally curious.

Sentiers by Patrick Tanguay:

A carefully curated selection of articles with thoughtful commentary on technology, society, culture, and potential futures.

The Fitzwilliam:

Policy, ethics and applied rationality with an Irish slant.

The Science Of Fiction:

How science shapes stories about the future and how stories about the future shape science.

Adjacent Possible by Steven Johnson:

Exploring where good ideas come from—and how to keep them from turning against us.

Faster, Please! by James Pethokoukis:

Discovering, creating, and inventing a better world through technological innovation, economic growth, and pro-progress culture.

undefended / undefeated by Sara Hendren:

Ideas at the heart of material culture—the everyday stuff in all our lives

Today in Tabs by Rusty Foster:

Your favorite newsletter’s favorite newsletter.

I’ve been reading the excellent Design For Safety by Eva PenzeyMoog. There was a line that really stood out to me:

The idea that it’s alright to do whatever unethical thing is currently the industry norm is widespread in tech, and dangerous.

It stood out to me because I had been thinking about certain practices that are widespread, accepted, and yet strike me as deeply problematic. These practices involve tracking users.

The first problem is that even the terminology I’m using would be rejected. When you track users on your website, it’s called analytics. Or maybe it’s stats. If you track users on a large enough scale, I guess you get to just call it data.

Those words—“analytics”, “stats”, and “data”—are often used when the more accurate word would be “tracking.”

Or to put it another way; analytics, stats, data, numbers …these are all outputs. But what produced these outputs? Tracking.

Here’s a concrete example: email newsletters.

Do you have numbers on how many people opened a particular newsletter? Do you have numbers on how many people clicked a particular link?

You can call it data, or stats, or analytics, but make no mistake, that’s tracking.

Follow-on question: do you honestly think that everyone who opens a newsletter or clicks on a link in a newsletter has given their informed constent to be tracked by you?

You may well answer that this is a widespread—nay, universal—practice. Well yes, but a) that’s not what I asked, and b) see the above quote from Design For Safety.

You could quite correctly point out that this tracking is out of your hands. Your newsletter provider—probably Mailchimp—does this by default. So if the tracking is happening anyway, why not take a look at those numbers?

But that’s like saying it’s okay to eat battery-farmed chicken as long as you’re not breeding the chickens yourself.

When I try to argue against this kind of tracking from an ethical standpoint, I get a frosty reception. I might have better luck battling numbers with numbers. Increasing numbers of users are taking steps to prevent tracking. I had a plug-in installed in my mail client—Apple Mail—to prevent tracking. Now I don’t even need the plug-in. Apple have built it into the app. That should tell you something. It reminds me of when browsers had to introduce pop-up blocking.

If the outputs generated by tracking turn out to be inaccurate, then shouldn’t they lose their status?

But that line of reasoning shouldn’t even by necessary. We shouldn’t stop tracking users because it’s inaccurate. We should stop stop tracking users because it’s wrong.

The Clearleft newsletter goes out every two weeks on a Thursday. You can peruse the archive to see past editions.

I think it’s a really good newsletter, but then again, I’m the one who writes it. It just kind of worked out that way. In theory, anyone at Clearleft could write an edition of the newsletter.

To make that prospect less intimidating, I put together a document for my colleagues describing how I go about creating a new edition of the newsletter. Then I thought it might be interesting for other people outside of Clearleft to get a peek at how the sausage is made.

So here’s what I wrote…

Topics

The description of the newsletter is:

A round-up of handpicked hyperlinks from Clearleft, covering design, technology, and culture.

It usually has three links (maybe four, tops) on a single topic.

The topic can be anything that’s interesting, especially if it’s related to design or technology. Every now and then the topic can be something that incorporates an item that’s specifically Clearleft-related (a case study, an event, a job opening). In general it’s not very salesy at all so people will tolerate the occasional plug.

You can use the “iiiinteresting” Slack channel to find potential topics of interest. I’ve gotten in the habit of popping potential newsletter fodder in there, and then adding related links in a thread.

Tone

Imagine you’re telling a friend about something cool you’ve just discovered. You can sound excited. Don’t worry about this looking unprofessional—it’s better to come across as enthusiastic than too robotic. You can put real feelings on display: anger, disappointment, happiness.

That said, you can also just stick to the facts and describe each link in turn, letting the content speak for itself.

If you’re expressing a feeling or an opinion, use the personal pronoun “I”. Don’t use “we” unless you’re specifically referring to Clearleft.

But most of the time, you won’t be using any pronouns at all:

So-and-so has written an article in such-and-such magazine on this-particular-topic.

You might find it useful to have connecting phrases as you move from link to link:

Speaking of some-specific-thing, this-other-person has a different viewpoint.

or

On the subject of this-particular-topic, so-and-so wrote something about this a while back.

Structure

The format of the newsletter is:

1. An introductory sentence or short paragraph.
2. A sentence describing the first link, ending with the title of the item in bold.
3. A link to the item on its own separate line.
4. An excerpt from the link, usually a sentence or two, styled as a quote.
5. Repeat steps 2 to 4 another two times.


Take a look through the archive of previous newsletters to get a feel for it.

Subject line

Currently the newsletter is called dConstruct from Clearleft. The subject line of every edition is in the format:

dConstruct from Clearleft — Title of the edition

(Note that’s an em dash with a space on either side of it separating the name of the newsletter and the title of the edition)

I often try to come up with a pun-based title (often a punny portmanteau) but that’s not necessary. It should be nice and short though: just one or two words.

Firefox has a nifty extension—made by Mozilla—called Facebook Container. It does two things.

First of all, it sandboxes any of your activity while you’re on the facebook.com domain. The tab you’re in is isolated from all others.

Secondly, when you visit a site that loads a tracker from Facebook, the extension alerts you to its presence. For example, if a page has a share widget that would post to Facebook, a little fence icon appears over the widget warning you that Facebook will be able to track that activity.

It’s a nifty extension that I’ve been using for quite a while. Except now it’s gone completely haywire. That little fence icon is appearing all over the web wherever there’s a form with an email input. See, for example, the newsletter sign-up form in the footer of the Clearleft site. It’s happening on forms over on The Session too despite the rigourous-bordering-on-paranoid security restrictions in place there.

Hovering over the fence icon displays this text:

If you use your real email address here, Facebook may be able to track you.

That is, of course, false. It’s also really damaging. One of the worst things that you can do in the security space is to cry wolf. If a concerned user is told that they can ignore that warning, you’re lessening the impact of all warnings, even serious legitimate ones.

Sometimes false positives are an acceptable price to pay for overall increased security, but in this case, the rate of false positives can only decrease trust.

I tried to find out how to submit a bug report about this but I couldn’t work it out (and I certainly don’t want to file a bug report in a review) so I’m writing this in the hopes that somebody at Mozilla sees it.

What’s really worrying is that this might not be considered a bug. The release notes for the version of the extension that came out last week say:

Email fields will now show a prompt, alerting users about how Facebook can track users by their email address.

Like …all email fields? That’s ridiculous!

I thought the issue might’ve been fixed in the latest release that came out yesterday. The release notes say:

This release addresses fixes a issue from our last release – the email field prompt now only displays on sites where Facebook resources have been blocked.

But the behaviour is unfortunately still there, even on sites like The Session or Clearleft that wouldn’t touch Facebook resources with a barge pole. The fence icon continues to pop up all over the web.

I hope this gets sorted soon. I like the Facebook Container extension and I’d like to be able to recommend it to other people. Right now I’d recommed the opposite—don’t install this extension while it’s behaving so overzealously. If the current behaviour continues, I’ll be uninstalling this extension myself.

Update: It looks like a fix is being rolled out. Fingers crossed!

I’ve been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.

I’ve written before about how I’ve got a blind spot for the web so it’s no surprise that I was praising the use of a well marked-up form, styled clearly, and unencumbered by unnecessary JavaScript. But other technologies were in play too: Short Message Service (SMS) and email.

All of those technologies are platform-agnostic.

No matter what operating system I’m using, or what email software I’ve chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: “Doctor, it hurts when I do this.” (“Well, don’t do that.”)

No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.

Then there’s the web. No matter what operating system I’m using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I’ve chosen to use, the World Wide Web works.

I originally said:

It feels like the principle of least power in action.

But another way of rephrasing “least power” is “most availability.” Technologies that are old, simple, and boring tend to be more widely available.

I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of “system requirements”: operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.

Hence my soft spot for the boring and basic technologies like email, SMS, and yes, web pages. The difference with web pages is that you can choose to layer added extras on top. As long as the fundamental functionality is using universally-supported technology, you’re free to enhance with all the latest CSS and JavaScript. If any of it fails, that’s okay: it falls back to a nice solid base.

Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.

Anyway, I’ve been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.

QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there’s something nice and lo-fi about them. They’re like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren’t so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you’re about to rickroll yourself.

Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I’ve always found the prospect of doing something with, say, Twilio’s API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.

I know very little about chat apps or voice apps, but I don’t think there’s a cross-platform format that works with different products, right? I imagine it’s like the situation with native apps which require a different codebase for each app store and operating system. And so there’s a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.

They’re trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that’s the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.

The wastefulness of having to write the same app for multiple platforms isn’t the only thing that puts me off making native apps. The exclusivity works in two directions. There’s the exclusive nature of the runtime that requires a bespoke codebase. There’s also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can’t just walk in and put your software on the shelf. That’s the shopkeeper’s job.

There is no shopkeeper for the World Wide Web.

Progressive enhancement is at the heart of everything I do on the web. It’s the bedrock of my speaking and writing too. Whether I’m writing about JavaScript, Ajax, HTML, or service workers, it’s always through the lens of progressive enhancement. Sometimes I explicitly bang the drum, like with Resilient Web Design. Other times I don’t mention it by name at all, and instead talk only about its benefits.

I sometimes get asked to name some examples of sites that still offer their core functionality even when JavaScript fails. I usually mention Amazon.com, although that has other issues. But quite often I find that a lot of the examples I might mention are dismissed as not being “web apps” (whatever that means).

The pushback I get usually takes the form of “Well, that approach is fine for websites, but it wouldn’t work something like Gmail.”

It’s always Gmail. Which is odd. Because if you really wanted to flummox me with a product or service that defies progressive enhancement, I’d have a hard time with something like, say, a game (although it would be pretty cool to build a text adventure that’s progressively enhanced into a first-person shooter). But an email client? That would work.

Identify core functionality.

Read emails. Write emails.

Make that functionality available using the simplest possible technology.

HTML for showing a list of emails, HTML for displaying the contents of the HTML, HTML for the form you write the response in.

Enhance!

Now add all the enhancements that improve the experience—keyboard shortcuts; Ajax instead of full-page refreshes; local storage, all that stuff.

Can you build something that works just like Gmail without using any JavaScript? No. But that’s not what progressive enhancement is about. It’s about providing the core functionality (reading and writing emails) with the simplest possible technology (HTML) and then enhancing using more powerful technologies (like JavaScript).

Progressive enhancement isn’t about making a choice between using simpler more robust technologies or using more advanced features; it’s about using simpler more robust technologies and then using more advanced features. Have your cake and eat it.

Fortunately I no longer need to run this thought experiment to imagine what it would be like if something like Gmail were built with a progressive enhancement approach. That’s what HEY is.

Sam Stephenson describes the approach they took:

HEY’s UI is 100% HTML over the wire. We render plain-old HTML pages on the server and send them to your browser encoded as text/html. No JSON APIs, no GraphQL, no React—just form submissions and links.

If you think that sounds like the web of 25 years ago, you’re right! Except the HEY front-end stack progressively enhances the “classic web” to work like the “2020 web,” with all the fidelity you’d expect from a well-built SPA.

See? It’s not either resilient or modern—it’s resilient and modern. Have your cake and eat it.

And yet this supremely sensible approach is not considered “modern” web development:

The architecture astronauts who, for the past decade, have been selling us on the necessity of React, Redux, and megabytes of JS, cannot comprehend the possibility of building an email app in 2020 with server-rendered HTML.

HEY isn’t perfect by any means—they’ve got a lot of work to do on their accessibility. But it’s good to have a nice short answer to the question “But what about something like Gmail?”

It reminds me of responsive web design:

When Ethan Marcotte demonstrated the power of responsive design, it was met with resistance. “Sure, a responsive design might work for a simple personal site but there’s no way it could scale to a large complex project.”

Then the Boston Globe launched its responsive site. Microsoft made their homepage responsive. The floodgates opened again.

It’s a similar story today. “Sure, progressive enhancement might work for a simple personal site, but there’s no way it could scale to a large complex project.”

The floodgates are ready to open. We just need you to create the poster child for resilient web design.

It looks like HEY might be that poster child.

I have to wonder if its coincidence or connected that this is a service that’s also tackling ethical issues like tracking? Their focus is very much on people above technology. They’ve taken a human-centric approach to their product and a human-centric approach to web development …because ultimately, that’s what progressive enhancement is.

I’ve been using Mailchimp for years now to send out a weekly newsletter from The Session. But I never visit the Mailchimp website. Instead, I use the API to create a campaign each week, and then send it out. I also use the API whenever a member of The Session updates their email preferences (or changes their details).

I got an email from Mailchimp that their old API was being deprecated and I’d need to update to their more recent one. The code I was using had been happily running for about seven years, but now I’d have to change it.

Luckily, Drew has written a really handy Mailchimp API wrapper for PHP, the language that The Session’s codebase is in. Thanks, Drew! I downloaded that wrapper and updated my code accordingly.

Everything went pretty smoothly. I was able to create campaigns, send campaigns, add new subscribers, and delete subscribers. But I ran into an issue when I wanted to update someone’s email address (on The Session, you can edit your details at any time, including your email address).

Here’s the set up:

use \DrewM\MailChimp\MailChimp;
$MailChimp = new MailChimp('abc123abc123abc123abc123abc123-us1');
$list_id = 'b1234346';
$subscriber_hash = $MailChimp -> subscriberHash('currentemail@example.com');
$endpoint = 'lists/'.$listID.'/members/'.$subscriber_hash;

Now to update details, according to the API, I can use the patch method on that endpoint:

$MailChimp -> patch($endpoint, [
    'email_address' => 'newemail@example.com'
]);

But that doesn’t work. Mailchimp effectively treats email addresses as unique IDs for subscribers. So the only way to change someone’s email address appears to be to delete them, and then subscribe them fresh with the new email address:

$MailChimp -> delete($endpoint);
$newendpoint = 'lists/'.$listID.'/members';
$MailChimp -> post($newendpoint, [
    'email_address' => 'newemail@example.com',
    'status' => 'subscribed'
]);

That’s somewhat annoying, as the previous version of the API allowed email addresses to be updated, but this workaround isn’t too arduous.

Anyway, I figured it share this just in case it was useful for anyone else migrating to the newer API.

Update: Belay that. Turns out that you can update email addresses, but you have to be sure to include the status value:

$MailChimp -> patch($endpoint, [
    'email_address' => 'newemail@example.com',
    'status' => 'subscribed'
]);

Okay, that’s a lot more straightforward. Ignore everything I said.

What hath God wrought?

Mr. Watson, come here—I want to see you.

lo

Larry, can you get my razor?

Quite quickly after I wrote my email to Findings about their email notification anti-pattern, I got a response back from Lauren Leto:

Give it to us. I applaud you shouting at us from a rooftop. I also hate defaulting to all notifications and agree that it was a douchebag startup move but can assure it was one made accidentally - a horrible oversight that the entire team feels bad about and will work to amend for you and the rest of our users.

We try to be a site for the common user - nothing like Facebook taking cheap shots wherever they can. I hope we haven’t forever turned you off from our site. Relaunches are hard and mistakes were made but nothing like this will happen again.

Apart from the use of the passive voice (“mistakes were made” rather than “we made mistakes”), that’s a pretty damn good response. She didn’t try to defend or justify the behaviour. That’s good.

She also asked if there was anything they could do to make it up to me. I asked if I could publish their response here. “Yeah, feel free to post”, she said.

I think it’s important that situations like this get documented. It could be especially useful for new start-ups who might be thinking about indulging in a bit of “growth hacking” (spit!) under the impression that this kind of behaviour is acceptable just because other start-ups—like Findings—implemented the email notification anti-pattern.

As Lauren said:

I think every startup manages to mess up one of these at some point in their life, either willingly or unwillingly. A clear listing of all offenses could be useful to everyone.

That’s where Harry’s Dark Patterns wiki comes in:

The purpose of this pattern library is to “name and shame” Dark Patterns and the companies that use them.

• For consumers, forewarned is fore-armed.
• For brand-owners, the bad-press associated with being named as an offender should discourage usage.
• For designers, this site provides ammunition to refuse unethical requests by our clients / bosses. (e.g. “I won’t implement opt-out defaults for the insurance upsells because that practice is considered unethical and it will get you unwanted bad press.”)

The email notification anti-pattern isn’t yet listed on the wiki. I’ll see if I can get Harry to add it.

Dear Findings,

I see you have introduced some new email notifications. I have also noticed (via my newly-overstuffed inbox) that by default, these new email notifications are checked.

WHAT THE FSCK WERE YOU THINKING‽

Sorry. Sorry. I lost my temper for a moment there. And the question is rhetorical because I think I know exactly what you were thinking …“traction”, “retention”, “engagement”, yadda yadda.

I realise that many other sites also do this. That does not make it right. In fact, given the sites that already do this include such pillars of empathy as Facebook, I would say that this kind of behaviour probably has a one-to-one correlation with the douchebaggery of the site in question.

You’re better than this.

Stop. Think. Spare a thought for those of us who don’t suddenly—from one day to the next—want our inboxes spammed by emails we never opted into.

Didn’t anybody stop to think about just how intrusive this would be?

Also, doesn’t this flood of new emails directly contradict this section of your privacy policy?:

As part of the Services, you may occasionally receive email and other communications from us, such as communications relating to your Account. Communications relating to your Account will only be sent for purposes important to the Services, such as password recovery.

Contrary to appearances, I don’t want to be completely negative, so I’ve got a constructive suggestion.

How about this:

If you’re about to introduce new email notifications, and all my existing notification settings are set to “off”, perhaps you could set the new notifications to “off” as well?

Sound good?

All the best,

Jeremy

I’m sure that by now you’ve already seen the infamous email from Richard Stallman—free software’s own worst enemy—detailing his somewhat eccentric approach to speaking at conferences.

I particularly like the memetic variation of The Stallman Dialogues. There’s a real genius in the way that it quotes passages from the email verbatim.

Y’know, I’m supposed to have a Skype call with Andy sometime next week about my upcoming talk and workshop at Build (tickets are still available for the workshop, by the way). I’m very tempted to channel my inner Stallman for the duration of our conversation.

Meeting that sad animal is not an agreeable surprise.

Design patterns are useful. They enable us as developers to encapsulate recurring interactions and refine them. From simple pagination right up to Ajax requests, patterns allow us to codify common conventions.

Inevitably, conventions can lead to a cargo cult mentality. Clients start to request Web 2.0 standards. I have no idea what that means but it usually involves tagging, “friends” and gratuitous use of JavaScript. This kind of copycat development isn’t so bad if you’re ripping off a site like Flickr—the more sites like Flickr, the better. The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be phished.

This issue was raised by Tantek at Fundamentos Web. Rigo Wenning—privacy activity lead at the W3C—was quick to back Tantek’s position. While we can’t protect people from themselves, we have a duty not to deceive them into thinking that throwing passwords around like confetti is acceptable behaviour.

Oh, don’t worry… the terms of service for Google accounts puts the responsibility in the hands of the user:

• Your passwords and account security
  • 6.1 You agree and understand that you are responsible for maintaining the confidentiality of passwords associated with any account you use to access the Services.
  • 6.2 Accordingly, you agree that you will be solely responsible to Google for all activities that occur under your account.

…but this isn’t a question of legalities.

I was somewhat surprised, even shocked, to see 37 Signals highlight this anti-pattern on Facebook as a smart way to connect members of the site. Simon was quick to point out the problem:

The Facebook thing isn’t a smart way of connecting members, it’s a horrible precedent that teaches users to be phished. Unfortunately that kind of feature is so prevalent now that you’d be foolish to launch a new social network without it, but from an ethical point of view it’s distinctly unpleasant.

He’s right. The issue for us as developers is a moral question. Do we blindly follow the dictates of clients looking to “add value” to their applications even when we know that the long-term effect is corrosive? I don’t think we should. We can collectively make a choice not to erode the long-term stability of our users’ data. Sure, the particular site you’re working on might not have any nefarious plans and the next site might claim to be secure, but over time we’re creating a climate conducive to cultivating honeypots.

Morality (or ethics) is not something that’s usually discussed alongside Web development. But Jeff Veen pointed me towards this great quote from Jamais Cascio’s talk at the Singularity Summity that illustrates the underlying truth:

To put it bluntly, software, like all technologies, is inherently political. Even the most disruptive technologies, the innovations and ideas that can utterly transform society, carry with them the legacies of past decisions, the culture and history of the societies that spawned them. Code inevitably reflects the choices, biases and desires of its creators.

So here’s what I’m going to do: even if it costs me a contract in the short-term, I will refuse to implement any kind of interface that involves asking the user for a password from a third-party site. I urge you to do the same. And if you feel equally strongly about this, make your thoughts known: blog about it, talk about it… you might even want to make your position clear in your terms and conditions. As the Naked Yak blog so eloquently puts it:

With the endless possibilities of the social web it is easy to fall into the trap of going for broke, applying everything in life to a particular application or piece of software that seems to enhance it. From now, I will always ask the question “Will this have a positive effect on my world?” rather than “What could I pull into this new tool?”

Update: For all the people saying yeah, but no, but yeah, but we need access to users’ data, please read the post again and this time, pay attention to the part about OAuth. See also:

• The Flickr authentication API and
• Google’s AuthSub.

I don’t know how much clearer I can make this: the end result of exporting data is desirable; teaching users to hand over their passwords to any site that asks for them is not. There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site.

Date

3 July 2007 10:37:16 BDT

Subject

Adactio message from Michael McDonald

Mister Wong, Europe’s largest Social Bookmarking portal, is now available in English!

My name is Michael, from Mister Wong, and I am preparing the launch of the portal for the English speaking community. Your blog, Adactio, caught our eye while researching. We would, therefore, like to warmly invite you to try out Mister Wong as a beta tester.

In exchange for importing your bookmarks and feedback, you will receive a Mister Wong T-shirt and a pin set. In addition, we are also giving away an iPod Nano to one of our lucky testers.

Date

3 July 2007 10:47:09 BDT

Subject

Re: Adactio message from Michael McDonald

Hi Michael,

Great! Here’s a bookmark I’d like to share with you:

Mister Wong, the Offensive Social Bookmarking Portal

kthxbai!

Tchuess,

Jeremy

Since I started working at the Clearleft office, I’ve been using a lovely new 20 inch Intel iMac. That’s great… but it means that I now use three different machines; I have my 17 inch G4 iMac at home and my 12 inch G4 iBook for when I’m on the move. I decided that I really needed to centralise all my data.

The first step was a no-brainer: start using IMAP instead of POP for my email. This is something I should have done a long time ago but I’ve just been putting it off. I’ve got six different email accounts so I knew it would be a bit of chore.

After a few false starts and wrong turns, I got everything up and running on all three computers. Unfortunately somewhere along the way I lost a couple of emails from the last day or two.

Which reminds me…

If you’re the person who sent me an email about doing a pre-Reboot podcast interview (or if anyone else out there knows who I’m talking about), please write to me again — I lost your email but I’d love to have a chat.

Anyway…

With my email all set up, that left contacts and calendars. I looked into contact syncing services like Plaxo but I wasn’t all that impressed by what I saw (and tales of address book spamming really put me off). In the end, I decided to drink the Apple koolaid and get a .Mac account. I doubt I’ll make use of any of the other services on offer (I certainly don’t plan to send any electronic postcards… sheesh!) but I think it’ll be worth it just for the Address Book and iCal syncing. As an added bonus, I can also sync my Transmit favourites — a feature I didn’t know about.

I am surprised by one thing that isn’t synchronised through .Mac. There’s no option to centralise the podcasts I’m subscribed to. That still seems to be based around the model of one computer and one iPod. I would have thought it would be pretty easy to just keep an OPML file on a server somewhere and point iTunes at that to keep podcasts in sync but this doesn’t seem to be something that’s built in by default. No doubt somebody somewhere has built a plug-in to do this. If not, I guess somebody somewhere soon will.

Apart from that, I’m all set. I’m relying on Apple to store my data and my hosting provider to store my emails, but I somehow feel more secure than if I was just hoarding everything locally. I feel a bit less tied down and a bit more footloose and fancy free.

Erik Sagen received a very tempting email out the blue, which he has posted on his website:

Dear Mr Sagen,

My sincere apologies for writing to you unannounced. My name is Arno Zimmerman and I am CEO of an Internet domain name acquisitions agency based here in Los Angeles, California.

My agency is currently engaged by a well-known Hollywood studio. The studio is producing a new action movie called The Kartooner. The movie has an all star cast, including Bruce Willis in the title role, and will be released in the fall. My client is therefore very keen to purchase the rights to the domain name kartooner.com from you.

And so on. Now, I found this particularly interesting because, just a little earlier, I found this in my inbox:

Dear Mr Keith,

My sincere apologies for writing to you unannounced. My name is Arno Zimmerman and I am CEO of an Internet domain name acquisitions agency based here in Manhattan.

My agency is currently engaged by a well-known fragrance manufacturer who will soon be launching a new product range under the brand of Adactio. Adactio is a new fragrance for men and will be marketed world-wide and on all media, including of course the Internet. My client is therefore very keen to purchase the rights to the domain name adactio.com from you.

But wait — the plot thickens. Mr. Zimmerman wrote back to Erik with some more information that movie project:

As I mentioned in my previous email, The Kartooner will star Bruce Willis in the title role. Bruce plays an impoverished artist in New York who pays his bills by drawing cartoons for the New York Times. Through a series of unfortunate accidents, Bruce’s character mistakenly becomes the target of a Mafia hit squad and must use all his wits (as well as his artistic skills) to stay alive. Needless to say I cannot divulge any further plot details.

Sounds awesome, doesn’t it? I want in.

Here’s the email I sent back:

Hi Arno,

Thanks for getting in touch. And allow me to be the first to congratulate you on your move from Los Angeles to Manhatten — and in record time, too!

Y’know, I could never imagine letting go of my domain name but the idea of a fragrance called Adactio is almost irresistible. I’m not really very money-oriented so I’m not going to name some huge price. I am, however, a huge attention whore. Therefore, all I ask is that I am the “face” of the advertising campaign for the fragrance.

It’s a win-win situation. You get your domain name, I get my face on a billboard in Times Square and sales of the fragrance will undoubtedly skyrocket.

But what would really seal the deal would be the promise of some product placement. I think I should have a part in the upcoming Kartooner movie project. Clearly, it would boost the profile of the film to have the face of Adactio featured prominently. In exchange, the movie studio should probably offer an endorsement by Bruce Willis. I’m picturing a short TV ad with Bruce speaking the tagline:

“I love the smell of Adactio in the morning. Smells like… web standards.”

By the way, what did you say the name of your company was again?

Update: Oh, man! This keeps getting better. I got a reply:

You have asked to be considered as the face of the advertising campaign for the fragrance and I will pass on your request to the advertising agencies handling the Adactio campaign. Will you please email to me a selection of photographs of yourself? As the campaign concepts feature a bare chested man, I would be grateful if you would include photographs from the waist up and of your naked chest.

As the media buying for the campaign is not yet finalized, I cannot guarantee a billboard in New York. However I do know that the poster campaign for Adactio will run across the UK, so your image will appear on several thousand London buses.

This comedic genius continues in a similar vein for a while, which prompts me to ask… John — on second thoughts — , is that you?

In other news: the Photoshopping has begun. Mike has already done the Vanity Fair spread.