Are the posted questions getting worse?

  • I would go for something like not allowing more than two new threads in two minutes, not more than 3 in 4 minutes, not more than 4 in 7 minutes, not more than 5 in 10 minutes, and no more new threads than 5 until 15 minutes after the first one, and no sixth new thread until 30 minutes after the first one; if when a user creates a new thread this is his first new thread in an hour or the count goes back to 1, also the count is maintained modulo 5 (so when you might expect it to become 6 it becomes 1 instead). If the new thread count hits 6 (at least 15 minutes after the caused it to be set to 1) the count is set back to 1 again;

    Maybe people with lots of points could be free to create a few more threads than that, but I don't see the point - there isn't really any legitimate reason for creating a lot of threads faster than a dozen threads per hour.

    Of course this requires the users current new thread count to be retained when he logs out if it is to work. Maybe that could be avoided if there was a restriction on the login rate, but any such restriction should be designed to hit a balance between user convenience and security, so it is best to keep spam prevention separate.

    Tom

  • TomThomson (8/11/2014)


    I would go for something like not allowing more than two new threads in two minutes, not more than 3 in 4 minutes, not more than 4 in 7 minutes, not more than 5 in 10 minutes, and no more new threads than 5 until 15 minutes after the first one, and no sixth new thread until 30 minutes after the first one; if when a user creates a new thread this is his first new thread in an hour or the count goes back to 1, also the count is maintained modulo 5 (so when you might expect it to become 6 it becomes 1 instead). If the new thread count hits 6 (at least 15 minutes after the caused it to be set to 1) the count is set back to 1 again;

    Maybe people with lots of points could be free to create a few more threads than that, but I don't see the point - there isn't really any legitimate reason for creating a lot of threads faster than a dozen threads per hour.

    Of course this requires the users current new thread count to be retained when he logs out if it is to work. Maybe that could be avoided if there was a restriction on the login rate, but any such restriction should be designed to hit a balance between user convenience and security, so it is best to keep spam prevention separate.

    My compliments, Tom. There's a lot of wisdom in that idea. What if the login restrictions were tied to total points? The spam posters are usually vetted out and dropped before they get very far. The new thread restriction above would prevent them from getting very far to begin with, so this could work. It would be another layer of security, but a captcha on the new thread screen could also help eliminate the bot-style posts.

    Of course, it's easy for us to come up with the ideas...we don't have the full picture and aren't the ones who have to write it. 😛

  • One more thing that may help, a separate SPAM ALERT button. It sends a report regarding the post, and sets an Invisible flag so that the post is kept from displaying in the Active Threads screen. You would have to refresh the thread to see the spam post disappear, but that is no big deal.

    At that point the admin can review the post and decide if it is actually spam and delete it, or make it visible again and post a response to the thread regarding the decision.

  • Ed Wagner (8/11/2014)


    It would be another layer of security, but a captcha on the new thread screen could also help eliminate the bot-style posts.

    No, please no. Captchas are so annoying and computers can solve them just fine.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • To expand on Lynns idea:

    It might be an additional "feature" to set a minimum number of forum posts before being allowed to flag a thread.

    While I do trust each of the "regulars" to identify a spam post I don't think it'll be a good idea to let anybody make such a decision...

    This might help to clean that spam almost immediately and would take some pressure off the admins while at the same time the admins still have final control whether to delete or to "unflag" it.



    Lutz
    A pessimist is an optimist with experience.

    How to get fast answers to your question[/url]
    How to post performance related questions[/url]
    Links for Tally Table [/url] , Cross Tabs [/url] and Dynamic Cross Tabs [/url], Delimited Split Function[/url]

  • GilaMonster (8/11/2014)


    Ed Wagner (8/11/2014)


    It would be another layer of security, but a captcha on the new thread screen could also help eliminate the bot-style posts.

    No, please no. Captchas are so annoying and computers can solve them just fine.

    I 100% agree that they are completely annoying and many times I can't read them, but I wasn't aware that people had figured out how to solve captchas programmatically. I don't keep up-to-date on these things. If that's the case, then please scratch my ideas from the record.

  • LutzM (8/11/2014)


    To expand on Lynns idea:

    It might be an additional "feature" to set a minimum number of forum posts before being allowed to flag a thread.

    While I do trust each of the "regulars" to identify a spam post I don't think it'll be a good idea to let anybody make such a decision...

    This might help to clean that spam almost immediately and would take some pressure off the admins while at the same time the admins still have final control whether to delete or to "unflag" it.

    Say people in the top 25? These are the ones most active on SSC. Just a suggestion.

  • Ed Wagner (8/11/2014)


    TomThomson (8/11/2014)


    I would go for something like not allowing more than two new threads in two minutes, not more than 3 in 4 minutes, not more than 4 in 7 minutes, not more than 5 in 10 minutes, and no more new threads than 5 until 15 minutes after the first one, and no sixth new thread until 30 minutes after the first one; if when a user creates a new thread this is his first new thread in an hour or the count goes back to 1, also the count is maintained modulo 5 (so when you might expect it to become 6 it becomes 1 instead). If the new thread count hits 6 (at least 15 minutes after the caused it to be set to 1) the count is set back to 1 again;

    Maybe people with lots of points could be free to create a few more threads than that, but I don't see the point - there isn't really any legitimate reason for creating a lot of threads faster than a dozen threads per hour.

    Of course this requires the users current new thread count to be retained when he logs out if it is to work. Maybe that could be avoided if there was a restriction on the login rate, but any such restriction should be designed to hit a balance between user convenience and security, so it is best to keep spam prevention separate.

    My compliments, Tom. There's a lot of wisdom in that idea. What if the login restrictions were tied to total points? The spam posters are usually vetted out and dropped before they get very far. The new thread restriction above would prevent them from getting very far to begin with, so this could work. It would be another layer of security, but a captcha on the new thread screen could also help eliminate the bot-style posts.

    Of course, it's easy for us to come up with the ideas...we don't have the full picture and aren't the ones who have to write it. 😛

    Captchas are really annoying. Moreover to annoy us even further many times they are made case-sensitive :doze:!


    Sujeet Singh

  • Holy crap, I'm almost speechless:

    http://www.sqlservercentral.com/Forums/Topic1601764-1633-1.aspx


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Evil Kraig F (8/11/2014)


    Holy crap, I'm almost speechless:

    http://www.sqlservercentral.com/Forums/Topic1601764-1633-1.aspx

    I don't know what to say to the OP on that one. Where do you go with a question like that? I think you handled it as well as can be expected.

  • Ed Wagner (8/11/2014)


    Evil Kraig F (8/11/2014)


    Holy crap, I'm almost speechless:

    http://www.sqlservercentral.com/Forums/Topic1601764-1633-1.aspx

    I don't know what to say to the OP on that one. Where do you go with a question like that? I think you handled it as well as can be expected.

    Maybe ask if they also run pirated software?

    Probably would only be surprised if they said 'no'.

  • Evil Kraig F (8/11/2014)


    Holy crap, I'm almost speechless:

    http://www.sqlservercentral.com/Forums/Topic1601764-1633-1.aspx

    That's a new one, aside to the questions asking for exam dumps and free copies of books.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • So three days after implementing replication, I have a pile or replication-related errors on my desk (cannot truncate table because it's replicated, lob size exceeds max replicated text size)

    How the #$%^%&^% did this pass QA testing?

    Oh, let me guess, the app wasn't part of the testing. $#%$!!!!

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (8/12/2014)


    So three days after implementing replication, I have a pile or replication-related errors on my desk (cannot truncate table because it's replicated, lob size exceeds max replicated text size)

    How the #$%^%&^% did this pass QA testing?

    Oh, let me guess, the app wasn't part of the testing. $#%$!!!!

    Ouch...

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Koen Verbeeck (8/12/2014)


    GilaMonster (8/12/2014)


    So three days after implementing replication, I have a pile or replication-related errors on my desk (cannot truncate table because it's replicated, lob size exceeds max replicated text size)

    How the #$%^%&^% did this pass QA testing?

    Oh, let me guess, the app wasn't part of the testing. $#%$!!!!

    Ouch...

    Eek, sounds horrible. Just saw your tweet as well, step away from the forums Gail 😉

    Rodders...

Viewing 15 posts - 45,151 through 45,165 (of 66,712 total)

You must be logged in to reply to this topic. Login to reply