3 ms·
The security holes are caused by C/C++ being unsafe language to develop with, not new image formats. If image, and other, encoders and decoders do not use unsaf
by miohtama 3y ago
The security holes are caused by C/C++ being unsafe language to develop with, not new image formats. If image, and other, encoders and decoders do not use unsafe languages, it’s unlikely they introduce any such bugs.
- acdha 3y agoThat would definitely help, but it doesn’t eliminate the problem entirely (consider for example the attacks on hardware accelerators). I do think that’d be a good policy: new codecs have to be written in Rust or run in WASM.
- miohtama 3y agoIt is a good idea. When WebAssembly becomes more widespread, it is likely we can drop fixed encoders altogether. Though at this stage the performance impact might be still too much to warrant anything like this.
- toastal 3y agoSo every website would ship with its own codecs? There aren’t shared caches across domains. Why would anyone choose that much latency+badwidth+compute (which new require JS enabled) to use a new codec over the native ones? Certainly not the small–medium sites.
- miohtama 3y agoBecause of the total saved bandwidth. Codec binaries are few hundred kb at most, while high quality images are dozens of megabytes.
- niutech 3y agoMy JPEG XL decoder uses WASM: https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js
- acdha 3y agoNice! I did a quick proof of concept for JPEG 2000 a few years back but it really needed the sophistication of your multithreading and SIMD work.