| 16:54 | <xalqor> | anyone on right now? i have an issue with iframes :( |
| 16:56 | <xalqor> | i'll just go ahead and rant, then |
| 16:56 | <xalqor> | i have a site with a page that is specifically intended for other sites to embed via iframe |
| 16:57 | <xalqor> | for the user's convenience, if the user is already logged in to my site they should be able to access their logged-in account via the iframe |
| 16:57 | <xalqor> | and this used to work but then browsers starting adding inconsistent/buggy support for 3rd party cookies |
| 16:58 | <xalqor> | so i thought, ok I don't really need a cookie, I could just store a session id with localStorage since all the access is with javascript I can just add that token in a header |
| 16:58 | <xalqor> | but the trouble is that localStorage seems to be blocked by browsers via the same setting that blocks 3rd party cookies |
| 17:00 | <xalqor> | so site A loads an iframe with a page from site B, and the iframe tries to store foo=bar in localStorage, the browser interprets that as a request to store under site A's local storage and that's blocked if the user has "block 3rd party cookies" |
| 17:00 | <Domenic> | Yes, I think browsers are generally moving away from letting iframes track people around the internet in that way |
| 17:00 | <Domenic> | localStorage, cookies, whatever |
| 17:00 | <xalqor> | yes but it's not about tracking users across sites |
| 17:00 | <xalqor> | it's about communicating with users of my own site |
| 17:00 | <Domenic> | Knowing who the user is (i.e., accessing their logged in account) is tracking them |
| 17:00 | <xalqor> | in fact I don't want my localStorage associated to site A at all |
| 17:01 | <xalqor> | I'd like a localStorage in an iframe that is associated only to the site the iframe came from |
| 17:01 | <Domenic> | The difficulty there is that the browser would need some guarantee that the embedding site never tells the iframe "I exist" |
| 17:02 | <xalqor> | there could have been some iframe option to say, allow iframe-origin localStorage and block postMessage at the same time |
| 17:02 | <Domenic> | It'd have to be stricter than that |
| 17:03 | <Domenic> | No headers, no query params... actually, I can't think of anything that would work, because you can just use the URL path |
| 17:03 | <Domenic> | E.g. <iframe src="https://tracking-widget.example/userID1234/"></iframe>; |
| 17:03 | <xalqor> | if the parent site wants to leak the user's identity i don't think you can stop it |
| 17:04 | <Domenic> | Right |
| 17:04 | <Domenic> | Which is why browsers are doing this |
| 17:04 | <Domenic> | So that once it's leaked, there's no way to store it |
| 17:04 | <annevk> | Domenic: using allow="" as additional guard for SAB postMessage() doesn't seem unreasonable to me, how serious is this proposal? Mainly wondering if you thought through all the changes required already. |
| 17:05 | <Domenic> | annevk: it is new and just something that came up. We have not thought it through very much but wanted to start a discussion earlier rather than later. |
| 17:05 | <annevk> | Domenic: in particular, I'm wondering if it should influence the public crossOriginIsolated getter and perhaps availability of the SAB constructor |
| 17:05 | <annevk> | Domenic: kk |
| 17:05 | <Domenic> | annevk: it's a bit weirder for Chrome since this is all about a future move to lock up SAB, instead of about how to expose SAB. |
| 17:06 | <Domenic> | Influencing SAB constructor makes sense, unsure about the crossOriginIsolated getter |
| 17:06 | <Domenic> | If the meaning of crossOriginIsolated is "powerful features available" then that makes sense |
| 17:07 | <Domenic> | If the meaning is "COOP+COEP enabled" then maybe not |
| 17:07 | <Domenic> | Probably "powerful features available" is more useful |
| 17:13 | <xalqor> | iframe with postMessage was a great solution to let a site integrate a feature from a second site, while protecting the javascript in both directions |
| 17:14 | <xalqor> | so trying to do this in a way that respects user privacy, meaning it still works with all privacy settings enabled (but still allowing javascript) |
| 17:15 | <xalqor> | can it still be done? if the user has an account at parent site and also on the iframe site, it seems like now the iframe will also need to have a login form inside |
| 17:16 | <xalqor> | definitely don't want the user to login through the parent site and reveal their credentials to some other site |
| 17:16 | <xalqor> | and if we develop a plugin now we have to do it separately for every browsre |
| 17:17 | <Domenic> | xalqor: I am not an expert, but my understanding is that yes, logging in a second time is the current direction browsers are heading. |
| 17:17 | <xalqor> | but it's not just a second time, it's also every time they visit the parent site -- because the iframe can't store the cookie or anything in localStorage to remember that session across reloads |
| 17:19 | <Domenic> | Hmm, I thought the plan was just a second time, i.e. you'd get a different storage partition for when you're top level vs. when you're embedded in site A vs. when you're embedded in site B. |
| 17:19 | <xalqor> | if 3rd party cookies & storage is blocked then it doesn't work |
| 17:19 | <xalqor> | and i don't want to tell my users to disable that setting -- because it affects them on all sites |
| 17:19 | <Domenic> | Well I guess that setting is basically saying "don't allow embedded iframes to store any state" so it makes sense that it would prevent use cases like that |
| 17:21 | <Domenic> | (embedded _third-party_ iframes, that is) |
| 17:22 | <xalqor> | yeah |
| 17:24 | <xalqor> | thanks for the chat, i will need to rethink how i'm doing this thing |
| 17:25 | <Domenic> | Happy to help! |
| 17:42 | <annevk> | Domenic: I’d like to keep the number of (public) booleans down I think. It’s confusing enough as-is |