Impact of browser security/privacy measures & configuration on performance

[oh-ren]

This first occured to me when running Nyrikki's Fin Lander (a 10-line BASIC program) in Firefox Quantum (59 beta) (as opposed to 52 ESR) - the game seemed to run slower (confirmed for sure by the slow rate at which the end of stage tune played). I noticed wmsx Error: Could not detect video native frequency. V-Synch DISABLED! in the console.

Seemed to be the privacy.resistFingerprinting setting at play here (when set to true). And I think in the future privacy.reduceTimerPrecision will be an issue as well.

The latter I believe will be by enabled by default in FF59, with a precision of 20us (which is already in effect since FF 57.0.4, but will however be raised to 2ms in FF60). privacy.resistFingerprinting is false by default.

Workaround (for now) is making sure privacy.resistFingerprinting is set to false. Setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds to 0 wasn't enough so it seems.

I didn't look into Chrome.

Resources:

https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

[ppeccin]

I see.

But tell me, do you get this consistently? I mean, your browser NEVER enables VSynch?

Its normal to fail the detection sometimes, particularly when your are opening the browser for the first time or when there are many things running on the background.

But a precision of around 1ms or 2ms should be enough.

Does Firefox now come with this active by DEFAULT?

Thanks!

On Tue, Mar 6, 2018 at 1:52 PM, ren notifications@github.com wrote:

This first occured to me when running Nyrikki's Fin Lander https://msxpen.com/?gist=faf918438d5695d249a66af22431760c (a 10-line BASIC program) in Firefox Quantum (59 beta) (as opposed to 52 ESR) - the game seemed to run slower (confirmed for sure by the slow rate at which the end of stage tune played). I noticed wmsx Error: Could not detect video native frequency. V-Synch DISABLED! in the console.

Seemed the privacy.resistFingerprinting at play here (when set to true). And I think in the future privacy.reduceTimerPrecision will be an issue as well.

The latter I believe will be by enabled by default in FF59, with a precision of 20us (which will become 2ms however in FF60). privacy.resistFingerprinting is false by default.

Workaround (for now) is making sure privacy.resistFingerprinting is set to false. Setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds to 0 wasn't enough so it seems.

I didn't look into Chrome.

Resources:

https://developer.mozilla.org/en-US/docs/Web/API/Performance/now https://blog.mozilla.org/security/2018/01/03/ mitigations-landing-new-class-timing-attack/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ppeccin/WebMSX/issues/32, or mute the thread https://github.com/notifications/unsubscribe-auth/AArloJMO7mRH3niWdETNthEuzLhmk5BVks5tbr7IgaJpZM4SfDgq .

[oh-ren]

Yuup, every time. So the culprit is privacy.resistFingerprinting, which should be false be default (checked using FF portable). But setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds (defaults: FF58 (current): 20, FF59 (beta): 2000) to 0 didn't matter. So there must be more at play there (that has an effect on WebMSX)..

Not sure if FF60 with the increased privacy.reduceTimerPrecision of 2ms (which is / will be enabled by default) will raise issues.

Anyway, thought I'd give a heads up, and (for now) perhaps something useful to add to an FAQ /troubleshooting section or something.. ;) I could still have a look at FF60 nightly..

Btw: noticed you're working / have been working on quite some stuff, making me curious! ;)

[ppeccin]

I don't know if I understand you. I'm not familiar with privacy.resistFingerprinting, but if its FALSE by default, why are you having this problem? Did you set it to TRUE manually on your machine? In that case, the average user will not have problems, right?

I understand that we are dealing with possible future problems, but I need to understand if the average user is having the same problem as you NOW. Thank you for raising this up. I never imagined they could activate a restriction so strong as this one.

Regarding the next release, yes, very nice things coming very soon!

Paulo

On Tue, Mar 6, 2018 at 3:42 PM, ren notifications@github.com wrote:

Yuup, every time. So the culprit is privacy.resistFingerprinting, which should be false be default (checked using FF portable). But setting privacy.resistFingerprinting.reduceTimerPrecision.microseconds (defaults: FF58: 20, FF59: 2000) to 0 didn't matter. So there must be more at play there (that has an effect on WebMSX)..

Not sure if FF60 with the increased privacy.reduceTimerPrecision of 2ms (which is / will be enabled by default) will raise issues.

Anyway, thought I'd give a heads up, and (for now) perhaps something useful to add to an FAQ /troubleshooting section or something.. ;) I could still have a look at FF60 nightly..

