3 ms·

Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, bec

Your problem isn't the quality of your own code, it's that Google exists and is unable to stop their employees from doing stupid things like inventing WebP, because now you need to support WebP too which means using their code to do it. (Worse, WebP is at least two completely different formats - the lossless mode has nothing to do with the lossy mode.)

alkonaut 3y ago
I think Apple should either sandbox or reimplement even the most complex formats. Video formats might be painfully complex to implement, but to avoid zero-click you don't even need to safeguard the whole process. You stop autoplaying and you ensure the safety of the parts that parse the metadata/thumbnails required to show the preview. Then worst case you have at least a 1-click threat when someone plays the video which then calls into some 3rd party code.
insanitybit 3y ago
I think that: a) Google should be doing that in a memory safe language, kinda nuts that they haven't started doing that already b) Apple could definitely write their own? Unless I'm missing something crazy here, it seems like they could burn 8 figures and just have their own implementations that are safe
- astrange 3y ago
  If you reimplemented it they'd just change it. It's Google, they can't stop themselves.
  - insanitybit 3y ago
    I don't believe you, frankly. I don't believe that Google makes breaking changes to existing image formats often.
    - astrange 3y ago
      They already did - WebP added a lossless mode and VP8 was updated to VP9. Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)
      - insanitybit 3y ago
        Are those breaking changes? I'd assume that a decoder would continue to work, just would not support the lossless mode/ VP9.
        astrange 3y ago
        It will work on old files (since they've already been encoded) but not on new files with the same file extension, and not on, say, YouTube.
        insanitybit 3y ago
        Interesting, thanks.
saagarjha 3y ago
As opposed to Apple’s formats, for which the parsers are definitely less buggy and likely to be hacked.
- deleted 3y ago
  [deleted]

alkonaut 3y ago

I think Apple should either sandbox or reimplement even the most complex formats. Video formats might be painfully complex to implement, but to avoid zero-click you don't even need to safeguard the whole process. You stop autoplaying and you ensure the safety of the parts that parse the metadata/thumbnails required to show the preview. Then worst case you have at least a 1-click threat when someone plays the video which then calls into some 3rd party code.

insanitybit 3y ago

I think that: a) Google should be doing that in a memory safe language, kinda nuts that they haven't started doing that already b) Apple could definitely write their own? Unless I'm missing something crazy here, it seems like they could burn 8 figures and just have their own implementations that are safe

astrange 3y ago
If you reimplemented it they'd just change it. It's Google, they can't stop themselves.
- insanitybit 3y ago
  I don't believe you, frankly. I don't believe that Google makes breaking changes to existing image formats often.
  - astrange 3y ago
    They already did - WebP added a lossless mode and VP8 was updated to VP9. Though the same may happen to JPEG; it always had 10-bit and 12-bit modes but most decoders don't support them. (Not sure if they can decode it as 8-bit or not.)
    - insanitybit 3y ago
      Are those breaking changes? I'd assume that a decoder would continue to work, just would not support the lossless mode/ VP9.
      - astrange 3y ago
        It will work on old files (since they've already been encoded) but not on new files with the same file extension, and not on, say, YouTube.
        insanitybit 3y ago
        Interesting, thanks.

saagarjha 3y ago

As opposed to Apple’s formats, for which the parsers are definitely less buggy and likely to be hacked.

deleted 3y ago
[deleted]