Denis, On 02/12/2020 23.39, denis walker via db-wg wrote:
Personally I don't think MNTNER objects should be visible at all to the public. I don't know of any other service on the internet where details of how you secure your data are open to the public. Being able to query for someone else's MNTNER object is a throw back to the days when only nice people used the internet :)
My understanding of why MNTNER is public is quite different. Many years ago (like 19 or 20 years ago) I was told that the RIPE Database was completely open because of the benefits that transparency brings. Among these were: * Not having to trust that the RIPE NCC was properly managing the data. No data leaks are possible if all data is published at the start! * Being able to make a copy of the database and have the entire public registry available for archive or backup purposes (for example if Holland was flooded and all RIPE NCC servers were destroyed). If I recall correctly two main factors changed this philosophy: 1. Publishing encrypted passwords using CRYPT-PW was vulnerable to brute force attacks, and even when updated to MD5-PW still vulnerable to dictionary attacks. 2. PERSON objects became a huge privacy problem as more and more contact data was published for people who had never even heard of RIPE. As far as I know there is no suggestion that this complete openness is a good idea today. Certainly I don't remember this being raised in the RIPE Database Requirements Task Force discussions - quite the opposite! There is a strong desire to collect and publish the minimum amount of data possible. As for whether MNTNER objects should be public... I always felt that the MNTNER concept conflated authentication and authorization and identity, and really the world would be better off without it. When I was looking at the requirements for the ARIN database back in the 20th century I proposed that authentication should always be tied to a human being, since any access to a database was always done on behalf of a person (even when done via an automated tool). Authorization should proceed based on role-based access controls (RBAC). At the time there was not a strong privacy requirement (and since ARIN is in the USA probably there still is no strong privacy requirement), so the idea was to collect a complete history of all changes for all time, allowing audits and rollback. Today I'd probably propose that policy for historical data be a first class object that was something that could be tweaked by users within system-defined limits. Cheers, -- Shane