Tweak and analyze the value and find out an appropriate way to generate the padding size for opaque response

NEW
Unassigned

Status

()

P3
normal
a year ago
27 days ago

People

(Reporter: tt, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fingerprinting] [fxprivacy] [fp-triaged])

(Reporter)

Description

a year ago
Please see the bug 1290481 comment #111 and bug 1290481 comment #116. 

Patch P5 in bug 1290481 implement a simple method to generate random size of padding for opaque. However, we should find out a more convincing way to generate padding with analysis or tweak the value/distribution by [1].

[1] https://gist.github.com/tomvangoethem/eaf9312401ab6098282eb7631bff8547

Updated

a year ago
Whiteboard: [fingerprinting] [fxprivacy]
Priority: -- → P2
(Reporter)

Comment 1

a year ago
Hi Ben,

I want to decide the appropriate distribution (uniform or normal) to generate the random number, the boundary of the random number(rMax), and the suitable rounding number(D) by running the script[1] provided by Tom Van Goethem. 

And, the value of the response size is relevant to decide rMax and D. However, I have no idea about setting a reasonable response size. I'll try to collect the average response size from my daily use Nightly, but it would be better if we have data from telemetry.

Do we have any telemetry data for average response size? Or could you give me some suggestions for setting response size? Thanks!

[1] https://gist.github.com/tomvangoethem/eaf9312401ab6098282eb7631bff8547
Flags: needinfo?(bkelly)
Honestly I have no idea here.

We do not have any telemetry on resource size in Cache API.  We could add it, but our telemetry is public and maybe that would not be good to expose to people trying to guess sizes.

I guess my feeling is we should ship an initial implementation and then get feedback from security researchers after they have been able to experiment with it.  If someone has a better suggestion, we could do that too.
Flags: needinfo?(bkelly)
(Reporter)

Comment 3

a year ago
(In reply to Ben Kelly [:bkelly] from comment #2)
Thanks for the feedback!

> We do not have any telemetry on resource size in Cache API.  We could add
> it, but our telemetry is public and maybe that would not be good to expose
> to people trying to guess sizes.

Oh, I see.
 
> I guess my feeling is we should ship an initial implementation and then get
> feedback from security researchers after they have been able to experiment
> with it.  If someone has a better suggestion, we could do that too.

I totally agree with you. We should ship an initial implementation at first and have an advanced version after collecting enough feedback. That's what I intend to do for bug 1290481. I was trying to help as much as I can so that someone who takes this bug will have more information. But, maybe I should just wait until we have more feedback.

Updated

11 months ago
Whiteboard: [fingerprinting] [fxprivacy] → [fingerprinting] [fxprivacy] [fp-triaged]

Comment 4

11 months ago
Realistically I'm not going to get to this soon, but I'm tracking it myself for when I have time.
Priority: P2 → P3

Updated

6 months ago
Blocks: 1147820
Whiteboard: [fingerprinting] [fxprivacy] [fp-triaged] → [fingerprinting] [fxprivacy]

Updated

27 days ago
Whiteboard: [fingerprinting] [fxprivacy] → [fingerprinting] [fxprivacy] [fp-triaged]
You need to log in before you can comment on or make changes to this bug.