Hi Christian,
In my opinion your use case (GDPR) is not widely used, since Nginx offers developer number of ways to change nginx behaviour and add more feature other than default, you should consider to write your own module to archive what you want
--
Hưng
> On Sep 22, 2020, at 13:31, Christian Theune <ct@flyingcircus.io> wrote:
>
> 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 <ct@flyingcircus.io> 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 <ct@flyingcircus.io> 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 · ct@flyingcircus.io · +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 · ct@flyingcircus.io · +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 · ct@flyingcircus.io · +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
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
