| 02:34 | <sideshowbarker> | About the “sandboxed origin browsing context flag”, how I can figure out which APIs it affects in addition to Or more specifically, if I have an iframe without |
| 02:38 | <Domenic> |
|
| 03:05 | <sideshowbarker> | incidentally, the specific context is the behavior of the “Playground” in MDN — which is a feature where you can directly edit MDN-article code snippets directly in the browser, and see the results immediately. So if you go for example to https://webdocs.dev/en-us/docs/web/api/document/cookie#example_1_simple_usage and click the Play link, it opens a new tab to https://webdocs.dev/en-us/play with the content of the snippets from that MDN article. And if you inspect the source for the iframe in the right-hand side there, you’ll see this: notice the URL, https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/en-US/docs/Web/CSS/minmax/runner.html It’s a dynamically-generated subdomain. And if you want to try replicating the hosting for that, it requires some relatively complex DNS setup. |
| 03:10 | <sideshowbarker> | But if instead you just don’t use The tradeoff is that anything you run from that iframe that requires an origin check won’t work in the “Playground” environment. So for users, that would mean that for any of those articles that have code snippets with features which require |
| 04:43 | <Domenic> | Yeah, but if you allow same-origin access, then playground scripts can steal cookies and such. Not sure what MDN's security model is for the playground but it's generally best practice not to let arbitrary script run in such un-sandboxed iframes. (allow-same-origin undoes most of what we think of as sandboxing.) |
| 05:04 | <sideshowbarker> | Yeah, but if you allow same-origin access, then playground scripts can steal cookies and such. Not sure what MDN's security model is for the playground but it's generally best practice not to let arbitrary script run in such un-sandboxed iframes. (allow-same-origin undoes most of what we think of as sandboxing.) allow-same-origin on those iframes. Given that the goal is to give developers authoritative guidance on how to use web-platform features, deploying the article code content in a way that conflicts with best practices is not a great way to model things for developers. |
| 05:14 | <sideshowbarker> | Domenic: I now wonder if we should a (non-normative) Note to the spec:
|
| 05:16 | <Domenic> | Sorry, I think there are a lot of double-negatives that are confusing things... |
| 05:16 | <Domenic> |
|
| 05:19 | <sideshowbarker> | OK that I understand — but I guess my (re)wording doesn’t convey that clearly |
| 05:21 | <sideshowbarker> | the iframes in this case would still be deployed with sandbox="allow-scripts" — just not with sandbox="allow-scripts allow-same-origin" (as MDN is currently doing, and which is insecure) |
| 05:34 | <Domenic> | I guess MDN's setup is "insecure" in that code running on https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/ can mess with other code running on that domain. But presumably the idea is that only one piece of code ever runs on that domain? So it's probably secure enough. |
| 05:39 | <sideshowbarker> | Yeah, all the content at those URLs is ephemeral. If you navigate directly to https://ab457e4a-7a76-49c5-ad28-d5b08e7bfbdc.mdnplay.dev/, you’ll see there’s no body content there at all, and if you navigate directly to the https://webdocs.dev/en-us/play parent, it’s not populated with anything. It only gets populated when you open a Play link from any particular MDN article. |
| 19:32 | <radr72> | Hello, I want to implement a subset of the HTML standard and from what I've gathered the strings in the DOM need to be UTF-16 encoded. Is this caused by JavaScript and, if yes, what would it change if I were to use UTF-8 instead? |