You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When generating reports, we will create a hash signature used to verify the integrity of reports generated regardless of who is running them. Two report signatures will only match if the report was generated using the same input data, same config, and same aggregation source code. We will do this by calculating the SHA256 of the concatenation of the data log's SHA256, the SHA256 of the stringified config, and the SHA-1 or SHA-256 of the HEAD git commit of the source used when generating the report. Collisions will be theoretically possible with this scheme, but impractical given current compute constraints. Creating these hashes will make it easy for us to create versioned reports when something important changes in the data or aggregation methodology, and this will exposed in the report listing interface of the UI.
The text was updated successfully, but these errors were encountered:
A sha-256 hash is now generated using a combination of the input data + the version of the mobility-metrics code that was used to generate the reports. I have added this signature to the bottom of each report, which can be used to compare reports generated by 2+ parties to verify methodology and data integrity.
When generating reports, we will create a hash signature used to verify the integrity of reports generated regardless of who is running them. Two report signatures will only match if the report was generated using the same input data, same config, and same aggregation source code. We will do this by calculating the SHA256 of the concatenation of the data log's SHA256, the SHA256 of the stringified config, and the SHA-1 or SHA-256 of the HEAD git commit of the source used when generating the report. Collisions will be theoretically possible with this scheme, but impractical given current compute constraints. Creating these hashes will make it easy for us to create versioned reports when something important changes in the data or aggregation methodology, and this will exposed in the report listing interface of the UI.
The text was updated successfully, but these errors were encountered: