1637985 - Unable to login to PornHub when privacy.resistFingerprinting=true

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Brian Carpenter [:geeknik]]

Logging into PornHub with RFP=true quit working sometime in the last month or so.

STR:

1. Create new profile in Nightly.
2. Open about:config and set privacy.resistFingerprinting to true.
3. Restart Nightly.
4. Go to https://www.pornhub.com
5. After entering credentials, clicking the Log In button does nothing.

If you set privacy.resistFingerprinting to false and then login and revert privacy.resistFingerprinting to true, you will be unable to interact with the thumbs up, thumbs down, favorite or flag buttons.

Comment 1

[Thorin [:thorin]]

In uBO add the following filter and try again

pornhub.com##+js(set-constant.js, performance.timing.loadEventEnd, 1)

• without the filter, the login button takes me to a new page and entering a fake username + pw = the login button fails
• with the filter, the login button opens an overlay which looks different: enter fake details, hit login: works (i.e it sends and tells you it's invalid)

Comment 2

[Brian Carpenter [:geeknik]]

Excellent, that did the trick. I'll leave this bug open if Mozilla wants to take action, otherwise, this can be closed.

Comment 3

[Tom Ritter [:tjr]]

Does the login work if you have RFP disabled but dom_enable_performance_navigation_timing also disabled?

If so, the bug is arguably in PornHub for not doing feature testing. However; regardless, I think the action item here for RFP is to enable Navigation Timing API (but keep the 100ms timing clamping of course.) This is an API that Tor Browser disables, but with the timer mitigations I don't think it needs to. Matt, what do you think?

Comment 4

[Brian Carpenter [:geeknik]]

Setting dom.enable_performance_navigation_timing and privacy.resistFingerprinting both to false allows for a login, however, logging in while privacy.resistFingerprinting is false has always worked. Setting privacy.resistFingerprinting to true and dom.enable_performance_navigation_timing to false doesn't allow me to login without the UBO filter.

Comment 5

[Matthew Finkel [:sysrqb]]

(In reply to Tom Ritter [:tjr] (OOTO until 6/1?) from comment #3)

Does the login work if you have RFP disabled but dom_enable_performance_navigation_timing also disabled?

If so, the bug is arguably in PornHub for not doing feature testing. However; regardless, I think the action item here for RFP is to enable Navigation Timing API (but keep the 100ms timing clamping of course.) This is an API that Tor Browser disables, but with the timer mitigations I don't think it needs to. Matt, what do you think?

Thanks Tom. I'm not opposed to the idea, but I'm going to pass this on to Georg (and adding Arthur, too). The Navigation Timing API was zeroed in Bug 1369303.

Clamping at 100ms (with jitter) should significant reduce locality precision. I don't know the research around this well enough to make a decision about this yet. For Tor Browser, currently stream latency is (usually) >200ms, so the clamping won't have much influence on the results. For Firefox+RFP this is probably okay. Similar measurements can already be made with scripting, anyway, so RFP timer clamping is probably the limiting factor anyway. I wonder if |domanlookup| could be a distinguisher if the computer is using an unusually slow DNS resolver (ignoring DoH, for now).

Comment 6

[Matthew Finkel [:sysrqb]]

(In reply to Matthew Finkel [:sysrqb] from comment #5)

(In reply to Tom Ritter [:tjr] (OOTO until 6/1?) from comment #3)

Does the login work if you have RFP disabled but dom_enable_performance_navigation_timing also disabled?

If so, the bug is arguably in PornHub for not doing feature testing. However; regardless, I think the action item here for RFP is to enable Navigation Timing API (but keep the 100ms timing clamping of course.) This is an API that Tor Browser disables, but with the timer mitigations I don't think it needs to. Matt, what do you think?

Thanks Tom. I'm not opposed to the idea, but I'm going to pass this on to Georg (and adding Arthur, too). The Navigation Timing API was zeroed in Bug 1369303.

Clamping at 100ms (with jitter) should significant reduce locality precision. I don't know the research around this well enough to make a decision about this yet. For Tor Browser, currently stream latency is (usually) >200ms, so the clamping won't have much influence on the results. For Firefox+RFP this is probably okay. Similar measurements can already be made with scripting, anyway, so RFP timer clamping is probably the limiting factor anyway. I wonder if |domanlookup| could be a distinguisher if the computer is using an unusually slow DNS resolver (ignoring DoH, for now).

(re-adding NI...ticket update conflict)

Comment 7

[Tom Ritter [:tjr]]

(In reply to Matthew Finkel [:sysrqb] from comment #5)

I wonder if |domanlookup| could be a distinguisher if the computer is using an unusually slow DNS resolver (ignoring DoH, for now).

With SOCKS doing the resolution in the exit, I don't know what the API will expose for domainlookup but I can't imagine it will be sensical....

Comment 8

[Georg Koppen]

(In reply to Matthew Finkel [:sysrqb] from comment #5)

(In reply to Tom Ritter [:tjr] (OOTO until 6/1?) from comment #3)

Does the login work if you have RFP disabled but dom_enable_performance_navigation_timing also disabled?

If so, the bug is arguably in PornHub for not doing feature testing. However; regardless, I think the action item here for RFP is to enable Navigation Timing API (but keep the 100ms timing clamping of course.) This is an API that Tor Browser disables, but with the timer mitigations I don't think it needs to. Matt, what do you think?

Thanks Tom. I'm not opposed to the idea, but I'm going to pass this on to Georg (and adding Arthur, too). The Navigation Timing API was zeroed in Bug 1369303.

I think enabling that one with the jitter is okay.

Comment 9

[Matthew Finkel [:sysrqb]]

(In reply to Tom Ritter [:tjr] (OOTO until 6/1?) from comment #7)

(In reply to Matthew Finkel [:sysrqb] from comment #5)

I wonder if |domanlookup| could be a distinguisher if the computer is using an unusually slow DNS resolver (ignoring DoH, for now).

With SOCKS doing the resolution in the exit, I don't know what the API will expose for domainlookup but I can't imagine it will be sensical....

Sorry I wasn't clear. For this case I meant Firefox+RFP (not specifically Tor Browser). The values of domainLookup{Start,End} are equal when a SOCKS proxy is configured.

Comment 11

[Arthur Edelstein [:arthur]]

In general, jitter can be countered by averaging. Isn't that a concern here? I'm wondering if it's worth looking into exactly why this login is failing and if there's a mitigation that doesn't require revealing timing information.

Comment 12

[Matthew Finkel [:sysrqb]]

(In reply to Arthur Edelstein [:arthur] from comment #11)

In general, jitter can be countered by averaging. Isn't that a concern here? I'm wondering if it's worth looking into exactly why this login is failing and if there's a mitigation that doesn't require revealing timing information.

I see adding jitter as being in the same category as using randomization as a poison-pill. It reduces fingerprintability if you don't take it into account when you calculate the browser's (fingerprint) value.

Regarding why the login fails without this API, sanketh pointed us at https://bugzilla.mozilla.org/show_bug.cgi?id=1581492#c0 which includes a code snippet waiting for loadEventEnd > 0 before executing a callback.

At least for Tor Browser, enabling this API with 100ms-clamped values does not leak any more information than is already available by combining javascript timing with server-side timing.

Comment 13

[Tom Ritter [:tjr]]

The jitter we add isn't really jitter to the timestamp - it's fuzzyfox, as applied to a timestamp and not the whole system. That is, we choose a random number between epoch x and epoch x+1, and if we are above that random number, we ceil to x+1, otherwise we floor to x. We do enable performance.now()...

The slow DNS server aspect does seem less than ideal. If RFP is enabled I would propose hardcoding it to return fetchStart as described in the spec as a valid behavior.

Comment 14

[sanketh]

Tom, to clarify, you are proposing that we implement all of the PerformanceTiming API but with clamping+jitter and PerformanceTiming.domainLookup[Start|End] hardcoded to PerformanceTiming.fetchStart.

Comment 15

[Tom Ritter [:tjr]]

(In reply to sanketh from comment #14)

Tom, to clarify, you are proposing that we implement all of the PerformanceTiming API but with clamping+jitter and PerformanceTiming.domainLookup[Start|End] hardcoded to PerformanceTiming.fetchStart.

Yes. Although for everything except the domainLookup entries, it's really it's just removing the RFP check. The clamping+Jitter will happen automatically.

Comment 16

[sanketh]

Attachment: Bug 1637985 - Reenable the PerformanceTiming API in RFP mode r?tjr

Reenable the PerformanceTiming API in RFP mode (with 100ms clamping+jitter)
except for domainLookupStart and domainLookupEnd (which are now spoofed to
fetchStart.) Updated
browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js
to account for this change.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0fd90d6f9937
Reenable the PerformanceTiming API in RFP mode r=tjr

Comment 19

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/0fd90d6f9937

Comment 20

[Anca Soncutean, Desktop QA]

Reproduced with 78.0a1 (2020-05-14) on Ubuntu 18.04
Verified fixed with Fx 80.0a1 (2020-07-20) and Fx 79.0 on Ubuntu 18.04