4 ms·

The spec pdf looks a lot like the DP-3T protocol. The DP-3T docs have more explanation and a good discussion of privacy aspects. https://github.com/DP-3T/docu

by soamv 7y ago

The spec pdf looks a lot like the DP-3T protocol. The DP-3T docs have more explanation and a good discussion of privacy aspects. https://github.com/DP-3T/documents https://github.com/DP-3T/documents paper: https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf https://github.com/DP-3T/documents/blob/master/DP3T%20White%... data protection aspects: https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Data%20Protection%20and%20Security.pdf https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Da... Here's an overview comparing that approach to some others (such as Singapore's tracetogether): https://github.com/vteague/contactTracing https://github.com/vteague/contactTracing

colmmacc 6y ago
They're not the same and I think Google/Apple's is a bit better. In DP3T the infected person shares a single daily key from which all future daily keys can be derived. In Google/Apple's each daily key is HKDF derived from a master key and they are not linkable. Infected people share the relevant daily keys from their infection period. THat's more data to push around, but it is better for privacy. It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by.
- Confiks 6y ago
  > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Edit: This actually turns out to be correct, but your conclusion: > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Is not possible, because every time secrets are made public, the secret key is reset. [1] https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf https://github.com/DP-3T/documents/blob/master/DP3T%20White%...
  - FabHK 6y ago
    GP is correct, but it doesn’t matter much. They were referring to daily key, not the EphID (RPI in the Apple/google spec). DP3T specifies that SK _t = H( SK _{t-1} ). In that design, you share the daily key from when you started to become infectious, and then the subsequent ones can be computed. Then you go into quarantine, stop being infectious, and (see spec) create a new random daily key going forward (or delete the app). In the A/G proposal, daily keys can’t be correlated, and you share the daily key for each day you were infectious. The end result seems pretty much the same for me.
    - sratner 6y ago
      The difference is that you can continue tracking a person indefinitely, even after they are no longer infectious. It requires explicit user action to avoid that (opt-out vs opt-in).
      - FabHK 6y ago
        If the DP3T app is implemented to spec and creates a new random daily key after the infectious period ends, no. If the A/G app is not implemented to spec and keeps uploading daily keys even after the infectious period is over, yes. So, dunno. A/G has a bit more privacy (maybe) for 5x more data volume than DP3T.
  - sratner 6y ago
    I see: SK_(t) = H(SK_(t-1)), where SK_(t) is the secret key for day t. This seems to align with the statement that knowing the key for one day (i.e. once it is uploaded following diagnosis) allows one to derive all future keys. Is there another section I am missing? Edit: clarified that daily keys are shared post-diagnosis, to trace prior contact.
    - Confiks 6y ago
      Indeed, sorry. I was under the impression that every daily ratchet-key was independent, and only the inter-day keys were linked. The conclusion of your post still is not possible however. I edited my post.
- mikarv 6y ago
  Check the second half of the DP3T white paper - the 'high cost' version does not do that, and unlike the Apple/Google version, allows you to redact more specific times of day you do not want to upload, for whatever reason. It is important to also weigh up these issues against daily bandwidth concerns for usability.

by soamv 7y ago

colmmacc 6y ago

They're not the same and I think Google/Apple's is a bit better. In DP3T the infected person shares a single daily key from which all future daily keys can be derived. In Google/Apple's each daily key is HKDF derived from a master key and they are not linkable. Infected people share the relevant daily keys from their infection period. THat's more data to push around, but it is better for privacy. It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by.

Confiks 6y ago
> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Edit: This actually turns out to be correct, but your conclusion: > It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by. Is not possible, because every time secrets are made public, the secret key is reset. [1] https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf https://github.com/DP-3T/documents/blob/master/DP3T%20White%...
- FabHK 6y ago
  GP is correct, but it doesn’t matter much. They were referring to daily key, not the EphID (RPI in the Apple/google spec). DP3T specifies that SK _t = H( SK _{t-1} ). In that design, you share the daily key from when you started to become infectious, and then the subsequent ones can be computed. Then you go into quarantine, stop being infectious, and (see spec) create a new random daily key going forward (or delete the app). In the A/G proposal, daily keys can’t be correlated, and you share the daily key for each day you were infectious. The end result seems pretty much the same for me.
  - sratner 6y ago
    The difference is that you can continue tracking a person indefinitely, even after they are no longer infectious. It requires explicit user action to avoid that (opt-out vs opt-in).
    - FabHK 6y ago
      If the DP3T app is implemented to spec and creates a new random daily key after the infectious period ends, no. If the A/G app is not implemented to spec and keeps uploading daily keys even after the infectious period is over, yes. So, dunno. A/G has a bit more privacy (maybe) for 5x more data volume than DP3T.
- sratner 6y ago
  I see: SK_(t) = H(SK_(t-1)), where SK_(t) is the secret key for day t. This seems to align with the statement that knowing the key for one day (i.e. once it is uploaded following diagnosis) allows one to derive all future keys. Is there another section I am missing? Edit: clarified that daily keys are shared post-diagnosis, to trace prior contact.
  - Confiks 6y ago
    Indeed, sorry. I was under the impression that every daily ratchet-key was independent, and only the inter-day keys were linked. The conclusion of your post still is not possible however. I edited my post.
mikarv 6y ago
Check the second half of the DP3T white paper - the 'high cost' version does not do that, and unlike the Apple/Google version, allows you to redact more specific times of day you do not want to upload, for whatever reason. It is important to also weigh up these issues against daily bandwidth concerns for usability.