- From: Pete Snyder <psnyder@brave.com>
- Date: Tue, 16 Apr 2019 14:46:37 -0700
- To: Nick Doty <npdoty@ischool.berkeley.edu>
- Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Sounds good, thanks Nick. I’ll sit on it until after Thursday’s call, to see how the group feels. Pete Snyder {pes,psnyder}@brave.com Brave Software Privacy Researcher > On Apr 16, 2019, at 2:45 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote: > > On Apr 10, 2019, at 11:23 AM, Pete Snyder <psnyder@brave.com> wrote: >> >> Hi PING folks, >> >> I initially committed to getting a more formal version of the “Heightened Privacy Mode” spec written up and ready for discussion next Thursday. However, at the AC meeting, it seemed like there was a surprisingly positive reception to the idea of requiring privacy mitigations in standards to be normative; and that the current anti-practice of making the privacy-risking functionality normative, but the mitigations non-normative has been a bad idea. >> >> It further seemed that there was (some? much?) greater openness to the idea of not “allowing” specs to go forward if they had privacy harms, when all normative sections were considered together. > > I’m not sure that “allowing” is the most accurate verb as I don’t think PING or W3C or any other group has very strong control authority, but I do think that we should propose and expect normative privacy mitigations wherever that makes sense, for example, when it contributes to interoperability or is necessary to ensure compatibility with the basic privacy model of the Web. And there can and should be other non-normative mitigations that are suggested or otherwise explored by different implementations, because they should feel free to go further, to experiment with different implementations and to provide features that work for particular subsets of users. > >> If others share the same read of the room, then I think my "Heightened Privacy Mode” spec might be a strategic misstep right now, since the proposal's main goal is to make it easier to write normative mitigations in specs. > > I was in that camp previously: I wouldn’t want a separate mode spec to become an excuse for limiting the general applicability of privacy protections in Web features generally. I’m not entirely convinced that it would be strategically *harmful*, more just that it might make some conversations about normative requirements a little more confusing. I guess I mean, I don’t think it’s bad if you want to write it up further for discussion (it might be useful to figure out how to explain handling users who have exceptional use cases and will want to disable functionality in exchange for greater privacy protections), but I share the basic feeling that there is interest in broad privacy protections across Web features right now and that we should focus on identifying issues and mitigations for specs without limiting just to a certain mode. > > My two cents, > Nick
Received on Tuesday, 16 April 2019 21:47:08 UTC