The REAL "fancy pants"

[Vikram Dhillon]

On Mon, Aug 15, 2011 at 12:55 PM, Manjul Apratim
<manjul.apratim at gmail.com> wrote:
> Hey Vikram,
>
> Thanks for the clarification! My concern is this - if this user created a
> genuine Launchpad account merely to spam the documentation, and that too
> twice already, then that is one hell of an evil determination. In this case,
> can we not take more drastic steps to prevent such spam - like banning the
> user's ip address, or something of the like?
>
> On Mon, Aug 15, 2011 at 12:47 PM, Vikram Dhillon <dhillonv10 at gmail.com>
> wrote:
>>
>> On Mon, Aug 15, 2011 at 12:00 PM, Manjul Apratim
>> <manjul.apratim at gmail.com> wrote:
>> > Whilst objections are being raised over a perfectly good Google
>> > solution,
>> > there is a REAL "fancy pants" who keeps messing up
>> > https://help.ubuntu.com/community/UserDocumentation. Apparently he has
>> > the
>> > nick "SammyWilson", and he inserts spurious links to some "loan
>> > modification" web page in there - this has happened twice in the past
>> > few
>> > days already, and thanks to the vigilant Ubuntu warriors out there such
>> > spam
>> > has not prevailed for long. What bothers me is not the fact that the
>> > page
>> > was vandalized, but that changing something on help.ubuntu.com requires
>> > a
>> > Launchpad account, and this entity's account does not exist now, but
>> > apparently did when the page was exploited. I remember seeing the
>> > discussion
>> > that Launchpad was hard to register at in the first place, particularly
>> > because of the Ubuntu Code of Conduct, and I remember that that was my
>> > first
>> > tryst with GPG keys. So either this person goes through a lot of trouble
>> > each time, or there is a security flaw in Launchpad, and either issue is
>> > a
>> > cause for concern!
>> >
>> > --
>> > Manjul Apratim
>> >
>> > --
>> > ubuntu-doc mailing list
>> > ubuntu-doc at lists.ubuntu.com
>> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc
>> >
>> >
>>
>> Manjul, I read your previous reply to the other conversation about
>> using google for internal search. While we appreciate that you took
>> the time to look through revision history, there's no problem there.
>> Here's what I mean:
>>
>> [DIFF]  MediaWiki       06:33   Info    Tom [1-2]
>>                                                        SammyWilson [3]
>>
>> [DIFF]  Community Documentation         06:32   Info    Tom [1]
>>
>>         SammyWilson [2]
>>
>> The first edit was made at 6:32, then the next one at 6:33, the
>> account was removed after the second edit therefore both of them were
>> made before the user was removed and at that time he still had editing
>> privileges. The launchpad security model is one of the best I've seen
>> around, so there's nothing wrong with it.
>>
>> --
>> Regards,
>> Vikram Dhillon
>>
>> ~~~
>> To perceive is to suffer.
>
>
>
> --
> Manjul Apratim
>

Manjul,

Try to avoid top-posting, if possible. Now then, to answer your
concerns. I will tell you that if I want to spam a website, no amount
of ip-banning is going to stop me, proxies can easily jump over
several ip addresses, then there's ssh tunneling but nonetheless if
you're determined to spam, there's not much we can do.

Most people use the wikis constructively so we can't lock the pages
simply because a handful cases want to spam, that's why we have a lot
of people who edit those links when they see them, Tom for instance is
one of them. Also realistically, we don't have the kind of time to
implement hard-core anti-spamming procedures, if someone continues to
spam, banning their account is simpler and the documentation team has
other things that take priority. We simply divide the work amongst the
people who help us, some people write pages, others edit, that's how
we are who we are because of what everyone else is (that btw is
Ubuntu's philosophy)

Spam is indeed a hard issue to deal with, especially on wiki pages,
but I'll talk to Matthew about a possible solution.

-- 
Regards,
Vikram Dhillon

~~~
To perceive is to suffer.

PS. I forgot to CC the list hence sending this out again.