Re: Intent to implement and ship: Ignore navigation to unknown protocol
Op zondag 29 maart 2020 08:24:06 UTC+2 schreef Emilio Cobos Álvarez: > Hey, a quick web-observable change that may deserve a bit more > visibility / an intent. > > I'd welcome some feedback, specially from the fingerprinting / privacy > angle (where I'm clearly not an expert). > > Summary: A page redirecting / navigating to an unknown protocol will be > silently ignored (and logged to the DevTools console) instead of showing > an error page. This is not amazing, but it's needed because it causes a > bunch of compat issues (see the list of issues in the bug below). > > There are a few subtle problems here. Part of the issue is that authors > don't have a cross-browser way of detecting whether a protocol will be > handled externally (that is, whether an app is installed to handle a > given protocol). > > They technically can in Firefox (see example below). It's unclear > whether we want to expose more than that, or that at all. > > Given Chrome just ignores the navigation if they can't handle it, some > authors (who don't seem to test on other browsers ;)) just spam the > redirect (using various methods like the location href setter / meta > refresh / whatevs). This works just fine in Chromium-based browsers, but > not in Firefox or Safari, which will just show an error, which causes a > very frustrating experience for users. > > As far as I know, this behavior doesn't really expose more information > than we were exposing before. In a test-case like: > > > > > we have different behavior also before this patch: the contentDocument > for the handled-protocol iframe will be accessible to content, and be > about:blank. The contentDocument for the unhandled protocol will be the > error page, which will not be accessible to content and thus be null. > > Other browsers seem to do about:blank for both iframes, but you can also > detect this in all browsers via window.open instead (there may be other > ways around it too, haven't dug all that much). Chrome insta-closes the > handled protocol window (so you can check window.closed). Firefox / > Safari will leave about:blank in that window, and show an error document > for the second (which will throw a security error on access). > > So I don't think this change introduces a new privacy hole. That being > said, this all seems a bit sad, and a somewhat-serious potential > fingerprinting factor. I was in fact a bit nervous about this change > before realizing we were already exposing this information in other > (even simpler to test) ways... But I'm clearly not an expert on this matter. > > There are mitigations possible both for the ignored-navigation case > (maybe only ignore the navigation to an unknown protocol once per > document or something, and only for browsing contexts that can't be > accessed by any ancestor JS? not sure) and the iframe case (probably > just not show error pages in frames?). Please let me know if I you think > I should file this and follow-up on it. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305 > > Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme > allows for both the old and new behavior, as far as I (and Anne) can > tell. This uses urls after redirect and so on so beforeunload and such > will fire. This matches the behavior of Chromium browsers. > > Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it > a bit more). > > Devtools bug: N/A, ignored navigations get logged to the console. > > Other browsers: Chromium browsers do this, but WebKit doesn't seem to. > This was causing compat issues, specially on Android, but also desktop > (see above). > > web-platform-tests: Spec allows both behaviors, so I've added an > internal test for now. Furthermore it's not clear if we want to do this > for sub-windows, which my patch does, so I may need to tweak the test or > add an internal switch depending on the outcome of the discussion here. > > Secure contexts: not restricted to secure contexts, this is a compat > hack, of sorts... > > Is this feature enabled by default in sandboxed iframes? Not sure if the > question quite applies to this, but we don't special-case sandboxed > iframes here. This doesn't expose anything you couldn't do before, as > discussed above. > > Thanks for reading all the way until here > > -- Emilio the issue is more complex: as the browser is an application , the purpose is making an tcp connect that never completed a state, as this would give access to the webserver in a socket where the client (browser) can send any code , as the transmission runs on the protocol level, while http is an application protocol, the issue with crypto is that the tcp out get's an reply to the ack-syn-nack the port doesn't matter you can run https over tcp 80, it's only not by the w3c standard allowed to use the first 1024 tcp ports for running public services, so for those , the agreements and
Re: Intent to implement and ship: Ignore navigation to unknown protocol
On 3/30/20 8:02 PM, Bobby Holley wrote: Reading the post a few times, I'm still unclear on a few things, so would appreciate clarification. Here's what I understand from the post: On the user's machine, there is some entropy, i.e. the set of schemes for which an external protocol handler is registered. This entropy is currently retrievable via various mechanisms. For webcompat reasons, we want to make a change to one of those mechanisms, but the entropy will remain accessible after this change. What's less clear to me is how the proposed change impacts the entropy exposure by the mechanism it targets. It seems to me that using about:blank for both the handled and unhandled case would not expose this entropy, but the post implies otherwise. In other words: does this change put us on a path to eventually making this entropy non-observable, or would we need to undo this change if/when we pursue that? Yeah, you're right. I was not clear about this when I wrote the original email, but this patch makes things slightly better. It makes the known / unknown-ness of the protocol not observable in the navigation case. That being said there are still a bunch of ways to get that information. I just filed bug 1626068 to potentially try to minimize this. -- Emilio Thanks! On Sun, Mar 29, 2020 at 12:29 AM Emilio Cobos Álvarez wrote: On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote: Doing a bit of digging, https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more interesting context... We apparently used to sync-throw when assigning location.href to an unknown protocol URI in the past, there we changed it to silently fail, and now it is navigating to an error page... I'll try to look at when behavior changed around here... Though the sync-throwing clearly makes no sense as it doesn't account for redirects or what not. Apparently the pre-firefox63 behavior was to both navigate and throw... So not all that much to dig in, that was just obviously wrong, but didn't address the fingerprinting angle other than patching one of the holes. On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote: Hey, a quick web-observable change that may deserve a bit more visibility / an intent. I'd welcome some feedback, specially from the fingerprinting / privacy angle (where I'm clearly not an expert). Summary: A page redirecting / navigating to an unknown protocol will be silently ignored (and logged to the DevTools console) instead of showing an error page. This is not amazing, but it's needed because it causes a bunch of compat issues (see the list of issues in the bug below). There are a few subtle problems here. Part of the issue is that authors don't have a cross-browser way of detecting whether a protocol will be handled externally (that is, whether an app is installed to handle a given protocol). They technically can in Firefox (see example below). It's unclear whether we want to expose more than that, or that at all. Given Chrome just ignores the navigation if they can't handle it, some authors (who don't seem to test on other browsers ;)) just spam the redirect (using various methods like the location href setter / meta refresh / whatevs). This works just fine in Chromium-based browsers, but not in Firefox or Safari, which will just show an error, which causes a very frustrating experience for users. As far as I know, this behavior doesn't really expose more information than we were exposing before. In a test-case like: we have different behavior also before this patch: the contentDocument for the handled-protocol iframe will be accessible to content, and be about:blank. The contentDocument for the unhandled protocol will be the error page, which will not be accessible to content and thus be null. Other browsers seem to do about:blank for both iframes, but you can also detect this in all browsers via window.open instead (there may be other ways around it too, haven't dug all that much). Chrome insta-closes the handled protocol window (so you can check window.closed). Firefox / Safari will leave about:blank in that window, and show an error document for the second (which will throw a security error on access). So I don't think this change introduces a new privacy hole. That being said, this all seems a bit sad, and a somewhat-serious potential fingerprinting factor. I was in fact a bit nervous about this change before realizing we were already exposing this information in other (even simpler to test) ways... But I'm clearly not an expert on this matter. There are mitigations possible both for the ignored-navigation case (maybe only ignore the navigation to an unknown protocol once per document or something, and only for browsing contexts that can't be accessed by any ancestor JS? not sure) and the iframe case (probably just not show error pages in frames?). Please let me know if I you think I should file this and follow-up on it. Bug:
Re: Intent to implement and ship: Ignore navigation to unknown protocol
Reading the post a few times, I'm still unclear on a few things, so would appreciate clarification. Here's what I understand from the post: On the user's machine, there is some entropy, i.e. the set of schemes for which an external protocol handler is registered. This entropy is currently retrievable via various mechanisms. For webcompat reasons, we want to make a change to one of those mechanisms, but the entropy will remain accessible after this change. What's less clear to me is how the proposed change impacts the entropy exposure by the mechanism it targets. It seems to me that using about:blank for both the handled and unhandled case would not expose this entropy, but the post implies otherwise. In other words: does this change put us on a path to eventually making this entropy non-observable, or would we need to undo this change if/when we pursue that? Thanks! On Sun, Mar 29, 2020 at 12:29 AM Emilio Cobos Álvarez wrote: > On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote: > > Doing a bit of digging, > > https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more > > interesting context... > > > > We apparently used to sync-throw when assigning location.href to an > > unknown protocol URI in the past, there we changed it to silently fail, > > and now it is navigating to an error page... > > > > I'll try to look at when behavior changed around here... Though the > > sync-throwing clearly makes no sense as it doesn't account for redirects > > or what not. > > Apparently the pre-firefox63 behavior was to both navigate and throw... > > So not all that much to dig in, that was just obviously wrong, but > didn't address the fingerprinting angle other than patching one of the > holes. > > > On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote: > >> Hey, a quick web-observable change that may deserve a bit more > >> visibility / an intent. > >> > >> I'd welcome some feedback, specially from the fingerprinting / privacy > >> angle (where I'm clearly not an expert). > >> > >> Summary: A page redirecting / navigating to an unknown protocol will > >> be silently ignored (and logged to the DevTools console) instead of > >> showing an error page. This is not amazing, but it's needed because it > >> causes a bunch of compat issues (see the list of issues in the bug > >> below). > >> > >> There are a few subtle problems here. Part of the issue is that > >> authors don't have a cross-browser way of detecting whether a protocol > >> will be handled externally (that is, whether an app is installed to > >> handle a given protocol). > >> > >> They technically can in Firefox (see example below). It's unclear > >> whether we want to expose more than that, or that at all. > >> > >> Given Chrome just ignores the navigation if they can't handle it, some > >> authors (who don't seem to test on other browsers ;)) just spam the > >> redirect (using various methods like the location href setter / meta > >> refresh / whatevs). This works just fine in Chromium-based browsers, > >> but not in Firefox or Safari, which will just show an error, which > >> causes a very frustrating experience for users. > >> > >> As far as I know, this behavior doesn't really expose more information > >> than we were exposing before. In a test-case like: > >> > >> > >> > >> > >> we have different behavior also before this patch: the contentDocument > >> for the handled-protocol iframe will be accessible to content, and be > >> about:blank. The contentDocument for the unhandled protocol will be > >> the error page, which will not be accessible to content and thus be > null. > >> > >> Other browsers seem to do about:blank for both iframes, but you can > >> also detect this in all browsers via window.open instead (there may be > >> other ways around it too, haven't dug all that much). Chrome > >> insta-closes the handled protocol window (so you can check > >> window.closed). Firefox / Safari will leave about:blank in that > >> window, and show an error document for the second (which will throw a > >> security error on access). > >> > >> So I don't think this change introduces a new privacy hole. That being > >> said, this all seems a bit sad, and a somewhat-serious potential > >> fingerprinting factor. I was in fact a bit nervous about this change > >> before realizing we were already exposing this information in other > >> (even simpler to test) ways... But I'm clearly not an expert on this > >> matter. > >> > >> There are mitigations possible both for the ignored-navigation case > >> (maybe only ignore the navigation to an unknown protocol once per > >> document or something, and only for browsing contexts that can't be > >> accessed by any ancestor JS? not sure) and the iframe case (probably > >> just not show error pages in frames?). Please let me know if I you > >> think I should file this and follow-up on it. > >> > >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305 > >> > >> Standard:
Re: Intent to implement and ship: Ignore navigation to unknown protocol
On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote: Doing a bit of digging, https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more interesting context... We apparently used to sync-throw when assigning location.href to an unknown protocol URI in the past, there we changed it to silently fail, and now it is navigating to an error page... I'll try to look at when behavior changed around here... Though the sync-throwing clearly makes no sense as it doesn't account for redirects or what not. Apparently the pre-firefox63 behavior was to both navigate and throw... So not all that much to dig in, that was just obviously wrong, but didn't address the fingerprinting angle other than patching one of the holes. On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote: Hey, a quick web-observable change that may deserve a bit more visibility / an intent. I'd welcome some feedback, specially from the fingerprinting / privacy angle (where I'm clearly not an expert). Summary: A page redirecting / navigating to an unknown protocol will be silently ignored (and logged to the DevTools console) instead of showing an error page. This is not amazing, but it's needed because it causes a bunch of compat issues (see the list of issues in the bug below). There are a few subtle problems here. Part of the issue is that authors don't have a cross-browser way of detecting whether a protocol will be handled externally (that is, whether an app is installed to handle a given protocol). They technically can in Firefox (see example below). It's unclear whether we want to expose more than that, or that at all. Given Chrome just ignores the navigation if they can't handle it, some authors (who don't seem to test on other browsers ;)) just spam the redirect (using various methods like the location href setter / meta refresh / whatevs). This works just fine in Chromium-based browsers, but not in Firefox or Safari, which will just show an error, which causes a very frustrating experience for users. As far as I know, this behavior doesn't really expose more information than we were exposing before. In a test-case like: we have different behavior also before this patch: the contentDocument for the handled-protocol iframe will be accessible to content, and be about:blank. The contentDocument for the unhandled protocol will be the error page, which will not be accessible to content and thus be null. Other browsers seem to do about:blank for both iframes, but you can also detect this in all browsers via window.open instead (there may be other ways around it too, haven't dug all that much). Chrome insta-closes the handled protocol window (so you can check window.closed). Firefox / Safari will leave about:blank in that window, and show an error document for the second (which will throw a security error on access). So I don't think this change introduces a new privacy hole. That being said, this all seems a bit sad, and a somewhat-serious potential fingerprinting factor. I was in fact a bit nervous about this change before realizing we were already exposing this information in other (even simpler to test) ways... But I'm clearly not an expert on this matter. There are mitigations possible both for the ignored-navigation case (maybe only ignore the navigation to an unknown protocol once per document or something, and only for browsing contexts that can't be accessed by any ancestor JS? not sure) and the iframe case (probably just not show error pages in frames?). Please let me know if I you think I should file this and follow-up on it. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305 Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme allows for both the old and new behavior, as far as I (and Anne) can tell. This uses urls after redirect and so on so beforeunload and such will fire. This matches the behavior of Chromium browsers. Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it a bit more). Devtools bug: N/A, ignored navigations get logged to the console. Other browsers: Chromium browsers do this, but WebKit doesn't seem to. This was causing compat issues, specially on Android, but also desktop (see above). web-platform-tests: Spec allows both behaviors, so I've added an internal test for now. Furthermore it's not clear if we want to do this for sub-windows, which my patch does, so I may need to tweak the test or add an internal switch depending on the outcome of the discussion here. Secure contexts: not restricted to secure contexts, this is a compat hack, of sorts... Is this feature enabled by default in sandboxed iframes? Not sure if the question quite applies to this, but we don't special-case sandboxed iframes here. This doesn't expose anything you couldn't do before, as discussed above. Thanks for reading all the way until here -- Emilio
Re: Intent to implement and ship: Ignore navigation to unknown protocol
Doing a bit of digging, https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more interesting context... We apparently used to sync-throw when assigning location.href to an unknown protocol URI in the past, there we changed it to silently fail, and now it is navigating to an error page... I'll try to look at when behavior changed around here... Though the sync-throwing clearly makes no sense as it doesn't account for redirects or what not. -- Emilio On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote: Hey, a quick web-observable change that may deserve a bit more visibility / an intent. I'd welcome some feedback, specially from the fingerprinting / privacy angle (where I'm clearly not an expert). Summary: A page redirecting / navigating to an unknown protocol will be silently ignored (and logged to the DevTools console) instead of showing an error page. This is not amazing, but it's needed because it causes a bunch of compat issues (see the list of issues in the bug below). There are a few subtle problems here. Part of the issue is that authors don't have a cross-browser way of detecting whether a protocol will be handled externally (that is, whether an app is installed to handle a given protocol). They technically can in Firefox (see example below). It's unclear whether we want to expose more than that, or that at all. Given Chrome just ignores the navigation if they can't handle it, some authors (who don't seem to test on other browsers ;)) just spam the redirect (using various methods like the location href setter / meta refresh / whatevs). This works just fine in Chromium-based browsers, but not in Firefox or Safari, which will just show an error, which causes a very frustrating experience for users. As far as I know, this behavior doesn't really expose more information than we were exposing before. In a test-case like: we have different behavior also before this patch: the contentDocument for the handled-protocol iframe will be accessible to content, and be about:blank. The contentDocument for the unhandled protocol will be the error page, which will not be accessible to content and thus be null. Other browsers seem to do about:blank for both iframes, but you can also detect this in all browsers via window.open instead (there may be other ways around it too, haven't dug all that much). Chrome insta-closes the handled protocol window (so you can check window.closed). Firefox / Safari will leave about:blank in that window, and show an error document for the second (which will throw a security error on access). So I don't think this change introduces a new privacy hole. That being said, this all seems a bit sad, and a somewhat-serious potential fingerprinting factor. I was in fact a bit nervous about this change before realizing we were already exposing this information in other (even simpler to test) ways... But I'm clearly not an expert on this matter. There are mitigations possible both for the ignored-navigation case (maybe only ignore the navigation to an unknown protocol once per document or something, and only for browsing contexts that can't be accessed by any ancestor JS? not sure) and the iframe case (probably just not show error pages in frames?). Please let me know if I you think I should file this and follow-up on it. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305 Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme allows for both the old and new behavior, as far as I (and Anne) can tell. This uses urls after redirect and so on so beforeunload and such will fire. This matches the behavior of Chromium browsers. Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it a bit more). Devtools bug: N/A, ignored navigations get logged to the console. Other browsers: Chromium browsers do this, but WebKit doesn't seem to. This was causing compat issues, specially on Android, but also desktop (see above). web-platform-tests: Spec allows both behaviors, so I've added an internal test for now. Furthermore it's not clear if we want to do this for sub-windows, which my patch does, so I may need to tweak the test or add an internal switch depending on the outcome of the discussion here. Secure contexts: not restricted to secure contexts, this is a compat hack, of sorts... Is this feature enabled by default in sandboxed iframes? Not sure if the question quite applies to this, but we don't special-case sandboxed iframes here. This doesn't expose anything you couldn't do before, as discussed above. Thanks for reading all the way until here -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: Ignore navigation to unknown protocol
Hey, a quick web-observable change that may deserve a bit more visibility / an intent. I'd welcome some feedback, specially from the fingerprinting / privacy angle (where I'm clearly not an expert). Summary: A page redirecting / navigating to an unknown protocol will be silently ignored (and logged to the DevTools console) instead of showing an error page. This is not amazing, but it's needed because it causes a bunch of compat issues (see the list of issues in the bug below). There are a few subtle problems here. Part of the issue is that authors don't have a cross-browser way of detecting whether a protocol will be handled externally (that is, whether an app is installed to handle a given protocol). They technically can in Firefox (see example below). It's unclear whether we want to expose more than that, or that at all. Given Chrome just ignores the navigation if they can't handle it, some authors (who don't seem to test on other browsers ;)) just spam the redirect (using various methods like the location href setter / meta refresh / whatevs). This works just fine in Chromium-based browsers, but not in Firefox or Safari, which will just show an error, which causes a very frustrating experience for users. As far as I know, this behavior doesn't really expose more information than we were exposing before. In a test-case like: we have different behavior also before this patch: the contentDocument for the handled-protocol iframe will be accessible to content, and be about:blank. The contentDocument for the unhandled protocol will be the error page, which will not be accessible to content and thus be null. Other browsers seem to do about:blank for both iframes, but you can also detect this in all browsers via window.open instead (there may be other ways around it too, haven't dug all that much). Chrome insta-closes the handled protocol window (so you can check window.closed). Firefox / Safari will leave about:blank in that window, and show an error document for the second (which will throw a security error on access). So I don't think this change introduces a new privacy hole. That being said, this all seems a bit sad, and a somewhat-serious potential fingerprinting factor. I was in fact a bit nervous about this change before realizing we were already exposing this information in other (even simpler to test) ways... But I'm clearly not an expert on this matter. There are mitigations possible both for the ignored-navigation case (maybe only ignore the navigation to an unknown protocol once per document or something, and only for browsing contexts that can't be accessed by any ancestor JS? not sure) and the iframe case (probably just not show error pages in frames?). Please let me know if I you think I should file this and follow-up on it. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305 Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme allows for both the old and new behavior, as far as I (and Anne) can tell. This uses urls after redirect and so on so beforeunload and such will fire. This matches the behavior of Chromium browsers. Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it a bit more). Devtools bug: N/A, ignored navigations get logged to the console. Other browsers: Chromium browsers do this, but WebKit doesn't seem to. This was causing compat issues, specially on Android, but also desktop (see above). web-platform-tests: Spec allows both behaviors, so I've added an internal test for now. Furthermore it's not clear if we want to do this for sub-windows, which my patch does, so I may need to tweak the test or add an internal switch depending on the outcome of the discussion here. Secure contexts: not restricted to secure contexts, this is a compat hack, of sorts... Is this feature enabled by default in sandboxed iframes? Not sure if the question quite applies to this, but we don't special-case sandboxed iframes here. This doesn't expose anything you couldn't do before, as discussed above. Thanks for reading all the way until here -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
