After reading the thread, I added Decentraleyes to Firefox 50.01, lol. Firefox is a leaky bucket, I want to patch as many as possible without ruining the browser. Besides, uMatrix continues to elude my understanding, darn it.
Do you have any statistics about implementation ratio? Last time I read about it, it was said that implementation is really slow.
What's giving you a hard time with uMatrix? I'd be glad to lend what help I can if you'd like; I love the thing. Feel free to shoot me a PM.
Hey, thank you. Admittedly, I must first reread the developer's notes and the uM thread here to get a better (much) understanding of this rather powerful extension. My goal for Firefox is to have maximum of three security/privacy extensions effectively doing the work of 6 or more.
There are contexts where ignoring/overriding/tampering-with something labelled a "security measure" qualifies as BAD for security/privacy. However, there are also contexts where doing so qualifies as GOOD for security/privacy. With many things qualifying as bad for one class of user/application, and good for a different class, and thus calling for user-level control over "security measure" overriding. You mentioned a case where ignoring SRI would be bad. Can you think of actual and/or plausible cases where ignoring SRI would be good?
Please help me understand what to do about this recommendation If "Fake Readout API" is chosen, be sure to adjust the "Maximal Fake Size" setting. Adjust it to what?
Sorry, I was under the impression I could update the original post perpetually (not realizing that the ability to edit a given post is subject to a time limit.) I'll be posting a Wordpress site before month's end with updated info, but as discussed further down in the thread 30000 appears to be a suitable size (the default of 0 will disable an upper limit otherwise).
F**kAdBlock! How Publishers are defeating ad blockers & how ad blockers are fighting back. http://blog.bugreplay.com/post/153861574674/fkadblock-how-publishers-are-defeating-ad#
IIRC, leaving that at 0 will disable the "maximum fake size feature" and allow CanvasBlocker to fake the readout for any size canvas. Which is basically what you'd want from a protection POV, because it frees you from having to guess/know the maximum size of a canvas that will be used for fingerprinting. However, the mechanisms used to fake data involve overhead and may cause problems in some contexts (a function of canvas size, normal canvas operations, faking operations, system resources/performance). I think some other features may also be helpful (blacklist and whitelist for example) but this is why you may want to impose a maximum size (canvas width * canvas height, in pixels). The dev expressed a personal preference for not setting the max size below 30000. However, I don't recall him saying why he picked that number. It may be that he has only seen a canvas up to that size actually used for fingerprinting. It may just be his gut estimate for a "reasonable upper bound" based on his awareness that a smaller canvas will suffice for fingerprinting. It may be that he is [also] factoring in other aspects that are particular to the specific contexts he knows of (such as the point at which the faking overhead became sufficiently annoying at sites he visited using his systems). Apart from questioning whether browsers impose a maximum size, and if so whether that has any relation to screen size (I haven't looked into such things)... and pointing out that a site which uses a large canvas for a legitimate purpose could also use a small portion of it (even an upper region) for fingerprinting... I don't think I can add more. The main thing is that you understand the trade-off nature of this setting. Do you?
Nor do I but ... I hope @TheWindBringeth is right and that and not that value 0 disables 'Fake Readout API' itself. Probably not, if 0 is the default.
Start here: https://github.com/kkapsner/CanvasBlocker/blob/master/lib/modifiedAPI.js#L191 Code: var maxSize = prefs("maxFakeSize") || Number.POSITIVE_INFINITY; I'll probably take another look at it too, perhaps after the New Year.
