[Moin-user] MoinMoin used for porn spam publication

Jean-Philippe Guérard jean-philippe.guerard at tigreraye.org
Thu May 10 18:47:51 EDT 2007


Le 2007-05-10 00:57:20 +0000, George (Skip) VerDuin écrivait :
> >  - There is no ACL defined to limit adding attachments. Write access 
> >    gives you both the right to add attachments (if attachments are 
> >    enabled) and to write text. Either you forbid attachment to 
> >    everybody, either you enable attachment to all users with write 
> >    access.
> Your suggestion is worthy of *developer* analysis, but I suggest you
> might not really "like" your modified access rule as much as you might
> like a revert functionality added to attachments?

A revert functionnality for attachment would be nice, but you would also 
need to be able to completely remove the image from the revision 
history.

Otherwise, it would still be possible to access the image, which was the 
aim of the spammer.

> >  - The subscription feature act as an audit tool for the text being
> >    written. If somebody writes something that's not acceptable, I'm 
> >    notified (as I'm subscribed to the whole wiki), and I can revert the 
> >    page. There is no such audit tool for attachments.

> This contains an idea that might be applicable to my site, perhaps your
> site, if it were available (per developer priority).  The ACL feature
> might have a graded access rule - "publish" & "review".  It is *NOT* my
> role here to suggest moinmoin features, but to suggest how I might apply
> the above idea to help me sleep...

I can see two ACL entries that would de nice :

 - An "attach" ACL entry, for trusted people.
 - An "offer" ACL entry, to enable people without attach access
   to submit an attachment for approval.

> If I can jump to a conclusion, your present problem and my worry is over
> material quality added to our wiki sites.  In your case the material was
> graphic contained in attachment, in my case it was text placed on a
> reflector.  In both cases there seems to be (almost) no automated
> solution to content review *prior* to publishing the new material.  Our
> present tools require human intervention either always or never...
> 
> Consider the user group as having a variety of permissions, some of
> which would trigger the audit tool you suggest.  Certainly you have
> users who have developed trust and there is little reason to audit the
> contributions from them - the "recent changes" might be adequate to
> follow their work.  Others like StepStep need to be culled from the
> flock *before* they ruin your reputation.  We have the lock-out tool
> already...
> 
> I'd like to suggest an administrator attribute on the user (ACL?) list
> that would not in fact permit immediate publishing of the material
> submitted but would create an email alert that there is material in a
> "hold queue" for review prior to authorization to publish.  You might
> consider this a forward looking revert type feature?  The original
> remains as the published page, and the administrator has the option of
> permitting the new page (and/or attachment) to be made visible to all.
> YES - I have not thought thru all the implications for moinmoin, but
> with all tools there is a give-and-take when dealing with authority
> given to individuals.  I like the openness and responsiveness of moin to
> a trusted group of contributors and I would not like to detract from
> that capability...
> 
> So Jean-Philippe and Jim, does this approach seem sane and has the
> concept been evaluated in the past?

I think that would be very nice.

I fact, I would need two additionnal features:

 - An ACL management of attachments (as described above - with an hold 
   queue if possible).
 
 - Notification via e-mail subscriptions of attachments updates (if 
   you're subscribed to a page, you get notification of attachments
   changes in addition to content changes).

The minimal safe option would be:

 - An ACL entry "attach" to enable attachment used (that would therefore 
   be distinct from write permission).
   
 - Notification of attachement update.

That is, without the hold queue feature. That would be less open, but as 
safe as the first option.

Thanks.

-- 
Jean-Philippe Guérard
http://tigreraye.org





More information about the Moin-user mailing list