I'm not aware of websites providing a detailed comparison. Note, in particular, that DP-3T is not one, but three different proposals, and the Google-Apple system is an API specifying structural requirements for a contact tracing app, rather than a full-fledged application.
However, the DP-3T white paper is fairly detailed and explains in a very readable way how each of the three proposals work. It can be found here :https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf.
As for the main differences between DP-3T and Apple-Google: DP-3T already provides an in-depth comparison between their three proposals in the white paper. Out of the three, the hybrid design is very close in spirit to the Apple Google proposal. To my knowledge, there are essentially two main differences between the Apple-Google proposal and DP-3T's hybrid design:
- Both require to upload and publicly reveal session keys, from which several ephemeral IDs are derived, corresponding to some fixed time-period. However, the hybrid design allows a variable duration for the session key, and recommends 2 to 4 hours, while the Apple-Google recommends a 24 hours window. To explain why this matters: 1) the smaller the window, the larger the amount of material each user must download on a daily basis (numbers are given on the white paper and depend on the number of daily new cases). 2) however, a user is traceable for the time of the window, in the following sense: if two users have been in contact with the same user with the same time period, they both know the same session key from which the ephemeral IDs broadcasted during this period have been generated, hence they both know that they have been in contact with the same infected user. Of course, the smaller the time window, the less of a real concern this is. Hence, the choice of the time window is a tradeoff between efficiency and traceability.
- DP-3T allows to redact your upload. This means that it gives you the opportunity, when you are infected, to not upload some of your session keys. This is useful for example if you've been on a one-to-one job interview for two hours: you might want to not upload the session key corresponding to those two hours, since the interviewer might have turned on his phone during this period alone and therefore learn whether you are infected, breaking anonymity. The Apple-Google app does not allow for this.
Otherwise, the exact choice of cryptographic primitives might differ very slightly for generating the ephemeral ideas (and hashing, for the variants that involve hashing), but honestly it does not matter, all use standard and well-established cryptographic primitives in a correct way.
