Open Bug 1383656 Opened 7 years ago Updated 2 years ago

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

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: tt, Unassigned)

References

(Blocks 1 open bug)

Details

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

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
Whiteboard: [fingerprinting] [fxprivacy]
Priority: -- → P2
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)
(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.
Whiteboard: [fingerprinting] [fxprivacy] → [fingerprinting] [fxprivacy] [fp-triaged]
Realistically I'm not going to get to this soon, but I'm tracking it myself for when I have time.
Priority: P2 → P3
Blocks: 1147820
Whiteboard: [fingerprinting] [fxprivacy] [fp-triaged] → [fingerprinting] [fxprivacy]
Whiteboard: [fingerprinting] [fxprivacy] → [fingerprinting] [fxprivacy] [fp-triaged]
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.