Deleted Comment
- Keys will now be randomly generated rather than derived from a temporary tracing key, making it more difficult for someone to guess how the keys are derived and use that information to try and track people.
- Bluetooth metadata will be encrypted, making it more difficult for someone to try and use that information to identify a person.
- Exposure time will be recorded in five minute intervals, with the maximum reported exposure time capped at 30 minutes.
- The API will include information about the power level of the Bluetooth signal in the data that is exchanged between phones. This can be used in conjunction with the RSSI ("Received Signal Strength Indication") to more accurately estimate the distance between two phones when contact was made.
- Apple and Google will allow developers to specify signal strength and duration thresholds for exposure events.
- The API will now allow for determining the number of days since the last exposure event to better determine what actions the user should take next.
- The API's encryption algorithm is switching from HMAC to AES. Many devices have built-in hardware for accelerating AES encryption, so this change should help performance and efficiency on phones.
* how much do you care about performance?
* how much do you care about safety?
The simplest and fastest would be to check for the "PDF" signature at the start of the file. Refer to the open PDF spec to ensure you are allowing anything that's acceptable (eg. do you care about FDF files?).
If you need to protect against malicious attempts, rather than user errors, it gets much harder quickly (and theoretically impossible, since you can construct files which will be both valid PDFs and something else).
To give another example, if you are aiming to protect yourself from being used as a media-sharing service, PDF allows embedding media as well, so allowing PDFs will not stop that — they are container formats as much as anything else.
The safest would be to reprocess and re-render only the subset you allow: but that's most expensive in terms of implementation and CPU time, and also somewhat limiting — you can't keep digital signatures, for instance.
It is to protect against user errors. Your suggestion to check for a signature sounds what I'm looking for.
Why do you use your own servers instead of for example CloudKit?
How do you make money?
Is unlimited storage really unlimited? If I upload 2 TB of pictures that’s fine?
Are you iOS only or also available on other platforms?
If iOS only, why do you use an android design pattern (floating + button) and not conform to platform standards?
I guess your privacy policy is not finished yet. It’s lacks details to conform to gdpr and ccpa.