Open therealglazou opened 3 years ago
One of the problems we faced at Dashlane is dealing with frameIDs. It's currently super tricky to associate a frameID to a given element and it's even too complicated to retrieve a frameID at all since the only existing way to do that ATM is to send a message, from the inner context to that iframe, to the background, collect the frameID there and send it back to the origin iframe.</p> <p>I think there should be an easy way to retrieve a frameID for a given iframe element, from the enclosing context of that iframe element. Similarly, from the JS context inside an iframe, there should be an easy way to retrieve the current frameID without having to ping-pong the background.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p><em>Side note</em>: even if <code><embed></code> is deprecated, some sites still use it (yeah, fools...). Example: <a href="https://www2.rxnt.com/phr/">https://www2.rxnt.com/phr/</a></p> <p>Getting the frameID for a document embedded through <code><embed></code> is even more complicated because it's not possible to <code>postMessage()</code> the inner window.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/dotproto"><img src="https://avatars.githubusercontent.com/u/1047763?v=4" />dotproto</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>… it's even too complicated to retrieve a frameID at all since the only existing way to do that ATM is …</p> </blockquote> <p>Another way to do this is to use the <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webNavigation/getAllFrames">webNavigation.getAllFrames()</a>, but this requires the webNavigation permission. Offhand I'm not sure what permission prompt other browsers display for this, but Chrome warns users that this permission allows extensions to "<a href="https://developer.chrome.com/docs/extensions/mv3/permission_warnings/#:~:text=%22webnavigation%22">Read your browsing history</a>."</p> <p>Can you share a bit more about why the content script needs to know the ID of its host frame? As opposed to, say, the background script using this data.</p> <p>Exposing a way for the host frame to get it's own frame ID sounds reasonable. We may also want to investigate a more ergonomic way of getting all frame IDs for a given tab than the current webNavigation approach, as that grants access to much more data than necessary to, say, properly target script injection for a given frame.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Can you share a bit more about why the content script needs to know the ID of its host frame? As opposed to, say, the background script using thi data.</p> </blockquote> <p>We're a Password Manager. When a form contains iframes themselves containing form fields (well-known example visible at <a href="https://account.protonmail.com/signup?language=en">https://account.protonmail.com/signup?language=en</a> but many banks do that too), we need to "replace" an iframe in such a form by its inner form fields when we "recognize" forms at the outermost level. Reaching the frameElement is often impossible and a direct postMessage() to the iframe's window can be unreliable if the contents of the iframe rely themselves on messages and do not accept easily third-party messages (well-known example is Office365, ahem...). So one of the only reliable things to associate an iframe element and its inner contents is the frameID. All Password Managers share the same burden.</p> <p>As of today, of course, we ping/pong the background to get the frameID but that feels like a hack: in short you send a dummy message to the background to grab the originating frameID from the message and send it back. <code>getAllFrames()</code> is hardly usable because of the permission constraints it adds on our webextension. Maybe <code>getAllFrames()</code> should not live inside <code>webNavigation</code>. And even if you can capture the frameID that way, you can capture from within the iframe, it's still not directly associated to the iframe element at the upper level...</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/dylanb"><img src="https://avatars.githubusercontent.com/u/79245?v=4" />dylanb</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>100% agree with this suggestion, this change would make it easier to implement secure messaging between content scripts in cross domain iframe environments. It is currently very difficult with the messaging hack mentioned above being one of the ways to do it.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/oliverdunk"><img src="https://avatars.githubusercontent.com/u/6097064?v=4" />oliverdunk</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>We face exactly the same problem at 1Password, working on our own password manager. Some sites split username and password fields in login forms across frames, and for the purposes of filling, we need a reliable way of knowing where each is located.</p> <p>Additionally, some of the UI we display is added to the DOM of the top frame, but positioned based on the location of a field within an iframe. For this, we need to add the offset of the field within the frame to the offset of the frame itself in the page. Doing so requires that we identify the particular iframe we are showing UI for. Workarounds include comparing the size of an iframe with the size of the window within it. Ideally, however, this would be as simple as using the frame ID that sent us the message.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/bershanskiy"><img src="https://avatars.githubusercontent.com/u/45960703?v=4" />bershanskiy</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>As of today, of course, we ping/pong the background to get the frameID</p> </blockquote> <p><a href="https://darkreader.org/">Dark Reader</a> does this <a href="https://github.com/darkreader/darkreader/blob/309d99c0885cfd23e04901a2c82bdbed28d3a46e/src/background/tab-manager.ts#L52">too</a>.</p> <blockquote> <p>Maybe <code>getAllFrames()</code> should not live inside <code>webNavigation</code>.</p> </blockquote> <p>It would be great solution. Perhaps, it can live under <code>tabs</code>? Also, <code>"tabs"</code> permission could gate some information (like URL)like it already does <code>Tab.url</code>, <code>Tab.title</code>, and <code>Tab.faviconUrl</code>.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>I tried to design something to address all mentioned use cases, but still keep it minimal to enable quick and easy adoption by other implementations. My assumptions are:</p> <ul> <li>Content scripts want <code>frameId</code> of the current frame.</li> <li>Also a way to get <code>frameId</code> for all descendant <code><iframes></code>.</li> <li>(probably nice to have) Get <code>frameId</code> for parent and ancestor frames.</li> <li>(desirable because permissions) Avoid the <code>webNavigation</code> namespace.</li> <li>(if possible) Make it a sync method, it would be used for communication between frames on page load.</li> </ul> <p>So here's the proposal:</p> <p><code>browser.runtime.getFrameId(target: WindowProxy | HTMLIFrameElement): number</code></p> <p>This returns the <code>frameId</code> from the passed Window or container element, <del>or for the current (caller) frame if omitted</del>. Since the <a href="https://www.w3.org/html/wg/spec/browsers.html#browsing-context">Browsing Context</a> subtree already needs to be available in the process, it should be possible to make this a sync method in all implementations.</p> <p>You can pass the <code><iframe></code> directly if you're interested in positioning inside the page, <code>window.parent.parent...</code> to get all ancestor frames, or any descendant <a href="https://www.w3.org/html/wg/spec/browsers.html#the-windowproxy-object"><code>WindowProxy</code></a> from the <code>postMessage()</code> <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#the_dispatched_event"><code>event.source</code></a>.</p> <p>One potential issue is that AFAIKT this would be the first extension API that receives a DOM element as an argument. I had to work around a minor issue (for cross-origin values), and it might be a larger issue in other engines.</p> <p>I've put together a <a href="https://phabricator.services.mozilla.com/D126914">quick prototype</a>, you can test it yourself if you're able to <a href="https://firefox-source-docs.mozilla.org/setup/index.html">build Firefox locally</a>.</p> <p>(That patch also includes an alternative design for <code>getFrameInfo</code> I was considering, which enables enumerating all child frames, but it turned out overall more complex and less capable, and it's not clear that's a real use case).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <ul> <li>(probably nice to have) Get <code>frameId</code> for parent and ancestor frames.</li> </ul> </blockquote> <p>Not only "probably nice to have" but absolutely necessary. Let me explain....</p> <ul> <li>injected JS code needs to use the various origins of the frames in a page (or worse <code>"*"</code>) to <code>postMessage()</code> a parent frame because otherwise the messages will always trigger an origin error.</li> <li>because of that, Website JS cannot make any difference between messages sent by the site itself and messages sent by an extension</li> <li>most websites, including MAJOR ones (Microsoft, Google, etc.) do not make any coherence control on incoming messages, ie, verify that incoming messages are conformant to an expected grammar AND do nothing if they don't. As an example, a major website, a bank I won't name, has a very weird behaviour: it does one thing on incoming string messages it understands, another one on incoming messages being a number and always refresh the page in ALL other cases... So if a WebExtension sends itself, from a frame to another, a JSON, k-boom the website gets a refresh. No, we won't be able to evangelize the whole world on good postMessage() handling practices, that's too late.</li> <li>in other words, <strong><code>postMessage()</code> to communicate between frames is totally unusable in WebExtensions</strong>.</li> <li>a way to associate a <code><frame></code> or <code><iframe></code> element to a frameId goes through finding the index of a frame's window into its <code>window.parent.frames</code> array. BUT <code>window.frames</code> and <code>document.querySelectorAll('frame,iframe')</code> are NOT in sync, contrarily to what developer docs are saying. Frame windows seem to be added to that array at creation time while the other list is in tree traversal order.... It's then completely impossible to reliably use that path.</li> <li>conclusions: 1. only <code>sendMessage()</code> is reliable between frames inside WebExtension code, <code>postMessage()</code> just cannot be used, it breaks websites; 2. it's crucial for each frame to have its frameId and its parentFrameId (communication upwards); 3. it's crucial for extension code to be able, for any arbitrary <code><frame></code> or <code><iframe></code> element, to get its frameId (communication downwards)</li> </ul> <p>This is doable but only through <code>webNavigation</code> permission (that many extensions are reluctant to ask for given the scary message browsers show) or non-blocking <code>webRequest</code>. In both cases, that's hacky and complicated for something that should be trivial. And we have absolutely nothing to fix the conclusion3 issue ATM.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>you can test it yourself if you're able to <a href="https://firefox-source-docs.mozilla.org/setup/index.html">build Firefox locally</a>.</p> </blockquote> <p>I forgot you can actually download builds from our CI infra for <a href="https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O83xcfBiQLiFELx2lWqSlA/runs/0/artifacts/public/build/target.tar.bz2">Linux</a>, <a href="https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JchnG-gtQ6yYO5ChpaMzKQ/runs/0/artifacts/public/build/target.dmg">OSX</a> or <a href="https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/AKlLpdhSRimkGOn4zJWTHQ/runs/0/artifacts/public/build/target.zip">Windows</a> -- though I only tested the last one, please ping me if something doesn't work for you.</p> <blockquote> <p>Not only "probably nice to have" but absolutely necessary. Let me explain....</p> </blockquote> <p>Thank you for the clarification.</p> <p>I didn't notice that requirement mentioned in above use cases, but while trying to work through them, I realized it's probably important, so thanks for confirming.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p><code>browser.runtime.getFrameId(target?: WindowProxy | HTMLIFrameElement): number</code></p> </blockquote> <p>That would perfectly fit our needs. Thanks a lot @zombie !!!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xeenon"><img src="https://avatars.githubusercontent.com/u/190589?v=4" />xeenon</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>This works for the Safari team.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Rob--W"><img src="https://avatars.githubusercontent.com/u/1365071?v=4" />Rob--W</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>One point of feedback on the API design.</p> <p>The parameter being a mixed type and potentially optional may be problematic. Consider the following example:</p> <pre><code class="language-javascript">let frameId = chrome.runtime.getFrameId(window.opener);</code></pre> <p>The intention behind this code is to get the frameId of the window that opened this page. However, <code>window.opener</code> can be <code>null</code>, in which case the API would return the current frame. This unexpected result can potentially cause the extension to use the wrong frameId, and therefore the wrong frame/window.</p> <p>This could be resolved by disambiguating the parameters, by being explicit about which frame is meant.</p> <p>For example by always requiring a parameter instead of <code>null</code> (i.e. <code>getFrameId(self)</code> aka <code>getFrameId(window)</code> to get the current frame's windowId).</p> <p>Or by being even more explicit, taking a dictionary that does not have "unsafe" fallbacks (i.e. overlap between optional parameters and different results). For example:</p> <pre><code class="language-javascript">// Get frameId of current window. let frameId = chrome.runtime.getFrameId({ type: "self", }); let frameId = chrome.runtime.getFrameId({ type: "windowProxy", windowProxy: window, // or parent / opener / top / frames[x] / iframe.contentWindow / event.source, ... }); let frameId = chrome.runtime.getFrameId({ type: "htmlElement", htmlElement: iframe, // One of: <iframe> / <frame> / <embed> / <object> });</code></pre> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>I wonder if the dual type argument, <code>WindowProxy | HTMLIFrameElement</code>, is really necessary. Since <code>chrome.runtime.getFrameId(frameElement)</code> and <code>chrome.runtime.getFrameId(frameElement.contentWindow)</code> should be strictly equivalent, maybe <code>WindowProxy</code> is enough.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Rob--W"><img src="https://avatars.githubusercontent.com/u/1365071?v=4" />Rob--W</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I wonder if the dual type argument, <code>WindowProxy | HTMLIFrameElement</code>, is really necessary. Since <code>chrome.runtime.getFrameId(frameElement)</code> and <code>chrome.runtime.getFrameId(frameElement.contentWindow)</code> should be strictly equivalent, maybe <code>WindowProxy</code> is enough.</p> </blockquote> <p>As mentioned in the example in my last comment, there are more ways to embed a document other than <code><iframe></code>. For frames (<code><iframe></code> and <code><frame></code>), it's indeed possible to get the window with <code>iframe.contentWindow</code>. It's even possible to do the same for <code><object></code>. For <code><embed></code>, that's not possible. Interestingly, documents from embeds do appear in the <code>window.frames</code> object.</p> <p><code><embed></code> used to be used to embed plugins in web pages. Plugins can expose a scripting interface, so up until a few years ago, it was not really safe to expose more properties. Now that support for plugins have been dropped from browsers, it may be feasible to add properties such as <code>contentWindow</code> and <code>contentDocument</code> to <code><embed></code>, which would indeed make the <code>htmlElement</code> kind of parameter redundant. I filed an issue with a request to add <code>.contentWindow</code> to <code><embed></code> at <a href="https://github.com/whatwg/html/issues/7140">https://github.com/whatwg/html/issues/7140</a></p> <p>If that issue gets resolved, then <code>getFrameId</code> only needs to take a <code>window</code>.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Ok, thanks a lot @Rob--W .</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>For example by always requiring a parameter instead of <code>null</code> (i.e. <code>getFrameId(self)</code> aka <code>getFrameId(window)</code> to get the current frame's windowId).</p> </blockquote> <p>Good callout, the <no params to get current frame's id> is a leftover from when the method only worked with <code>EmbedderElements</code>, and since you suggested including <code>WindowProxy</code>, it's not really needed anymore (I've edited the original proposal to make it clearer).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>@dotproto Can you please check with the Chrome team if this would present implementation difficulties, or if they have any other feedback to this proposal?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/theseanl"><img src="https://avatars.githubusercontent.com/u/22858651?v=4" />theseanl</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>This discussion sounds similar to what has been done for <em>closed shadow roots</em>. Closed shadow roots are meant to be inaccessible from main world, and it has been requested to allow extensions to access them. It is now available on <code>chrome.dom.openOrClosedShadowRoot</code> from Chrome's side, and <code>Element.openOrClosedShadowRoot</code> from Firefox's side.</p> <p>I mostly agree with spec writers' rationale for not wanting to expose <code>contentWindow</code> on <code>HTMLEmbedElement</code>. I propose that browser venders should implement a corresponding <code>chrome.dom.contentWindow</code> / <code>HTMLEmbedElement.contentWindow</code> API to allow content scripts to access content window of <code><embed></code> nodes.</p> <p>Previous proposals add unnecessary overhead to the API call just for one edge case: Making API polymorphic will likely require browser's wrapper code to introduce a type check, and requiring consumers to pass a one-off dictionary seems bad for garbage collection.</p> <p>Moreover, once we have an API for accessing <code>contentWindow</code> of <code><embed></code> nodes, developers may find other good uses of it.</p> <p>For completeness's sake, below is one possible API design that I just came up with.</p> <pre><code class="language-ts">chrome.dom.contentWindow(element:HTMLIFrameElement | HTMLFrameElement | HTMLObjectElement | HTMLEmbedElement): Window | null interface HTMLEmbedElement { contentWindow: Window | null }</code></pre> <p>For extending existing <code>HTMLEmbedElement</code>, one may consider using a different property name to signal developers that this is an extension-only API.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/carlosjeurissen"><img src="https://avatars.githubusercontent.com/u/1038267?v=4" />carlosjeurissen</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>As mentioned here: <a href="https://github.com/w3c/webextensions/issues/77#issuecomment-938053187">https://github.com/w3c/webextensions/issues/77#issuecomment-938053187</a></p> <p>@dotproto created a crbug for the proposal here: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1256872">https://bugs.chromium.org/p/chromium/issues/detail?id=1256872</a> </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rdcronin"><img src="https://avatars.githubusercontent.com/u/1915693?v=4" />rdcronin</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Chiming in from the Chromium side.</p> <p>I was able to bring this up with our security team, and there were a few different considerations. First off, to explain a few of our primary considerations:</p> <p>First, we often try to assume that almost <em>any</em> renderer process can be compromised (and, it turns out, that this is pretty much true : )). Because of these, we try to limit the amount of information and capabilities we give to renderer processes. In particular, it ideally shouldn’t be possible for a compromised renderer process to access or affect other renderer processes.</p> <p>Second, the boundary between content scripts and the main page is also weaker, since it’s only a JS context boundary (and not a hard process boundary). In either the case of a compromised renderer or just a “pierced” boundary between JS contexts, an attacker can potentially gain access to any power or knowledge that a content script has.</p> <p>These are the reasons that the vast majority of extension APIs aren’t accessible from a content script context and that we’ve adjusted the cross-origin fetching capabilities of content scripts, and that we are generally opposed to expanding those capabilities.</p> <p>In this case, though, it’s a bit of a blurred line. For one thing, I can absolutely see the benefit and desire here for extension developers - dealing with frame IDs is painful, and if there’s frame-specific logic you need in content scripts, it’s even more so (and sometimes impractical, if you need it synchronously for a script running at document_start). There's also an argument that, at least for retrieving the current frame's ID, it's not really an "extra" capability (though this is somewhat inaccurate for Chromium; discussed below). From a platform viewpoint, I’m supportive of exposing this information to ease development.</p> <p>Now, though, we get into the nitty gritty. In Chromium, frame IDs (apart from the main frame, which is always 0) are currently associated with something called the Frame Tree Node ID. This a globally-unique, monotonically-increasing identifier given to a frame. If we expose this information to a compromised renderer, it can give away information about the current state of the browser, as well as being able to detect happenings in other tabs (by adding new frames and seeing the delta from the previous ones). This type of information can then help attackers mount timing attacks, among others. A second risk here is that if an attacker has control over a process and the knowledge of the frame tree node IDs within it, that attacker could try and leverage an inter-process message to the browser targeting different frame tree node IDs that are likely to exist.</p> <p>It’s true that these are largely only security concerns when one (or frequently, more than one) thing already goes wrong, but we very much strive to have defense-in-depth. We’ve historically seen many vulnerabilities that chain together multiple things going wrong.</p> <p>Now, for the path forward. On the Chromium side, I think many of these concerns would be assuaged if we had an unguessable identifier associated with frame IDs. I think this is an approach that we could take (I’ll investigate it), but we’d likely block runtime.getFrameId() on that being completed. Even then, there could be a slight (though significantly mitigated) concern around allowing frames to retrieve the unique identifier of other frames in the hierarchy, especially ones that might be cross-origin and/or cross-process; I’m continuing the discussion there to see if, with an extension-specific identifier here, that’s a reasonably low risk.</p> <p>I’m curious for the other browsers’ implementations here - are frame IDs (apart from the main frame) already random? Or are any of these also concerns for other implementations?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 3 years ago</strong> </div> <div class="markdown-body"> <p>Thank you Devlin for the Chromium perspective. I think your proposal for using random frame IDs is compatible with the <code>getFrameId()</code> design, and something we could implement if/when we decide to (though it might not be a priority for us, see notes below for mitigating circumstances in Gecko).</p> <p>Since additional exposure seems marginal (at least for Firefox), and using random IDs would be an implementation-level change transparent to extension, it doesn't look like a blocker for the proposed design. I think we can proceed with shipping this as an experimental API to get it into the hands of developers, to test it and provide any potential feedback.</p> <blockquote> <p>A second risk here is that if an attacker has control over a process and the knowledge of the frame tree node IDs within it, that attacker could try and leverage an inter-process message to the browser targeting different frame tree node IDs that are likely to exist.</p> </blockquote> <p>I'm somewhat confused by this. My presumption based on talking to Gecko's site isolation team is that these frame node IDs (or Browsing Context IDs I mentioned in the <a href="https://github.com/w3c/webextensions/issues/12#issuecomment-930545112">proposal above</a>) would already be available in each render process, since we already need to support <code>WindowProxy</code> references to each frame in the same subtree (or perhaps even the whole Browsing Context Group), including cross-origin ones. In case of a compromised render process you mention, these IDs would already be in the process's memory and available to the attacker.</p> <p>Of course this could be mitigated by parent process generating a per-process mapping of frame node IDs, or maybe with something similar to what you're proposing about randomized IDs exposed to extensions, and Chromium might already be doing something along those lines, but at least Gecko isn't (perhaps partially because of the second point below).</p> <blockquote> <p>I’m curious for the other browsers’ implementations here - are frame IDs (apart from the main frame) already random? Or are any of these also concerns for other implementations?</p> </blockquote> <p>They are not random in Gecko either, but they're (mostly) monotonically-increasing only per-process. At least for the case you described, a compromised child process wouldn't be able to observe the creation of frames initiated from other processes.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Quick update, we landed this in Firefox 96, which is currently <a href="https://www.mozilla.org/en-US/firefox/channel/desktop/#beta">in beta or dev edition</a>, and will be released on January 11th.</p> <p>Not documented on MDN yet, in case we need to adjust the design based on feedback from developers or other implementations, so please try it now and report any issues or bugs.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zombie"><img src="https://avatars.githubusercontent.com/u/207002?v=4" />zombie</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>And for clarity, since there's no documentation, this is the implemented API:</p> <blockquote> <p><code>browser.runtime.getFrameId(target: WindowProxy | HTMLIFrameElement): number</code></p> </blockquote> <p>Should be fairly obvious, returns the frameId for any passed <code>Window</code> reference or an embedder element, and throws if passed anything else.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Quick update, we landed this in Firefox 96, which is currently <a href="https://www.mozilla.org/en-US/firefox/channel/desktop/#beta">in beta or dev edition</a>, and will be released on January 11th.</p> <p>Not documented on MDN yet, in case we need to adjust the design based on feedback from developers or other implementations, so please try it now and report any issues or bugs.</p> </blockquote> <p>This is <strong>wonderful</strong> ! Thanks a lot @zombie, we'll make sure to test it ASAP.</p> <p>Chrome, the ball is now in your hands. 😄 </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/oliverdunk"><img src="https://avatars.githubusercontent.com/u/6097064?v=4" />oliverdunk</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Hey @zombie! We jumped on this at 1Password and I'm happy to share that I was able to use the new API as a drop-in replacement for our existing matching logic. That involved both getting the id of a <code>window</code> as well as an <code>iframe</code> from the parent frame. I don't think I have any extra feedback at the moment - a huge thanks for implementing this and we look forward to it reaching other browsers.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/therealglazou"><img src="https://avatars.githubusercontent.com/u/2053679?v=4" />therealglazou</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>@zombie we tested it too at Dashlane inside our browser extension and it works absolutely fine! Thanks a zillion again and we're waiting for Chrome and Safari implementations now.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/GaurangTandon"><img src="https://avatars.githubusercontent.com/u/6308683?v=4" />GaurangTandon</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>@dotproto As a follow up to the previous WECG meeting, I intended to ask if Chrome's position has changed about the security implications of this proposal (and Mozilla's proposed implementation), and also in reference to devlin's comment earlier (<a href="https://github.com/w3c/webextensions/issues/12#issuecomment-942826300">linked</a>). It would be nice to have this feature in all major browsers. Thanks!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>+1 </p> <p>This would be great to see in MV3, supported across all browsers. </p> <p>We need to check the allow policy set on an <code><iframe allow="monetization"></code> to determine if a request initiated in the content script of an iframe is allowed. </p> <p>We are currently using <code>webNavigation</code> apis and a bunch of messaging of correlation ids between content scripts and the background page to be able to get the id of an iframe. It's complicated enough that I can't recall it all offhand now a few years after it was written. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/fregante"><img src="https://avatars.githubusercontent.com/u/1402241?v=4" />fregante</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Could this be expanded to include the tab ID as well? </p> <pre><code class="language-js">browser.runtime.getTarget(window) // {tabId: 1, frameId: 0} browser.runtime.getTarget(iframe) // {tabId: 1, frameId: 63748}</code></pre> <p>It's a pretty common request to know "this" tab ID: <a href="https://stackoverflow.com/q/6202953/288906">https://stackoverflow.com/q/6202953/288906</a> (123 upvotes)</p> <p>Currently this requires a ping to the runtime, which may or may not be "quick".</p> <p>Including the recently-added <code>documentId</code> would be great. There's a lot of potential here so limiting it to just a <code>frameId</code> seems overly specific; returning an object makes it more flexible for future usage without having to create specific APIs.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>I agree with @fregante. It would be convenient </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/dotproto"><img src="https://avatars.githubusercontent.com/u/1047763?v=4" />dotproto</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Following up on this after the 2022-11-10 meeting. @rdcronin's <a href="#issuecomment-942826300">last comments</a> still reflect Chrome's current position. We still need to resolve outstanding questions with our security counterparts before we can proceed with this feature request.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Hi @dotproto </p> <blockquote> <p>@rdcronin's <a href="https://github.com/w3c/webextensions/issues/12#issuecomment-942826300">last comments</a> still reflect Chrome's current position.</p> </blockquote> <p>still ? </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Rob--W"><img src="https://avatars.githubusercontent.com/u/1365071?v=4" />Rob--W</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Hi @dotproto </p> <blockquote> <p>@rdcronin's <a href="https://github.com/w3c/webextensions/issues/12#issuecomment-942826300">last comments</a> still reflect Chrome's current position.</p> </blockquote> <p>still ? </p> </blockquote> <p>@oliverdunk is the current Google representative in this group.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@Rob--W </p> <p>Thanks, I saw dotproto with the most recent action here, and got it confused. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/oliverdunk"><img src="https://avatars.githubusercontent.com/u/6097064?v=4" />oliverdunk</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I haven't heard of any new conversation around this and I don't think anything has changed which would influence our decision. That said, I can try to bring this up again.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <ol start="3"> <li>it's crucial for extension code to be able, for any arbitrary <code><frame></code> or <code><iframe></code> element, to get its frameId (communication downwards) <blockquote> <p>This is doable but only through <code>webNavigation</code> permission (that many extensions are reluctant to ask for given the scary message browsers show) or non-blocking <code>webRequest</code>. In both cases, that's hacky and complicated for something that should be trivial. And we have absolutely nothing to fix the conclusion3 issue ATM.</p> </blockquote></li> </ol> <p>@therealglazou can you elaborate on how you use webNavigation(.getAllFrames?) to retrieve a frameID for any <iframe> element ? On my side, I am struggling to associate the frameIds received thru webNavigation.getAllFrames() with the iframes elements contained in webpage. Urls can't be used since some iframes have an empty src url or a urn:</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@addeective </p> <p>I did this at a previous gig and started to put some rough documentation together before I left. There may be simpler ways to do it, and it may not be all that clear, as I didn't get around to finishing it, but it should serve as a pointer in a direction that worked:</p> <p><a href="https://github.com/interledger/web-monetization-projects/pull/3687/files">https://github.com/interledger/web-monetization-projects/pull/3687/files</a></p> <p>Where it says: <code>The request handler in the background page consults the BackgroundFramesService</code></p> <p>You can just "consult" webNavigation.getAllFrames</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@sublimator I used iframe.contentwindow.postMessage() but the listener registered in the content script hosted by the iframe is either <strong>always</strong> receiving the message by some iframes, either <strong>never</strong> received by other iframes. I have verified that the listener is active at the time of the postMessage by setting the name of the target iframe window (inside that same content script) , and then logging the name of the contentWindow at the time of the postMessage. Hence my question: is there a theoretical constraint inherent to an iframe preventing the reception of the message ?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I don't recall coming across any issues like that, but it's been many years since I gave it any real attention. Other than those notes, I don't have a lot else to help you with. </p> <p>It's probably not timing issues, if you are getting consistent results. Cross origin restrictions? Do you see any commonality between the pages that don't work?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>What did you set as targetOrigin ?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@sublimator </p> <blockquote> <p>What did you set as targetOrigin ? targetOrigin '*' (unfortunately I need to communicate from any origin.)</p> <p>It's probably not timing issues, if you are getting consistent results. Cross origin restrictions? Do you see any commonality between the pages that don't work? I'm on a blank src commonality lead at the moment.</p> </blockquote> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/hamax"><img src="https://avatars.githubusercontent.com/u/394506?v=4" />hamax</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>If the iframe has other message listeners, they could be calling stopPropagation/stopImmediatePropagation and preventing your listener from being called. To make it work reliably you would need to make sure your content script runs before anything else on the page (document_start), and use "capture" in the event listener.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Yeah, we used document_start iirc</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I'm on a blank src commonality lead at the moment.</p> </blockquote> <p>an iframe without a @src set ? curious :) </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@hamax here is my manifest: { "matches": [ "<all_urls>" ], "js": [ 'adsfilter.bundle.js'], "match_about_blank": true,<br /> "all_frames": true, "run_at": "document_start" }</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@sublimator I did not introduce the scope of the project but I'm working on a research program which wants to track ads inserted in webpages. I assume those empty urls iframes are dynamic frames built by some advertisor javascript </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I was about to say, "Have you tried setting match_about_blank: true", but I see ... Shrug, try setting up a controlled context with your own blank iframe and see if you can send it a message from the dev tools?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I was about to say, "Have you tried setting match_about_blank: true", but I see ... Shrug, try setting up a controlled context with your own blank iframe and see if you can send it a message from the dev tools?</p> </blockquote> <p>@sublimator yes I need to dig deeper thanks!</p> <p>my life would be so easier if we had the chrome.runtime.getFrameId ready :)</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/sublimator"><img src="https://avatars.githubusercontent.com/u/525211?v=4" />sublimator</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>I hear ya!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/addeective"><img src="https://avatars.githubusercontent.com/u/114247584?v=4" />addeective</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@oliverdunk any chance you can give a kick to this feature? everybody has it except chrome since quite a while...</p> </div> </div> <div class="page-bar-simple"> <a href="/w3c/webextensions/12?page=2" class="next">Next</a> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>
One of the problems we faced at Dashlane is dealing with frameIDs. It's currently super tricky to associate a frameID to a given