| 03:53 | <Eric Portis (he/him)> | Domenic Noam Rosenthal annevk Thank you for the answers re: CORS/CORP differences (a week ago)! Very helpful. |
| 03:53 | <Eric Portis (he/him)> | Sounds like, for the use case I had in mind (serving a totally static, public resource), add both… and it’s overly reductive to say ACAO:* represents “global read access” and CORP:cross-origin represents “global embed access, which, worst case, escalates to read access”. The flows are different enough in at least some cases that the platform can’t always infer that CORP:cross-origin would be safe, given the presence of ACAO:*. |
| 03:55 | <Eric Portis (he/him)> | One follow up question… Noam Rosenthal said CORP:cross-origin “kind of” means that you send all/the same data to every Origin. Which (I think) makes sense... But let’s say the resource doesn’t vary per Origin, and doesn’t vary based on Cookie or Authentication, but does vary based on other things (Accept, User-Agent… IP??) Is adding either/both headers to responses that vary in these ways dangerous? Does the "degree or type of variance" matter? |
| 04:41 | <Eric Portis (he/him)> | After some thought, my guess is it’s not dangerous because the value of those request headers doesn’t change based on origin, so they don’t reveal anything about the user’s relationship to that other origin. |
| 04:50 | <californiatok> | I'll help 10 people on how to earn $12,000 within 72 hours but you will pay me 10% of your profit when you receive it. Note: only interested people should apply, click and drop a message let's get started https://t.me/isheilabillyinvest |
| 05:31 | <annevk> | Eric Portis (he/him): the question is more about whether the variations reveal something about the user only the server in question knows about and whether you are comfortable sharing that widely |
| 06:42 | <Noam Rosenthal> | Eric Portis (he/him): Example: If embedder.com is embedding an image from image.com, and the served image is different per client-IP, then it's a question of - is that information that embedder.com should have access to? |
| 06:45 | <Noam Rosenthal> | The Origin header answers the question: "which website is asking for this image on behalf of this user?". The only thing it reveals about the user in itself, is the fact that they are currently visiting that origin |
| 06:52 | <Noam Rosenthal> | ... What helps me remember the CORS/CORP essence is that when you make a server-to-server request. both don't apply. That's because a server is not a user-agent - it doesn't have the user's cookies/client-certs, and also not other anonymous-but-revealing properties like IP and user-agent. CORS/CORP are both there to protect the user from having a content site reveal to the embedding document information that only the user should know and protected by their credentials or private information like client IP. Either by having the embedder self-identify (CORS), or by allowing limited access to unidentified origins (CORP) |
| 16:02 | <annevk> | wanderview: presumably someone at Chromium has thought about this though? E.g., the anonymous iframe proposal clearly wants the partitioned nonce for both storage and networking |
| 16:03 | <annevk> | To me that, as well as what we've learned about the security/privacy boundary over the last couple years suggests some kind of unification is in order |
| 16:03 | <annevk> | I'd rather not work on a solution just for storage keys if a couple months later we have to do it again for networking |
| 16:04 | <wanderview> | I think making storage partitioning block on that unification is going to delay spec'ing storage partitioning... at least I don't have bandwidth for it at the moment |
| 16:04 | <wanderview> | and arguably I don't understand it... maybe you are the only here who knows what your vision looks like? |
| 16:05 | <wanderview> | at a minimum it would need more definition of what your final state looks like... right now it seems a bit vague to me |
| 16:05 | <wanderview> | and I hesitate to invest a lot of time trying to implement a grand vision that I don't understand and may not be what you are looking for anyway |
| 16:07 | <annevk> | That's fair, but that also goes for the variety of Google's proposals in this area, no? |
| 16:08 | <wanderview> | I don't understand what you mean? |
| 16:08 | <annevk> | Well, going back to https://github.com/whatwg/storage/issues/142. What's stated there is incorrect as I've shown by pointing to the anonymous iframe proposal. |
| 16:09 | <annevk> | In that the nonce is used elsewhere. |
| 16:09 | <annevk> | So it's also not clear to me what Google's vision is here as there are contradictory statements. |
| 16:09 | <wanderview> | "used elsewhere" means for networking in addition to storage? |
| 16:10 | <wanderview> | are we bikeshedding the word "storage"... I mean StorageKey is also used for communication APIs like broadcastchannel |
| 16:10 | <wanderview> | I don't understand why StorageKey can't be the one source of truth here |
| 16:10 | <annevk> | Yes networking, which cannot use the storage key directly as it doesn't use the "origin" part. |
| 16:12 | <wanderview> | I'm confused.... networking would not use all of whatever this 'authority struct' is either... |
| 16:12 | <wanderview> | why can't networking pull the nonce out of storagekey |
| 16:13 | <wanderview> | just as it would this authority struct |
| 16:13 | <annevk> | It doesn't currently no, but that's what I'm suggesting we do over time. Unify the networking partition key and the storage key somewhat. |
| 16:13 | <annevk> | And have them be more centrally owned, similar to origin. |
| 16:14 | <wanderview> | the "over time" does not seem consistent with the "can't make incremental improvements" position you have here |
| 16:14 | <wanderview> | I'm fine with that being the goal long term... but you seem to be saying you want it now before we do anything else |
| 16:14 | <annevk> | I think my suggestion can be mostly backwards compatible. |
| 16:15 | <annevk> | As in we put the state there, you'd have to adjust "obtain a storage key" slightly, but after that it would all still work. |
| 16:16 | <wanderview> | so you want to do the opposite of what I wrote in https://github.com/whatwg/storage/issues/142... I did not take that from your comment there |
| 16:19 | <annevk> | wanderview: perhaps your comment above naming is correct; I think we should group this state on environment and give it a name that'll serve us going forward |
| 16:20 | <annevk> | But I meant what I wrote there, I agree that it would make sense for us to store this state on environment, I just think it's wider than a storage key, especially given that with "storage" the web platform typically doesn't mean cookies or network state |
| 16:34 | <annevk> | I gotta go, happy to discuss more on Monday; also happy to try to explain it better or work with whoever at Chromium is nominally in charge of these various keys to hash something out, let me know |
| 16:49 | <Eric Portis (he/him)> | Noam Rosenthal annevk Thank you, again, for the explanations. Very helpful. annevk said: “whether the variations reveal something about the user only the server in question knows…” Ok, so… interpreted literally, that’s potentially every aspect of the request. image.com has no guarantee that the user is sending any of the same headers (or IP) to image.com vs embedder.com. annevk said: “…and whether you are comfortable sharing that widely” This is the part I struggle to reason through, in cases that don’t involve Cookies/Authentication (which are more obvious). Wrote up some examples and how I'm thinking about them... https://gist.github.com/eeeps/ecfbf8d554bcbdd0d92c74c7edd11d15 Am I thinking ~correctly? Any advice on the murky cases? |
| 17:18 | <annevk> | Eric Portis (he/him): in practice these are all probably okay; it seems unlikely the two requests end up with different IP addresses though perhaps this will be more common in the future (but who is to say that image.com is getting an accurate one then) |
| 17:19 | <annevk> | Eric Portis (he/him): the main problematic case without credentials is using the IP address of the user to authenticate them |
| 17:19 | <annevk> | Eric Portis (he/him): so not so much revealing their IP address, but revealing who they are |
| 17:23 | <Eric Portis (he/him)> | annevk: Huh, ok. I think I get it. Thank you!! |