865238 - Hashing scheme for FHR document payload format v.Next

Status: RESOLVED WONTFIX

(Firefox Health Report Graveyard :: Client: Desktop, defect)

Description

[Mark Reid [:mreid]]

+++ This bug was initially created as a clone of Bug #863440 +++

As a follow-up to the discussion of the next version of the FHR document payload, the question was raised whether we want to require a stable hash of the app info.

That is, if the app info changes from A to B and back to A, do we want to require that the hashes in those respective parts of the payload show up as "hashA", "hashB", "hashA", or is it OK if it changes from "hashA" to "hashB" to "hashC"?

Since the hashes will be formed using the entire app/config/addons information, the cardinality of the set of all hashes in the FHR data will likely be too large to make the hashes directly useful for analysis (ie. grouping data by hashes across users).

On the other hand, if we don't have stable hashes, the A -> B -> A scenario above would result in redundant storage of app info.

I would suggest that if all other things were equal, it is preferable to use stable hashes, but I'm not sure if it's important enough to make it a firm requirement.  

Thoughts?

Comment 1

[Georg Fritzsche [:gfritzsche]]

FHR is going away per bug 1209088, closing.