Once the masked ip is stored, it's not useable in the heuristics match.

Live and GeoIP are the only plugins that look up the IP. Live queries the DB. GeoIP is being moved into core, but can be disabled like any other plugin.

Are there any other specific use cases?

Anthon, I'm not quite sure if I get your point. Do you mean that the heuristics use the full IP-Address but do not match against the IP which is stored in the DB (since it is masked)?

I only want to make sure, that we find a consitent solution for being sure, that no component (if core or plugin) can't use the full IP-Address if the anonymizeIp-Plugin is active. To comply with the privacy laws, not only storing the full IP is against the terms but also calculations / computations / Geolocalization / etc at (tracker) runtime.

So I'm stating this for discussion: If I activate the anonymizeIP-Plugin, I want to be sure that nothing is contrary to any privacy laws. A standard (not technical user) is not aware of the fact that he would also have to disable the GeoIP-Plugin to be absolutely safe.

Are there arguments for / against this statement?

I think that only "IP Exclude" feature requires the full IP (but not stored anywhere, since the visit is ignored). Must have for Data and user Privacy

See proposal for User Privacy unified plugin #2233

The new config setting will be: ip_address_pre_mask_length

We can implement the unified Privacy plugin after I check in this enhancement (along with the IPv6 changes).

(In [4533]) fixes #1111 - add support for IPv6 addresses (tracking, anonymization, and exclusion)
fixes #2095 - add new anonymization hook (pre-heuristics)
fixes #2055 - optional IP filter when multiple proxies present
fixes #1775 - SitesManager: supports CIDR notation for IP exclusion

Notes:

• Installer no longer checks for IPv6, so the related messages should be deleted from translations
• IPv4 mapped addresses (e.g., ::ffff:127.0.0.1) are no longer re-mapped into IPv4 space
• users who to query IP addresses from MySQL directly, can use the following SQL, but inet_ntoa() is limited to IPv4 addresses:

select inet_ntoa(conv(hex(location_ip), 16, 10)) from piwik_log_visit;

• Windows: IPv6 inet_pton()/inet_ntop() not supported until php 5.3; see Windows: IPv6 inet_pton/inet_ntop not supported until php 5.3 #2351

(In [5772]) Refs #2233, #2095, #2902 - set ip_address_mask_length and ip_address_pre_mask_length on anonymizeIP-plugin activation. Synchronize both variables on PrivacyManager call.