the captioning on the screen here is so tiny.
", "time": "2024-03-20T05:00:44Z"}, {"author": "Watson Ladd", "text": "i am struggling to make the slides bigger in meetecho
", "time": "2024-03-20T05:01:42Z"}, {"author": "Lorenzo Miniero", "text": "@Watson Ladd do you mean display them bigger in the UI?
", "time": "2024-03-20T05:03:24Z"}, {"author": "Nick Doty", "text": "(deleted)
", "time": "2024-03-20T05:04:01Z"}, {"author": "Lorenzo Miniero", "text": "If you hover over them there's a pin button (slides are pinned by default anyway). You can give them more screen estate by collapsing the two columns on the side (e.g. chat and participants list)
", "time": "2024-03-20T05:04:20Z"}, {"author": "Watson Ladd", "text": "oh that's what pin means.
", "time": "2024-03-20T05:04:42Z"}, {"author": "Nick Doty", "text": "content can change at the end of a cache lifetime without violating consistency, right?
", "time": "2024-03-20T05:11:17Z"}, {"author": "Nick Doty", "text": "timey-wimey stuff
", "time": "2024-03-20T05:11:52Z"}, {"author": "Martin Thomson", "text": "ben, don't we insist that the consistency check server enforce a minimum TTL?
", "time": "2024-03-20T05:12:42Z"}, {"author": "Nick Doty", "text": "should the consistency mirror set a policy for how often you should check it?
", "time": "2024-03-20T05:14:55Z"}, {"author": "Nick Doty", "text": "I'm not sure I see the thundering herd problem, not every user will need to refetch the resource at every instance when it's out of date, right?
", "time": "2024-03-20T05:16:35Z"}, {"author": "Martin Thomson", "text": "ohttp would be interesting here, but I think it would depend on what you are asking about
", "time": "2024-03-20T05:16:41Z"}, {"author": "Martin Thomson", "text": "Nick: if we decide to have resources expire at a fixed time for all clients (so that it can be updated), then you definitely have a synchronized DDoS
", "time": "2024-03-20T05:17:16Z"}, {"author": "Scott Hendrickson", "text": "It would change the direction of the draft quite a bit, but is there interest in using k-anonymity directly, instead of implying it based on deployment size and resource lifetime?
", "time": "2024-03-20T05:18:12Z"}, {"author": "Martin Thomson", "text": "Even if only a portion of clients have a need, there is still a spike at the cutover point
", "time": "2024-03-20T05:18:17Z"}, {"author": "Nick Doty", "text": "Martin: but why does the whole herd of clients need the updated resource immediately?
", "time": "2024-03-20T05:18:19Z"}, {"author": "Martin Thomson", "text": "Nick, even if it's just a portion of the set, it's still a synchronization point that should be avoided.
", "time": "2024-03-20T05:18:54Z"}, {"author": "Martin Thomson", "text": "Scott: I have serious k-anon skepticism, what would be k-anonymous and what mechanism would ensure that?
", "time": "2024-03-20T05:19:22Z"}, {"author": "Nick Doty", "text": "traffic would be higher at the cutover point than otherwise, but I'm not envisioning that clients have to even close to constantly update their resources
", "time": "2024-03-20T05:20:13Z"}, {"author": "Martin Thomson", "text": "Big +1 to Ben on getting clarity about what the model is for updates to resources.
", "time": "2024-03-20T05:20:28Z"}, {"author": "Scott Hendrickson", "text": "MT: Agreed, it is why i noted \"change of direction\". Something (central?) would have to keep track of individual users that add up to K
", "time": "2024-03-20T05:20:54Z"}, {"author": "Watson Ladd", "text": "Scott Hendrickson said:
\n\n\nMT: Agreed, it is why i noted \"change of direction\". Something (central?) would have to keep track of individual users that add up to K
\n
But don't we want to do the opposite? Namely not count them until there are K?
", "time": "2024-03-20T05:23:21Z"}, {"author": "Nick Doty", "text": "(losing speaker audio/video -- is that just me?) (yep, just a local network issue here, sorry)
", "time": "2024-03-20T05:26:08Z"}, {"author": "Watson Ladd", "text": "If no nonces, I think this makes my draft a lot more interesting.
", "time": "2024-03-20T05:30:34Z"}, {"author": "Tommy Pauly", "text": "I think it still has nonce. Just not redemption context.
", "time": "2024-03-20T05:32:03Z"}, {"author": "Thibault Meunier", "text": "issue #2 for extension negotiation? https://github.com/chris-wood/draft-wood-privacypass-auth-scheme-extensions/issues/2
", "time": "2024-03-20T05:35:39Z"}, {"author": "Scott Hendrickson", "text": "^that is the one
", "time": "2024-03-20T05:35:53Z"}, {"author": "Benjamin Schwartz", "text": "Maybe we need a document about \"extension profiles\" and how to define them safely...
", "time": "2024-03-20T05:41:04Z"}, {"author": "Nick Doty", "text": "it seems like the expiration draft would need to standardize how negotiation is done about validity of tokens and how they are rounded in order to be more consistent for a larger set of clients, if this is going to provide privacy protections for the public use case
", "time": "2024-03-20T05:42:58Z"}, {"author": "Nick Doty", "text": "origins don't get what they need => origins don't get what they want
", "time": "2024-03-20T05:44:01Z"}, {"author": "Martin Thomson", "text": "Nick: think of this as \"other people are looking to add linkability to their selective disclosure, this is looking to add selective disclosure to our unlinkability\"
", "time": "2024-03-20T05:52:20Z"}, {"author": "Nick Doty", "text": "@mt, yes, right, that's what I'm trying to confirm
", "time": "2024-03-20T05:52:44Z"}, {"author": "Martin Thomson", "text": "Or rather \"add unlinkability\"
", "time": "2024-03-20T05:52:46Z"}, {"author": "Martin Thomson", "text": "OR, we could use one hammer for both...
", "time": "2024-03-20T05:53:22Z"}, {"author": "Martin Thomson", "text": "the solutions converge
", "time": "2024-03-20T05:53:30Z"}, {"author": "Nick Doty", "text": "selective disclosure only works if the user (or at least the user's agent) understands what the potential sensitivity and use of the data is, and then can make a reasonable decision about what to disclose
", "time": "2024-03-20T05:55:35Z"}, {"author": "Steven Valdez", "text": "Does using BBS actually solve the problem of the client still needing to choose what extensions to allow? I guess one approach is that you add everything to the token and the client only allows disclosure of things it knows?
", "time": "2024-03-20T05:55:41Z"}, {"author": "Nick Doty", "text": "if you ask a person whether they want to reveal their age or not, that's something they can make a decision about
", "time": "2024-03-20T05:55:49Z"}, {"author": "Nick Doty", "text": "but for many of the use cases we have in mind for privacypass, I don't see how a user or user agent could decide what is reasonable to selectively disclose
", "time": "2024-03-20T05:56:27Z"}, {"author": "Watson Ladd", "text": "it would fit with Privacy Sandbox like approaches: you get some things, but not a lot
", "time": "2024-03-20T05:57:09Z"}, {"author": "Steven Valdez", "text": "Trusting yourself actually falls into the API threat model sometimes, ie needing to worry about temporary compromises of a client (tokens stolen locally) or an issuer whose keys (that are still valid) are stolen or lost. But I think that's probably out of scope for privacypass itself.
", "time": "2024-03-20T06:09:34Z"}, {"author": "Martin Thomson", "text": "OK, I spoke ill of meatehco before. I was not logged out from my laptop when I logged in on the phone. Nice work.
", "time": "2024-03-20T06:16:06Z"}, {"author": "Steven Valdez", "text": "Gossip protocols for key usage.
", "time": "2024-03-20T06:18:07Z"}, {"author": "Martin Thomson", "text": "Transport privacy is an obvious prerequisite, yes.
", "time": "2024-03-20T06:19:50Z"}, {"author": "Martin Thomson", "text": "Though I have a strong negative reaction to the idea that trust for purpose A naturally translates into trust for purpose B. That's a cognitive shortcut that I loathe.
", "time": "2024-03-20T06:20:53Z"}, {"author": "Martin Thomson", "text": "Watson: got it in one :)
", "time": "2024-03-20T06:22:13Z"}, {"author": "Benjamin Schwartz", "text": "My view is that every token means something different, and that's fine. Ultimately, each token, whatever it means, carries a different amount of utility to a particular origin, and the origin can asses that for itself. The \"system\" doesn't need to know the meaning.
", "time": "2024-03-20T06:24:04Z"}, {"author": "Nick Doty", "text": "can Nick share context on those FIDO-attestation style deployments?
", "time": "2024-03-20T06:24:16Z"}, {"author": "Benjamin Schwartz", "text": "@Steven Valdez If an origin has a preference order list of 1024 issuers, that's 10 bits of entropy leakage in the worst case, and far less in reality. That should be well within the privacy budget and not too consolidating.
", "time": "2024-03-20T06:26:05Z"}, {"author": "Nick Sullivan", "text": "@nick here are the most recent docs I could find: https://developers.cloudflare.com/fundamentals/reference/cryptographic-personhood/
", "time": "2024-03-20T06:26:46Z"}, {"author": "Nick Doty", "text": "here's my running rough list of considerations (these are written for device attestation, but seem pretty generally applicable):
\nhttps://gitlab.com/pitg/device-attestation-user-considerations/-/blob/main/device-attestation-user-considerations.md
I think we have way over-relied on anonymity set concepts here, because almost always there is other information that the origin has about the user, which is often not included in the calculation
", "time": "2024-03-20T06:31:06Z"}]