Several months ago I wrote about the legal problems facing electronic ‘alternative currencies’ and the shuttering of one particularly sketchy operation — e-gold-based ‘meta-currency’ 1MDC.

Now it seems that the owners of E-Gold are facing stiff fines and possible prison time after pleading guilty to conspiracy to engage in money laundering and operating an unlicensed money-transmitting business, an indictment E-Gold’s founder once called “a farce.”

Basically, the Feds really didn’t like the core strength of E-Gold, which was that it provided a way to anonymously transfer funds without any sort of user verification. E-Gold didn’t make you prove who you were, and thus there wasn’t any prohibition on how many accounts you could have, which meant that there wasn’t a way to really bar someone from using the service — close down one account, and they could just open up a new one.

Unsurprisingly, the plea agreement includes a “comprehensive money-laundering-detection program that will require verified customer identification” — in short, an end to anonymous transfers.

Although E-Gold never amounted to much in the world of legitimate commerce, and it probably would be little missed by most people if it disappeared completely as a result of the changes, it’s unfortunate and sad to see yet another early-Internet dream — that of anonymous, untraceable electronic currency, immune to the whims of national law or taxation — go (dare I say it) down the tubes.

I was pleased to read today that Netflix has come to its collective senses and decided to save the “Profiles” feature. For those of you living under a rock, Profiles was a neat feature that Netflix offered, allowing you to essentially split your account into ‘sub-accounts’ each with their own queue and number of simultaneous movies. This was pretty nice if you had multiple people (say, family members, or you and a S.O.) sharing the same account.

Their elimination of the feature was ostensibly to simplify the website by removing a feature that few users actually took advantage of, but many felt it was done more to encourage the purchase of multiple accounts (which cost more than one account, even one with many movies at a time).

This is by any measurement a good thing. Netflix avoided doing something very stupid, and alienating its userbase (probably driving more than a few of them right into the arms of the competition, Blockbuster) by announcing its intentions, listening to the response, and then changing their tune when it became obvious they were about to shoot themselves in the foot. All good. This should be a lesson to others on how to craft policy that affects your users.

Unfortunately, they had already disabled access to the feature for most users, apparently in preparation for killing it outright. (Which is a bit of a drag for folks like me, who were holding out because they’d only heard of it as a result of the hubbub and didn’t want to try something that was on its way out.) But according to the official blog, the option to create new profiles will return in a couple of weeks. Here’s hoping.

One of my favorite Google products is Google Notebook, and one of my more frequent uses of it is to keep track of particularly insightful or pithy posts that I read online. Sure, most sites have their own methods for doing this, but Notebook keeps them all in one place. Unfortunately, I never really end up doing much with all the stuff I save.

Earlier today I found myself reading through some of my notes, and thought I’d share a few. Any one of them could be an entry in itself, but honestly I think there’s little I can add to most of them, so I’ll just point you back to the originals and leave it at that.

On Hillary Clinton’s ‘Prayer Breakfasts’, by MetaFilter’s dw:

[…] Hillary attending the prayer meetings is all about triangulation for her. She knows where the business of the GOP elite gets done, so she’s just going to walk right in there. If they were into watching pre-op trans burlesque while drinking paint thinner, Hillary would show up at the door with a copy of The Crying Game and a gallon of turpentine. […]

boubelium had an insightful quip about the difference between politicians and economists:

[…] if a charismatic politician tells you that he has seen the economic future, he hasn’t. He isn’t smart enough or boring enough to undertake the effort.

“Tom Collins” of Tom Collins’ World Wide Web Log — sort of a ‘Fake Steve Jobs’ of the Beltway, with the best understanding of that milieu on the Internet — sums up everything you need to know:

“Veronica, this is the United States of America. With the exception of short period of reform that lasted about forty years during the last century, the entire history of this country has been nothing more or less than the work of lying, thieving, cheating, amoral, greedy, inhuman scum bags.”
“Which means?”
“That, given the chance, you should always go with the lying, thieving, cheating, amoral, greedy, inhuman scum bags. Do that, and you can’t lose - it’s the American Way.”

On a slightly less cynical note, Vorfeed has one of the better comments I’ve read about the gun control ‘debate’ in a while:

[…] A little less than half of US households (and about 25% of all US adults) own at least one gun, and yet only about 30,000 people are killed by them per year, and more than half of those are suicides. … Criminalizing 25% of the country in order to save 30,000 lives is a terrible trade-off — if saving lives is really the issue, we’d do much better if we built a huge public transportation network and then banned cars. … As far as I can tell, the “gun control debate” in this country serves merely to distract from the actual issue — that is to say, the problem is violence, not guns! Rather than myopically concentrating on the instrument used, both sides of the gun debate could probably benefit from some realistic, holistic thinking about ways to mitigate the root causes of violence.

I spent a while explaining Spamgourmet to some coworkers today. It amazes me a little that more people aren’t aware of it, and that it gets mentioned so seldom in the popular and trade press.

