I’m working on a website using OpenFL/Starling, however it encounters a blocking issue on some browsers (Brave) and possibly privacy plugins. I’m testing this on desktop.
The website is attempting device recognition, however when it’s prevented by the browser, it doesn’t gracefully fail or make do without it, it fails to load the website at all, presenting only a black screen.
Of course, one can turn off the privacy guard for the website, but I don’t like the idea of hoping visitors do that, or that they’ll realise they need to before giving up. Is it feasible that the site could handle this better? What is it under the hood of OpenFL/Haxe that requires this feature before the site will load and can that check be better handled?
The default is “Cross-site device recognition blocked” which, according to Brave, only permits first-party attempts at fingerprinting. “Device recognition attempts blocked” will stop all attempts at fingerprinting (which could cause problems with some sites), while “All device recognition attempts allowed” basically allows everything through.
Perhaps we access an API that’s considered a way to fingerprint, such as the Gamepad API?
EDIT: Found this:
Currently Brave protects against fingerprinting by preventing third party sites from accessing functionality frequently used to fingerprint users. This includes highly identifying parts of the Canvas, Web Audio and WebGL APIs, among others.
Not sure if there’s an easy way to test against the browser until we identify what’s triggering it? Try -Ddom mode or canvas first? It could also be caused by howler.js?
It would not appear to be caused by howler.js. When testing -Ddom mode which still makes use of howler.js, Device Recognition isn’t triggered. Unfortunately however, all I get in -Ddom mode is a black screen.
openfl test html5 -Ddom
When testing in -Dcanvas mode, Device Recognition is triggered still. Perhaps more serious though (but expected), I’m presented with the error, “Stage3D error: Context3D not available”. I expect this is because I’m using Starling so that’s likely unrelated, given the Device Recognition issue is being fired in non-Starling projects too, such as the OpenFL samples.
Removing the source for howler.js, it’s spacial plugin, pako.js and FlieSaver.js, made no difference.
I tried commenting out a few parts of the generated source that looked possibly related to device recognition, but it either had no effect or broke my code Granted, I probably need to better understand the generated source, so my efforts were rather haphazard.
It could be as simple as checking the user agent or it could be more complex like if we use toDataURL or other “get pixel” operations which might be impossible to avoid
We use toDataURL currently in the PrintJob class but I’m not sure if that would be included in an order dead-code-elimination build
Good to hear that -Ddom does not trigger it though so that’s a start to understanding what they are looking at
No joy there. I tested this with my project and the OpenFL sample “DisplayingABitmap” and both triggered device detection.
In project.xml: <haxeflag name="-dce full" />
Then ran: openfl test html5 -final
For the time being, I’m going to put the issue aside as I know Brave is not a particularly common browser and hopefully those using it are savvy enough to know they get the odd website issue. Something to keep in mind perhaps though, with possible implications with the GPRD and a general push towards privacy occurring, Brave may not be the only one with issues in the days to come
Granted, I probably need to better understand the generated source, so my efforts were rather haphazard.
