| 09:51 | <zcorpan> | yoav: re https://groups.google.com/a/chromium.org/d/msg/blink-dev/zlLSxQ9BA8Y/0L7gimc3DwAJ - maybe the situation for tests would be clearer if the intent to ship template asked for a testing plan? |
| 09:59 | <annevk> | Domenic: changes to the same-origin policy are always scary |
| 10:00 | <annevk> | And I strongly suspect that downplaying the significance of such changes has led to quite a number of exploits in the past we're still coping with today |
| 10:02 | <yoav> | zcorpan: it currently asks if the feature is fully tested, which should cover it, but maybe we can do better |
| 10:15 | <zcorpan> | yoav: right. i think often people claim "Yes" when tests exist, but it's not actually fully tested. Reviewing a testing plan is easier than reviewing tests, so makes it easier for others to poke holes in the testing plan or note that the plan says to test something but no test exist for it |
| 10:18 | <zcorpan> | yoav: where is the right place to send feedback about the intent to X process? |
| 10:33 | <yoav> | The blink-api-owners mailing list would be the best venue |
| 10:34 | <yoav> | https://groups.google.com/a/chromium.org/forum/m/#!forum/blink-api-owners-discuss |
| 11:10 | <zcorpan> | https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-api-owners-discuss/S2cZGThNPlY |
| 14:38 | <dtapuska> | annevk: How is it pure fiction? This check is the first quick check V8 makes. |
| 14:44 | <annevk> | dtapuska: at a conceptual level |
| 14:46 | <dtapuska> | annevk: Two agents that are cross domain should just fail on the check right away. So it is an early out. Yes it is true that it could be an assert after the same-domain check today. |
| 14:46 | <annevk> | dtapuska: the thing is that per JavaScript two objects that are in different agents shouldn't be able to reach each other |
| 14:47 | <annevk> | dtapuska: an agent is kinda like a process boundary (although implementation-wise the process boundary is more at the agent cluster level) |
| 14:48 | <annevk> | dtapuska: so if you're talking to an object from another agent, you're really talking to some kind of "remote object" in your agent that messages things across the boundary |
| 14:48 | <dtapuska> | WindowProxy is a PaltformObject |
| 14:48 | <dtapuska> | https://html.spec.whatwg.org/multipage/window-object.html#windowproxy-getprototypeof |
| 14:48 | <annevk> | (again, this is how it's supposed to be, the spec quite freely lets objects cross this boundary, but that's not necessarily great) |
| 14:49 | <annevk> | (as in, HTML steps a bit all over ECMAScript and ECMAScript doesn't really give great tools for working with agents) |
| 14:50 | <dtapuska> | In V8 I'd consider an Agent mapping to an Isolate. |
| 14:50 | <dtapuska> | And an Isolate can't access memory that it doesn't have mapped into it. |
| 14:51 | <annevk> | I'm not really familiar with V8 internals |
| 14:52 | <dtapuska> | Ya.. I understand that. I just want to be sure that you are aware there can be multiple Agents in a given standard operating system process. |
| 14:55 | <annevk> | Sure, that's clear to me, that's why I said conceptual |
| 14:55 | <Domenic> | (agent ~ thread, agent cluster ~ process) |
| 14:55 | <annevk> | In Firefox agents are also a number |
| 14:56 | <annevk> | Domenic: in impl yes, conceptually agents are closer to processes imo |
| 14:56 | <Domenic> | No, conceptually they are threads, since they can share memory amongst each other |
| 14:56 | <annevk> | But they cannot share anything else, which threads typically can |
| 14:56 | <Domenic> | Only in languages which choose to make that possible |
| 14:56 | <annevk> | And there's cross-process shared memory as well on some architectures |
| 14:56 | <annevk> | So meh |
| 14:57 | <Domenic> | Well, actually, memory is the only thing that is shareable in other languages too, they just hide it behind different language constructs |
| 15:02 | <dtapuska> | So you are saying that we probably really need to define Location and WindowProxy having the Agent check then? |
| 15:03 | <dtapuska> | https://www.irccloud.com/pastebin/zcSyTABj/ |
| 15:04 | <dtapuska> | err sorry... ie; cause on a Remote WindowProxy.. |
| 15:04 | <dtapuska> | 1. Let W be the value of the [[Window]] internal slot of this. <--- This doesn't really exist if they are different Agents... |
| 15:04 | <dtapuska> | 2. If ! IsPlatformObjectSameOrigin(W) is true, then return ! OrdinaryGetPrototypeOf(W). |
| 15:04 | <dtapuska> | 3. Return null. |
| 15:40 | <annevk> | dtapuska: ideally we'd have "remote WindowProxy" and "remote Location" objects for WindowProxy and Location others in other agents and those would message to their local counterparts in those agents |
| 15:45 | <annevk> | Domenic: what's the current state of 5107 and 5109 according to you? I believe I replied to all feedback in the PRs and tests |
| 15:47 | <annevk> | dtapuska: anyway, I was wrong about saying we can use asserts, as clearly we don't have remote/local objects and happily compare objects across agents. But I think continuing to build on the current setup with ECMAScript clearly having a different idea about this isn't great |
| 15:49 | <Domenic> | annevk: in both cases I don't believe the current tests are sufficient. In 5107 you've stated they are, and vaguely gestured toward why, so when I have several hours I can try to sit down and figure out what you mean. In 5109 you stated that only one of the two scenarios I outlined was tested so there the ball is in your court I believe? |
| 15:54 | <annevk> | Domenic: I suspect the second test would require browsers to expose document.domain in SVG documents, I'm not sure all of them do |
| 15:55 | <Domenic> | Hmm that would be an interesting divergence from the spec |
| 15:55 | <annevk> | Though I guess it should work, so why not |
| 15:57 | <annevk> | I'm not sure I was that vague btw |
| 15:57 | <annevk> | If you navigate from A1 to A2 and that's same origin and same origin-domain |
| 15:57 | <Domenic> | I feel that in 5107 you've been repeatedly brief and unclear, which is not helpful when trying to evaluate this very complex space. |
| 15:58 | <annevk> | If you do the same but A1 has set document.domain, it's still same origin, but not same origin-domain |
| 15:58 | <annevk> | A2 can never set document.domain |
| 15:58 | <annevk> | So same origin-domain is a stricter check and more secure |
| 15:58 | <Domenic> | I've tried to express in great detail scenarios that I think are being changed by the PR and that would be important to test, and you have given short not-very-clear answers as to why they're not important to test. |
| 15:58 | <Domenic> | GTG to a meeting for a bit |
| 15:59 | <annevk> | Well, I've said why they would be redundant with existing tests or cannot be tested and you have not provided an example why that's untrue... |
| 16:32 | <Domenic> | I haven't understood your "why's because they are very short and cryptic |
| 16:32 | <Domenic> | Fundamentally I find it impossible to understand how a spec change that preserves Window object identity doesn't end up testing Window object identity by checking if globals stay the same |
| 16:33 | <Domenic> | I understand that the ball is in my court to respond but it would take me a lot less time to respond if you were more clear |
| 16:33 | <annevk> | Again, as I wrote above it doesn't, it preserves it in fewer cases |
| 16:33 | <Domenic> | OK, then checks that the global variables disappear, either way |
| 16:33 | <annevk> | The whole bug is that it was preserved |
| 16:33 | <annevk> | Those would security error as is already checked? |
| 16:34 | <Domenic> | That isn't clear to me, so I'll spend some time when I can trying to make it clearer |
| 16:34 | <annevk> | Sure |