Page Comparison

...

These are definitely post-MVP1, and quite possibly much later, so there is no need for detailed review of these at this point, but they are indicated to show some possible future directions as this might impact teh MVP1 design.

Changes to HA-> App JSON format

New top-level fields - Hashing Info

A further new new top-level field is added:

...

Note, given the current hashing design, this will be computationally expensive, as hashes will need to be computed for every 5 minute period covered, each hash taking 1-4 CPU seconds). Careful consideration is needed as to whether this computational cost will be acceptable. We could only reduce the cost by weakening the cost of our slow hash, which would have other consequences.

Changes to App-> HA JSON format

As well as changing the JSON data for Exposure Notifications, we are will also change the JSON data exposed by the App when the user chooses to share their location with the HA. This will allow Safe Places to use hashes computed by the App, rather than having to compute all hashes itself.

Currently the data consists of a series of points like this.

{"longitude": 14.91328448, 
 "latitude": 41.24060321,  
 "time": 1589117739000
}

SIngle Hash

If parameters (cost & salt) are not controllable by HAs, we can just add a single has value like this:

{"longitude": 14.91328448, 
 "latitude": 41.24060321,  
 "time": 1589117739000,
 "hash": "87e916850d4def3c"
}

“hash”: the scrypt-generated 64-bit Hash value of the location + time data point, as described above (See: “Hash Calculation”).

Multiple Hashes

In future, if we implement function to enable HAs to set their own costs & salt (see above) we could to expand the format to allow multiple sets of hash data, and therefore to have a format like this:

For MVP1, each point is expanded to include a hashes (there could be zero, one or more of these).

{"longitude": 14.91328448, 
 "latitude": 41.24060321,  
 "time": 1589117739000,
 "hash_data": [
    {"hash":"87e916850d4def3c",
     "cost":18,
     "salt":"LetsDefeatCovid-19"} 
 ]
}

The new fields would be as follows;

“hash_data”: an array of hashes of the data point, with details as below. In MVP1, there is expected to be exactly one set of points. In future, the App may receive different “cost” and “salt” parameters from different Health Authorities, and therefore may compute multiple hashes for each data point. When it does this, it will include a set of hash data for each hash that it has computed.

“cost” the cost of the Hash - in MVP1 this will always be a fixed value. Exact value TBC but currently expected to be 18 - in future we expect some Health Authorities to set this to other values,

“salt” the salt used to generate the Hash. In MVP1 this will always be: “LetsDefeatCovid-19” - in future we expect some Health Authorities to set this to other values,

There is no good reason to implement this additional change to the format in advance of the function to allow HAs to set their own hashes and salts (which may never be implemented).

When we do implement that function, it will be straightforward to support back compatibility on Safe Places simply by interpreting a single “hash” field as being equivalent to a single row “hash_data” table, with default “cost” & “salt”.