Lots of people understand the benefits of having multiple email addresses; one that you keep to yourself and give only to trusted friends, and another that you use more widely (for site signups and for doing business with companies that you know are likely to spam you). Spamgourmet takes this concept further and allows you to create a basically-infinite number of disposable addresses. Instead of just having one ‘untrusted’ address, you can have one for each skeezy company you have to give a working address to.

This is pretty cool, because it allows you to turn addresses on and off at will. You can have an address that only allows emails in from one domain or address, or only works for a specified number of messages, silently ‘eating’ everything else.

The best part is that Spamgourmet lets you look at your list of addresses and see which ones have recieved the most spam. If you give out unique addresses to each company, it’s trivial to see exactly who sold you out. (Worst offenders: sketchy PayPal clone “ChronoPay,” followed by a litany of UBB-based forums. A plague on both your houses.) It’s pretty awesome to look in and see that you’ve been spared 50,000 spam messages over the course of 4 years, thanks to the service.

Did I mention that it’s free? (Really, no-strings-attached, no advertising, we-don’t-want-your-money kind of free.)

It’s one of the few things that I flat-out recommend to everyone. It really has no downside. It takes a few seconds to set up, and can keep your inbox from being overrun for years to come.

If you use a Mac, you may have at some point saved a pointer to an interesting page by dragging its ‘favicon’ (the little icon that sits to the left of a page’s URL in the URL bar in most browsers) to the Finder, which creates a neat little file.

I’d also been doing this, and blindly assumed that the files created in the Finder were standard “.url” files — basically nothing but an ASCII text file containing the page’s address. However, they’re not.

As a quick peek in the Get Info window will show you, they’re actually .webloc files. They’re actually somewhat more complex than basic .url’s.

For starters, the data is XML, formatted as a “PLIST” (one of Apple’s favorite XML schemas). The .webloc file for “http://kadin.sdf-us.org” is shown below.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>URL</key>
        <string>http://kadin.sdf-us.org/</string>
</dict>
</plist>

This is the case in Mac OS 10.4, at least. With previous versions of the OS, it seems that the URL data might have been contained in the file’s resource fork instead, or in addition to, the XML PLIST.

Although normally I’d berate Apple here for ignoring an established de facto standard (the .url file) that works well, the .webloc format is interesting, because it’s easily extended. You could, for instance, encapsulate not just the URL of a page, but its entire HTML contents, or an MD5 hash, into the .webloc, if you wanted to. And, of course, it’s UTF-8 rather than ASCII (and it makes it clear that it’s UTF-8, rather than leaving the determination up to the user’s application), so it has obvious localization advantages.

Email encryption is a topic that comes up frequently in both technical and privacy circles. Pretty much everyone with any sense agrees that it would be a good thing — or at least a better situation than we have right now — if encryption was more widespread and not limited to geeks and the occasional criminal, but exactly how to get encryption into the hands of the masses in a usable form remains a challenge.

One of the problems is that most email-encryption products that offer end-to-end privacy (as opposed to simple transport-layer privacy, like SSL) are designed as part of a traditional desktop MUA, and many people are moving away from POP-based email and desktop MUAs in favor of server-stored messages and webmail.

This presents a problem, since without a desktop MUA, it’s not clear where the encryption/decryption logic will live. Some schemes in the past (e.g. HushMail, at least based on my understanding of how it works) that offer ‘encrypted webmail’ do the message encryption on the server, relying on transport-layer security to get the message to and from the user’s web browser.

This approach is seriously flawed: it requires that the user trust the webmail provider, something I think they probably should be wary of doing. (After all, the webmail provider may not be ‘evil,’ but almost certainly has priorities that are different from those of any randomly-chosen individual user.) Once you send your unencrypted message off to the server, even if it’s via SSL, you really have no idea what becomes of it or who can read it.

For real security, you need to encrypt the message before you let it out of your sight. What’s needed is something that combines the security of end-to-end encryption and client-side logic, with the convenience of webmail.

Naturally, I’m not the first person to have gone down this path. Herbert Hanewinkel, of Hanewin.net, even has a nice example implementation of GPG encryption in Javascript, under a freely-modifiable and re-distributable license. With it, you can plug in a public key, type some text, and have it encrypted for that key, all right in your browser. As he points out, this has several advantages:

• All code is implememented in readable Javascript.
• You can save the page and verify the source code.
• No binaries are loaded from a server or used embedded.
• No hidden transfer of plain text.

As-is, this is a nice way to submit forms (he has a contact form on his site that encrypts the message with his public key and sends it); combined with a matching decryptor, it could be the basis for a secure webmail system that doesn’t require the user to trust their ISP or the mailserver operator. (Sort of, anyway: the user would have to be constantly vigilant that the JS applet that they were being sent was the real thing…)