Btw: noticed you're working / have been working on quite some stuff, making me curious! ;)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ppeccin/WebMSX/issues/32#issuecomment-370884712, or mute the thread https://github.com/notifications/unsubscribe-auth/AArloPcOOShb2zsunAmxOS8PaAJCdQoqks5tbtijgaJpZM4SfDgq .

[oh-ren]

Sorry for the delayed reply. So current FF beta is 60.0b1 now.

No, no issues by default (FF59, FF60). Yes, I enabled this (privacy.resistFingerprinting that is) myself (via the Privacy Settings extension). The thing is an user might have enabled this (perhaps using aforementioned extension) but is unaware this impacts the performance of WebMSX.

The deal is that it has a not-so-slight impact. Suddenly I got very good at the game, turns out that may be partly because it was running tens of procents (my rough offhand estimate) slower... :wink:

It might be interesting to investigate what it is exactly this setting entails. It does a multitude of things, and I believe they (the Firefox devs) are ever adjusting it, adding new bits, modifying existing bits etc.

A question that could be asked is: is WebMSX (perhaps) relying on stuff it shouldn't (or can't) rely on?

I don't know to what extent the outcome of the vsync detection impacts further execution. It can't detect vsync in the situation I ran into, but does this justify the emu running too slow?

Anyway, getting good to great performance from the emu is a challenge on it's own I reckon, doing an awesome job here :wink:

Note that privacy.reduceTimerPrecision is enabled by default, but this doesn't seem to cause problems.

-update: the issue title might be a bit misleading, as it turns out the culprit is basically the resistFingerpretting setting. Before all I kinda assumed this stuff had to do with (the) reduced precision of performance.now.

The workaround for now is simply to disable the setting when running WebMSX. Perhaps some extension exists (and otherwise it should not be too hard to create one) that can apply this setting (and/or other settings (in general)) on the fly based on domain or something.

[ppeccin]

Thanks ren, its awesome that you even detected this!

I will have to take a closer look and test with these parameters to understand what may be happening.

When the emulator can't detect the native FPS, it cannot use the browser vsync mechanism, which is very good and precisely "in sync :-)" with the native frame generation. In that case, it falls back to using normal Javascript timers, which have lower precision. But that should not make the emulation run much slower, only less fluidly and maybe a little slower. Probably those settings you changed also affected how those imprecise timers work, making them even less precise to the point of causing a big effect. Too bad if that becomes standard...

On Thu, Mar 8, 2018 at 7:32 AM, ren notifications@github.com wrote:

Sorry for the delayed reply. So current FF beta is 60.0b1 now.

No, no issues by default (FF59, FF60). Yes, I enabled this ( privacy.resistFingerprinting that is) myself (via the Privacy Settings plugin). The thing is an user might have enabled this (perhaps using aforementioned plugin) but is unaware this impacts the performance of WebMSX.

The deal is that it has a not-so-slight impact. Suddenly I got very good at the game, turns out that may be partly because it was running tens of procents (my estimate) slower... 😉

It might be interesting to investigate what it is exactly this setting entails. It does a multitude of things, and I believe they're ever adjusting it, adding new bits, modifying existing bits etc.

A questions we could ask is: is WebMSX (perhaps) relying on stuff it shouldn't (or can't) rely on?

I don't know to what extent the outcome of the vsync detection impacts further execution. It can't detect vsync in the situation I ran into, but does this 'justify' the emu running too slow?

Anyway, getting good to great performance from the emu is a challenge on it's own I reckon, doing an awesome job here anyway 😉

Note that privacy.reduceTimerPrecision is enabled by default, but this doesn't seem to cause problems.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ppeccin/WebMSX/issues/32#issuecomment-371446411, or mute the thread https://github.com/notifications/unsubscribe-auth/AArloGmVMQI3NYecCfmtUGUAvESDYbPvks5tcQdJgaJpZM4SfDgq .

[oh-ren]

I thought helpful to report in any case ;)

I don't think the fingerprint resist setting will be enabled by default any time soon, as I think they do expect some stuff not working 100% when the setting is enabled. (From the looks of it, seems that's what we're experiencing here as well.)

So I wouldn't worry too much about it.. :wink:

There's an article on ghacks.net from this month that looks into it a bit: A history of Fingerprinting protection in Firefox.

To quote from that:

These preferences are set to disabled by default usually as they may break things on the Internet.

[...]

It is not clear whether this will ever be enabled by default or listed as an option in the Firefox preferences though.

[ppeccin]

Not doing anything for now....