The thing that finally pushed me into activating comments was MT 2.6, which allows you to close previously open comment threads.
I don't have a way of automatically closing them after a certain time, so it's not ideal, but it still cuts down on automated comment spam.
You know, the Comment API will only make this problem worse.
You've said that before about the comment API. To date, I've seen no evidence to back up that assertion.
My guess is that the SMTP spam I've gotten is from people who look for mailto addresses and assume that what they found was an InBox for an individual. In other words, they weren't specifically targetting a blog.
On the other hand, I do have two ip addresses that I block from HTTP POSTs. These were clearly individuals that were well aware of what they were doing.
Standardized, machine-readable, auto-discoverable APIs for posting arbitrary text and links on high-traffic sites without authentication. Yeah, I can't imagine how that could be abused.
Ask Phil; people have already written scripts to rip through an MT site to post comments on every entry.
Nobody saw e-mail spam coming either. That was in 1978 or so.
Absolutely. I have the same reservations about Trackback. And, just as with the Comment API, there has been very little abuse to date. I verify all the trackbacks I get (note to readers: want me to visit your site at least once? use Trackback) and so far have had zero problems with it.
Unauthenticated SMTP servers weren't a significant problem for years. Then it exploded. I'm just wondering if we're doing the world any favors by sitting around saying "that would be a cool feature, and sure it could easily be abused, but let's worry about that later".
Sam,
I agree with Mark that it is just a matter of time before technologies like the CommentAPI are abused by spammers. All it takes is for the technology to be used in a widespread manner.
However I also think that authentication can mitigate some of these issues. Whenever someone comes up with some sort of authentication mechanism for the CommentAPI I'll throw that support into RSS Bandit ASAP.
And commentAPI couldn't require a link?
And if there was the ability to have headers, once could even require a verifiable digital signature.
If it weren't for those damned hamsters.
Dare, do the following words ring a bell:
I clearly see this differently.
Let me turn this around. If you wish to define an alternative to what already exists, I will support the protocol you define. Alternately, we both could simply support what already exists.
Ahem.
http://example.com/post.cgi?id=ABCDEF0123456789
<a href="http://example.com/post.cgi?user=f8dy&pwd=whatever">http://example.com/post.cgi?user=f8dy&pwd=whatever</a>
I always have trouble wrapping my head around security issues. Is this an authentication problem or a verification problem?
How would an ideal system work, one that would filter out spam, yet not inconvenience legitimate users.
Even with SMTP security, spam is still a problem. Either people putting up open relays innocently or ISPs that are willing to host spammers.
The only solution that seems to be getting any traction in e-mail spam is Bayesian filtering.
Sam, I'm still a giant hamster, as I
see no reason to run here:
http://www.w3.org/TR/SOAP-dsig/
when you could have gone here:
Ideal system: posting software not only provides links, but also signatures. And do so without inconveniencing the user of this software.
Software that receives the post would not only fetch the page (like Mark and I do for trackbacks), but also fetch a public key used to validate the signature.
Now, for the details. Joe, you are pointing to the right place, but that doesn't answer the question about where in the document such signatures should be placed. Also, should the keys be actually in the page (like trackback's metadata today), or with one or at most two autodiscovery links away (perhaps tucked away inside of FOAF or perhaps as a standalone file).
If the signature was passed as a header, without mustUnderstand being set, then those who wish to operate completely open commentAPI systems could do so. Those that wish to check for signatures could also do so.
Mark: no, I'm not "worrying about it later". In my typical style, I know what I am want to implement, and I am waiting for there be enough awareness of the issues that need to be solved before proceeding.
Sam,
To make sure I am following your proposal, to use the CommentAPI on your blog, I would need:
1. A public key.
2. An item on my website that contained a link to your item.
And what is going to stop that Russian site from complying with those requirements?
I'm not well versed in security, but I can only see two ways out of this problem:
1. Registration - which doesn't meet the ease-of-use criterion.
2. Bayesian filtering.
Looks like I'm ordering Bruce Schneier's Secrets and Lies : Digital Security in a Networked World tonight.
Joe, you keep repeating the filtering thought. What you may or may not realize is that the content being sent already went through SpamAssassin.
Registration is equivalent to the public key mechanism (the russian site could simply register) from a security perspective, just less user friendly than the solution I outlined.
What registration and signing both do is remove a level of plausible deniability whereby the owner of the site could say that they didn't do it.