You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At this point in the algorithm we only care about responses that are CSS or JavaScript and want to block everything else. So a thing that could be done here in theory:
If mimeType is not failure and it's essence starts with "audio/", "image/", or "video/", then return false.
If response's body parses as JavaScript and does not parse as JSON, then return true.
If mimeType is not failure, then return false. (Because CSS either needs text/css (which is safelisted early) or failure.)
We parse as CSS, then serialize the result and return that in a fresh response body. (This should end up hiding a lot of information as while everything can be parsed as CSS, a lot of things end up being dropped in the process of doing so.)
This would require the oracle process to run more often (can be somewhat offset with #27 perhaps), but it would block even more problematic cases.
The text was updated successfully, but these errors were encountered:
@tomrittervg inspired me to revisit whatwg/fetch#964 which is the main reason we have this step currently:
At this point in the algorithm we only care about responses that are CSS or JavaScript and want to block everything else. So a thing that could be done here in theory:
audio/
", "image/
", or "video/
", then return false.text/css
(which is safelisted early) or failure.)This would require the oracle process to run more often (can be somewhat offset with #27 perhaps), but it would block even more problematic cases.
The text was updated successfully, but these errors were encountered: