There's also the opposite scenario of a hostile component.

Please also see http://www.w3.org/mid/op.wuyfg2o4idj3kv@simons-macbook-pro.local

Did I get this right? https://dvcs.w3.org/hg/webcomponents/rev/27c0e8822ebb

3:42 PM <annevk> dglazkov: so now you cannot have CORS-cross-origin resources so that part of the spec doesn't make sense anymore
3:43 PM <annevk> dglazkov: you also need to say what happens if fetching failed
3:44 PM <annevk> I guess it's mostly fine otherwise, although I wonder if it shouldn't use a crossorigin attribute on <link> like most other things we have

(In reply to comment #4)
> 3:44 PM <annevk> although I wonder if it
> shouldn't use a crossorigin attribute on <link> like most other things we
> have

But then if you don't specify the attribute, you'll just have a No CORS state, right?

The <track> element works like that, yes. No real opinion on what is better, but some consistency throughout would be good.

(In reply to Anne from comment #6)
> The <track> element works like that, yes. No real opinion on what is better,
> but some consistency throughout would be good.

For <track>, it makes sense to load it but not to expose the detail through API. So having @crossorigin (on its parent <media>) makes sense. However for imports, it doesn't make sense to do that: Unlike movie subtitles, API-invisible imports aren't useful at all.

Theoretically we could possibly have @crossorigin for imports so that the author can make requests with credentials. But I don't see any usecase for that.
In contrast, not having @crossdomain makes the usage easier/simpler. If we introduce @crossorigin, people needs to give @crossorigin all the time once they want it CDN-aware, which is sad. I prefer to have better default than to just make the orange consistent to apples.

I'm closing this for now. Feel free to reopen this to continue conversation.