John Walker at Fourmilab.ch has a more generalized version called Javascrypt that does both encryption and decryption. (Hanewinkel’s encryptor seems to be based on Walker’s, but includes some performance enhancements.) His page also has a nice summary of the benefits of browser-based cryptography and some of its weaknesses and vulnerabilities.

While it would be nice if Google built a JavaScript implementation of GPG into its next version of Gmail, I’m not going to hold my breath (for starters, it would make their business model — basically data-mining all your stored messages — impractical). But I don’t think it would be too difficult to take the examples that are around right now, and work them into some of the more common OSS webmail packages.

I have a love/hate relationship with Wikipedia. On one hand, it’s a great project, and I use it — mostly as a ‘casual reference’ for settling friendly arguments or digging up little gems of information — all the time. But on the other hand, sometimes I’m pained by Wikipedia, because I can’t help but look at it and see how much potential it has, for going above and beyond what it is right now. And that’s frustrating.

There have been lots of criticisms of Wikipedia since its inception, and I’m not going to go over the well-trod ground of reliability or factual correctness. Wikipedia is “good enough,” apparently, for lots of people to use, and that’s what matters.

No, what gets me about Wikipedia is its desire to be ‘encyclopediac,’ manifested in its ‘notability’ requirements for articles. I think this is a huge misstep.

Our notions of what an “encyclopedia” is — for all but the very youngest among us — is driven by memories of the old, dead-tree variety. Paper encyclopedias, by their very nature, couldn’t contain everything about everything; it would just be impractical. There isn’t enough paper to print such a beast, and even if there was, certainly you couldn’t economically mass-produce it. So when we think about an encyclopedia, we think about a series of relatively short, introductory articles, on key topics. The best encyclopedias had the most and longest articles — the greatest breadth and depth of content — but they were still limited.

But that’s not what it has to be. That’s a limitation borne of physical restrictions, which don’t necessarily exist in the digital electronic realm, particularly with the ever-falling price of bandwidth and mass storage.

The Wikipedia Gods seem to get this, to a certain extent. One of WP’s tenets is that it’s ‘not paper.’ But despite this, it still sticks to certain key assumptions about what is fit for an encyclopedia, about what an encyclopedia is, that are based on analog premises and ideas.

Put simply, there’s no reason to reject any content that’s well-written and well-researched, on ‘notability’ grounds. There’s just no reason to do it. There is no such thing as bad information, as long as it’s correct.

There are better ways to keep the main namespace clear, and the signal-to-noise ratio high, than by constantly destroying information. Articles that get crufty can (and should!) be rewritten and pared down; cruft can be left in the historical versions for those that want to find it. Articles that get top-heavy with trivia or ‘popular culture’ sections can move the extra content to sub-pages within the main article’s namespace, to preserve the cleanliness of the main page, without deleting anything. The result would be a resource with much more depth in its articles, and potentially much more breadth as well.

Wikipedia as it currently exists strikes me as a terrible waste of potential. Within a generation, Wikipedia and other online resources like it are going to own the concept of ‘encyclopedia’ within the public consciousness. Young people growing up today will probably never think of a stack of large books when they hear that word — yet the online resources are being designed with constraints thoughtlessly inherited from their dead-tree ancestors.

I love Wikipedia for what it is, but sometimes I can’t help but hate it for what it is, too, because of the gap between what it is and what it could and can be.

I discovered something interesting about the SDF’s web server today: it doesn’t seem to have a rule set up for serving .xhtml content by default.

I didn’t notice this initially, and my XHTML pages were coming through okay, because they use the “http-equiv content-type” meta element. But a quick check with the Web Sniffer revealed that they were actually being sent with a content-type of text/html, rather than the correct application/xhtml+xml. I would have thought that this would make them fail to validate cleanly, but apparently since the media type is a “SHOULD” rather than a “MUST,” it doesn’t fail. Or maybe it uses the META http-equiv and ignores the one actually coming from the server, for purposes of validation. I’m not sure.

Inserting AddType application/xhtml+xml .xhtml into my .htaccess file in the root ~/html/ directory solved the problem, and now my XHTML pages (mostly static articles produced using MultMarkdown from plaintext) are served correctly.

Anyway, just something for other people to note, I guess. I don’t know what accepted best practice is in this area, but I think I’m going to go and explicitly specify the content-type that I want transmitted for all the various file types that I use on the site, just to make sure; the way things are looking, I’m going to end up with a mix of plain text (including some UTF-8), XHTML, and plain old HTML.

(This was originally posted to my Slashdot Journal, which allows comments and is available here.)

So I recently ran across a new site, courtesy of the fine folks at MetaFilter: Rememble. In a nutshell, it’s a sort of ‘digital scrapbooking’ site. It describes itself as “a ‘washing line’ for your digital bits and pieces. Thread together texts, photos, videos, sounds, scribbles, scans, notes, tweets… so they’re not drifting in a digital wasteland.”

See more ...