There's all this talk lately about redoing SMTP. There's no reason for that. Authentication of senders is indeed the right way to go -- not with a challenge/response mechanism, but with the tool designed for the job: digital signatures. Mail clients (and eventually servers) can be easily configured to bounce unsigned mail (unless on a whitelist), and signed mail can be traced to senders and sorted reliably.
Ubiquitously signed mail would lead to senders with public reputations, and lists of spammers whose mail you might reliably choose not to accept. You would only treat as valid signatures associated with a trusted certificate-authority validated identity, so spammers couldn't just make up new identities every day.
In general, "cold-call" mail -- mail from people you didn't expect to receive anything from and therefore could not have whitelisted -- should cost some small amount to get through. Again, there's no no need to replace SMTP. A standard challenge-response protocol could easily be implemented over SMTP: (1) receive mail; (2) reply to unknown sender with request for payment via PayPal et al, referencing a unique ID; (3) when payment is received send confirmation that mail has been delivered to user-visible inbox. Users can set their own rates.
Spam is not really a hard problem or a technical problem. Content-based filtering is a dead-end, it just encourages people to pretend and dissemble more cleverly. The problem is social -- changing end users' habits (embedded in their software) and senders' expectations from an assumption that all mail sent will be accepted and read to a more realistic understanding that most mail sent will be returned unread unless the sender can persuade the recipient the letter merits even two seconds of her attention.
I would never buy an Archos product again after they jerked me around on their rebate for the Archos Jukebox. I purchased their device retail (CompUSA) and had all my paperwork copied and in order. After contacting a guy at Archos on and off for nearly a year and being told various stories about problems with their claims processor and wait just another few weeks and whatnot, I gave up. I would not trust this company with a dime.
I disagree with the author's advice discouraging the use of final classes and methods. Both from a design and a performance method, I think final classes and methods are underutilized by programmers. For an in-depth essay on why, see
here.
What I pay for, I should to own. That means, I should have full control over the use of it, and the use of all of its resources.
When I pay for a service, I want the service provider to be my agent and my agent alone. I am happy to pay full price in a competitive marketplace. I prefer paying service providers a reasonable fee over accepting a subsidy and having to wonder whose interests people I have to trust are looking after.
I do not want spies, salesmen, or trojan horses in my living room, bedroom, bathroom, or car. A device acts (or fails to act) in order to suit the interests of its producer, a film studio, a maketing firm, or any other party is not a device I can trust. A life where the very objects that surround me in my own home may harrass, ignore, or betray me is not a life I want.
These are matters of principle. Even if a device is gentle in its looking after other people's interests over my own, even if the inconvenience or privacy leak is slight, it is a betrayal. We are heading for a world where a thousand tiny nuisances will leave us wondering if we can trust the dishwasher. There will always be an explanation, a mitigation, a minimization of these things. But it is not okay.
I hope I am not alone in feeling this way, and that consumers collectively demand, simplicity and trustworthiness in the artifacts and relationships that surround us.
4) The Federal government does have a role to play, shepherding into the digital age the incentives that undergird
creative activity. An appropriate policy would include the following elements:
it would discourage non-payment rather than reproduction; it would promote public disclosure rather
than technological access control; it would legalize compensated sharing;
it would provide for the development of content registries, whereby consumers would conveniently pay
for the right to make legal use of protected works, however, and in whatever format, they obtain them;
it would provide for enforcement, whereby individuals or companies engaging in a pattern or practice
over time of using protected content without payment would be subject to potentially severe civil and
criminal penalties;
it would establish a strong, high profile means of effecting that enforcement, potentially establishing
a new agency, which would actively seek out egregious violators and prosecute them publicly and
vigorously to deter persistent noncompliance;
it would provide for a public education campaign, making it clear to citizens that they are free to use and
copy digital content as they wish, but they are legally responsible and ethically bound to register and pay
for what they use.
The goal of such a policy would not be to prevent all uncompensated use, nor would it attempt to punish each and
every infraction. Rather, the purpose would be to define norms of lawful, honest behavior that allow for the full use
and enjoyment of works in digital form, with compensation to rightsholders. Flaunting of these norms would not
result in guaranteed penalty, but habitual, intentional violators would be at significant risk. Determined pirates could
still evade the law, just as determined shoplifters, drug users, and tax evaders do today. But most Americans do pay
their taxes, voluntarily, similarly encouraged by the carrot of doing the right thing and the stick of potential legal
consequence. If the Federal government can raise more than a trillion dollars a year this way, is it that naive to imagine
that we can actually get authors and other rightsholders compensated using the same approach?
The best thing about UNIX config files is that they are self-documenting -- the good ones contain comments that allow users with a basic proficiency to figure out how to configure stuff easily. The history and purpose of changes can be conveniently embedded. Putting aside its fragility, Windows' registry is broken because it is simply incomprehensible. Even sendmail.cf gives some guidance about what stuff means in the UNIX world.
But most UNIX config files are broken in that comments don't have a well defined place in the config file syntax -- they are just ignored by parsers. This is BAD. If config files are edited both by users and by automatic tools that parse and regenerate, all of this infomation and history can be lost. It is hard to code around this -- even if you preserve the comments, their meanings are location dependent and getting the location right in the face of changes can be nearly impossible.
The biggest win about XML is that instead of defining a comment syntax that parsers ignore, we could define a standard <config:comment> element which would maintain a well defined place in the structure of the files. Hackers could edit plaintext and comment, tools could edit and regenerate (and comment), and all the documentation would be well preseved. [Parser-ignored <!--... --> comments would not be used.]
This is a perfection, not a departure from the UNIX philosophy -- information in simple, human readable, machine manipulable ASCII files. We just need to take care that our DTDs are easy for humans to read, understand, and edit.
Two motherboard replacements and a copped-out fan on my Ultra... Most expensive machine I ever bought; I'll never pay for that again. Fortunately all was still under warranty. PC hardware craps out a lot, but it costs beans to replace. Much less fear.
Slashdot Mirror
After a very bad rebate non-fulfillment experience, I would never purchase or recommend an Archos product.
There's all this talk lately about redoing SMTP. There's no reason for that. Authentication of senders is indeed the right way to go -- not with a challenge/response mechanism, but with the tool designed for the job: digital signatures. Mail clients (and eventually servers) can be easily configured to bounce unsigned mail (unless on a whitelist), and signed mail can be traced to senders and sorted reliably.
Ubiquitously signed mail would lead to senders with public reputations, and lists of spammers whose mail you might reliably choose not to accept. You would only treat as valid signatures associated with a trusted certificate-authority validated identity, so spammers couldn't just make up new identities every day.
In general, "cold-call" mail -- mail from people you didn't expect to receive anything from and therefore could not have whitelisted -- should cost some small amount to get through. Again, there's no no need to replace SMTP. A standard challenge-response protocol could easily be implemented over SMTP: (1) receive mail; (2) reply to unknown sender with request for payment via PayPal et al, referencing a unique ID; (3) when payment is received send confirmation that mail has been delivered to user-visible inbox. Users can set their own rates.
Spam is not really a hard problem or a technical problem. Content-based filtering is a dead-end, it just encourages people to pretend and dissemble more cleverly. The problem is social -- changing end users' habits (embedded in their software) and senders' expectations from an assumption that all mail sent will be accepted and read to a more realistic understanding that most mail sent will be returned unread unless the sender can persuade the recipient the letter merits even two seconds of her attention.
I would never buy an Archos product again after they jerked me around on their rebate for the Archos Jukebox. I purchased their device retail (CompUSA) and had all my paperwork copied and in order. After contacting a guy at Archos on and off for nearly a year and being told various stories about problems with their claims processor and wait just another few weeks and whatnot, I gave up. I would not trust this company with a dime.
I disagree with the author's advice discouraging the use of final classes and methods. Both from a design and a performance method, I think final classes and methods are underutilized by programmers. For an in-depth essay on why, see here.
The goal of such a policy would not be to prevent all uncompensated use, nor would it attempt to punish each and every infraction. Rather, the purpose would be to define norms of lawful, honest behavior that allow for the full use and enjoyment of works in digital form, with compensation to rightsholders. Flaunting of these norms would not result in guaranteed penalty, but habitual, intentional violators would be at significant risk. Determined pirates could still evade the law, just as determined shoplifters, drug users, and tax evaders do today. But most Americans do pay their taxes, voluntarily, similarly encouraged by the carrot of doing the right thing and the stick of potential legal consequence. If the Federal government can raise more than a trillion dollars a year this way, is it that naive to imagine that we can actually get authors and other rightsholders compensated using the same approach?
The best thing about UNIX config files is that they are self-documenting -- the good ones contain comments that allow users with a basic proficiency to figure out how to configure stuff easily. The history and purpose of changes can be conveniently embedded. Putting aside its fragility, Windows' registry is broken because it is simply incomprehensible. Even sendmail.cf gives some guidance about what stuff means in the UNIX world.
But most UNIX config files are broken in that comments don't have a well defined place in the config file syntax -- they are just ignored by parsers. This is BAD. If config files are edited both by users and by automatic tools that parse and regenerate, all of this infomation and history can be lost. It is hard to code around this -- even if you preserve the comments, their meanings are location dependent and getting the location right in the face of changes can be nearly impossible.
The biggest win about XML is that instead of defining a comment syntax that parsers ignore, we could define a standard <config:comment> element which would maintain a well defined place in the structure of the files. Hackers could edit plaintext and comment, tools could edit and regenerate (and comment), and all the documentation would be well preseved. [Parser-ignored <!-- ... --> comments would not be used.]
This is a perfection, not a departure from the UNIX philosophy -- information in simple, human readable, machine manipulable ASCII files. We just need to take care that our DTDs are easy for humans to read, understand, and edit.
Two motherboard replacements and a copped-out fan on my Ultra... Most expensive machine I ever bought; I'll never pay for that again. Fortunately all was still under warranty. PC hardware craps out a lot, but it costs beans to replace. Much less fear.