@peterbo opened this Issue on February 15th 2011 Contributor

For the anonymizeIP-Plugin, it is not only necessary to mask the IP for storing in the DB but also for the user recognition heuristics and all other plugins / tools / components that use the visitor IP before it is masked.

Since it must be masked very early at runtime to be sure, that only the shortened IP is used for all correlations, we need a new hook.

// (proposal from matt)
// Hook to modify the IP 
Piwik_PostEvent('Tracker.Visit.setVisitorIp', &$this->visitorInfo['location_ip']);

Any suggestions on this?

@robocoder commented on February 15th 2011 Contributor

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?

@peterbo commented on February 16th 2011 Contributor

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?

@mattab commented on February 17th 2011 Member

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

@mattab commented on March 27th 2011 Member

See proposal for User Privacy unified plugin #2233

@robocoder commented on April 22nd 2011 Contributor

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).

@robocoder commented on April 23rd 2011 Contributor

(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


  • Installer no longer checks for IPv6, so the related messages should be deleted from translations
  • IPv4 mapped addresses (e.g., ::ffff: 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 #2351
@peterbo commented on February 7th 2012 Contributor

(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.

This Issue was closed on February 7th 2012
Powered by GitHub Issue Mirror