Re: [w3ctag/design-reviews] JPEG XL decoding (#633)

Thanks for the educational example and excuses for my ignorance.

When we define new standards, obviously we avoid defining the file signature in a way that could be ambiguous or overlapping with already-existing standards, exactly to avoid such things. Of course `sensitive-user-data.bin` could be arbitrary raw data that by coincidence happens to look like a JXL header (or like a JPEG header for that matter). And obviously, the more patterns are added to the mimesniff spec, the more likely it becomes (in principle) that such coincidences happen.

But wouldn't it be a better approach then to check/enforce that the returned media type is either image/* or unknown, but not something known that is not an image? That way also coincidental matches with a jpeg/png/webp/... header could be caught in the example you described, while magic sniffing can still solve the problem of servers not yet knowing about avif/jxl and returning them as unknown content type.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/633#issuecomment-840707699