Server should implement rate limiting for appended keys

[HendX]

After an approved positive diagnosis, user device should continue to submit keys on following days. This is allowed by an authenticated device with a previous submission ID.

Since the subsequent keys are associated with an existing submission, to avoid having to re-approve the diagnosis each time, the server can simply accept up to 1 key per day for that submission (for X number of days beyond the initial submission).

[tatey]

Yes, I think the server should have rate limiting in general to prevent abuse. See https://github.com/tatey/trace_privately/issues/4.

the server can simply accept up to 1 key per day for that submission

The downside of this is if the client misses a submission for any reason (ie. flakey network) then they wouldn't be able to submit two days worth of keys.

Would these protections be adequate:

• Protect against the same key being submitted again. Does the server tell the client this happened in the response, or does the server just silently ignore it?
• Limit to a single submission per day
• Limit the total number of additional keys since diagnosis to +14

This would give some flexibility to the client but ultimately stop abuse.

[HendX]

On the other thread (or somewhere) I wrote "an average of 1 key per day", so make-up can occur if necessary.

I think a success code from server is required so the client knows whether or not to try again, but behind the scenes the server can choose its own strategy for rate-limiting.

[tatey]

FYI I've patched it so a submission can have a maximum of 21 keys. This should give the client a fair degree of flexibility to either submit many keys on one day or one key per day. There's also general rate limiting on the sever as well as the ability to revoke authentication tokens to prevent abuse.

See https://github.com/tatey/trace_privately/commit/86019820cbbc765cdef2bbf64783c2965990c80f.