4 ms·

> And the few websites that do can explain why you should click "Allow" when they prompt you for access. You missed it, this doesn't require an Allow, because

> And the few websites that do can explain why you should click "Allow" when they prompt you for access. You missed it, this doesn't require an Allow, because it's not actually accessing the microphone. It's using the audio APIs to generate a waveform, and depending on your computer/DSP, the waveform will be slightly different. It's not using any of your computers sensors https://news.ycombinator.com/item?id=21436414 https://news.ycombinator.com/item?id=21436414

kbenson 7y ago
> You missed it, this doesn't require an Allow, because it's not actually accessing the microphone. Presumably, without an allow the API doesn't function at all, so it works perfectly well. When denied access, the API should either not exist, or (more appropriately) just return errors.
- shakna 7y ago
  > Presumably, without an allow the API doesn't function at all An incorrect presumption. The API works perfectly fine without the need for permissions. This is not a new technique. There's a decent write up here [0]. Permissions are only required to play to the actual device, or record from the actual device. Recording from nothing and not playing is allowed. [0] https://iq.opengenus.org/audio-fingerprinting/ https://iq.opengenus.org/audio-fingerprinting/
  - kbenson 7y ago
    We're talking about a theoretical situation where we gate the canvas and audio api behind a permission prompt. My "presumably" is about how that would be theoretically implemented.
    - shakna 7y ago
      Why would gating the API behind the Permissions API change what is currently considered permission by the Browser? That'd require rewriting the API itself.
      - kbenson 7y ago
        Gating the API behind a permissions dialog or permission setting. The difference being that an end site either uses it and gets valid data (because the user allowed it, the default without a dialog today), or gets errors letting them know the data can't be relied upon. If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you. The canvas api might be a little more likely to be allowed by the average person, but enough might disallow or ask about it that sites that have a valid use for it will put up a banner noting why it's important, making sites using it for tracking stand out all the more. The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.
        shakna 7y ago
        > Gating the API behind a permissions dialog or permission setting. Those dialogs and settings are controlled by the Permissions API today. > If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you. You and I might disable it. Overwhelmingly, the majority of the public click "enable" or "yes" on permission pop-ups. And tend to make sure "enable forever" is ticked. > The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions. I don't disagree. The problem here is that the permission model itself has been broken, and won't be repaired because of backwards compatibility, and a lack of incentive.
    - ehsankia 7y ago
      Except prompt spam is a real issue too. Very quickly you can end up like Windows' UAC that basically trains people to blindly click "yes" on any dialog they see. Putting a permission prompt for every tiny little thing a browser can do isn't a good experience for the user, and most people will have no clue what "allow access to canvas/audio api" means.
      - kbenson 7y ago
        Except that with a prompt for a specific API, you can get specific on when it's appropriate. E.g. "This website has asked for permission to use the Audio API. If they aren't actively doing audio processing, this may be an attempt to identify and track you. If you haven't been presented by the site with a good reason why to allow this access, and it's not immediately obvious (such as for a music service), consider whether you want them to have access." This accomplishes a few things. First, it's very clear about the implications and when it's obvious it should be allowed. Second, it gently suggests the default behavior for people should be to deny unless needed. Thirdly, it communicates to sites (through users the appropriate way to ask for permissions if hey have a legitimate reason, which is to let users know why they need access. Lastly, if sites lie to users about why they need access, they can be called out on that. People don't like being lied to.
        ehsankia 7y ago
        Now imagine getting 10 of these, as a user who has no idea what those words mean, nor care, because you just want to see the latest meme on Facebook, and you just blindly press Allow on everything and quickly become desensitized to all prompts.

kbenson 7y ago

> You missed it, this doesn't require an Allow, because it's not actually accessing the microphone. Presumably, without an allow the API doesn't function at all, so it works perfectly well. When denied access, the API should either not exist, or (more appropriately) just return errors.

shakna 7y ago
> Presumably, without an allow the API doesn't function at all An incorrect presumption. The API works perfectly fine without the need for permissions. This is not a new technique. There's a decent write up here [0]. Permissions are only required to play to the actual device, or record from the actual device. Recording from nothing and not playing is allowed. [0] https://iq.opengenus.org/audio-fingerprinting/ https://iq.opengenus.org/audio-fingerprinting/
- kbenson 7y ago
  We're talking about a theoretical situation where we gate the canvas and audio api behind a permission prompt. My "presumably" is about how that would be theoretically implemented.
  - shakna 7y ago
    Why would gating the API behind the Permissions API change what is currently considered permission by the Browser? That'd require rewriting the API itself.
    - kbenson 7y ago
      Gating the API behind a permissions dialog or permission setting. The difference being that an end site either uses it and gets valid data (because the user allowed it, the default without a dialog today), or gets errors letting them know the data can't be relied upon. If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you. The canvas api might be a little more likely to be allowed by the average person, but enough might disallow or ask about it that sites that have a valid use for it will put up a banner noting why it's important, making sites using it for tracking stand out all the more. The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.
      - shakna 7y ago
        > Gating the API behind a permissions dialog or permission setting. Those dialogs and settings are controlled by the Permissions API today. > If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you. You and I might disable it. Overwhelmingly, the majority of the public click "enable" or "yes" on permission pop-ups. And tend to make sure "enable forever" is ticked. > The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions. I don't disagree. The problem here is that the permission model itself has been broken, and won't be repaired because of backwards compatibility, and a lack of incentive.
  - ehsankia 7y ago
    Except prompt spam is a real issue too. Very quickly you can end up like Windows' UAC that basically trains people to blindly click "yes" on any dialog they see. Putting a permission prompt for every tiny little thing a browser can do isn't a good experience for the user, and most people will have no clue what "allow access to canvas/audio api" means.
    - kbenson 7y ago
      Except that with a prompt for a specific API, you can get specific on when it's appropriate. E.g. "This website has asked for permission to use the Audio API. If they aren't actively doing audio processing, this may be an attempt to identify and track you. If you haven't been presented by the site with a good reason why to allow this access, and it's not immediately obvious (such as for a music service), consider whether you want them to have access." This accomplishes a few things. First, it's very clear about the implications and when it's obvious it should be allowed. Second, it gently suggests the default behavior for people should be to deny unless needed. Thirdly, it communicates to sites (through users the appropriate way to ask for permissions if hey have a legitimate reason, which is to let users know why they need access. Lastly, if sites lie to users about why they need access, they can be called out on that. People don't like being lied to.
      - ehsankia 7y ago
        Now imagine getting 10 of these, as a user who has no idea what those words mean, nor care, because you just want to see the latest meme on Facebook, and you just blindly press Allow on everything and quickly become desensitized to all prompts.