- From: Mark Nottingham <notifications@github.com>
- Date: Mon, 30 Mar 2020 22:14:46 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1006/606404546@github.com>
> The harder to deploy thing is almost certainly a feature, for sure. I'd say that once software is in place, flipping the switch should be easy, it's the process you might want to follow before you flip the switch that is challenging. From a server perspective, it's another weird switch to explain and support. And, given that the people who operate these things are usually very separated from the people who actually write the applications, I suspect you're going to fail miserably at making things actually more secure; the flag will either be turned on by default, or by a "helpful" administrator who doesn't have a clue about whether or not it's actually safe to do so. >The other concern I've heard is that preflighting (or fetching Origin Policy) is expensive, and a flag in the connection setup would avoid that cost. Preflighting is expensive, but if you amortise it across many requests with a cache, it becomes much less onerous. > Origin Policy has the disadvantage of needing to define a scope over which it applies, with interesting characteristics from a privacy perspective as a result. On the other hand, it's fairly clear what the scope of applicability for a TLS flag is. I thought it was the origin... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1006#issuecomment-606404546
Received on Tuesday, 31 March 2020 05:15:00 UTC