TIL: Chrome/Safari block style sheets without an ok status...

annevk: non-2xx status you mean?

they won’t follow 3xx’s?

MikeSmith: at the point where the relevant algorithm gets a response, redirects have been handled

When rendering an <object> element I would need to set the Authorization header to be used for fetching its data. Is this possible to do "directly"?

I'm not sure I understand the question, but I'm pretty sure the answer is no

What is not clear in the question? annevk

I have <object data='my.url.com/path' />

This will make a request for the object (a pdf) to this url. But the url won't allow unauthorized requests.

So in the request additional headers should be specified.

The <image src='...' > is a similar example that I saw people are struggling with.

Is this possible? If it is not possible why not add this capability to the standard?

I think everyone removed that (you could use the username/password fields of a URL) because it would allow for dictionary attacks

annevk: so what does “without an ok status” mean? what other status is there that would not also cause all browsers to not load the stylesheet either?

MikeSmith: Firefox applies a style sheet whose status is 600

MikeSmith: can I rename the default branch on whatwg/misc-server?

annevk, what do you mean by "everyone removed that", you mean every browser? does this mean some browsers supported something like that?

yes

Why not add to the standard to add some header fields to the img or object elements?

would really come handy in situations like this, and a lot of people are wondering this over the internet

As annevk said, letting some script on some random website manipulate the Authentication header would be a big security risk

annevk: IIRC Opera blocked everything !ok as part of the cross-origin stylesheet snooping fixes, IIRC

gsnedders: well, they didn't standardize it

annevk: hence WebKit/Blink (quite possibly pre-fork) blocking them doesn't seem super surprising?

annevk: none of that cross-origin protection stuff was standardised for a long time after, AFAIK :|

and wasn't there some quirks mode scoping of some of it, at least the text/css check, originally?

The main things about being strict on text/css has been standardized for a long time

(this is CVE-2010-0654 I'm referring to)

So if !ok was part of that I would have expected that to have come up, but it hasn't and Firefox doesn't implement it

andreubotella, annevk how would it be a security risk, and what does it have to do with dictionary attacks?

What does allowing Authentication header have anything to do with a dictionary attack?

croraf: gist.github.com/andreubotella/04e617f15af88125597d842c40e2edba

I'm not actually sure that img.decode works that way – this is an example, not a proof of concept

And what possible workaround offers protection by such attacks?

I always confuse atob and btoa

This is silly I think. Why is having Authorization header in the image making site less secure than not having.

croraf: the point is not having the header, it's letting scripts from other sites modify it

An attacker can try dictionary attacks on everything, it can try to access the same resource using fetch and with dictionary attack.

huh, right

with fetch probably not because of cors

but an attacker could use any non-browser http client

This is the usual problem

You cannot use fetch to access internal (e.g. intranet) resources, because of CORS

You can use <img> to do so

I see.

So <img> with arbitrary headers can be used for attacks on intranets

Why is cors not applied to images?

Because it wasn't in Netscape 1.0 :(

"don't break the web" is an important principle, and that means if something used to work, it must keep working unless the risks would be huge

Arguably the risks are pretty bad these days, but we've gone with less strict mitigations than full CORS. E.g. CORB is such a mitigation.

annevk: oh, trac.webkit.org/changeset/72743/webkit might be the change that made this happen in WebKit, which makes it look accidental?

gsnedders: isn't that for images? Pretty sure that it's important to ignore status there

annevk: it changes WebCore/loader/cache/CachedResource.h and WebCore/loader/loader.cpp to make < 400 a failure by default, except where things opt-in to it being okay (like images)

Domenic: with "these days" you mean because of Spectre, right?

annevk: basically anywhere that didn't explicitly check "has an error occured" started being strict about this

gsnedders: I guess that means I should check media as well, at least for ORB purposes

andreubotella: indeed

gsnedders: there's a bunch of other things like text tracks that might then also need to be checked, but I care less about those

I still need slight clarification. So scripts on website A loaded from any origin can access the <image>. Or the issue is that scripts from any origin can create the <image> element with some URL and access that data?

croraf: some of the CORS-related restrictions that were put on the <img> element means you can't access the contents of the image from a website in a different origin, because those capabilities were only added after CORS, but you can see if the image loads or not

so if you can change the Authorization header, just create an <img> element in any origin that points to a resource in the intranet, and see if it loads

Domenic: are there server aspects that depend on the default branch name? Or would that all be documented in misc-server in which case I should find it shortly?

annevk: my guess is if you do a full-text search on misc-server for "master" you'll find all such dependencies.

great

(assuming you are only talking about renaming misc-server)

Domenic: I'm talking about renaming all repos, but I'm also grepping all repos

Domenic: so the main question is if we have stuff that's outside repos I suppose

andreubotella, how can you see that it loads?

annevk: OK, I can't think of anything outside repos then. We'll see...

croraf: my example was using the img.decode() method, that I believe returns a promise that rejects if the image doesn't load. but you can also listen for an "error" event

If anything breaks down it should be easy to fix, not planning on switching today though

Maybe Tuesday would be a good day after we get the RDs out

andreubotella, I see

I'm also confused now with this <object> element, it loads a document in my example, but I cannot apply Network latency in Chome devtools to it.

<object type='application/pdf' data={url} />

I'm so confused with this <object_

croraf: <object> and <embed> used to be elements that allowed you to integrate plugins like flash into a page

So I should use Iframe for pdf's?

yeah

:thumbs-up:

I mean I know there are subtle differences between the three.

see whatwg/html #6003, which will make object and embed more similar to iframe now that flash is deprecated

I'm wondering if the latency will be applied on the iframe

it is not :(

that sounds like a chrome devtools issue, rather than something the spec would require

yes

Can I apply custom headers to Iframe, I guess not :( ?

bugs.chromium.org/p/chromium/issues…q=devtools%20latency%20iframe&can=2 I guess that's the bug

Damn, thats from 2012, and still open

But even on FF it is not throttled

annevk: I think I'll file a PR for whatwg/html #6247 and see what the folks from the different browsers think

andreubotella: sounds reasonable, unfortunate that people are not more proactive, but that's pretty common I'm afraid

Domenic: if you're okay with it I think I'm also happy to switch tomorrow

Domenic: it doesn't seem like we have many dependencies on the default branch name so all the PRs have been rather straightforward

Domenic: misc-server doesn't need updating at all; participate.whatwg.org does though

And whatwg.org of course

annevk: sounds good to me

Domenic: cool, I think I'll do it around this time and then watch the fireworks for a one or two hours, assuming you don't find anything problematic

Is there any way to put <iframe> into loading state?