- From: Anne van Kesteren <notifications@github.com>
- Date: Wed, 28 Aug 2019 04:18:00 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 28 August 2019 11:18:22 UTC
As was a problem with CSP, I'm worried with trying to address this problem based on callsites, rather than the more fundamental algorithms that are responsible for performing a certain action that we want to avoid exposing to non-privileged code. That is, I think a more principled model would modify "navigate" to take a "trusted" value and based on some policy error on non-"trusted" values, and then adapt callsites as appropriate to be able to pass it "trusted" values. (I'm also a little worried that the current approach leaves certain attack vectors unexplored. Are malicious `target` values problematic? Is changing `<form method>` not problematic? I.e., should all parameters to "navigate" effectively be "trusted" values? Why only the URLs? (Also, `window.location` is protected, but MathML links are not? With a system that protects navigation (and similar such algorithms) at source, you don't really have to worry about this, at least not until someone wants to use MathML links with it.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/198#issuecomment-525699658
Received on Wednesday, 28 August 2019 11:18:22 UTC