9 ms·

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 u

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.

db48x 4y ago
If it breaks uploading a photo, it’s because the page unnecessarily copies the image into a <canvas> and then tries to upload the data from the <canvas> instead of the original image.
- codetrotter 4y ago
  > the page unnecessarily copies the image into a <canvas> and then tries to upload the data from the <canvas> instead of the original image. 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
  - deleted 4y ago
    [deleted]
  - TylerE 4y ago
    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.
    - kevincox 4y ago
      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).
    - alexriddle 4y ago
      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.
      - ambicapter 4y ago
        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?
        bdhcuidbebe 4y ago
        > a base64 string representing a compressed image Parent explained that the base64 encoding held compressed data.
        TylerE 4y ago
        But why base64 and not just… send the bytes? 6 bits per character vs 8
  - magicalhippo 4y ago
    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.
    - db48x 4y ago
      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.
      - magicalhippo 4y ago
        Sure fonts and text is hard. But none of that is needed for basic surfing of the web.
        DoctorOW 4y ago
        Either there is a complete and total consensus on every aspect of rendering or there are differences in how <canvas> is rendered.
        magicalhippo 4y ago
        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>.
        db48x 4y ago
        In that case you should use Firefox, and turn on “resistFingerprinting”. It’s not perfect, but it’s approaching real privacy.
- chaosite 4y ago
  It's necessary if you have filters in the upload flow, like Instagram does (which is why it breaks.) Or it might not be strictly necessary, but Instagram does it anyway.
- donatj 4y ago
  There are many perfectly valid reasons to do that. It’s a lot more scalable to resize images client side rather than server side and using a canvas is one of the simplest ways to achieve that.
- throwawayapples 4y ago
  > unnecessarily 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.
rolisz 4y ago
For the photo problem you can give explicit permission for the website to use Canvas and then reupload the photo. It's annoying, but oh well.
vesinisa 4y ago
I just tried putting it on with the idea of trying it out for one workday to see if it breaks something. It immediataly broke favicons on my GitLab tabs (turning them into random vertical stripes of pixels), which is both odd and a pretty bad start. 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.
- d-z-m 4y ago
  RFP randomizes Canvas data extraction by default, which might have something to do with it. Gitlab favicon seems normal to me when I navigate there(RFP on).
perihelions 4y ago
It also breaks page zoom. The user's preferred zoom level for a domain isn't preserved between new-tab page loads, but resets itself every time. (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).
- seqizz 4y ago
  Yeah I enabled the option yesterday after learning, today I disabled it back since NOPE without site-specific zoom settings retained the web is too inconsistent for me.
bawolff 4y ago
I've been using it for years. I've barely noticed.
d-z-m 4y ago
This is FUD. As others have said, been using RFP for years and barely noticed.
- chaosite 4y ago
  I'm not saying don't use it, I also have it turned on. I'm saying that it has consequences, and you might not immediately realize it's related to RFP.
  - d-z-m 4y ago
    There certainly are consequences. However, you said it "breaks a lot of the web" including "the back button". Maybe this is the case with some very complicated SPA type sites, but personally, I've never seen this.
    - chaosite 4y ago
      Yes, all the problems are on very complicated SPA type sites. You know, like Google Docs/Drive, YouTube, Facebook, Instagram.
account42 4y ago
It also tells websites that you want a light color scheme (instead of not indicating any preference).

db48x 4y ago

If it breaks uploading a photo, it’s because the page unnecessarily copies the image into a <canvas> and then tries to upload the data from the <canvas> instead of the original image.

codetrotter 4y ago
> the page unnecessarily copies the image into a <canvas> and then tries to upload the data from the <canvas> instead of the original image. 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
- deleted 4y ago
  [deleted]
- TylerE 4y ago
  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.
  - kevincox 4y ago
    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).
  - alexriddle 4y ago
    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.
    - ambicapter 4y ago
      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?
      - bdhcuidbebe 4y ago
        > a base64 string representing a compressed image Parent explained that the base64 encoding held compressed data.
        TylerE 4y ago
        But why base64 and not just… send the bytes? 6 bits per character vs 8
- magicalhippo 4y ago
  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.
  - db48x 4y ago
    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.
    - magicalhippo 4y ago
      Sure fonts and text is hard. But none of that is needed for basic surfing of the web.
      - DoctorOW 4y ago
        Either there is a complete and total consensus on every aspect of rendering or there are differences in how <canvas> is rendered.
        magicalhippo 4y ago
        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>.
      - db48x 4y ago
        In that case you should use Firefox, and turn on “resistFingerprinting”. It’s not perfect, but it’s approaching real privacy.
chaosite 4y ago
It's necessary if you have filters in the upload flow, like Instagram does (which is why it breaks.) Or it might not be strictly necessary, but Instagram does it anyway.
donatj 4y ago
There are many perfectly valid reasons to do that. It’s a lot more scalable to resize images client side rather than server side and using a canvas is one of the simplest ways to achieve that.
throwawayapples 4y ago
> unnecessarily 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.

rolisz 4y ago

For the photo problem you can give explicit permission for the website to use Canvas and then reupload the photo. It's annoying, but oh well.

vesinisa 4y ago

I just tried putting it on with the idea of trying it out for one workday to see if it breaks something. It immediataly broke favicons on my GitLab tabs (turning them into random vertical stripes of pixels), which is both odd and a pretty bad start. 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.

d-z-m 4y ago
RFP randomizes Canvas data extraction by default, which might have something to do with it. Gitlab favicon seems normal to me when I navigate there(RFP on).

perihelions 4y ago

It also breaks page zoom. The user's preferred zoom level for a domain isn't preserved between new-tab page loads, but resets itself every time. (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).

seqizz 4y ago
Yeah I enabled the option yesterday after learning, today I disabled it back since NOPE without site-specific zoom settings retained the web is too inconsistent for me.

bawolff 4y ago

I've been using it for years. I've barely noticed.

d-z-m 4y ago

This is FUD. As others have said, been using RFP for years and barely noticed.

chaosite 4y ago
I'm not saying don't use it, I also have it turned on. I'm saying that it has consequences, and you might not immediately realize it's related to RFP.
- d-z-m 4y ago
  There certainly are consequences. However, you said it "breaks a lot of the web" including "the back button". Maybe this is the case with some very complicated SPA type sites, but personally, I've never seen this.
  - chaosite 4y ago
    Yes, all the problems are on very complicated SPA type sites. You know, like Google Docs/Drive, YouTube, Facebook, Instagram.

account42 4y ago

It also tells websites that you want a light color scheme (instead of not indicating any preference).