there goes the neighbourhood (launchpad is getting owned by spammers)

Bug #495250 reported by James Troup
44
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Critical
Unassigned

Bug Description

Spammers are now (?) registering as users on launchpad, filling
homepage_content with spam and then sending it out spam mails linking
to their Launchpad user page, e.g.

  <https://launchpad.net/~buy-valium-without-prescription>

We're already getting complaints about this to abuse@ type addresses
and it's safe to assume that as a result launchpad.net URLs are going
to start adversely affecting the spam "score" of otherwise legitimate
emails.

A simple check of the person table showed nearly 600 users with
'prescription' in their homepage_content entry and (from a quick
glance) none of them looked legitimate.

IMO, we need to urgently:

 a) make the controls on signing up for Launchpad stronger; e.g. by
    using recaptcha rather than the incredibly weak mathcaptcha we
    have right now.

 b) clean out all the existing bogus accounts to reduce the damage
    done to launchpad.net's "reputation" (in terms of spam and search)

Related branches

Revision history for this message
Henning Eggers (henninge) wrote :

Complete agreement from me. I filed bug 493960 a few days ago.

Revision history for this message
Māris Fogels (mars) wrote :

That is part of an automated or farm system. A Google search of one key site resulted in 5000 page hits for Launchpad user names. There are multiple names on each page, and each name is a spam or scam account of some sort. I filed https://answers.edge.launchpad.net/launchpad/+question/93104 about it, but there will be no action until I can write a script to parse and extract the names.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

It's worth checking to see if any of these accounts are being used to spam wiki.ubuntu.com as well.

I don't want to paint the bikeshed or anything, but perhaps we could refrain from making a user's links "live" until the account has a certain level of karma. This seems to be a leakage of trust, if nothing else, and karma is the closest thing to a trust metric of any sort.

Revision history for this message
Martin Albisetti (beuno) wrote :

Another (cheap) thing we could do to deter spammers a bit is add the "nofollow" tag to external links so it's less attractive from a SEO point of view.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

To be more precise, I meant that a user's karma should determine whether links become "a href=" tags for anonymous access only. So a new user can post URLs, and maybe logged-in users can click them, but the anonymous access (including google) will just see them as a block of un-marked-up text.

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

bug 495516 also seems related to this

Curtis Hovey (sinzui)
Changed in launchpad:
assignee: nobody → Curtis Hovey (sinzui)
status: New → In Progress
importance: Undecided → Critical
Revision history for this message
Francis J. Lacoste (flacoste) wrote :

* Maris is going to take care of writing a script deleting the 5000 spammy accounts found.

* We are going to add nofollow to all external links in user content.

* We are going to not render links on person's page without karma to anonymous user.

Changed in launchpad:
importance: Critical → High
status: In Progress → Triaged
affects: launchpad → launchpad-registry
Changed in launchpad-registry:
status: Triaged → In Progress
importance: High → Critical
Revision history for this message
Curtis Hovey (sinzui) wrote :

We make two changes to address this motivation to use Launchpad for spam:

    * modify the text-to-html formatter to always render links with the rel="nofollow"
      attribute. User created links will not be indexed by Google, Yahoo, or what ever
      engine Microsoft is using this month to get an advertising business.
    * Never convert URLs to links when anonymous users are viewing profiles
      without karma.

Revision history for this message
Don Marti (dmarti) wrote :

I got hit with a bunch of links to these spam pages. To make cleanup easier on the targets, any chance that you could serve the home pages for removed users with an HTTP 403 or 404, so we could know yes you did have a spam account, but you closed it? When the page comes back as a 200 it's harder to tell a closed account from an active one.

Curtis Hovey (sinzui)
Changed in launchpad-registry:
milestone: none → 3.1.12
Revision history for this message
Francis J. Lacoste (flacoste) wrote :

Actually, Don has a good point, we should serve the user's page with status SUSPENDED with the HTTP status of 410 Gone.

Revision history for this message
Curtis Hovey (sinzui) wrote :

I have a branch that introduces the concept of a probationary user. We do not allow their profile page to be indexed, nor will its content be formatted as HTML. We can change the karma requirement to for probation. Spammers will have help projects get our of probation.

I think the account issue is a separate bug because we want the status set from any launchpad application, not just the registry. Does this behaviour affect all launchpad users? I believe that launchpad admins or registry experts should have permission to see and reactivate the user to correct mistake.

It is hard to distinguish a suspend account from one that has never been activated. Deactivated accounts state they are deactivated, and the owner can reactivate it. Suspended accounts look like unused accounts, The account cannot be reactivated and if the user tries to reuse it; he is asked to send an email to an admin at feedback@launchpad,net

Revision history for this message
Francis J. Lacoste (flacoste) wrote :

I think we could serve the content of SUSPENDED user home page as is now, but just set the HTTP status to 410. A browser should render the returned page but a spider will notice the status code and delete the link from the index.

Curtis Hovey (sinzui)
tags: added: current-rollout-blocker
Curtis Hovey (sinzui)
Changed in launchpad-registry:
milestone: 3.1.12 → 3.1.13
Revision history for this message
Ursula Junque (ursinha) wrote :

According to Curtis, this is going to be cherrypicked in the beginning of the next cycle.

Revision history for this message
Curtis Hovey (sinzui) wrote :

Fixed in launchpad devel r10062

Changed in launchpad-registry:
status: In Progress → Fix Committed
Curtis Hovey (sinzui)
Changed in launchpad-registry:
status: Fix Committed → Fix Released
Curtis Hovey (sinzui)
Changed in launchpad:
assignee: Curtis Hovey (sinzui) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.