chris, check room mic please
", "time": "2022-07-25T17:30:18Z"}, {"author": "Mike Rosulek", "text": "as a remote speaker, will I screen-share my own slides or will they be operated by someone in the room?
", "time": "2022-07-25T17:31:21Z"}, {"author": "Christopher Patton", "text": "I can take notes.
", "time": "2022-07-25T17:31:42Z"}, {"author": "Sara Dickinson", "text": "We can share you slides so you can control them via Meetecho
", "time": "2022-07-25T17:31:42Z"}, {"author": "Mike Rosulek", "text": "ok great, as long as I don't have to command a person to advance the slide a gazillion times ;) -- I used a lot of overlays
", "time": "2022-07-25T17:32:24Z"}, {"author": "Rob Austein", "text": "I just lost audio. Just me?
", "time": "2022-07-25T17:33:21Z"}, {"author": "Randy Bush", "text": "/me haz audio
", "time": "2022-07-25T17:33:38Z"}, {"author": "Mike Rosulek", "text": "audio is still working for me
", "time": "2022-07-25T17:33:43Z"}, {"author": "Rob Austein", "text": "Ack, tnx
", "time": "2022-07-25T17:33:50Z"}, {"author": "Martin Thomson", "text": "@Sara Dickinson I think that you can hand control of the slides over to Sof\u00eca
", "time": "2022-07-25T17:35:49Z"}, {"author": "Sara Dickinson", "text": "OK - I think sofia should have control now
", "time": "2022-07-25T17:36:49Z"}, {"author": "Christopher Wood", "text": "Yes, it looks that way.
", "time": "2022-07-25T17:37:00Z"}, {"author": "Sara Dickinson", "text": "@Mike - yes we have the power to hand you control of your slides (Thanks @Martin for the prompt!)
", "time": "2022-07-25T17:38:21Z"}, {"author": "Rob Austein", "text": "Since Meetecho gets blamed for everything even when it's not their fault: it was not their fault, totally local issue (bluetooth transceiver glitched)
", "time": "2022-07-25T17:39:52Z"}, {"author": "Jabber", "text": "npd: what do we mean by \"costly\" in describing RAPPOR? just that it's less efficient per report, because their is client-side randomization/noise?
", "time": "2022-07-25T17:42:45Z"}, {"author": "Mike Rosulek", "text": "@Sof\u00eda: can you list some functions that would be useful to compute using PPM techniques, but for which we currently lack efficient techniques? (asking from a research perspective)
", "time": "2022-07-25T17:48:09Z"}, {"author": "Christopher Wood", "text": "Given the time remaining, we may have to take Q&A offline to the chat.
", "time": "2022-07-25T17:49:21Z"}, {"author": "Martin Thomson", "text": "I don't think that this characterization is correct for STAR
", "time": "2022-07-25T17:49:42Z"}, {"author": "Shivan Sahib", "text": "Definitely taking all Qs to chat :)
", "time": "2022-07-25T17:50:36Z"}, {"author": "Martin Thomson", "text": "Prio is probably on the cheap side, though it might depend on the circuit you are executing. A simple sum over a small range of input values is pretty cheap.
", "time": "2022-07-25T17:51:24Z"}, {"author": "Martin Thomson", "text": "Mike Rosulek said:
\n\n\n@Sof\u00eda: can you list some functions that would be useful to compute using PPM techniques, but for which we currently lack efficient techniques? (asking from a research perspective)
\n
You should look at the attribution problem. Private set intersection or similar protocols are currently quite difficult.
", "time": "2022-07-25T17:52:20Z"}, {"author": "Deirdre Connolly", "text": ":clap:
", "time": "2022-07-25T17:52:52Z"}, {"author": "Christian Huitema", "text": "When it comes to telemetry, there are two usages. Statistics is one. But debugging requires looking at complete sessions. Are there techniques for that too?
", "time": "2022-07-25T17:53:01Z"}, {"author": "Jabber", "text": "npd: thank you for the presentation!
", "time": "2022-07-25T17:53:20Z"}, {"author": "Jabber", "text": "npd: there's lots of options to summarize and it's good to start thinking about comparison. and I really appreciate explicitly considering those questions of whether users understand or how they would choose whether to participate
", "time": "2022-07-25T17:53:20Z"}, {"author": "Sofia Celi", "text": "Jabber said:
\n\n\nnpd: what do we mean by \"costly\" in describing RAPPOR? just that it's less efficient per report, because their is client-side randomization/noise?
\n
yes. The PROCHLO paper goes into more details
", "time": "2022-07-25T17:54:26Z"}, {"author": "Martin Thomson", "text": "@Christian Huitema the problem with debugging is that you often don't know a priori what you will need to know, which tends to lead to systems that gather everything
", "time": "2022-07-25T17:54:27Z"}, {"author": "Mike Rosulek", "text": "Thanks @Martin, if you have a good reference for this attribution problem, I'd love to see it. I like PSI-related problems ;)
", "time": "2022-07-25T17:54:32Z"}, {"author": "Martin Thomson", "text": "@Mike Rosulek something I've been working on is ad attribution - you want to count correlated events in contexts where you don't want to reveal the correlation
", "time": "2022-07-25T17:55:07Z"}, {"author": "Rob Austein", "text": "One could envision two levels of debug, one still sort of privacy preserving, the other just show me everything. The challenge would be making the first useful enough that anybody would bother to use it.
", "time": "2022-07-25T17:55:44Z"}, {"author": "Martin Thomson", "text": "This is old, but there's a sketch of a solution here: https://github.com/patcg/private-measurement/issues/9
", "time": "2022-07-25T17:55:49Z"}, {"author": "Sofia Celi", "text": "Mike Rosulek said:
\n\n\n@Sof\u00eda: can you list some functions that would be useful to compute using PPM techniques, but for which we currently lack efficient techniques? (asking from a research perspective)
\n
Depends on the scheme used. In Prio-based, there is a more efficient system called 'Prio+' that uses boolean circuits. Unfortunately, not all aggreagate functions work in the boolean, so one translates from boolean to arithmetic. It will be nice to expand all functions to boolean
", "time": "2022-07-25T17:55:59Z"}, {"author": "Sofia Celi", "text": "and, of course, in Prio-based (except for POPLAR) is all numeric data types
", "time": "2022-07-25T17:56:29Z"}, {"author": "Jabber", "text": "npd: @sofia \"costly\" in terms of efficiency of every report is pretty different from costly-for-the-client or costly-and-infeasible-to-adopt. some measurements will take more reports to gather with RAPPOR style systems. is that completely unacceptable?
", "time": "2022-07-25T17:56:55Z"}, {"author": "Sofia Celi", "text": "Martin Thomson said:
\n\n\nPrio is probably on the cheap side, though it might depend on the circuit you are executing. A simple sum over a small range of input values is pretty cheap.
\n
Yes, but only over numeric values.
", "time": "2022-07-25T17:57:09Z"}, {"author": "Nils Wisiol", "text": "Sofia, why is the randomness server needed in STAR? What does it do that the client cannot do by itself?
", "time": "2022-07-25T17:57:29Z"}, {"author": "Martin Thomson", "text": "@Sofia Celi one of the things you didn't emphasize enough in comparing poplar and star is that star can do arbitrary strings, whereas the strings in poplar are finite length, which can be difficult for some applications
", "time": "2022-07-25T17:57:48Z"}, {"author": "Sofia Celi", "text": "Martin Thomson said:
\n\n\nSofia Celi one of the things you didn't emphasize enough in comparing poplar and star is that star can do arbitrary strings, whereas the strings in poplar are finite length, which can be difficult for some applications
\n
oh yes! I should add that to the note. Thank you!
", "time": "2022-07-25T17:58:08Z"}, {"author": "Shivan Sahib", "text": "@Nils Wisiol come to the PPM session on Thursday where we'll be discussing STAR :) but in a nutshell, some input data doesn't have sufficient entropy to ensure it's not easy for the Aggregation Server to break
", "time": "2022-07-25T17:58:40Z"}, {"author": "Sofia Celi", "text": "Jabber said:
\n\n\nnpd: @sofia \"costly\" in terms of efficiency of every report is pretty different from costly-for-the-client or costly-and-infeasible-to-adopt. some measurements will take more reports to gather with RAPPOR style systems. is that completely unacceptable?
\n
It is not infeasible to adopt. It was used some time ago, but I think preceded by PROCHLO. Depends on your needs.
", "time": "2022-07-25T17:59:00Z"}, {"author": "Martin Thomson", "text": "Talking to the folks at Google who deployed RAPPOR, I think that they might disagree about it being feasible. The quality of the data it produced was pretty poor.
", "time": "2022-07-25T17:59:39Z"}, {"author": "Shivan Sahib", "text": "@Sofia Celi, maybe \"efficiency\" is more accurate than \"costly\" for RAPPOR?
", "time": "2022-07-25T18:00:07Z"}, {"author": "Shivan Sahib", "text": "@Martin, that's also what I've heard
", "time": "2022-07-25T18:00:15Z"}, {"author": "Martin Thomson", "text": "The problem, as I understand it, was that the layers of randomness that RAPPOR added was all per-record noise (local DP), which loses the advantages of central DP and just makes the output close to pure noise
", "time": "2022-07-25T18:01:03Z"}, {"author": "Sofia Celi", "text": "Shivan Sahib said:
\n\n\n@Sofia Celi, maybe \"efficiency\" is more accurate than \"costly\" for RAPPOR?
\n
yes! I don't remember what I put in the slides. If it is only that I said it, it is prob that I get nervous and forget words haha ;)
", "time": "2022-07-25T18:01:10Z"}, {"author": "Chris Box", "text": "Barath's presentation is really clear. Useful to have this terminology.
", "time": "2022-07-25T18:04:00Z"}, {"author": "Nick Doty", "text": "I had thought the premise of RAPPOR was that there was per-record noise but that they showed that an average could still give increasingly useful data as the population size increased. but if they reported later that actually it didn't work out too well, then I need to read more of the latest writing
", "time": "2022-07-25T18:04:52Z"}, {"author": "Nick Doty", "text": "is it that users don't care whether they reveal they use a service? or just that we haven't provided it, and they've had the risk as mostly inevitable?
", "time": "2022-07-25T18:06:24Z"}, {"author": "Matthew Finkel", "text": "Martin Thomson said:
\n\n\nThe problem, as I understand it, was that the layers of randomness that RAPPOR added was all per-record noise (local DP), which loses the advantages of central DP and just makes the output close to pure noise
\n
But that is ideal, we just don't know how to get data with utility at the end. Local DP should be a goal in some systems.
", "time": "2022-07-25T18:06:26Z"}, {"author": "Sofia Celi", "text": "The overall magnitude of this added random noise (which is Gausian noise) can be very large in RAPPOR: even in the theoretical best case, the standard deviation grows in proportion to the square root of the survey count (\u221an, where n is the number of participants), and the randomness is in practice higher by an order of magnitude. Thus, if a billion users data are analyzed, then, a common signal from even up to a million reports may be missed.
", "time": "2022-07-25T18:06:57Z"}, {"author": "Antoine Fressancourt", "text": "I am puzzled by the fact that sensitivity is considered \u00ab\u00a0in absolute\u00a0\u00bb while I think it is depending on the observer interest and capabilities (imho)
", "time": "2022-07-25T18:07:21Z"}, {"author": "Andrew Campling", "text": "With Oblivious DNS you have to trust that the decoupling is applied as it is not forced by the protocol. You can have colluding proxies.
", "time": "2022-07-25T18:07:38Z"}, {"author": "Shivan Sahib", "text": "Non-collusion is an assumption for all of these systems
", "time": "2022-07-25T18:08:13Z"}, {"author": "Martin Thomson", "text": "@Matthew Finkel Yeah, I agree that local DP can be useful, but the trade-off is often very poor. There is a continuum between \"no noise\" and \"no utility\", which is connected by a line where you have both \"too much noise\" and \"too little utility\". I generally don't think that local DP is useful unless you have an absurdly large set of inputs.
", "time": "2022-07-25T18:08:22Z"}, {"author": "Andrew Campling", "text": "Discovery and selection of proxies by the user / client software could help avoid collusion
", "time": "2022-07-25T18:08:40Z"}, {"author": "Sofia Celi", "text": "Nick Doty said:
\n\n\nis it that users don't care whether they reveal they use a service? or just that we haven't provided it, and they've had the risk as mostly inevitable?
\n
Not so sure I follow. But, from what I understand (sorry if I misunderstand): privacy is a main concern of these schemes, but it should be also user consent, meaning, some users even if they know it is private might not want to participate in x survey.
", "time": "2022-07-25T18:09:32Z"}, {"author": "Nick Doty", "text": "we shouldn't assume that our failure to provide privacy is evidence that users don't care about their privacy of that information
", "time": "2022-07-25T18:09:58Z"}, {"author": "Martin Thomson", "text": "this SSH design sounds awful
", "time": "2022-07-25T18:10:41Z"}, {"author": "Sofia Celi", "text": "Nick Doty said:
\n\n\nwe shouldn't assume that our failure to provide privacy is evidence that users don't care about their privacy of that information
\n
yes! one thing also that some papers have higlighted is that good explanations of privacy matter to users. It is not enough to say 'it is private'
", "time": "2022-07-25T18:10:52Z"}, {"author": "Andrew Campling", "text": "There is reseach that shows US consumers would prefer to preserve privacy but are not provided options to do so
", "time": "2022-07-25T18:11:16Z"}, {"author": "Sofia Celi", "text": "one of those studies: https://arxiv.org/abs/2110.06452
", "time": "2022-07-25T18:11:25Z"}, {"author": "Alissa Cooper", "text": "Nick Doty said:
\n\n\nis it that users don't care whether they reveal they use a service? or just that we haven't provided it, and they've had the risk as mostly inevitable?
\n
I also found this a little overbroad -- it seems that the motivation for quite a number of uses of mixnets, Tor, etc. is that for those use cases/users they don't want to reveal that they are using a service. It might not be true for the broad population, but for vulnerable populations it is.
", "time": "2022-07-25T18:11:59Z"}, {"author": "Matthew Finkel", "text": "@Martin Thomson Yeah, that's unfortunate. Users are more likely to believe the privacy benefits of DP if the protections are achieved before the data leaves their device. That's not to say people understand DP, but if we are going to say people should enable telemetry because we use DP, then central DP is a bit sketchy.
", "time": "2022-07-25T18:12:53Z"}, {"author": "Erik Nygren", "text": "@mt: I still have scars from trying to work through the SSH Protocol 1 to Protocol 2 migration long ago.
", "time": "2022-07-25T18:13:37Z"}, {"author": "Alissa Cooper", "text": "More broadly regarding the decoupling principle, how can it be used in an actionable way in protocol design? It kind of seems like the caveats swallow the value (e.g., if you a declare a protocol \"conforms\" to the decoupling principle when in reality in deployment there are side channels that allow user re-identification).
", "time": "2022-07-25T18:14:05Z"}, {"author": "Matthew Finkel", "text": "Hrm. Deniable SSH auth?
", "time": "2022-07-25T18:14:46Z"}, {"author": "Christopher Wood", "text": "@Matthew Relevant: https://privacytools.seas.harvard.edu/publications/algorithmic-institutional-logics-politics-differential-privacy
", "time": "2022-07-25T18:15:27Z"}, {"author": "Barath Raghavan", "text": "I think of decoupling as a design test, but not the end-all. And side channels tend to be discovered over time, so at the time of design I think we want to plug as many side channels as possible with the expectation that new ones will be found (and then mitigated). However within the context of that mitigation, I think we'd like the architecture itself to have privacy baked in, and that's where decoupling may be beneficial.
", "time": "2022-07-25T18:16:56Z"}, {"author": "Shivan Sahib", "text": "I guess it's also interesting for the trust model when the decoupling proxy is used for some other function in the protocol. For e.g. in STAR, you could potentially host the Randomness Server on the OHAI proxy. But this means that if the entity controlling the server colludes with the randomness server, it also automatically colludes with the decoupling proxy
", "time": "2022-07-25T18:18:21Z"}, {"author": "Christopher Patton", "text": "@mike: concrete performance is client or server side?
", "time": "2022-07-25T18:22:09Z"}, {"author": "Christopher Patton", "text": "Thanks!
", "time": "2022-07-25T18:22:50Z"}, {"author": "Erik Nygren", "text": "How does this work when different client keys have different configuration and constraints server-side?
", "time": "2022-07-25T18:22:59Z"}, {"author": "Martin Thomson", "text": "@Mike Rosulek why would you reveal the repository name? some of those are private/secret
", "time": "2022-07-25T18:25:35Z"}, {"author": "Mike Rosulek", "text": "@Martin the SSH username (repository name in my example) is sent after the client authenticates the identity of the server. I think there is no way to avoid having github learn what repository you are accessing, but the repository name is not sent in the clear for eavesdroppers to see.
", "time": "2022-07-25T18:27:25Z"}, {"author": "Nick Doty", "text": "to follow our decoupling model, doesn't the server always learn the sensitive data in the contents of the communication, like which data you are accessing that is served by that server?
", "time": "2022-07-25T18:27:44Z"}, {"author": "Barath Raghavan", "text": "@Nick yes in most cases the server/recipient does learn sensitive information because you want something from them. So, the notion here is that at that moment you may not need to reveal your identity (unless your identity is bound to the request itself, and even then decoupling is sometimes possible)
", "time": "2022-07-25T18:29:17Z"}, {"author": "Mike Rosulek", "text": "@Erik: I think I now understand your question: our protocol only makes sense if the server can specify a set of keys, all of which are authorized for some requested action.. If some keys are differently authorized then it wouldn't make sense to hide the identity of the key
", "time": "2022-07-25T18:29:23Z"}, {"author": "Mike Rosulek", "text": "@Nick: we don't have a great killer application for deniability about which key was used -- you could use github to set up an anonymous bulletin board where no one knows which of the authorized users has made any given commit
", "time": "2022-07-25T18:30:56Z"}, {"author": "Sofia Celi", "text": "@Mallory Knodel user consent prob in PPM schemes
", "time": "2022-07-25T18:30:57Z"}, {"author": "Nick Doty", "text": "@barath, I was just trying to see whether that decoupling model could help us answer questions about the privacy provided (or not) in ssh connections for git forges
", "time": "2022-07-25T18:30:58Z"}, {"author": "Christopher Patton", "text": "+1 Sofia
", "time": "2022-07-25T18:31:11Z"}, {"author": "Nick Doty", "text": "/me waves
", "time": "2022-07-25T18:31:34Z"}, {"author": "Sofia Celi", "text": "maybe a 'user considerations' draft for PPM
", "time": "2022-07-25T18:31:43Z"}, {"author": "Martin Thomson", "text": "Mike Rosulek said:
\n\n\n@Martin the SSH username (repository name in my example) is sent after the client authenticates the identity of the server. I think there is no way to avoid having github learn what repository you are accessing, but the repository name is not sent in the clear for eavesdroppers to see.
\n
In the case that a client probes a repo that it maybe doesn't know exists, doesn't the client learn the number of keys that the server accepts? Which might reveal if the repo exists...
", "time": "2022-07-25T18:31:50Z"}, {"author": "Barath Raghavan", "text": "@Nick ah, good question -- I haven't through through that
", "time": "2022-07-25T18:31:56Z"}, {"author": "Mike Rosulek", "text": "@Martin: yes that is an excellent point
", "time": "2022-07-25T18:32:18Z"}, {"author": "Jonathan Hoyland", "text": "@Meetecho mics still hot.
", "time": "2022-07-25T18:33:22Z"}, {"author": "Lorenzo Miniero", "text": "@Jonathan Hoyland what does that mean? My Italianglish parser can't compute :)
", "time": "2022-07-25T18:33:59Z"}, {"author": "Mike Rosulek", "text": "@Martin: to be more precise, the # of keys is not even leaked if all the keys are ECDSA/EdDSA.. so in that case the server can easily give a dummy response even for a non-existent repository.. then the PSI will fail
", "time": "2022-07-25T18:34:06Z"}, {"author": "Jonathan Hoyland", "text": "The microphone is still live, even though the session has ended, and people would not expect to be caught by it.
", "time": "2022-07-25T18:34:27Z"}]