dsandler.org

…your spam advertising your college recruiting program looks like complete ass.

Just thought you’d want to know.

Genius.

Fig. 1. Taken from Yahoo!’s documentation. (Recommended, my ass.)

OK, I have to take a break from writing my paper to complain about the new “Fully Featured” Yahoo! Groups email style, which was just turned on by default for everyone. Oh, but it’s got features, you say. Bah! My nice little plain-text emails have all been replaced by ugly, web-bugged, bulky HTML.

I had originally feared that you needed a Yahoo! ID to opt out of this monstrosity, but apparently you can switch back to “traditional” (read: plain text) emails by firing off a message to groupname-traditional@yahoogroups.com.

Elsewhere on the Interthing there’s some concern that because FeedTree moves feeds away from a polling architecture to one of on-demand notification, it takes away control from the user:

Mm, one last things. Several people have noted how happy they are that FeedTree can turn RSS from a push to a pull mechansim. I don’t like that concept. I like RSS for its meta-data, and for the control I’m afforded because I have complete control over it. “Push” the content and you take that away from me. Want push? Just get email updates. Setup your filters to organzie and categorize your emails. Ta da, instant, existing, pretty dang easy push system. :/

I assume that the “control” the author’s worried about losing is control over unsubscription, and if so, this is a very legitimate concern—even for email.

The fundamental problem with push-by-email is that your email address acts like a capability: by giving out your address, you offer someone the irrevocable ability to spam you. You must trust that the other side will never share your address, and will honor any unsubscription request. (As an aside, this is one of many reasons that email is becoming less popular as an interpersonal communication medium; the signal-noise ratio is so low—thanks to spam, mailing lists, and email update services—that many are abandoning it in favor of IM and SMS. Unfortunately, these services suffer most of the same capability-related access control weaknesses, and so it’s only a matter of time before these channels also become polluted.) Throwaway email addresses are one simple way to address the irrevocable-capability problem with email, but they’re hardly user-friendly and are not available to all users.

Feeds, on the other hand, solve this problem by retaining control over subscription locally, rather than deferring that control to outside parties. You can always unsubscribe to a feed: just stop polling it. It’s crucial to observe that FeedTree works exactly the same way. You can always unsubscribe to any feed whose updates are pushed via FeedTree; your local client will cease to receive updates via the Scribe multicast system. (Even if a malicious entity attempts to assault you with updates after you’ve unsubscribed, or updates for a topic which you’ve never been interested in, the Scribe framework will ignore these uninteresting messages.) In short, FeedTree’s “push” service model does nothing to reduce your control over which feeds you see.

The author has other harsh words for the FeedTree research project—most of which are, in my opinion, undeserved. His chief complaint is that all Web feed bandwidth issues are 100% solved by conditional HTTP GET (ETag/If-None-Match and If-Modified-Since). Conditional GET is hugely important for polling clients, but it’s hardly sufficient: if a feed changes frequently (many popular ones do), or has any dynamic content (read: advertisements, becoming increasingly common), this protocol breaks down and the entire feed is always transferred.

There are other aspects of the article which I disagree with, but these are the key areas in which I feel the author misunderstands both the architectural problems inherent in RSS and the way FeedTree intends to address them. As with all academic research projects in the field computer systems, FeedTree is a part of a larger discussion about how technology can be made more efficient, more powerful, and more usable. I welcome the debate.

A new technique in foiling content-based spam filters: using CSS rendering to construct text that the filter can’t see.

V<span style=”float: right”> b </span>I<span style=”float: right”> d </span>A<span=20 style=”float: right”> z …

The “chaff” characters (b, d, z, …) float to the right, while the letters “VIA” in the above example (followed by “GRA” in the source material) settle to the left, lining up in order. Your spam filter’s tokenizer sees nothing. (Previous version of this hack relying on HTML rendering to construct text that the filter can’t see. Example: V<!–foo–>I<!–foo–>A<!–foo–>G<!–foo–>R<!–foo–>A.)

Today I’m hating on Mail.app (10.4). Why can I suddenly not delete messages anymore? Instead of disappearing, they turn gray (first message in the screenshot below):

If I go over to the IMAP server in question, the message is flagged deleted; expunging it and then refreshing Mail.app causes the gray message to disappear. It certainly didn’t always work this way.

In case you were under a rock today (as I was): iPod nano (teeny-tiny, Flash-based, display and click wheel, two Benjamins); what happened to the mini? (Update: It went to the iPod family crypt.) Also, iTunes 5 has now been beaten by the same stick that hit Mail.app in Tiger. (Consolation prize: We finally get playlist folders.)