This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/mat-wg@ripe.net/
[mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
- Previous message (by thread): [mat-wg] [atlas] Proposing more public RIPE Atlas data and clarifying the current situation
- Next message (by thread): [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brian Trammell
trammell at tik.ee.ethz.ch
Fri Jan 10 10:18:39 CET 2014
hi Vesna, all, Another potential way to resolve the tension between public and "private" policies would be to allow each probe host to decide which of their probe(s) are available for non-public* measurements. Here, each probe has a "public-only bit". Probes with the public-only bit cleared can be used for public or non-public UDMs, and generate credits which can be used for public or non-public UDMs. Probes with the public-only bit set can only be used for public UDMs, and generate credits which can only be used for public UDMs. Probes default to having the public-only bit cleared; this allows probe hosts to opt out of allowing their probes to be used for non-public UDMs, but at the expense of being able to do non-public UDMs themselves. This arrangement would allow the whole community to decide for itself, in a decentralized manner. It would also require a bit of redesign, but so would measurements that would remain non-public for some escrow period. There are probably details I'm missing. For one, if we're going to allow non-public UDMs at all, all the anchors probably have to have their public-only bit cleared, otherwise the core of the network fragments. The default measurements for all probes must be public in all cases, as well. * I use "non-public" here as opposed to "private" intentionally, because the very notion of "private measurements" on a widely distributed volunteer active measurement network is somewhat dubious. It's trivially easy to find out what an Atlas probe is doing if you have access to the network it's on, so your measurements and results are leaking to a set of probe hosts even in the case of a some bit being set in the database. You cannot know the degree of collusion among Atlas probe hosts, so using the term "private" here gives an inaccurate impression of who can know what about non-public. If it's actually important that you can control who knows what about the measurements you're doing, what you want is a different architecture than Atlas provides. A non-public measurement is simply a measurement which can be later redacted from certain views of the database. And in the interests of disclosure, I'm one of the freeloading research types, so of course I want everything to be eventually public, and in return I agree not to care who knows that v6 connectivity to my web host could be better (https://atlas.ripe.net/atlas/udm.html?msm_id=1402190#!tab-probes1402190). I do large-scale, long term work, so it's less important to me that I can see all of today's UDMs today, and more important that I can see all the measurements from 2012 to 2017 in 2017, so a user-definable embargo period for UDMs would be a good solution too, if that addresses business-sensitivity concerns. Cheers, Brian Vesna Manojlovic wrote: > Dear colleagues, > > Three weeks ago, the RIPE NCC published a clarification about the > current state of RIPE Atlas public measurement data and the privacy of > probe data. We also proposed making some changes to the current situation. > > There has been some lively discussion about our proposal to make the > probe and measurement data public for new and existing users starting at > a future date. > > Most comments did not support this proposal. Some people are in favour > of keeping the situation as it is (i.e. making it possible to opt out of > making your measurements public), while others proposed an alternative > solution of delaying the publication of measurement data for a day (or a > week). > > We'd like to hear more opinions, either for or against any of these > proposals, including your motivation or the use case you have in mind. > > Please take part in the discussion on the mailing list. > > We will consider your input and come up with an updated proposal in > February. > > Regards, > > Vesna > Measurements Community Building > RIPE NCC > > > On 17-dec.-13 12:23, Vesna Manojlovic wrote: >> Dear colleagues, >> >> Sharing information about Internet performance is at the heart of >> collaborative efforts such as RIPE Atlas. >> >> Most of the RIPE Atlas probes and RIPE Atlas measurements are already >> public, and we'd now like to suggest opening up the publication of RIPE >> Atlas data further. We also want to clarify exactly what is and isn't >> public in the current system. We describe this in more detail in this >> RIPE Labs article, where we also ask for community feedback about our >> suggested plan to move forward: >> https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public >> >> >> >> Our proposed plan is to make all *new* measurements and technical >> information about the *new* probes public from an agreed upon date >> in the future. We propose implementing this change in mid-April. >> >> All probes and measurements that were not marked "public" by April 2014 >> would remain non-"public". For a detailed description of what this >> means, please see the RIPE Labs article (above). >> >> Although we believe that having public measurement data contributes to >> the goal of RIPE Atlas, the RIPE NCC greatly values our users' privacy. >> We want to ensure you that we will continue to protect our probe hosts' >> personal information. >> >> We look forward to your feedback and comments on the MAT Working Group >> Mailing List. >> >> Regards, >> >> Vesna Manojlovic >> Senior Community Builder >> Measurements Community Building >> RIPE NCC >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 600 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/mat-wg/attachments/20140110/0ab8284f/attachment.sig>
- Previous message (by thread): [mat-wg] [atlas] Proposing more public RIPE Atlas data and clarifying the current situation
- Next message (by thread): [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ mat-wg Archives ]