4 ms·

I think this is mistaken. The device API supposedly provides this, but the info you get is always generic due to fingerprinting protection. Also, AudioContext i

by sriku 7y ago

I think this is mistaken. The device API supposedly provides this, but the info you get is always generic due to fingerprinting protection. Also, AudioContext is expected to be active only when created within a user action like a button click. Otherwise it doesn't run (implemented in Safari). This is a pain - on the one hand, the browser vendors and w3c are locking down API capabilities to prevent fingerprinting and timing based security hacks, but these are interfering with genuine needs to provide audio functionality. For example, you can't determine whether the user has 3 audio devices connected and prompt them to select one for output. So you really can't build desktop quality audio systems with webaudio and siblings.

danShumway 7y ago
> Also, AudioContext is expected to be active only when created within a user action like a button click. I really hate the user-action restriction as a security measure, because it's ridiculously easy to bypass[0], particularly on Chrome. It's privacy theater -- annoying for legitimate developers, but easy for malicious actors to get around. Putting this stuff behind a permission or sandboxing it somehow would be better for both end-users and developers. As it stands, we just get fewer webaudio applications online from legitimate developers, and they all move to native platforms where it's even easier to fingerprint users. And the malicious sites that don't move to native just fingerprint anyway because we're using bad, opaque metrics for consent. [0]: https://danshumway.com/blog/chrome-autoplay/demo/ https://danshumway.com/blog/chrome-autoplay/demo/
- deleted 7y ago
  [deleted]
Mirioron 7y ago
>For example, you can't determine whether the user has 3 audio devices connected and prompt them to select one for output. Frankly, this really should be handled by the browser. JavaScript really shouldn't have any business messing with that.
- sriku 7y ago
  That's reasonable for just output selection. So shouldnt be able to send audio to all the devices? .. and different audio streams? .. which is all commonplace in the desktop world.
  - Mirioron 7y ago
    Sure, but the browser should handle that logic. Even if the website prompts a user to select an audio device it should be handled on the browser's side without feedback to the website.
- zaroth 7y ago
  I have no problem with sites being able to do this, after I’ve given them permission to access the audio stack in the first place, and limited to first-party scripts on the page.
liability 7y ago
> So you really can't build desktop quality audio systems with webaudio and siblings. Nor should anybody even be trying. We're better off without any of this sort of horseshit.
throwaway40324 7y ago
It's been a little while since I used this, but navigator.mediaDevices.enumerateDevices will give you that list, allowing you to have a menu for a user to choose one and then the client code must use setSinkId to assign the chosen device id. https://developer.mozilla.org/en-US/docs https://developer.mozilla.org/en-US/docs
- sriku 7y ago
  The IDs you get (both deviceID and groupID) are not user displayable. They're like random numbers. In normal browsing mode, you keep getting the same deviceIDs for the same domain, but random groupIDs for every refresh. You get different deviceIDs for different sites. In private browsing mode, you get both random every time.
  - throwaway40324 7y ago
    Ah, I forgot that the device label is only returned when there is an active stream. And has zero support in Safari. https://developer.mozilla.org/en-US/docs/Web/API/MediaDeviceInfo/label https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... I never knew the device ids were randomized like that, thanks for the info.

by sriku 7y ago

danShumway 7y ago

> Also, AudioContext is expected to be active only when created within a user action like a button click. I really hate the user-action restriction as a security measure, because it's ridiculously easy to bypass[0], particularly on Chrome. It's privacy theater -- annoying for legitimate developers, but easy for malicious actors to get around. Putting this stuff behind a permission or sandboxing it somehow would be better for both end-users and developers. As it stands, we just get fewer webaudio applications online from legitimate developers, and they all move to native platforms where it's even easier to fingerprint users. And the malicious sites that don't move to native just fingerprint anyway because we're using bad, opaque metrics for consent. [0]: https://danshumway.com/blog/chrome-autoplay/demo/ https://danshumway.com/blog/chrome-autoplay/demo/

deleted 7y ago
[deleted]

Mirioron 7y ago

>For example, you can't determine whether the user has 3 audio devices connected and prompt them to select one for output. Frankly, this really should be handled by the browser. JavaScript really shouldn't have any business messing with that.

sriku 7y ago
That's reasonable for just output selection. So shouldnt be able to send audio to all the devices? .. and different audio streams? .. which is all commonplace in the desktop world.
- Mirioron 7y ago
  Sure, but the browser should handle that logic. Even if the website prompts a user to select an audio device it should be handled on the browser's side without feedback to the website.
zaroth 7y ago
I have no problem with sites being able to do this, after I’ve given them permission to access the audio stack in the first place, and limited to first-party scripts on the page.

liability 7y ago

> So you really can't build desktop quality audio systems with webaudio and siblings. Nor should anybody even be trying. We're better off without any of this sort of horseshit.

throwaway40324 7y ago

It's been a little while since I used this, but navigator.mediaDevices.enumerateDevices will give you that list, allowing you to have a menu for a user to choose one and then the client code must use setSinkId to assign the chosen device id. https://developer.mozilla.org/en-US/docs https://developer.mozilla.org/en-US/docs

sriku 7y ago
The IDs you get (both deviceID and groupID) are not user displayable. They're like random numbers. In normal browsing mode, you keep getting the same deviceIDs for the same domain, but random groupIDs for every refresh. You get different deviceIDs for different sites. In private browsing mode, you get both random every time.
- throwaway40324 7y ago
  Ah, I forgot that the device label is only returned when there is an active stream. And has zero support in Safari. https://developer.mozilla.org/en-US/docs/Web/API/MediaDeviceInfo/label https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice... I never knew the device ids were randomized like that, thanks for the info.