Feature Request: Captive Portal detection: by "Search Domains" as Evidence

[Pro Backup]

Wireless access points often display captive portals on browser start.
This causes for instance the "Safari Top Sites" thumbnail generation
and "Changes Meter" to have screwed up results.

The feature request would be to have a new Evidence source: "Captive
Portal". Detection could start with detection for specific "search
domains" in /etc/resolv.conf (cap1.coova.org, coova.org, etc.)
Example:
---
domain coova.org
nameserver 192.168.182.1
nameserver 192.168.182.1
---

Next step would be to sent out http requests to known uri's as soon as
the response contains WISP XML code, the captive portal is detected.
Futher options could be, when WISP XML is not detected, but there is
still a 302 Moved Temporarily response, to search for (user pref)
known captive portal locations, example:

Location:
https://www.fon.com/login/gateway/custom/sec/e9839fa8025ef057100090a81bf0d453?res=notyet&uamip=192.168.182.1&uamport=3990&challenge=13f9653825022e18b2043ef0647b7951&mac=00-00-00-00-00-00&ip=192.168.182.22&nasid=00-00-00-00-00-00&userurl=http%3a%2f%2fwww.coova.org%2f

Another user pref for each location / rule should be (1) the first and
(2) latter recheck intervals. As hotspots are often available for a
fixed amount of time, for instance 1 hour, which would make me set the
first recheck (1) to 3597 seconds and the retry to (2) 3 seconds.

This evidence could also be subevidence of the WiFi rule for known
network names.