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
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.
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.
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.
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).
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.
