4 ms·

Not necessarily. I use a site local to my network to play music in my browser using the audio tag [0]. Some of the music in my library is flac. I never came aro

by onli 10y ago

Not necessarily. I use a site local to my network to play music in my browser using the audio tag [0]. Some of the music in my library is flac. I never came around encoding them, and the transcoding support of my player never worked perfectly, so much that I finally got annoyed and cut it. Having flac support in the browser will make those audio files work without further work on my side, which is great. [0]: https://github.com/onli/music-streamer https://github.com/onli/music-streamer, but there are probably better alternatives

sjwright 10y ago
That's a reasonable counter-example. Thank you.
- sitkack 10y ago
  Lots of browsing activity occurs on the intranet where bandwidth is effectively infinite. But I am not sure why more native code is being added to firefox that handles file parsing. An emscripten based extension to firefox could have been just as effective. And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot. The discussion in the bug itself covers JS flac implementations https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2 There doesn't seem to be any testing around security, attack surface, etc. Disappointing, and not recommending that anyone use Firefox for the foreseeable future.
  - dTal 10y ago
    >And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot. That's silly. By that argument no browser should ever bother adding any new features.
    - sitkack 10y ago
      Not ones that are trivially added "in user land". Browsers should add features where only they have access.
  - swift 10y ago
    Shipping new Firefox code that parses untrusted data from the network normally requires security view, and a new fuzzer for the data format in question is usually written. There's lots of process and infrastructure around this sort of thing at Mozilla. This is sometimes handled in a separate bug from the one implementing the feature. I'm surprised that the corresponding security review bug isn't linked from the FLAX bug, though, which may be an oversight. (Or it may be the non-public blocking bug, and it's non-public because an issue was found.)
    - sitkack 10y ago
      Now that I think of it, the majority of this work should have been done in JS land, with the heaviest decoding being exposed as a document._firefox.media.flac_decode() method that takes a buffer of flac stream. That one flac stream could be formally verified, everything else lives in user land.
- acdha 10y ago
  We have the exact same use-case for TIFF or JPEG 2000: users can browse a giant repository. They can view many files directly but we have to run a transcode server for browser-unsupported formats, which also means things like the standard Save As UI no longer work as expected. That's not clearly bad - the range of obscure formats is long & it's easier to update an app than every client - but it is a cost.

by onli 10y ago

sjwright 10y ago

That's a reasonable counter-example. Thank you.

sitkack 10y ago
Lots of browsing activity occurs on the intranet where bandwidth is effectively infinite. But I am not sure why more native code is being added to firefox that handles file parsing. An emscripten based extension to firefox could have been just as effective. And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot. The discussion in the bug itself covers JS flac implementations https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2 There doesn't seem to be any testing around security, attack surface, etc. Disappointing, and not recommending that anyone use Firefox for the foreseeable future.
- dTal 10y ago
  >And to support all browsers, one will need to drop in a JS flac library anyway, making this addition moot. That's silly. By that argument no browser should ever bother adding any new features.
  - sitkack 10y ago
    Not ones that are trivially added "in user land". Browsers should add features where only they have access.
- swift 10y ago
  Shipping new Firefox code that parses untrusted data from the network normally requires security view, and a new fuzzer for the data format in question is usually written. There's lots of process and infrastructure around this sort of thing at Mozilla. This is sometimes handled in a separate bug from the one implementing the feature. I'm surprised that the corresponding security review bug isn't linked from the FLAX bug, though, which may be an oversight. (Or it may be the non-public blocking bug, and it's non-public because an issue was found.)
  - sitkack 10y ago
    Now that I think of it, the majority of this work should have been done in JS land, with the heaviest decoding being exposed as a document._firefox.media.flac_decode() method that takes a buffer of flac stream. That one flac stream could be formally verified, everything else lives in user land.
acdha 10y ago
We have the exact same use-case for TIFF or JPEG 2000: users can browse a giant repository. They can view many files directly but we have to run a transcode server for browser-unsupported formats, which also means things like the standard Save As UI no longer work as expected. That's not clearly bad - the range of obscure formats is long & it's easier to update an app than every client - but it is a cost.