Monday, April 10, 2006
CommentAPI, CAPTCHA, and Credentials
CommentAPI and CAPTCHAs
CommentAPI is a very useful construct for use on mobile devices (see http://www.feederreader.com/TechnicalGuides/RSS_Basic.html )
One of the most common responses I get to suggesting CommentAPI for use in blogs is that the CommentAPI does not have any mechanism for preventing comment spam.
This is true, but it is also true that an early test (somewhere before 2003, if I recall correctly) by one person, indicated that the CommentAPI does not increase comment spam. Of course, that was early on. I don't know the status of CommentAPI vs. Comment spam, but it is certainly worth addressing because it is often the first response I get when suggesting CommentAPI to others.
On the other side of the fence, there are people who believe (and at least one person who has shown) that CHAPTCHAs are easily circumvented using straightforward algorithms.
To that end, I offer a way to add CAPTCHAs to CommentAPI. At some point I may figure out a way to add this in a backward compatible way or put my head around nailing down all the details. At this point, I would suggest that this is in no way a specification that should be deployed.
We could add one parameter to the RSS feed and the same parameter to the CommentAPI that would add a CAPTCHA capability to the CommentAPI.
URL of image or audio
(of course, this would need to be added to the namespace to be considered valid RSS)
Where "MIME type" is replace with the MIME type of the actual CAPTCHA and the "URL of image or audio" is replaced by a URL. This would handle either image or audio CAPTCHAs for a variety of users and allow the user to select "a priori" the type of CAPTCHA preferred.
I thought of other permutations, such as a CaptchaGuid that woud be retained and submitted, but it seems that sending back the url, which could encode a GUID, covers it.
Because the CAPTCHA could be downloaded then submitted days, weeks, or months apart, the server would need to keep track of each CAPTCHA that has been distributed. It's probably not a good idea to rely on any programmatic encoding of the valid CAPTCHA value within the URL (except if adequately encrypted?). It might be better to create a truly random number as a guid that is located within the URL and associated in the server with the appropriate value at the time of distribution.
An additional parameter would need to be added to the CommentAPI POST XML, specifically:
Reponse here
I'm not sure if CAPTCHAs allow different types of responses other than text, but it could be accommodated, potentially, using a "Type" attribute, and a base64-encoded response.
Another addition could be to specifically allow the use of HTTP Authentication during the CommentAPI POST. The client could keep track of the username and password (in a secure manner, of course) or present the user with a credentials request.
It seems to me that the addition of both of these mechanisms would make CommentAPI as secure as posting comments directly from a browser.
If anyone was interested in creating a server implementation, I would be happy to help by implementing the client side.
CommentAPI is a very useful construct for use on mobile devices (see http://www.feederreader.com/TechnicalGuides/RSS_Basic.html )
One of the most common responses I get to suggesting CommentAPI for use in blogs is that the CommentAPI does not have any mechanism for preventing comment spam.
This is true, but it is also true that an early test (somewhere before 2003, if I recall correctly) by one person, indicated that the CommentAPI does not increase comment spam. Of course, that was early on. I don't know the status of CommentAPI vs. Comment spam, but it is certainly worth addressing because it is often the first response I get when suggesting CommentAPI to others.
On the other side of the fence, there are people who believe (and at least one person who has shown) that CHAPTCHAs are easily circumvented using straightforward algorithms.
To that end, I offer a way to add CAPTCHAs to CommentAPI. At some point I may figure out a way to add this in a backward compatible way or put my head around nailing down all the details. At this point, I would suggest that this is in no way a specification that should be deployed.
We could add one parameter to the RSS feed and the same parameter to the CommentAPI that would add a CAPTCHA capability to the CommentAPI.
(of course, this would need to be added to the namespace to be considered valid RSS)
Where "MIME type" is replace with the MIME type of the actual CAPTCHA and the "URL of image or audio" is replaced by a URL. This would handle either image or audio CAPTCHAs for a variety of users and allow the user to select "a priori" the type of CAPTCHA preferred.
I thought of other permutations, such as a CaptchaGuid that woud be retained and submitted, but it seems that sending back the url, which could encode a GUID, covers it.
Because the CAPTCHA could be downloaded then submitted days, weeks, or months apart, the server would need to keep track of each CAPTCHA that has been distributed. It's probably not a good idea to rely on any programmatic encoding of the valid CAPTCHA value within the URL (except if adequately encrypted?). It might be better to create a truly random number as a guid that is located within the URL and associated in the server with the appropriate value at the time of distribution.
An additional parameter would need to be added to the CommentAPI POST XML, specifically:
I'm not sure if CAPTCHAs allow different types of responses other than text, but it could be accommodated, potentially, using a "Type" attribute, and a base64-encoded response.
Another addition could be to specifically allow the use of HTTP Authentication during the CommentAPI POST. The client could keep track of the username and password (in a secure manner, of course) or present the user with a credentials request.
It seems to me that the addition of both of these mechanisms would make CommentAPI as secure as posting comments directly from a browser.
If anyone was interested in creating a server implementation, I would be happy to help by implementing the client side.
# posted by Greg Smith @ 9:21 AM 
