Because web developers should rely on SOP, and not get into process-layer implementation details of UAs. UAs should guarantee SOP works, and fix their bugs if it's not there (like with Spectre)
-
-
Replying to @kkotowicz
The only plan the community has to defend SOP for reads is process per frame and eTLD+1 afaik. That’s not going to stop arbitrary cross-origin subresource loads. And will e.g. mid-range Android phones be able to spin up ~50 processes to load a webpage?
2 replies 0 retweets 0 likes -
Replying to @johnwilander
F-O is not a practical solution for web apps for prohibiting x-o loads. Setting it has extremely high possibility of breaking any complex app (which would benefit from Spectre hardenings the most), in a way that's hard to test for.
1 reply 0 retweets 0 likes -
Replying to @kkotowicz
The one thing that’s still discussed is whether F-O should allow origin whitelisting or not. Would that solve the problems you see? I just don’t want F-O to fail because of complexity.
2 replies 0 retweets 0 likes -
Replying to @johnwilander
I usually disagree with
@arturjanc vehemently, but he outlined what's wrong with F-O on GitHub, and I agree completely. I want to tackle x-origin loads and call for stronger SOP just the same, but F-O is IMHO not the way for practical reasons.1 reply 0 retweets 0 likes -
Replying to @kkotowicz @johnwilander
"Usually" might be an overstatement, how about "often"? ;-) More seriously, we collectively put some thought into this and summarized the main concerns in the doc linked from https://lists.w3.org/Archives/Public/public-webappsec/2018May/0009.html …
@johnwilander should we discuss the F-O adoption concerns in that doc / thread?1 reply 0 retweets 1 like -
Replying to @arturjanc @kkotowicz
I’m willing to discuss but I’d appreciate if such docs were a little more open about who’s proposed what, done work etc.
1 reply 0 retweets 0 likes -
Replying to @johnwilander @kkotowicz
Are you thinking about directly identifying the authors of the proposals discussed in the doc? Or people who reviewed the doc before we sent it out? Or adding more context? Tell me what you're missing and I'll add it, there's nothing there that we can't be completely open about.
1 reply 0 retweets 1 like -
Replying to @arturjanc @kkotowicz
WebKit has raised issues, proposed specs, and landed two open source implementations including ~50 test cases. If we’re going to collaborate, let’s give each other credit when we write docs.
1 reply 0 retweets 1 like -
To be clear, I don’t think there’s any bad intent here. I try to stick to benefit of the doubt. But IMHO, it’s important to give credit to make something like this stay collaborative.
1 reply 0 retweets 1 like
Totally, this is easy to rectify! I added the authors of the relevant specs/proposals (please let me know if I forgot someone from Apple, so far I have you and Ryosuke) and the people who contributed to the doc.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.