It's important to know that the mentioned "resistFingerprinting" breaks a lot of the web.
Examples include the back button, uploading photos on some websites uploads random data instead of the photo, etc.
Examples include the back button, uploading photos on some websites uploads random data instead of the photo, etc.
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.
> 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.
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.
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.
Parent explained that the base64 encoding held compressed data.
Or it might not be strictly necessary, but Instagram does it anyway.
No, this is how most pre-upload image editors work. Why upload a 5MB avatar photo that's you're going to have the user crop and scale on the client-side to a few hundred KB first?
Using canvas for this is much more friendly to their bandwidth, no nefarious intent needed.
(I'm guessing it was too much implementation work to separate out this feature: to preserve normal, expected UI behavior client-side, while presenting a fake pagezoom value to scripts. That would degrade only a handful of (poorly-designed, script-layout) websites, rather than the whole accessible browser experience).
I really like the idea behind this feature, but it seems the Web API might have become too complex to counteract bad actors like this. It's particularly scary that it can correlate your activity in private mode with your identity in normal mode.
Maybe this is the case with some very complicated SPA type sites, but personally, I've never seen this.