21–30 of 48 posts
My totally unmeasured hunch is that there is a downside to using noopener: it could make the new page that is being opened take slightly longer, since it now needs to spool up another process/thread/sandbox/whatever instead of piggy backing off the existing page's. More about the performance "benefit" here: https://jakearchibald.com/2016/performance-benefits-of-rel-n...
Earlier quoted context omitted.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
Seems like the simple solution would be for those apps to include something like “rel= yes opener” on the link to the payment provider, as a way to explicitly opt into the functionality. Browsers deprecate security related features all the time. See SSL, HSTS [EDIT: HPKP*], etc. At the very least, browsers could remain backward compatible but mark the URI as “Insecure” in the address bar if the link could result in t…
HSTS is what tells the browser "this website MUST be served over TLS".
HPKP is what tells the browser "this website must be served over TLS with this exact key".
HPKP is being deprecated due to the large "footgun" it creates for websites, and the difficulty at actually managing it. It's being replaced by "Expect-CT" which is a much easier and safer way of getting a similar result.
Earlier quoted context omitted.
Seems like the simple solution would be for those apps to include something like “rel= yes opener” on the link to the payment provider, as a way to explicitly opt into the functionality. Browsers deprecate security related features all the time. See SSL, HSTS [EDIT: HPKP*], etc. At the very least, browsers could remain backward compatible but mark the URI as “Insecure” in the address bar if the link could result in t…
HSTS is not deprecated, HPKP is. HSTS is what tells the browser "this website MUST be served over TLS". HPKP is what tells the browser "this website must be served over TLS with this exact key". HPKP is being deprecated due to the large "footgun" it creates for websites, and the difficulty at actually managing it. It's being replaced by "Expect-CT" which is a much easier and safer way of getting a similar result.
Expect-CT is very different, I'm not sure "similar result" is the right phrase. HPKP lets you pin to any set of keys, a reasonable choice might be your current key, a spare key that your DevOps have ready to go, and one more that's printed out on a piece of paper in the company safe labelled "important: Web site private key, never lose this".
Expect-CT is like Python's from future import, in the future we expect the Web PKI to use Certificate Transparency logging policy to ensure oversight over all CAs. Expect-CT lets you demand enforcement of such policy today, to the extent that's possible. Today policy is still in a state of flux, so enforcing it might not do what you expect, whereas HPKP was very predictable. On the other hand, it's definitely not subject to hostage taking, and it's probably less susceptible to footguns, so that's nice. And if the future does come to pass as expected it's future proof, since such a policy will become de facto the normal behaviour of common user agents.
[Edited to make more sense]
Earlier quoted context omitted.
HTML 2.0 was published in 1995. I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment. More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener
I'm aware of that - the existing HTML versions have been pretty much incremental though. XHTML was a breaking change but more for syntactical reasons. By a "2.x" version I mean a fresh rewrite with no requirements for parity with previous versions, so the lessons of the current engine can be applied in a clean-slate environment.
Why has this post been flagged?
Earlier quoted context omitted.
I'm aware of that - the existing HTML versions have been pretty much incremental though. XHTML was a breaking change but more for syntactical reasons. By a "2.x" version I mean a fresh rewrite with no requirements for parity with previous versions, so the lessons of the current engine can be applied in a clean-slate environment.
i feel like there must be an xkcd that sums up your suggestion...
Or mobile: https://m.xkcd.com/927/
Earlier quoted context omitted.
i feel like there must be an xkcd that sums up your suggestion...
https://xkcd.com/927/ Or mobile: https://m.xkcd.com/927/
Earlier quoted context omitted.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…
That does nothing for deployed sites that aren't actively developed? Browser devs have decided those sites are worth not breaking.