--On Wednesday, January 25, 2023 11:22 +0000 Mirja Kuehlewind
<mirja.kuehlewind@xxxxxxxxxxxx> wrote:
Hi John,
thanks for your review. I applied your nits below in github
and we will fix that in the next version.
For the others issue, I understand from the on-going
discussion that those issues are probably separate issues or
at least beyond the scope of this document.
I believe they are. I think that it would be really unfortunate
if they fell through the cracks because I believe that some of
them (maybe not all) are issues on which the IETF ought to be
establishing principles and positions because, no matter what
they look like on a given day, they may have implications about
who does or does not participate in the IETF, how we are seen by
governments, regulators, and the public as well as by those
companies who use our standards, and so on. The IETF's survival
probably does not depend on such decisions, but our long term
credibility and relevance might.
Particularly for you first issue on information disclosure,
quickly some further remarks: the document requests to publish
aggerated data (which we usually do in the plenary report),
but does not explicitly request to keep other data
confidential. However, my assumption is that individual
registration data (except the name in the participants list)
is treated as confidential anyway (given things like the
GDPR). If we as a community want to give further guidance
about this to the LLC, we should probably work on some general
guidance. Also as Jay said for the fee waiver I believe the
discussion in the working group indicated that we want to be
able to have this information checked (not publicly but by
some individuals) in case misuse is suspected.
I think your assumption and what I believe to be desirable are
closely aligned if not identical (hint: I think the GDPR was a
bit of an overreaction and that, over time, it is likely to
need, and probably get, some tuning). Having read Jason's note
and reviewed the LLC (and almost everyone else's) privacy
policy, let me describe just one example of the interaction
between existing principle and the type of edge cases that
concern me.
As a sometime-statistician who spent many years working on
issues of how to probe data that was published in aggregate form
and combine it with other aggregated data in order to infer
information at much lower levels of aggregation, "it will be
published only in aggregate form" does not do much for me.
Example: when last I paid careful attention to our attendance
statistics, we had no attendees from Antarctica. Suppose a
couple of people with addresses there registered for IETF 116.
Had we been publishing data aggregated by continent, some
adjustments would be necessary to avoid the "aggregate data"
being easily analyzed in a way that would come close to
identifying individuals. Now that example is silly (or I assume
it is) because I am confident that LLC staff would notice an
entry in an aggregate report with only one or two people in it
and would research and implement some way to deal with it that
would neither disclose information or turn those participants
into second-class citizens. But there are far more complex
multivariate (or multi-table) cases that are harder to detect
and that are not appreciably less vulnerable to identification
of individuals and data about them (want to read a couple of
Ph.D. dissertations? I didn't think so). Consequently a
principle that says "we will aggregate at a sufficient level to
prevent disaggregation or deanonymization" is great as a
principle (and, as principles go, maybe sufficient) but, as with
many Internet security issues, what it means in practice depends
to a considerable extent on the skill level, determination, and
resources available to the attacker.
My personal guess is that the statements in the present policy
document are somewhere between "fine" and "about as good as we
are going to get". However, where that connects with the SHMOO
draft works like this. Suppose there were someone who wanted to
participate in the IETF had what they believed to be a
legitimate concern about disclosure of any information other
than their names. They don't need to participate in surveys or
provide demographic information, so they (and we) are ok there.
If they are able and willing to pay a registration fee, I
imagine they would figure out a way to do that without
disclosing any additional information, even if that required
establishing a chain of intermediaries who could get an envelope
to Fremont with some significant amount of cash in it and a
registration confirmation number on the front. But, suppose
they decide to apply for a fee waiver. There is nothing in
your draft that says "if someone applies for a fee waiver, the
LLC is expected to collect the absolutely minimum amount of
information required to allow..." (whatever it is they decide
they need to allow) "and the community will be told what
information is to be collected so that potential applicants can
made informed decisions". It that either necessary or
desirable? I don't know, but I don't think it is an
administrative decision. Is someone who might consider applying
for a fee waiver enabled to ask what information will be
collected if they do and ask without identifying themselves
(and, if they are today, is that guaranteed long-term)? The
privacy policy does not answer that question and the same
comment about administrative decisions versus IETF policies
apply.
Similarly, if there is a policy about having the information
checked by "some individuals" (and I agree with you and Jay
about both the discussion and the appropriateness of doing
that), do we have specific rules, or do we expect the LLC to
develop and publish specific rules, about who those individuals
can be (or the characteristics they are expected to have) and
what personal confidentiality obligations they assume? Do we
expect that their identities be public? If not, are potential
applicants for fee waivers allowed to ask who will be doing the
review and to object to specific reviewers and ask that they be
kept away from the data? If they can ask, do we expect them to
specify a reason and are we willing to have that reason be
treated as extremely sensitive?
You can, I trust, see where this is going. The question is
whether, at the level of principles, the IETF should say "keep
the data confidential except when disclosure is necessary, e.g.,
to prevent or detect bad behavior", whether that should be
supplemented by "and tell the community what you are doing"
and/or "we expect that you will be really careful, optimizing
the policies to encourage both maximum (and maximally diverse)
IETF participation and non-disclosure of any data a potential
participant might consider sensitive (whether the rest of us do
or not)".. or whether we (and any potential participants) will
read the current privacy policy as requiring all of that.
Personally, I think the latter would be a stretch and I am not
nearly as sensitive about disclosure, of, e.g., where I live
than people who are significantly concerned about such
disclosures.
I am reminded that we had a micro-flap a couple of months ago
about whether it would be reasonable for someone to post an I-D,
and whether it would be possible to have that I-D generate IETF
work and evolve into a BCP, without disclosure that person's
name or affiliation, instead providing only a first name that
was probably an alias and an email address that provided no
identifying information. Parts of the above are, I believe,
part of the same question. I, personally, believe that
transparency of the process is important enough that it would be
reasonable for the IETF to say "no, if you want to write
documents or influence standards, we (and the world) need to
know who you are, at least at the name and maybe affiliation
level". But, again, that should be an IETF decision, possibly
one informed by external consultation, not one made by accident
via an administrative procedure.
Finally, the above is, to some extent, a reason for my
discussion of Observers. If we intend to impose what amount to
information disclosure conditions as a condition of
participation, do we want to be able to tell those for whom
those conditions are unacceptable that they can observe in real
time or it is acceptable to tell them "if you don't want to meet
the conditions to be a participant, you can always catch up
later on what happened". While I (obviously) have a fairly
strong opinion about that, what I think is more important is
that be an IETF decision, not a side-effect of some
administrative ones.
best,
john
_______________________________________________
Manycouches mailing list
Manycouches@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manycouches
