1. As I said, it is by design. If you're wondering why the tooltip has to stick: a. touch displays b. copying text from the tooltip to the textbox or clicking on URLs in the tooltip. Considering that this change reduced our Akeeba Backup support requests by a whooping 15% there's not a chance of reverting it: it would simply cost way too much and most of our clients seem to find it useful anyway.
1.a. See https://www.dropbox.com/s/afjd0lvoniplka2/Screenshot%202015-01-07%2014.41.27.png?dl=0 I can see the entire text of the tooltip. Please note that the bottom vertical pixel of the tooltip (the bottom outline) is not shown because of the outer shadow gradient applied to Joomla!'s footer bar. The pixel IS there, but covered by Joomla!'s chrome. I can't change that without "hacking core", i.e. modifying core Joomla! CSS. I can't do that, it's not really a problem (the text is readable), so there's nothing to change.
2. I reaffirm what I said. The IP gets blocked NOT because of a security BUT because there were X security exceptions of any kind in the last Y amount of time, where X and Y are user configurable parameters. If a user tries a SQL injection attack, a Direct File Inclusion attack and finally a tmpl= keyword attack which gets them block would it help to let you know that their IP was blocked because of a template= keyword attack? It would be bad for your own security. You'd think they simply triggered a false alarm and unblock them – template= keyword exceptions can be raised when someone's trying to use the send link by email feature and you haven't enabled the Allow site templates option. You unblock them and they're back trying to hack your site. How does that make sense? If you want to consider if an IP should be unblocked or not you should:
1. First confirm they are still blocked (if they are unblocked, why bother?)
2. Check their block history (repeat offenses are a sign of malice or incompetence)
3. Filter the security exceptions by their IP and review the kind of attacks they've raised. It will give you an idea of why they keep getting blocked which will tell you if you screwed up, they screwed up or they are really trying to hack you.
None of this information can be efficiently conveyed in an email message or acted upon from it. In fact, I consider the notification emails the most stupid feature I've ever written. It can act as a denial of service against your site and/or your email inbox. That's why I'm suggesting to not enable it and have implemented a rate limit. I wanted to remove it completely, but I was made to understand that many of you are using it to prove to your clients that their sites are at risk and you are doing something about it. I don't agree with the concept but I see why it's important to my clients (they need to convince their clients that they should pay them before they can justify paying me) so I kept this feature in :)
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!