Wednesday, November 9, 2022< ^ >
Meetecho has set the subject to: PEARG IETF 113
Room Configuration
Room Occupants

[14:50:55] <zulipbot> (Christian Huitema) Good morning! (or afternoon)
[14:51:11] <zulipbot> (Christian Huitema) Sara, Shivan, your mike is open...
[14:54:50] <zulipbot> (Shivan Sahib) hope nothing controversial was said...
[14:55:24] <zulipbot> (Markus Stenberg) I think it is a tradition, hearing whispered WG chairs' discussions pre-meeting is the perk of not coming to the actual meeting room.
[14:57:30] <zulipbot> (Massimiliano Pala) Good afternoon!
[15:00:02] <zulipbot> (Shivan Sahib) hi all, starting in just a moment
[15:00:19] <zulipbot> (Shivan Sahib) agenda:
[15:00:32] <zulipbot> (Shivan Sahib) notes:
[15:00:45] <zulipbot> (Shivan Sahib) thanks again to Gurshabad for taking notes!
[15:06:39] npd leaves the room
[15:10:39] <sftcd> wrt draft-irtf-pearg-ip-address-privacy-considerations, I wonder should section 2.1 include something like "ancillary interaction" - lots of the ways in which IP addresses could be (ab)used tend to relate to devices regularly calling home or similar in ways that aren't visible to people and hence don't seem to fit the current categories
[15:11:47] <zulipbot> (Shivan Sahib) +1 to developing privacy-preserving tech (including measurement) for small/open source/not for profit organizations
[15:12:29] <zulipbot> (Sofia Celi) +1 as well
[15:13:12] <zulipbot> (Massimiliano Pala) +1
[15:14:19] <zulipbot> (Jonathan Hoyland) De-resolutionising -> blurring?
[15:15:44] <zulipbot> (Shivan Sahib) would've said fuzzing but I think that term is overloaded
[15:16:02] <zulipbot> (Daniel Gillmor) coarsening?
[15:16:50] <zulipbot> (Jonathan Hoyland) Is domain fronting being used here in the technical/TLS sense?
[15:18:01] <zulipbot> (Jonathan Hoyland) Oh, another option quantising
[15:20:24] <zulipbot> (Christian Huitema) Are some people here interested in investigating chaff insertion to defeat fingerprinting?
[15:21:53] <zulipbot> (Shivan Sahib) chaff insertion in the measurements reported to the server?
[15:22:06] <zulipbot> (Shivan Sahib) that would be DP right?
[15:22:57] <zulipbot> (Christian Huitema) I am more thinking of the chaff insertion problem in general, but let's rater listen to Oliver's talsk
[15:26:02] <zulipbot> (Jonathan Hoyland) Given that most "consent" these days is coerced by user exhaustion, we would be better off requiring accepting tracking be strictly more clicks than rejecting all tracking.
[15:26:50] <zulipbot> (Andrew Campling) +1 to Jonathan - apply same to dark patterns too
[15:26:50] <zulipbot> (Nick Doty) I'm also concerned by over-reliance on consent, or abuse of flows that are purported to be consent
[15:27:03] <zulipbot> (Markus Stenberg) Some solutions are same number of clicks, which is probably fair too. More clicks to opt out is obnoxious.
[15:27:44] <zulipbot> (Andrew Campling) Most opt out tends to leave in a vast swath of "legitimate interest" anyway
[15:28:24] <zulipbot> (Shivan Sahib) Or, block cookie notice popups ;)
[15:28:37] <zulipbot> (Markus Stenberg) Weighing the choice towards opt-in on the other hand is pretty depressing (not naming names, but e.g. certain operating systems are quite good at hiding opt out options even if number of clicks is same).
[15:29:04] <sftcd> maybe we should make Jonathon the boss of marketing somewhere see if he can get that implemented? :-)
[15:29:33] <zulipbot> (Antoine Fressancourt) I really like the « one more click to accept than to reject » idea
[15:29:46] <zulipbot> (Sofia Celi) ;) ;) I would love to see Jonathan as head of marketing
[15:31:52] <zulipbot> (Collin Kurre) Great point before about service design diluting the validity of consent. the European Data Protection Board has put out relevant guidelines on this, about recognizing / avoiding "dark patterns" in platform interfaces
[15:32:50] <zulipbot> (Andrew Campling) @Collin I think that the UK ICO may be taking an interest in this too
[15:33:10] <zulipbot> (Jonathan Hoyland) "This product isn't the worst, but you know, probably isn't the best either."
[15:33:37] <zulipbot> (Shivan Sahib) hired
[15:35:54] <zulipbot> (David Oliver) @Daniel just seeing "coarsening". Thanks!
[15:40:42] <zulipbot> (Jonathan Hoyland) @**David Oliver** I was thinking packetising, discretising, or downsampling. Or quantising
[15:41:39] <zulipbot> (David Oliver) @Jonathan all good terms; I've put them in my notebook.
[15:42:03] <zulipbot> (Daniel Gillmor) quantising (or in en_US, quantizing) has a valence for me of "making precise", which is the opposite of the meaning you want to imply
[15:43:20] MattJ joins the room
[15:43:58] <zulipbot> (David Oliver) @collin I visited that EU url on "dark patterns" and (wait for it) IMMEDIATELY got the GDRP pop-up.
[15:44:12] <zulipbot> (Daniel Gillmor) ha ha
[15:44:53] <zulipbot> (David Oliver) Imagine how people who use Tor feel: "Wait, you build Tor but then want to MEASURE us?"
[15:45:52] <zulipbot> (Jonathan Hoyland) Quantising would mean breaking up into quanta i.e. making discrete.
verb approximate (a signal varying continuously in amplitude) by one whose amplitude is restricted to a prescribed set of discrete values
[15:46:40] <zulipbot> (Shivan Sahib) I think privacy-preserving measurement for Tor is actually pretty compelling. I attended a presentation by Snowflake folks where they said they have no insight into when things break, and Snowflake breaking has an impact on folks being able to access the Internet
[15:47:18] <zulipbot> (Daniel Gillmor) Jonathan, i know what quantizing means, and i understand how you meant it, i was just observing that it might not communicate the desired intent well because of other attached meanings and uses.  words are tricky!
[15:47:49] <zulipbot> (David Oliver) @shivan there's much socialization to be done, you know?  That's the user fatigue thing: users don't believe measurement can be "helpful"
[15:49:12] <zulipbot> (Andrew Campling) @David - presumably that's based on previous experience of measurement typically being for the sole benefit of the measuring party
[15:49:25] <zulipbot> (Jonathan Hoyland) @dkg I have to admit I haven't heard that alternative usage before. I guess it's related to quantum leaps being small, rather than large?
[15:49:38] <zulipbot> (David Oliver) Broadly developers in our community have been hesitant to implement measurement due to (vocal) user concerns.
[15:50:17] <zulipbot> (Daniel Gillmor) the ladder diagrams in this presentation (e.g. slide ~~27 and 30) have some amount of ambiguity when the homeserver (middle) sends messages to alice (on the left) and bob (on the right).  it looks like it could be meant as a bidirectional communication between alice and bob, skipping over the homeserver.
[15:50:40] <zulipbot> (Andrew Campling) Assumptions that "measurement" == tracking?
[15:50:53] <zulipbot> (David Oliver) @Andrew yes - the "imbalance of power"
[15:51:20] <zulipbot> (Jonathan Hoyland) And this is why we use context strings
[15:51:33] <zulipbot> (David Oliver) @Andrew exactly - user fatigue with saying "no" but ultimately that being turned into "yes" by TOS slight of hand or other service denial
[15:52:54] <zulipbot> (Jonathan Hoyland) I am a big fan of returning random values in 3rd party cookies, just to try and make the other side choke
[15:53:22] <zulipbot> (Daniel Gillmor) random values like ";drop tables"
[15:53:41] <zulipbot> (David Oliver) @Jonathan how dare you! (I'm sure you know that returning randomness within some bounds is part of the PPM idea)
[15:54:21] <sftcd> yep, and developing stuff in an open setting (like here) would I guess have caught some of these issues so hopefully mimi/mls will help too
[15:54:42] <zulipbot> (Daniel Gillmor) Sofia and Dan, this is really impressive work, thank you for doing it and for presenting it here!
[15:55:07] <sftcd> yeah, it's good stuff (and makes me glad I operate my own homeserver:-)
[15:55:11] <zulipbot> (Shivan Sahib) it sounds like at least the conclusions from here should definitely be consumed somehow at MIMI (draft or pres)
[15:55:39] <zulipbot> (Markus Stenberg) +1 - Brilliant stuff :)
[15:57:11] <zulipbot> (Nick Doty) having your own homeserver be the attacker does seem like a stronger threat model than whether some other homeserver can do something to you
[15:57:24] <zulipbot> (Shivan Sahib) @jonathan we locked the queue but if there's some time once we've drained the queue we can take it
[15:57:37] <zulipbot> (Jonathan Hoyland) W.r.t. Formal Analysis, come to the Formal Methods side meeting tomorrow at 11:30 in this room!
[15:58:21] <zulipbot> (Nick Doty) I kind of guessed that the user had to trust their homeserver to some extent. certainly the first use/encounter of a user is proxied by the user's homeserver, and they could of course completely substitute keys and messages
[15:58:51] <zulipbot> (Jonathan Hoyland) Oops, sorry, in Richmond 6
[16:00:06] <zulipbot> (Antoine Fressancourt) @**Nick Doty** given that the home server might be operated by a large org rather than the user, it’s not strange to include it in the threat model
[16:00:07] <zulipbot> (Dan Jones) Thanks for having us! Sorry for the technical issues :)
[16:00:19] <zulipbot> (Sofia Celi) thank you!
[16:01:08] <zulipbot> (Nick Doty) @antoine, sure, I'm glad we are considering it a threat! just noting that it's going to be hard to eliminate any trust in the host
[16:10:18] <zulipbot> (Shivan Sahib) Do folks know if Cloudflare IPs are blocked in general, or is it just DoH/DoT?
[16:10:32] <zulipbot> (Shivan Sahib) (in Iran)
[16:19:42] <zulipbot> (Antoine Fressancourt) How is user safety protected? Do Ooni refrain from performing some measurements because it would put probe runners at risk?
[16:27:09] <zulipbot> (Shivan Sahib) CF proactively blocks connections from Iran?
[16:33:36] <zulipbot> (Daniel Gillmor) chair mic is hot!
[16:33:49] <zulipbot> (Dan Jones) @Daniel Gilmour: Good point re. those diagrams -- thanks. We'll improve them for the future :)
[16:34:02] <zulipbot> (Daniel Gillmor) very cool work, Dan!
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!