These are valid use-cases I agree. However I don't see why <canvas> should be leaky to support those use-cases.
Browsers should ensure all <canvas> operations produce identical results across platforms and hardware, and anything in the spec that prevents this should be removed from the spec.
Now, I recognize some of that functionality is handy for certain apps. In that case do like Android and put it behind an opt-in API, so the user can deny.
Basically I think browsers need a "web app" mode and a "surf mode". Just using visiting my local news outlet shouldn't require all the fingerprinting stuff.
The real snag comes from putting text into a canvas. Nobody can agree on what fonts they have installed, and of course there are all kinds of subtle variations from one version of the “same” font to the next, and then everyone has different ideas about hinting, kerning, stem widths, etc, etc, etc. You can fingerprint basically everyone just from that information alone.
Or the Arkenfox config (https://github.com/arkenfox/user.js), which enables resistFingerprinting among other essentials. In this kind of game, a community config is exactly what you want.
Ciphers and hashes publish test data so you can ensure conformance. Don't see why, in principle, one couldn't do something similar with a stripped down <canvas>.
> I think browsers need a "web app" mode and a "surf mode"
Agree. It will be hard to define a standard for "surf mode", but in addition to privacy benefits there would be security benefits for the browser container as well.
I don't think it would be that hard, start with "no javascript". Add a better compataiblity method. Ideally add ways to get the browser to do common stuff like resize images, although even saving that for "app mode" would be a big improvement on the current situation. Making the standard is easy, it is getting anyone to follow it that is difficult. Sites could already work great without javascript if they wanted to but very few do.
"No javascript" is a non starter in my opinion. That's a very simple on/off switch that is already available but has very little buy in. As you noted, "JS off" mode requires a shift in what HTML/CSS are capable of on their own.
> Making the standard is easy, it is getting anyone to follow it that is difficult
That's my point, those two parts aren't disconnected. The standard isn't useful (or a standard really) until people follow it, and in this case that's most of the internet connected world. Both people building for the a new default subset, and users accepting a default subset with opt in "web app" bells and whistles.
Without removing JS, in my head it's along the lines of starting with a freeze of a current ECMA version, define the API's that are stripped out, force low fidelity timers, remove JIT, limit some cross origin options. Stop adding shiny new feature's every 8 weeks. Keep it there for 3-4 years. Or maybe a similar concept with a WASM container when it gains some browser usefulness. Then there's the html and css subset too. So, defining that stock subset navigator at the right level is what I see as the "hard" part.
There are some improvements that could be made to HTML/CSS but it is already possible to do a bunch of fancy stuff with no javascript. I don't think it is possible to avoid tracking while allowing javascript, unless only the most trivial javascript, and for that there is likely to already be HTML/CSS alternatives. The stuff you are talking about is already available if you dig into the settings, although of course picking and choosing your own collection of settings like I do is itself a unique identifier. But there need to be a bunch more restrictions to actually prevent fingerprinting.
I think the lack of buy in is because the people who would need to buy in are the ones pushing the tracking. Rather than a new standard something like a directory of sites that work well without javascript (and search engine just searching those sites) with enough people using it for it to be an advantage to be listed seems to me to be more likely to be effective.
> Browsers should ensure all <canvas> operations produce identical results across platforms and hardware, and anything in the spec that prevents this should be removed from the spec.
You would basically have to kill all hardware accelerated features and run everything in an interpreter. Also make sure that turbo button is set to slow, to get consistent behavior across all CPUs.
The only real way to prevent finger printing is to lock these features away by default and force websites to beg for every single one of them, not a "accept all" screen, make the process so painful that 90% of users would rather avoid those abusive sites entirely, basically the same dark pattern shit every site pulled with the cookie and GDPR accept popups, just in reverse.
3 sounds incredibly undesirable to me, assuming we’re dealing with a jpeg. Go through 3 or 4 rounds of that and compression starts to get pretty visible.
Most websites will recompress user images. Although you probably don't want to do it client side.
The biggest reason is if course cost saving. Store and transfer smaller images. This could be done client side with a server side check on max size.
Another big reason is metadata stripping. Both to protect the user (can be done client side) and to avoid unintentional data channels being provided.
Another reason is to avoid triggering exploits. If a major browser has a JPEG rendering exploit Facebook doesn't want you to be able to pwn everyone who sees your post. By using a trusted encoded it is very likely that the produced image is more or less following the standards and not likely to trigger any exploits (as exploits usually require invalid files).
I've had to implement this - we have a web app used by engineers in the field where signal is often not great. We got lots of complaints about image uploads as for a typical job there would be potentially 100+ images that needed to be uploaded (multiple assets with 2 before and 2 after photos per asset).
iPhone defaults to uploading a large image which can take ages to upload. We implemented a canvas based solution which sends a base64 string representing a compressed image and reduced the upload file size by about 90%. We don't need high quality original images in the backend.
I may have missed a trick, this has been in place for a few years now but at the time I couldn't find a better solution.
I was under the impression that base64 encoding doesn't reduce file size of an image at all, rather it sometimes increases it. That wasn't the point of using base64 string, right?
Surely there could be valid reasons for doing so?
I imagine for example that:
1. It ensures the selected file is a valid image before uploading it
2. It strips meta data like GPS position from the image before uploading it
3. It could reduce the size of the image, by either scaling it down, or compressing it more, or both, before uploading it