[hashcash] Re: Hashcash for Blogs
- From: "Mitch Denny" <mitch.denny@xxxxxxxxxxxxxx>
- To: <hashcash@xxxxxxxxxxxxx>
- Date: Sun, 29 Aug 2004 23:18:48 +1000
Hi Eric,
Thanks for responding.
EJ> Comment response delivers stamp resource and required
EJ> bit size. Since HTTP transactions are stateless, it
EJ> would be wise to encode the bit size in the resource
EJ> using some techniques like HMAC.
OK, I'm still very new to Hashcash so some of my comments may seem a little
bit thick :) One of the things that I mentioned in the post was that the RDF
that is embedded into the blog posts (when rendered to HTML) can be extended
to include the bit size required for the stamp. You can see an example of
what I am proposing at http://notgartner.com/Downloads/RDF.xml just in case
you missed it. So I guess this does what you mentioned above - unless I am
missing something. Its unlikely that the URL to the blog post will be able
to be changed - as this has huge implications for track-backs. One of the
good things about blogs is their two-way nature.
EJ> unlike most other hashcash contexts, there are precious
EJ> few opportunities for background stamp generation. If
EJ> you use the "brute force/bloody ignorance" approach and
EJ> generate stamps on "submit", users will get cranky. If
EJ> you try to generate stamps on pressing the comment button
EJ> (or more likely on receipt of the comment page), you have
EJ> the challenge of delaying submission until the stamp
EJ> calculation is done. personally, I do not know enough
EJ> about the Java/browser environment to know whether or not
EJ> it is possible to run one thread generating a stamp and
EJ> use the results of that thread on activation of the
EJ> summit button.
I speculate that there are really who types of blog readers out there, those
who are referred to the blog via Google and those who pick up the feed via
RSS. For example, when I read the blogs that I am subscribed to I use
NewsGator which is a plug-in for Microsoft Outlook. When I reply to a blog
post I will usually do so by creating a post of my own on my blog, using a
client-side tool like BlogJet. When I type in a URL BlogJet could poll the
site and produce a stamp in the background, I imagine other
aggregators/posters could do the same thing. That doesn't help the casual
blog reader though.
Some of the neat things that I have seen with JavaScript include popping a
little floating window over the top of the screen with a small and simple
animation obscuring the calculations going on behind the scenes. I would
imagine that something similar could be done. Obviously it would depend on
the size of the stamp, for a 16-bit stamp my non-optimised algorithm now
spews them forth very quickly, definitely not noticable in the overally
request/response for a HTTP post. Given that, a larger stamp size would be
more reasonable. 20-bits seems to be the standard but from what I read in
the archives it looks like being upped to 24-bit???
On threading, you don't really have any control over threads given the
constrained execution environment. But I wondered how threads would really
help on a single-proc box, surely driving the CPU at 100% for a few seconds
can't be improved by adding threads - wouldn't that just cause context
switches? I looked at the Java Hashcash implementation on the
http://www.hashcash.org site and wondered what was really being gained. This
is probably down to my in-experience with Hashcash.
EJ> I would also caution you to try and run as fast a stamp
EJ> generator as possible because the spammers will and any
EJ> performance differential between what spammers can run
EJ> and your customers can run is not in your favor. Which
EJ> raises the ever popular question, is it possible to use a
EJ> native hashcash from a browser?
Definitely can't run hashcash from the browser in the client process space
as this would violate the sandbox. Most legit commenters could probably wait
up to say twenty seconds to mint a stamp, whereas I think that would
probably stop it being economical for spammers (pure guess).
EJ> I also suggest timing out resources. Somewhere after
EJ> something like a five-minute limit, the resource becomes
EJ> invalid. the reason I'm thinking of this is it will
EJ> force spammers to serialize any attempts to bypass
EJ> without having too much of an impact on ordinary users.
I was planning on making the resource string the track-back URL. I guess
that could change, but it would be up to the blog implementation. The RDF
could probably have a hashcash:expiry attribute which contains the expiry
date for the resource (trackback URL), although I am not sure. The current
state of blog spamming bots would have to be fairly primative, they have
only really shown up over the last year or so.
Thanks for responding, you have given me lots to think about.
Mitch Denny
w: http://notgartner.com
e: mitch.denny@xxxxxxxxxxxxxx
m: +61 (414) 610-141
-----Original Message-----
From: hashcash-bounce@xxxxxxxxxxxxx [mailto:hashcash-bounce@xxxxxxxxxxxxx]
On Behalf Of Eric S. Johansson
Sent: Sunday, 29 August 2004 9:58 PM
To: hashcash@xxxxxxxxxxxxx
Subject: [hashcash] Re: Hashcash for Blogs
Mitch Denny wrote:
> Hi there,
>
> I've been reading the materials relating to Hashcash over the last few
days
> and seeing how the technique could be applied to protecting blogs from
> comment spam.
>
> I've made a post about it over here:
> http://notgartner.com/posts/572.aspx
>
> If any of you have advice/comments please feel free to reply here or in
the
> comments of the post referenced above.
>
> BTW, I've been reading the archives for this list and there is some really
> interesting discussion in there!
interesting application. I had figured out a protocol for using
hashcash with sms, IM, and VoIP but never thought about blog comments.
as you suggested, the protocol would do something like:
Comment response delivers stamp resource and required bit size. Since
HTTP transactions are stateless, it would be wise to encode the bit size
in the resource using some techniques like HMAC. This encoding will
protect you against spammers forging their own, smaller bit size.
You'll end up with a rather large resource but quite frankly, we really
don't care for a variety of reasons. stamp engine starts calculating
stamp and on submit, delivers stamp etc.
unlike most other hashcash contexts, there are precious few
opportunities for background stamp generation. If you use the "brute
force/bloody ignorance" approach and generate stamps on "submit", users
will get cranky. If you try to generate stamps on pressing the comment
button (or more likely on receipt of the comment page), you have the
challenge of delaying submission until the stamp calculation is done.
personally, I do not know enough about the Java/browser environment to
know whether or not it is possible to run one thread generating a stamp
and use the results of that thread on activation of the summit button.
although, as I think about it, as a proof of concept technique, this
submit button hook might not be such a bad place to start. Again, I
only had very little experience with Java stamp generators and would
recommend starting with lapo's stamp engine.
from a human factors perspective, I think you'll need to warn the user
that they are doing this work as an antispam technique so that someone
making a quick comment (i.e."get your green cards here"), will know that
they will need to wait for the stamp to complete before submission.
It'll take some careful language to reduce the offense potential.
I would also caution you to try and run as fast a stamp generator as
possible because the spammers will and any performance differential
between what spammers can run and your customers can run is not in your
favor. which raises the ever popular question, is it possible to use a
native hashcash from a browser?
I also suggest timing out resources. Somewhere after something like a
five-minute limit, the resource becomes invalid. the reason I'm
thinking of this is it will force spammers to serialize any attempts to
bypass without having too much of an impact on ordinary users.
---eric
Other related posts:
