Thanks for raising this. There's also #248 which we could address now I think (although I'm not familiar with the details).

There's also #248 which we could address now I think (although I'm not familiar with the details).

Yeah, I'm not too sure exactly where that should be addressed in Fetch. I'm also not familiar with how it's implemented in Firefox.

cc @artines1 @ddragana

If I understand the proposal correctly, this would have the effect of disabling meaningful access controls for resources that .onion pages wish to access (since any cross-origin response to a CORS-mode request would have to send headers that allowed any opaque origin to access the resource). That seems like a somewhat counterproductive restriction.

A weaker version of this proposal would apply the restriction to no-cors requests, but not to CORS requests (similar conceptually to the credentialless COEP mode). Is that direction worth exploring?

If I understand the proposal correctly, this would have the effect of disabling meaningful access controls for resources that .onion pages wish to access.

That's a good point. It seems indeed like an unfortunate side-effect of the current implementation in Tor Browser.

My understanding of what Tor Browser is trying to protect here is an Onion service accidentally leaking its identity via linking to or embedding cross-origin resources. If we limited this new restriction to no-CORS requests, then the only case of accidental leakage I can think of would be Onion services using an anonymous CORS request in order to use subresource integrity with https://code.jquery.com/jquery-1.11.1.js for example. I think we could make a convincing case that the more typical CORS requests (e.g. those with credentials) are intentional and coordinated with the third-party (i.e. no accidental leakage).

I'm happy to file implementation bugs and work on the tests, but before that, I'd like to know whether that's a change that Chrome and Firefox (others?) would be willing to make. (I would also be happy to work on upstreaming the Brave changes to Chromium.)

Is @mikewest 's suggestion (only touching no-cors) what folks think should be done? Is this something I should bring up at the next WebAppSec teleconf?

Some developers do seem to expect that CORS would include .onion domain details: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32865 (thanks @valenting for finding that!). But, having discussed this a bit with @tomrittervg it's not clear to me that's the way to go. Leaking .onion domains to other sites has these risks:

1. It reveals the .onion domain exists. .onion domains are a lot like capability URLs and some are definitely meant to stay secret as I understand it.
2. It reveals the user uses .onion domains. (I'm not sure this is a problem on its own, especially with newish state partitioning behavior.)

Coupled with the fact that depending on CORS is quite easy (e.g., using a cross-site library for a font), I don't think we want it to leak by default. Having said that, I could imagine supporting some kind of policy for this for .onion domains that self-declare in some manner that they are not secret. But it seems that should be a follow-up, if anything.

I'd additionally like to solicit feedback from those more closely involved with .onion. @sysrqb @alecmuffett perhaps you could comment as to whether this seems reasonable?

(Aside: I think it's also a bug in Tor Browser and possibly Firefox therefore that a `null` origin and credentials does not work. At least per https://fetch.spec.whatwg.org/#cors-check that is fine.)