PrioEncoder.encode() should take server public keys as input

ASSIGNED
Assigned to

Status

()

enhancement
P4
normal
ASSIGNED
8 months ago
4 months ago

People

(Reporter: henrycg, Assigned: rhelmer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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
Flags: needinfo?(rhelmer)
Priority: -- → P4
Assignee

Comment 2

8 months ago
(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.
Flags: needinfo?(rhelmer)
Assignee

Updated

8 months ago
Assignee: nobody → rhelmer
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee

Comment 3

4 months ago

:chutten, are you likely to use the PrioEncoder DOM function or do you think you will use libprio directly from Telemetry?

Flags: needinfo?(chutten)

Comment 4

4 months ago

Funny you should ask that, I was just looking at PrioEncoder :)

I haven't yet firmed up on where the data storage would live: JS or C++. If it's JS, I'll definitely be using the DOM function. If it's in C++ I was thinking about breaking ::Encode up into a few pieces so I could still use PrioEncoder. I wasn't planning on copy-pasta'ing PrioEncoder into toolkit/components/telemetry, unless that would be helpful to you.

Flags: needinfo?(chutten)
You need to log in before you can comment on or make changes to this bug.