Require a user gesture for a cross-origin frame to navigate the top-level page

[ojanvafai]

We are seeing a lot of ads that navigate the top-level page outside of a user gesture. We think this is user hostile and that we don't lose any important use cases by requiring a user gesture. Chrome has added formal measurement for this. Once we get the numbers back, we plan to make this change.

There is also the allow-top-navigation flag for iframe sandbox attribute. Once we make this change the plan is that sandbox disallows top navigation and allow-top-navigation allows the behavior described above (i.e. even with allow-top-navigation, you'd still need a user gesture to navigate the top-level page).

[MattMenke2]

Any consideration of doing this for modal dialogs as well? When I saw the email about not opening "popups" except in response to a user gesture, was excited about this because I thought it included blocking that particular behavior as well. A lot of abusive pages use OnBeforeUnload dialogs, which are just annoying.

[mikewest]

blink-dev thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Xi8-y4ySjA4/dc4BFfqyBQAJ

/cc @annevk @rlbmoz @johnwilander @travisleithead

[hillbrad]

:( This breaks a thing I'm working on. I'm trying to expose a cross-origin API in an iframe via postMessage. The parent frame uses postMessage to request a service from the iframe. If the request can be fulfilled without user confirmation, the iframe navigates the parent to a "success" page specified by the caller. Otherwise it makes a POST that navigates the parent frame to a confirmation page, which takes the user back to the specified "success" page after the user gesture.

I like the iframe top navigation pattern for a couple of reasons.

Compare it to the traditional workflow for doing this (as with OAuth) which requires POSTing directly to the cross-origin resource or opening a popup:

• If user consent isn't required the user is taken directly to the "success" page without incurring a synchronous additional round-trip and redirect in the top frame, giving better perceived performance, responsiveness and less drop-off.
• Popups suck and are frequently blocked.

The parent could implement another listener for a postMessage reply and do the navigation itself, but that makes using this kind of API more complicated, and it is nice to be able to do the POST from the iframe and include, e.g. a CSRF token and trustworthy indication of the parent origin that triggered the request.

A click to the iframe doesn't make sense; it takes away control over the UX that the parent wants.

Since a page that doesn't want this behavior from an iframe already has the ability to block top-navigation with the sandbox attribute, I'm not sure why we need to break this behavior by default?

Could we count receiving a postMessage from the parent as enabling navigation? (in addition to a user gesture)

[ramanathanrv]

For payments security, we collect sensitive card information within an embedded iFrame. A lot of our clients depend on our iFrame for this. Once the card information is collected in the iFrame, the user is then navigated (by changing window.top) to a page in our domain for authentication of the card information. This proposed change will break our flow permanently.

If allow-top-navigation is mentioned in the <iframe> tag, then the parent window has provided the consent. Can I request that the control to navigate top window be granted when the top window has given that permission?

[manki]

This is breaking sign-in flow for CapitalOne (https://servicing.capitalone.com/c1/Login.aspx). I see the following message in console:

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://servicing.capitalone.com/c1/Login.aspx' from frame with URL 'https://login2.capitalone.com/loginweb/login/postLogin.do'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

I presume Capital One will have to fix their site, and Chrome is working as intended?

[ghost]

We received user reports that this is breaking users of the Facebook SDK. https://developers.facebook.com/docs/games/gamesonfacebook/login explicitly encourages use of top level navigation.

[ojanvafai]

@reginaldos thanks for the report. Can you point us to an example page? We considering changing behavior here and being able to verify the new idea works would be helpful. It's hard for me to follow in that SDK documentation where top-level navigation is used.

[jontonsoup]

@ojanvafai this also seems to break typeform redirection

[loganrosen]

This broke eBay checkout flow for me. It hung after adding a credit card in PayPal, and an error in the console pointed me to this new Chrome feature.

In the console:

main.js:21966 Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://mbuy.ebay.com/xo?action=view&sessionid=(redacted)&redirect=mobile' from frame with URL 'https://www.paypal.com/webapps/helios?action=addCard&payer_id=(redacted)…hod%3DPAYPAL%26redirect%3Dmobile#/checkout/pageAddCard/addCardFlow/addCard'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.

findWindowAndRedirect @ main.js:21966

[Krinkle]

This seems to break the ability to log in on My3 (https://www.three.co.uk/My3Account/Login) in Chrome 56.0.2885.0 canary.

Error:

• Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://www.three.co.uk/My3Account/Login' from frame with URL 'https://sso.three.co.uk/mylogin/?service=https%3A%2F%2Fwww.three.co.uk%2FTh…&resource=portlet'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture. See https://www.chromestatus.com/features/5851021045661696.
• Uncaught DOMException: Failed to set the 'href' property on 'Location': The current window does not have permission to navigate the target frame to 'https://www.three.co.uk/ThreePortal/appmanager/Three/SelfcareUk?…'.

After submitting log-in credentials, the user stays on a (now partially blank) login page instead proceeding to the My3 home page.

It still works in Chrome 53.0.2785.143 stable.

[natechapin]

I just reenabled this experiment in Chrome 56+ builds (should be on the chrome canary in a day or two) with a few changes to try to make it less breaking:

• Instead of requiring a current user gesture, a cross-origin iframe can navigation top if it has ever received a user gesture.
• When setting the bit that indicates whether a given browsing context has received a user gesture, it is also set on all of that browsing context's ancestors.

[hillbrad]

I still think that the parent frame sending a postMessage should also
"activate" the iframe, or there needs to be a way to explicitly allow a
child frame to top-nav so without a user gesture. This is an important
cross-origin API surface. Iframes are not just ads.

On Wed, Oct 26, 2016 at 12:25 PM natechapin [email protected]
wrote:

I just reenabled this experiment in Chrome 56+ builds (should be on the
chrome canary in a day or two) with a few changes to try to make it less
breaking:

• Instead of requiring a current user gesture, a cross-origin iframe
  can navigation top if it has ever received a user gesture.
• When setting the bit that indicates whether a given browsing context
  has received a user gesture, it is also set on all of that browsing
  context's ancestors.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcAuXVIvL28tXEv6TmKkWFK9WGncOks5q36kXgaJpZM4IN2IH
.

[ojanvafai]

@hillbrad is it possible for your case to postMessage back to the parent page to do the navigation?

Having postMessage auto-grant this ability would take all the value out of this proposal since postMessage is so widely used.

Maybe we should consider adding a permission that we can delegate down via feature policy (e.g. via an enable attribute on the iframe) to allow the top-level page to say the iframe can navigate it without a user gesture. @hillbrad would that work for your use case?

[hillbrad]

@ojanvafai an explicit opt-in or callback could work, but there are 7 independent bug reports here, which seems to indicate reasonably wide legitimate use.

What does the data look like on the prevalence of legitimate vs. user-hostile occurrences?

[ojanvafai]

@hillbrad these bug reports were on the less permissive version that required a user gesture for the navigation instead of any user gesture during the life of the frame. It's hard to test all of these because most of them don't link to pages, but I confirmed that the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at scale. If we could distinguish the two reliably, we'd do a different intervention. :)

If we get reports of real content that breaks with this more permissive solution, we'll need to reconsider.

[hillbrad]

It seems that any use of hidden frames as an API surface that includes
automatic navigation will still break under the new approach because they
have no way to collect a user gesture? So I think there should be a way to
designate a frame at creation as capable of top navigating, or to decorate
a postMessage so it delegates a capability equivalent to a user gesture,
before intervening and requiring a larger redesign of these existing uses.
Setting up an event listener, parsing and navigating in response to a reply
message is not terribly difficult, but it is much more complicated than a
simple fire-and-forget postMessage.

On Tue, Nov 1, 2016 at 8:07 AM ojan [email protected] wrote:

@hillbrad https://github.com/hillbrad these bug reports were on the
less permissive version that required a user gesture for the navigation
instead of any user gesture during the life of the frame. It's hard to test
all of these because most of them don't link to pages, but I confirmed that
the capitalone case does get a user gesture today.

It's very hard to get data on prevalence of legitimate vs. user-hostile at
scale. If we could distinguish the two reliably, we'd do a different
intervention. :)

If we get reports of real content that breaks with this more permissive
solution, we'll need to reconsider.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcErrIcZj7CJk4PmxONoJp3niR9dyks5q51W9gaJpZM4IN2IH
.

[ojanvafai]

I think a way to delegate top navigation to subframes is reasonable. It would probably build on top of feature policy: https://wicg.github.io/feature-policy/. When we ship feature policy, I don't see any downside to adding the ability to delegate down the ability to do top-navigation without a gesture. But, I'm hesitant to block shipping this until then due to:

1. The large user benefit this has.
2. (so far) no complaints of real-world web sites breaking.
3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens during a user-gesture grant the messaged-frame the ability to top-navigate since we pass the user gesture bit with the postMessage already (e.g. the inner frame's message handler can open popups, etc). That'd probably be good for keeping the platform simple and consistent. But, I think that doesn't actually address your need @hillbrad, right?

[hillbrad]

If you can track a user gesture in a parent frame leading to an postMessage
to the child frame and carry the user intent flags through, that should
work for my specific use cases. But it would definitely be nice to have
something deterministic to set so every postMessage API documentation
doesn't need an extra page of explanation about this behavior.

On Tue, Nov 1, 2016 at 11:33 AM ojan [email protected] wrote:

I think a way to delegate top navigation to subframes is reasonable. It
would probably build on top of feature policy:
https://wicg.github.io/feature-policy/. When we ship feature policy, I
don't see any downside to adding the ability to delegate down the ability
to do top-navigation without a gesture. But, I'm hesitant to block shipping
this until then due to:

1. The large user benefit this has.
2. (so far) no complaints of real-world web sites breaking.
3. The restriction can be worked around via a postMessage to the parent.

I do think we might want to explore having a postMessage that happens
during a user-gesture grant the messaged-frame the ability to top-navigate
since we pass the user gesture bit with the postMessage already (e.g. the
inner frame's message handler can open popups, etc). That'd probably be
good for keeping the platform simple and consistent. But, I think that
doesn't actually address your need @hillbrad https://github.com/hillbrad,
right?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFbcA9bW9ghj0R0rZqmkdkr06UgsBH3ks5q54YRgaJpZM4IN2IH
.

[marcuscraske]

I'm seeing this in Chrome 56 (dev release), but not for post message. Does anyone know if this will definitely ship on January 31st? I am not familiar with the Chromium release cycle, and whether dates are strictly followed.

[ojanvafai]

@limpygnome the dates aren't strictly followed, but it should ship on January 31st give or take a week. Is this breaking a page for you?

[jitdasrjs]

In our facebook application we can not redirect pages using top.location.href any more in chrome v56 beta.
It worked fine in previous version.Now javascript error is coming-The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor is it processing a user gesture.

[tonygaillard]

https://apps.facebook.com/candycrush is broken on first install
https://apps.facebook.com/candycrushsoda is broken on first install
https://apps.facebook.com/livepool/ is broken on first install

[uofifox]

I have several applications that I work with that will be broken with this new feature. We have requirements for us to send users out to external websites and redirections. Why would you block an internal application from making decisions about where it should go?

In software if you don't provide a way for either a sub-element to communicate with the parent to help make informed decisions, or allow the child element to make a decision, you're in essence making the child restricted to basically a small task. There are many situations where the child is better suited to make decisions related to the situation it is being used and is basic to decomposing systems. Almost like inheritance, and saying the inherited element is allowed to only do a couple of things, but you can't add functionality.

Also note that many systems have clearly been built using iframes as modular breakdowns. Hopefully this feature will be augmented or an api will be added allowing the child frame to communicate with the parent otherwise I forsee chrome being an issue for many users moving forward.

[domenic]

an api will be added allowing the child frame to communicate with the parent

This sounds like the already-existing postMessage API

[uofifox]

Valid point, looks like the postMesage API could be used to accomplish the issue. Of course means the parent frame would need to add a listener to the events. Thank you for the reference.

[ojanvafai]

@tonygaillard this looks like a separate bug. Those apps are broken with this change disabled as well. Filed crbug.com/674229 to track that.

@uofifox sounds like your issue is resolved?

[uofifox]

Well I would prefer the feature not get implemented as opposed to saying my issue is resolved. In my case it's great there is a workaround but as I don't have control over the main frame it means we have to ask for feature enhancements which take time to implement

[aels]

@chrcoluk, yes, all "Default" state flags can be toggled to "On" by chrome/google guys at any time.

[mexhanic]

@ojanvafai
@lubin2010
You want to hit all rabbits with one bullet, but what about granular solution?
We have one thing, that brokes - oAuth, and one thing that must be stoped - ads framebusting.

So, lets assume we whitelist of (for example) "top Alexa 1k" domains, which allowed to bust-out their cross-domain top's. But let them still throw console warning from frame page, to notice developers.

If our frame is not in whitelist, let assume following algo when frame page try to bust-out (and cross-domain, and no gesture given):

• issue a warning to console from frame page (no notice frame-page developers)
• show access-request dialog on top page (like camera access request)
• issue a warning to console from top page (with url of frame-initiator), to allow in-page reporters to log, that someone wants to redirect us.
• if "granted", then pause redirection for 2 seconds and issue a warning from top page, to allow of logging this redirection. Then redirect.
• if "declined", then throw error to frame page, and issue warning to top page, to allow top-page developers to log incident.

Mechanism of "warnings" is on your own. But I think it will be good to include not only frame url, but urls of all frames in chain, in case of nested frames.
That raises second problem - possible leakage of any secure tokens inside intermediate urls to the top-page. But that needs additional research.

[mexhanic]

And second idea.
Mostly all of ad-frames have specific size (like 300x250), when oAuth-frames haven't.
So, if any of frames in chain from redirect-initiator to top page have ad-like size, then block.

[lubin2010]

We've reverted the change in Chrome 57, and are rethinking how to go forward with this, and will keep you updated once there is more to share. Thanks all for the feedback!

[oniric85]

Today I saw the warning the first time on my Chrome Console. We have a login system based on OAuth that automatically redirects to a success page by changing top navigation from inside the iframe. This breaks now that I activated the flag in Chrome flags as it does not require any user gesture on certain condition to increase responsiveness and performances.

Is this moving forward? Is there any way to whitelist the behavior from the top page?

[lubin2010]

Adding @ojanvafai to comment on the status of this.

[oniric85]

Any news? We could really make use of some rough timings as to adapt to this change as we would need to plan work on several systems that currently rely on this feature, probably switching to postMessage.

[tomloake]

I noticed some of the work to unblock this has happened recently (main frame navigation consumes a user gesture) has started to move forwards - do we have any updates on this status of this bug now?

[MrStonedOne]

This issue is, (and will always be) detection.

A script (be it a good faith one like sso/oauth, or a bad faith one like ads) that fails to meet the criteria will have no way of knowing before hand, and will have its entire frame errored out, leaving no way to recover from the error or fallback to a gesture request.

[lubin2010]

It was announced that in Chrome 64 (To be the stable version in around late Jan, 2018), all redirects originating from third-party iframes will show an infobar instead of redirecting, unless the user had been interacting with that frame.

+@rschoen to answer questions if there are any.

[MrStonedOne]

Is there a way to determine, at the script level, if a topframe redirect would lead to an infobar.

Also how does the blocking chain on that work? would the location set block while the infobar is up, what happens if it is denied, does the frame error out (like it did before) or does the code continue on as normal?

I have to use this in an oauth flow that involves in game prompts because of the way the game engine presents these things to users and the fact the devs refuse to create a native oauth way to authenticate users. I can present them with a button, but the system works best if it can auth them in the background during the loading and redirect them once both complete.

[chrisbro-MSFT]

@lubin2010 @rschoen, the announcement does not describe how the allow-top-navigation and allow-top-navigation-by-user-activation flags are impacted with this current change, and the announcement does not explain how a site can opt-in to actionless navigation in a particular iframe. Could you please clarify?

[Mehul24]

Restrict this ability to content that is processing a user gesture, unless it is same-origin to the parent.

Can an iframe(on a different domain) not change the top location even though its changing the domain to the same domain as the parent(top) domain? The wording is not very clear here 'same-origin to the parent', does that mean the iframe needs to be the same origin as the parent or it can only redirect to the same origin as the parent?

Example -
Window = DomainA.X
Iframe = DomainB.y
Iframe changes window = DomainA.Z without any user gesture.

[mayoque]

I am a little bit confused about current behavior and I am not sure it was really intended to work this way.
At this time (v69) cross-origin redirection within top window still works even without user gesture once iframe is sandboxed with "allow-top-navigation allow-same-origin".
However it does not work when iframe is defined without sandbox attribute.
Is there some intention to make it work ONLY in sandboxed iframe with explicit permissions?
Is it OK it doesn't work in iframe without restrictions - without sandbox attribute?

[veganchamp]

Since we took the auto update to Chrome from 74.0.3729.169 to 75.0.3770.100 our iframe based payment process no longer works. The iframe (on a different domain) has JS which posts a form to target _top and this used to work. Now we get JS error "Unsafe JavaScript attempt to initiate navigation for frame with URL...", I've managed to fix with explicit sandbox="//every allow option//" attr on the iframe, but can't explain why we're only getting this in v75?

[natechapin]

antbewes@. I'm a little surprised that this used to work...

My best guess for why this changed: in Chrome 74->75, I did a bunch of cleanup around targeting windows by name. Among other things, I fixed some bugs where instead of blocking a navigation that targeted a disallowed window, Chrome would instead navigate the wrong window. Is there any possibility that, in Chrome 74, that navigation was executed in the iframe that posted the form, rather than in _top? Skimming through the logic as it stood in 74.0.3729.169, it's quite possible that this case was ending up in the wrong window, where we had intended for it to be blocked.

Regarding the workaround: if any sandbox options besides "allow-top-navigation" are necessary to get this to work, I'd be interested in knowing which ones to make sure there aren't any lingering bugs here.

[veganchamp]

@natechapin Thanks for responding.
I'm not able to only set "allow-top-navigation" because our iframe needs to "allow-scripts" and "allow-forms" at least to function before it posts its form to target="_top". Because this worked without any sandbox attr pre v75, I took that to mean that if I now have to add a sandbox option then all should be added to preserve the permissioning. Strange though that Chrome 75 should treat iframe with no sandbox attr differently to iframe with all sandbox attr options.

[natechapin]

@antbewes yeah, there's some historical quirks in Chrome's navigation logic around sandbox with allow-top-navigation specifically. It's on my backlog... :/

[ShashankM3-hexaware]

The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor has it received a user gesture.
I'am facing above mentioned error when I try to get a fresh token from a Microsoft account using MSAL angular package.

[MiguelQueiroz]

Our Stripe payment iframe no longer works, the redirect is no longer happening, blank page :(

[jessejacob]

I have a stripe integration with wordpress that is failing because of this. I'm using postMessage to trigger form submission in a child shopping cart iframe and I get blocked by "Unsafe JavaScript attempt to initiate navigation for frame with origin 'https://a.com' from frame with URL 'https://b.com'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor has it received a user gesture. See https://www.chromestatus.com/features/5851021045661696."
I was expecting postMessage to work after reading some of the discussion above from years back. I also tried sandboxing the child iframe with allow-top-navigation (and then everything) and that didn't work either (same Chrome block). I'm also not seeing the discussed support for either a click that results in a postMessage from parent-to-iframe as a valid user gesture for top navigation from iframe, or an "allow" attribute for iframes to implement a specific permissions policy for top-level navigation. sandbox="allow-top-navigation" basically seems broken at the moment and there is no way around it. Super frustrating.

[annevk]

Are there plans to standardize this in the HTML Standard?

[Fjan]

Since Chrome version 102 it appears a redirect inside an iframe resets the awareness of previous user gestures in that frame. This means another user gesture is needed before a script can escape from the frame. This broke our app which performed a simple top.location.href = location.href on a new page after the user submitted a form.

Mainly putting this out here to help other people running into it to figure out what's going on, but it would be nice if we could use something like allow="top-navigation: *" instead of having to put more onclick handlers in our code.

[adamlavery]

Chrome/Edge v102 has broken PayPal hosted payments. This is a major issue. Hosted payments loads a Pay with PayPal button and card payment form:

Since Chrome/Edge v102 clicking Pay with PayPal is blocked.

If clicking the button to go to PayPal is not a user gesture then what is?

The only way I have found to fix this is to sandbox the iframe, but then that breaks card payments. Even with all sandbox restrictions disabled, 3DS processing fails. So we cannot use sandboxed iframes.

Clearly latest Chromium user gesture detection is flawed - how can clicking a button in an iframe not be a user gesture?

Please reverse this change soonest until you can come up with something that works properly.

[domenic]

With regard to the original proposal here, the route we went down was to only introduce this restriction to sandbox iframes, and it can be turned off via a variety of flags, such as allow-top-navigation or allow-top-navigation-by-user-activation. Those cases are specified in https://html.spec.whatwg.org/#allowed-to-navigate and this is fully cross-browser behavior by now.

In all cases, this is a choice by the embedding website; if the embedding website wants to allow navigation of the top-level page, it can easily do so, either by not using sandbox="", or by using those flags to reenable the functionality after using sandbox. So, if you are encountering this issue, a solution is to change your embedding website's sandboxing strategy.

However, it appears this issue is attracting a lot of comments unrelated to the original proposal. Basically, any time some part of the web platform causes a navigation failure, people are posting here. Even if it has nothing to do with the sandboxing restriction that was implemented. For example, it seems per https://chromestatus.com/feature/5851021045661696 Chrome might have implemented something in Chrome 68 which goes beyond the spec. But, some people in this thread are reporting that it's new as of Chrome 102, so, maybe it's not that at all, and is some other Chrome bug. Or maybe something changed in PayPal's code, around the same time Chrome/Edge 102 were released.

Discussing such issues in this thread is not helpful. If you are encountering an issue with your website in a given browser, where it worked in a previous version or works in other browser engines, you should post on the browser's issue tracker. For Chromium, that is https://crbug.com/.

Since we are generally shutting down this repository (see #72), I'll close this issue. Please feel free to have browser-specific discussions on browser-specific issue trackers.