It might make sense to have PrioEncoder.encode() also take as input the two server public keys (e.g., as hex-encoded strings). Although it might be a bit far off, I can imagine a future in which the browser might actually expose PrioEncoder.encode() to the DOM so that add-ons or webpages can use Prio to implement their own private statistics systems. For this to work, the add-on/webpage would have to be able to specify which public keys it wanted the client to use. Since the byte format of the Prio-encoded ciphertexts will probably change in the future, no one but telemetry should be using PrioEncoder for now, but it might make sense to have the flexibility to open up this API later on.
Do you have any plan on working on this? I've marked this as P4 as this seems fairly long in the future
Priority: -- → P4
(In reply to Alessio Placitelli [:Dexter] from comment #1) > Do you have any plan on working on this? I've marked this as P4 as this > seems fairly long in the future It's a pretty easy change, but we have not urgent need for it yet (as Henry points out). Currently we set the public keys via prefs, but we could have Telemetry read the prefs and pass the keys in and remove that code from the C++ DOM implementation which would be nice. I think P4 is appropriate.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.