#108 TTS & message spam protection


The TTS needs better spam protection. For example, someone could send a short repeating line of [][][][]... and the TTS could take an annoying minute or more to read it all, as has been demonstrated to me on two separate occasions. The existing length threshold is by far not enough to stop that kind of spam while still being usable.
If possible, the TTS should be set to stop after so many seconds of reading any one line, or be able to detect an overdose of punctuation characters and not read it, or at the very least have a shortcut key to stop the TTS output.

The other more common kind of spam, multiple text messages, could be another problem for TTS as it falls behind. For that, it should be able to skip lines or stop altogether when it falls too far behind.
As is common for most chat spam prevention, Mumble (or Murmur) at the least should detect when one user sends a set number of messages within a set amount of time and block messages from that user for a set amount of time.
An automatic temporary ban could also be useful for repeat offenders, the server would only need to remember when the last few offenses were and ban if there were too many in a short period.

I don't think text spam is really a problem in Mumble just yet, but seeing how popular Mumble is becoming and how strange some of the users are already, it's inevitable in the not-too-distant future and such a feature should be prepared ahead of time.


  • Logged In: YES
    Originator: NO

    Neither SAPI (Win32) or Festival (Linux) provide any easy APIs for determining TTS length. Windows has a "stop speaking now" call, but no such call exists in Festival.

    All spam protection has problems. First of all, there are genuine cases where I might want to send messages quite fast. Consider the following:
    - Hi
    - Hi
    - Sup?
    - Nada

    and so on. With that pattern, we'd have to allow .. oh... 1 message every 10 seconds? Which is more than enough for our spammer.
    We could also limit it to "N characters over T seconds", but that would mean no cut&paste of text from forums etc.

    Second, there is nothing really stopping the spammer from connecting 10 clients and distributing his spam load that way. So we are merely inconveniencing spammers AND users, we're not really stopping spam.

    1.1.0 will have ACLs for text messages -- if you can speak to someone you can text them. This means it's easier to restrict spammers.

    I'll have to do some more thinking about this. Mumble was originally designed for close knit groups of adult gamers on private servers. As such, it's very permissive as it assumes people aren't jerks. This assumption naturally fails on any kind of public server.

  • Kissaki

    Logged In: YES
    Originator: NO

    agreed, should have higher priority :)
    around 8

  • Kissaki

    A user should be able to skip TTS output.
    That way, if a spammer does abuse his permissions, the user can intervene at least the currently being played TTS audio.
    Just using the disable/enable TTS should be enough for that.

    Slicer said above “Windows has a "stop speaking now"” which would be usable for this I guess.

    TTS being disabled -> cancel any playing TTS output (by Mumble).

    I did not check on the implementation details.