external links editing problem on ruby garden

[Sam Roberts]

It has become quite hard to edit rubygarden's wiki. Any page with a
link, if you try to change it you get redirected to:

http://www.rubygarden.org/ruby?ExternalLinks

Your homework assignment is then to search the ruby-talk archives to
find out what's required...

This is NOT easier than asking for a passwd, not the first time. And
even once you know the mixed case convention, all editors are forced to
go through and change all the links in any page they edit. Again, this
is more time-consuming than logging in.

I wouldn't be so bad if the ?ExternalLinks page described how to fix
links, and why (everybody appreciates the pain of spam fighting).

Can I add that description, or is it some kind of security thing to only
let people in the know, or willing to search ruby-talk, edit pages?

I was just about to edit the page, then realized it might be
intentional...

Thanks!
Sam

 

[Francis Hwang]

It has become quite hard to edit rubygarden's wiki. Any page with a
link, if you try to change it you get redirected to:

http://www.rubygarden.org/ruby?ExternalLinks

Your homework assignment is then to search the ruby-talk archives to
find out what's required...

I haven't been paying that much attention to this discussion, but
wouldn't it be possible to set up a whitelist so certain external URLs
can be safely posted?

 

[James Britt]

Sam Roberts wrote:

...

Can I add that description, or is it some kind of security thing to only
let people in the know, or willing to search ruby-talk, edit pages?

I was just about to edit the page, then realized it might be
intentional...

Quick summary: Much spam. Much from bots. Quick hack to stop bot spam
by requiring urls to use uppercase HTTP. Still spam from humans; at
least make them work for it.


James

 

[Sam Roberts]

Quoteing (e-mail address removed), on Mon, Nov 15, 2004 at 02:15:51AM +0900:

Quick summary: Much spam. Much from bots. Quick hack to stop bot spam
by requiring urls to use uppercase HTTP. Still spam from humans; at
least make them work for it.

Understood. I'm starting to like the login/passwd idea, though. At least
internet users understand the mechanism. The capitialize all HTTP thing
is more like a secret handshake!

Cheers,
Sam

 

[James Britt]

Quoteing (e-mail address removed), on Mon, Nov 15, 2004 at 02:15:51AM +0900:


Understood. I'm starting to like the login/passwd idea, though. At least
internet users understand the mechanism. The capitialize all HTTP thing
is more like a secret handshake!

Yes, very much so.

Thinking out loud:

The choice seems to depend on where best to shift the burden or cost of
maintenance and compliance. Using a login system, code must be added to
manage it, which is a one-time cost, but there is also a recurring cost
of checking that users are not abusing privileges. Users may also
forget their passwords, so one can either write code to manage that
part, or carry the admin burden of manually providing the password. For
users, though, the system is familiar and easy, and password management
is often built into the Web browser, so there is little to do once a
login in obtained.

With the secret handshake approach, there is also a one-time code cost,
but it is arguably much lower than the cost of a password system. The
burden of compliance is carried more by the user, who must go figure out
the handshake. There is a recurring admin cost of monitoring for spam,
but that may always be the case no matter what. And users tend to be
the ones reporting spam, not a site admin. Users also carry a recurring
cost, having to employ the handshake for any post that includes a URL.

If the handshake needs to change, the overall cost is going to be much
lower for the administrator than for users.

In general, what are the criteria when deciding how to assign such
costs? Partly it has to do with barriers to entry, so another question
might be, what sort of barriers to participation produce the most useful
or interesting results?


James

 

[Jim Weirich]

It has become quite hard to edit rubygarden's wiki. Any page with a
link, if you try to change it you get redirected to:

http://www.rubygarden.org/ruby?ExternalLinks

Your homework assignment is then to search the ruby-talk archives to
find out what's required...

This is NOT easier than asking for a passwd, not the first time. And
even once you know the mixed case convention, all editors are forced to
go through and change all the links in any page they edit. Again, this
is more time-consuming than logging in.

I wouldn't be so bad if the ?ExternalLinks page described how to fix
links, and why (everybody appreciates the pain of spam fighting).

Can I add that description, or is it some kind of security thing to only
let people in the know, or willing to search ruby-talk, edit pages?

I was just about to edit the page, then realized it might be
intentional...

Sorry for the pain. I think the HTTP think was partially successful in
reducing spam. We have only had a few incidents of spam related activity in
the past few days. Perhaps the spammers have gone to greener pastures or
perhaps they are just waiting until our guard is down.

The ExternalLinks page did at one time have an explaination of how to
represent external links. It was expressed as a Ruby algorithm on the theory
that the casual spammer wouldn't/couldn't read it. Someone removed the
description because they felt it made the information too readily available.
At the time, I let it go, but based on your feedback I've restored it. Take
a look and see it it is ok. It should be plain enough to anyone with a ruby
background.

Regarding existing pages with lowercase links. You are right, they are a pain
to edit. I've fixed a number of them by hand, but the real answer is to walk
through each page file with a script and fix the page data. I've got this on
my todo list.

Thanks for the feedback.

 

[Sam Roberts]

Quoteing (e-mail address removed), on Mon, Nov 15, 2004 at 11:44:55AM +0900:

The ExternalLinks page did at one time have an explaination of how to
represent external links. It was expressed as a Ruby algorithm on the theory
that the casual spammer wouldn't/couldn't read it. Someone removed the
description because they felt it made the information too readily available.
At the time, I let it go, but based on your feedback I've restored it. Take
a look and see it it is ok. It should be plain enough to anyone with a ruby
background.

It looks great, particularly the note about existing links.

Thanks,
Sam