5 ms·

I tried really hard to get <video> and <audio> to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also ar

by roca 5y ago

I tried really hard to get <video> and <audio> to default to requiring same-origin but people were still skeptical about CORS deployment, and there were also arguments for consistency with <img>. Oh well, I think we eventually got to a consensus that that "consistency" is not worth having.

EE84M3i 5y ago
webfonts require it though! I was really surprised!
- roca 5y ago
  Yeah, when Web fonts rolled around we fought that battle again and won. Some important people saw the light :-). (And to be fair, CORS was more widely available on servers.)
  - jaffathecake 5y ago
    I think font foundries were particularly keen on that juicy Origin header so they could tell who was using their font, and block sites that hadn't paid.
    - roca 5y ago
      That is also true.
lloydatkinson 5y ago
I am really glad they overruled you.
jaffathecake 5y ago
I think you folks were in a really tricky spot. Making <audio>/<video> require CORS would have been the right decision for security reasons, particularly since <audio>/<video> introduces range requests. It would have prevented these security bugs https://jakearchibald.com/2018/i-discovered-a-browser-bug/ https://jakearchibald.com/2018/i-discovered-a-browser-bug/. However, the competition at the time was Flash, and making <audio>/<video> so much harder than it was with Flash would have put developers off. Fwiw, I regret that opaque responses can go into the service worker cache, since it caused quota-sniffing issues that we had to work around. But, if we didn't allow it, it would have been a feature regression vs appcache. sigh