Lukasz Anforowicz

Let me try to summarize the available options. # Strict MIME type enforcement for DASH/HLS One option on the table is to make ORB allow DASH/HLS MIME types like `application/dash+xml`,...

@annevk, could you help me understand how [JPEG XL](https://jpeg.org/jpegxl/index.html) could be adopted in an ORB-compatible way? The new image format is not yet standardized, but AFAIU: - The new MIME...

/cc @acolwell

> Can not just image/* be whitelisted instead of whitelisting image/svg+xml Allowlisting image/* (and audio/*, video/*, etc) is my preferred plan of action and what I have implemented in a...

> @anforowicz I don't think that approach really helps with this problem as the image fetching pipeline ignores MIME types (except for image/svg+xml). This is much more about what sniffing...

Using `Cross-Origin-Resource-Policy: cross-origin` as a signal to opt-out of CORB/ORB SGTM. I wonder if `Access-Control-Allow-Origin: *` should also be treated as such signal (even though CORB/ORB only applies to `no-cors`...

Some further thoughts on using `Cross-Origin-Resource-Policy: cross-origin` as a signal for CORB/ORB: - We can either require 1) using `Cross-Origin-Resource-Policy: cross-origin` as an **opt out* for ORB (when using MIME...

The current hypothesis for the observed data is that there are 2 same-origin frames, each with a <video> element pointing to the same video file. Each of the 2 frames...

I haven't really thought much about what can be implemented beyond ORB v0,1 in Chrome. In terms of the spec, we can either: - Ignore this problem as an implementation...

> doesn't this issue suggest we cannot use the first of these options? If we trust the medial element to correctly report initial-VS-subsequent media request state, then everything seems to...