Flea vs RubyGarden

[Phlip]

Rubistas:

I sympathize with the battle on spam, but I was using RubyGarden to build
the "home sites" for MRW and Flea. Both require pages with transcluded
graphics, to avoid the need for thousands of boring words.

RubyGarden stopped building the <img> tag around graphic file links.

I'm too lazy to build my own static Web site for these pictures. Was images
in spam a big problem? or did some script just clobber my graphics by
accident?

 

[David Ross]

Rubistas:

I sympathize with the battle on spam, but I was using RubyGarden to build
the "home sites" for MRW and Flea. Both require pages with transcluded
graphics, to avoid the need for thousands of boring words.

RubyGarden stopped building the <img> tag around graphic file links.

I'm too lazy to build my own static Web site for these pictures. Was images
in spam a big problem? or did some script just clobber my graphics by
accident?

did you have the location: with the capital HTTP://?

David Ross

 

[Chad Fowler]

Rubistas:

I sympathize with the battle on spam, but I was using RubyGarden to build
the "home sites" for MRW and Flea. Both require pages with transcluded
graphics, to avoid the need for thousands of boring words.

RubyGarden stopped building the <img> tag around graphic file links.

I'm too lazy to build my own static Web site for these pictures. Was images
in spam a big problem? or did some script just clobber my graphics by
accident?

Flipster,

The image links just need to be changed to upper-case the protocol
part of the URL (e.g. HTTP://www.blah.com/someimage.jpg).

Hopefully not too much of a pain.

Thanks,
Chad Fowler

http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 20,000 gems served!)

 

[Gavin Sinclair]

The image links just need to be changed to upper-case the protocol
part of the URL (e.g. HTTP://www.blah.com/someimage.jpg).

Hopefully not too much of a pain.

Wasn't the idea of the "HTTP" patch to only apply to _new_ Wiki edits?

Gavin

 

[David Ross]

Wasn't the idea of the "HTTP" patch to only apply to _new_ Wiki edits?

Gavin

What would be the point if it were only new? They would spam the current
wiki pages.

David Ross

 

[Eric Hodel]

--1Ow488MNN9B9o/ov
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Gavin Sinclair wrote:
=20
=20
What would be the point if it were only new? They would spam the current= =20
wiki pages.

Edits, not pages.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--1Ow488MNN9B9o/ov
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFBhEPNMypVHHlsnwQRAjhbAJ9KqDaW4ig+GlKMI2ayw+P3mfAJogCfQ/lI
XAKXHHSIea9dPsBLGQ1Aq50=
=FsAZ
-----END PGP SIGNATURE-----

--1Ow488MNN9B9o/ov--

 

[Phlip]

Edits, not pages.

That's the thing - the pages "should" have all been grandfathered-in. I
ain't touching nothin' until the spam fixes stabilize, so the question
remains: Did new Wiki source disable all graphic transclusion by fiat? or by
accident?

I didn't think the spammers had (yet) started to push in images.

 

[David Ross]

Eric Hodel wrote:




That's the thing - the pages "should" have all been grandfathered-in. I
ain't touching nothin' until the spam fixes stabilize, so the question
remains: Did new Wiki source disable all graphic transclusion by fiat? or by
accident?

I didn't think the spammers had (yet) started to push in images.

Right, this spamming problem is just text related(I've yet to see image
spam), but the current obfuscations disallow any type of modification
due to the nature of the posed solution.

David Ross

 

[Jim Weirich]

Wasn't the idea of the "HTTP" patch to only apply to _new_ Wiki edits?

Well, the patch does 2 things: (1) makes "HTTP:" the proper prefix for
recognized lines and (2) rejects edits containing "http:". I suppose the
patch author could have been more clever and allowed either HTTP or http as
recognized line prefixes. Probably a better solution is a script to update
the wiki pages to the new format.

 

[Phlip]

Well, the patch does 2 things: (1) makes "HTTP:" the proper prefix for
recognized lines and (2) rejects edits containing "http:". I suppose the
patch author could have been more clever and allowed either HTTP or http as
recognized line prefixes. Probably a better solution is a script to update
the wiki pages to the new format.

Thanks - I just "got" it. To rescue my few pages, I must edit _all_ their
http: tags.

When you change a page and save it, any http: tags bounce, not just the ones
you edited.

 

[Chad Fowler]

Thanks - I just "got" it. To rescue my few pages, I must edit _all_ their
http: tags.

When you change a page and save it, any http: tags bounce, not just the ones
you edited.

That's right.

--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 20,000 gems served!)

 

[Phlip]

Phlip wrote:

That's right.

Okay. Imagine a spammer changes their URLs (in their input files!) to read
HTTP:

Then they attack.

Any page with http: in it, they can't edit. They must erase the content, or
upgrade its http:s to HTTP:s. The later is unlikely.

However, my pages, which I just upgraded to HTTP:, are now _more_ vulnerable
to attack.

sigh<

"O bother, said Pooh, as his magazine emptied."

 

[trans. (T. Onoma)]

| > Phlip wrote:
| > > Thanks - I just "got" it. To rescue my few pages, I must edit _all_
|
| their
|
| > > http: tags.
| > >
| > > When you change a page and save it, any http: tags bounce, not just the
|
| ones
|
| > > you edited.
| >
| > That's right.
|
| Okay. Imagine a spammer changes their URLs (in their input files!) to read
| HTTP:
|
| Then they attack.
|
| Any page with http: in it, they can't edit. They must erase the content, or
| upgrade its http:s to HTTP:s. The later is unlikely.
|
| However, my pages, which I just upgraded to HTTP:, are now _more_
| vulnerable to attack.
|
| >sigh<

You bring up an interesting insight. If a page contains a "mark" of
un-save-ability, then it useless to spammers unless they can identify that
mark and remove. We've already seen that something as simple as 'http://' can
help do that. Of course eventually they could easily circumvent that. But we
have an interesting solution in the making.

If we allowed a special mark for a page, such that the lock sequence would
have to be _removed_ from the page before it will save. This would largely
thwart spammers b/c they generally just _add_ to the page --moreover, if the
lock sequence is redefinable to some degree it may help even more.

But how might it be done?

T.

 

[Phlip]

You bring up an interesting insight. If a page contains a "mark" of
un-save-ability, then it useless to spammers unless they can identify that
mark and remove. We've already seen that something as simple as 'http://' can
help do that. Of course eventually they could easily circumvent that. But we
have an interesting solution in the making.

If we allowed a special mark for a page, such that the lock sequence would
have to be _removed_ from the page before it will save. This would largely
thwart spammers b/c they generally just _add_ to the page --moreover, if the
lock sequence is redefinable to some degree it may help even more.

But how might it be done?

This arms race is bows-and-arrows against nukes. If we put a secret mark on
a page, this is the equivalent of a CAPTCHA, because a human must read the
documentation to find the mark. But the loophole is the spammer will just
erase the entire page.

 

[trans. (T. Onoma)]

On Sunday 31 October 2004 03:13 pm, Phlip wrote:
|
| This arms race is bows-and-arrows against nukes. If we put a secret mark on
| a page, this is the equivalent of a CAPTCHA, because a human must read the
| documentation to find the mark. But the loophole is the spammer will just
| erase the entire page.

Right, it is sort of a captcha. The only thing I was really drawing onw was
that you;d have to take something away rather then put something in. But your
right, they could just remove the whole pages. So you'd have to have both I
suppose.

Just foe sh*ts and g*ggles, what are the spmmer ramifications if the wiki
stuck a mark on the end of the page when you go to edit that you must delete,
and also gave a captcha string you must add to the end, in order to save the
document.

T.