Re: [patwg-charter] Ben Savage: Need to define Privacy (#6)

I think that statements can be supported either with simple reasoning, or with reference to supporting research/evidence, or, ideally, both. 

I am aware of all of the information you provided to the AC and TAG. None of it features either reasoning or research that supports your claims. Now you hint at "extensive information" that appears to have been provided under the cover of secrecy to just some people. If that "extensive information" actually supports your point of view, why keep it secret?

It seems pretty intuitive that we get a more level playing field if third parties get access to the same data as first parties instead of more. As [documented under public scrutiny](https://berjon.com/competition-privacy/), I have found a lot of research and policy work supporting such a conclusion (and hope to soon have time to summarise more of the field).

The TAG is not "self-appointed" but rather a mix of elected by the Membership and nominated by the Director. With that legitimacy is has appointed a task force to produce a draft that will go through the same kind of broad and stringent public review that supports the questionnaire.

You keep repeating "quasi-law, quasi-law, quasi-law" — the word you're looking for is "standard." What you're describing is a standard. Calling it a standard when it aligns with your personal preferences and a "quasi-law" when it doesn't isn't an argument, it's just a rhetorical trick.

For those who are curious to understand how standards work in this respect, a short primer. A key expectation of a standard is that you should be able to give it to two separate groups of people who don't communicate and they will produce compatible outcomes. This applies to bits on the wire standards of course, but also on broader architectural standards (since they are intended to help produce compatible output from working groups). This means that they have to be as clear and as clear-cut as you can make them. These aren't advice columns that each and everyone of us can take to heart in our own personal way. Wiggle room in standards is always a failure (even if sometimes unavoidable because the world is complicated). 

This is captured through the classic RFC2119 keywords `MAY`, `MUST`, and `MUST NOT` (`SHOULD` and `SHOULD NOT` indicate wiggle room, and are often frowned upon — though slightly less so in architectural standards). The standards community has aligned on these because they work, and also because they can be formalised using (one of the forms of) deontic logic. I won't bore you all with the details, but one thing worth noting is that assuming you can use negation then `may`/`must`/`must not` are mutually definable (eg. `MUST(a) = ¬MAY(¬a)`) so that you can't have for instance a system with just `MAY` and no form of `MUST`. Formally, applying these "deontics" to statements about technical systems is to specify its behaviour, and when such a specification is accepted in a given institutional context that's a standard.

Those of you who are more into humanities might have noticed that the deontics used in standards are the same as those used in [institutional analysis](https://press.princeton.edu/books/paperback/9780691122380/understanding-institutional-diversity). That's not a coincidence: standards are a form of institutional governance and they very often operate like a commons. That is certainly the case with the Web.

So yes, _all_ standards create rules. Calling them "quasi-laws" is just inventing a boogeyman by describing what they do. Picking _which_ rules matters. That's why we do it in public, with values, with arguments, with evidence, with research, with broad feedback and not with harassment, not with secret "extensive information," not with anonymous supporters, not with made-up boogeyman words.

-- 
GitHub Notification of comment by darobin
Please view or discuss this issue at https://github.com/patcg/patwg-charter/issues/6#issuecomment-1088060594 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 April 2022 22:08:37 UTC