Liudvikas Bukys

Rogue/Suspect Anti-Spyware Products & Web Sites
[via Diary Date]
See also some dissent about the specifics.

The problem is the bad platform.
The symptom is the miserythat so many users are living with.
The cottage industry for solutions is better than nothing, but it’s still a mess.

Jim Chow, Ben Pfaff, Tal Garfinkel, Kevin Christopher, Mendel Rosenblum:
Understanding Data Lifetime via Whole System Simulation:

We have used TaintBochs to analyze sensitive data handling in several
large, real world applications. Among these were Mozilla, Apache,
and Perl, which are used to process millions of passwords, credit card
numbers, etc. on a daily basis. Our investigation reveals that these
applications and the components they rely upon take virtually no measures
to limit the lifetime of sensitive data they handle, leaving passwords
and other sensitive data scattered throughout user and kernel memory. We
show how a few simple and practical changes can greatly reduce sensitive
data lifetime in these applications.

[via Justin Mason]

I had the opportunity to join GMail [beta]. My first piece of feedback to them was a request for user-defined recipient sub-addresses (e.g. using the sendmail “username+anything@domain” convention. Having that available for recipient filtering is more reliable than trying to parse numerous styles of correspondence (some list software inserts List-ID, some doesn’t, etc).

It turns out that GMail already implements the sendmail ‘+’ convention.
It works, but as far as I can tell, it’s not documented anywhere — or at least I didn’t think of the right search terms for it.

I hope that this creates new incentives for web sites and other email addressing processing software to
stop violating RFC2822 by excessively restricting the character set of email addresses.

P.S. If anyone else wants to try GMail [beta] also,
let me know;
I now have a ration of invitations too.

Jack Shafer in the Slate article
E-mail Confidential – Who’s afraid of Time Inc.’s legal disclaimer? has his attorney dissect an email disclaimer in detail.

This boilerplate proliferates because professionals
in the legal, auditing, and security consulting industries
feel compelled to recommend its use.
Unfortunately, the ratcheting ever-more-onerous language that
gets accreted by these things for cover-your-butt reasons results in most of them being statements that are intellectually ridiculous, legally dubious, and rude.

At this point, consulting professionals should be embarrassed to recommend this stuff.

[via Jeff Nolan via Techdirt]