Prevent low skill exploits

[zieren]

There is at least one low skill exploit:

1. Open a tab X for which the limit is zero
2. When the alert is shown (or rather, a few seconds later, within the grace period), switch to a tab Y for which the limit isn't zero. Maybe even press ^F12 now to pick this up immediately, or else wait for the warning window to disappear (which it now conveniently does).
3. Switch batch to tab X.

This could be addressed in several ways:

• Contact the server immediately when windows have changed: Rather than sample at a constant interval, we could improve accuracy and, more importantly, response time by contacting the server immediately when the window list has changed. Then this trick wouldn't give 15s, but maybe only 2s (1s sample interval + 1s request time), plus - in both cases - the grace period.
• Check if the grace period (and kill latency) can be set to zero, i.e. terminate the offending program immediately.
• Ignore changes to the window title. We know the PID so we can kill the whole program. This targets browsers specifically, but there may be other programs where you can change the title quickly to escape termination.
• Remember strikes and terminate faster on 2nd/3rd/... strike: Maybe set the grace period to zero only now, or even store window titles locally so they can be terminated immediately (that sounds good). We could send those "doomed" titles to the server to make sure there is still zero time for them (but not have them recorded as activity). Then, if time is added, they can be removed from the client-local list.

First simple step is to ensure that a grace period of 0 works. We need to document parameters and ranges anyway.

[zieren]

Another idea: If time elapses repeatedly for a class (say, 3x in 10 samples), blacklist it and kill the PID immediately.