Hi, as this is the first time I’m interacting with this list, I’d like to understand how to interpret silence. :)
Would someone mind educating me whether silence means: - you’re on the wrong list, please go elsewhere (where?) - the idea is not interesting enough to be considered - we currently don’t have time to deal with this - you’re completely wrong doing this and nobody wants to tell you ;) - you’re not adhering to some rule (sorry if that is the case) - something else (what?) Thanks a lot, Christian > On 16. Sep 2020, at 21:20, Christian Theune <[email protected]> wrote: > > Replying to myself for now ;) > > One thing I can imagine being desirable would be to make the number of bits > (v4/v6) that are masked configurable. > > The current choice of 8 bits for IPv4 and 64-bit on IPv6 is based on our > tradition that was considered a reasonable practice with respect to GDPR by > courts in Germany. Unfortunately I can’t find a reliable source at the > moment, but would take the time to dig one up if needed for the discussion. > > Cheers, > Christian > >> On 16. Sep 2020, at 17:28, Christian Theune <[email protected]> wrote: >> >> Signed PGP part >> Hi! >> >> first time posting here. I started working on a builtin-way for nginx to >> provide GDPR conformaing access logs reliably by default: >> >> https://github.com/nginx/nginx/compare/branches/stable-1.18...flyingcircusio:ctheune-anonymize-by-default >> >> This isn’t ready to be merged at this point as it suffers at least from two >> things: >> >> a) I’m not a C programmer by nature and might be making stupid mistakes. >> This is “monkey see monkey do code”. >> >> b) You likely do not want to have this on by default for everyone, so I’m >> expecting that this requires a config option (runtime or compile, with a >> slight preference to runtime from me). >> The new built-in variable remote_addr_anon should be available by default >> in any case, though. >> >> Some background: we tried implementing this purely by using a mapping >> approach, but this doesn’t make it a proper default as everybody defining an >> access log has to mention the proper format or accidentally IPs will leak. >> This happens over and over and we’d prefer a “privacy by design” approach >> very much. >> >> There is a trac ticket (https://trac.nginx.org/nginx/ticket/868) that >> already discusses this, however the .1 is IMHO not a good approach to >> recommend as it suggests a real IP whereas our impression is that nulling >> the last byte in IPv4 and nulling the last 8 bytes in IPv6 is the proper >> approach and it’s directly visible that this is an anonymized IP. >> >> Let me know what you think about this and - if you’d like to see this in the >> mainstream code - I’d appreciate if you give me the necessary hints to bring >> this code to the level of quality that is proper for nginx. >> >> Kind regards, >> Christian >> >> -- >> Christian Theune · [email protected] · +49 345 219401 0 >> Flying Circus Internet Operations GmbH · http://flyingcircus.io >> Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland >> HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian >> Zagrodnick > > -- > Christian Theune · [email protected] · +49 345 219401 0 > Flying Circus Internet Operations GmbH · http://flyingcircus.io > Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland > HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick > Liebe Grüße, Christian Theune -- Christian Theune · [email protected] · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
