31–40 of 48 posts
There’s also a disown-opener CSP directive that’s hopefully going to be implemented at some point. Should help take care of this.
Earlier quoted context omitted.
Internet Explorer tried to maintain multiple rendering engines. Every version from IE5 to IE11 (if you open the debug console you can switch rendering modes) And now they have Edge. It never took off. I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.
this is why I say it would have to be opt-in through something like a header or tag on the page in question (although I don't think doctype would work well for this). Existing sites would use the current engine and sites that explicitly stated they were for the new engine would be handled differently.
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...
That page says the opposite of what you just said.
But in the real world most websites don't do this. What likely matters to the user is that the page they're navigating to opens faster; the user likely doesn't care about the performance of the hidden tab they just came from.
Of course, `noopener` has security and privacy benefits which may outweigh the performance costs (if there are any).
Earlier quoted context omitted.
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…
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
Version # is not the phrase you want to overload. HTML5 is the latest version and was released 4 years ago.
I think this is an older article?* Any updates on support? * I also don't understand how this is being served. If you go to https://github.com/mathiasbynens there should be a repository called mathiasbynens.github.io right? But I can't find it.
Earlier quoted context omitted.
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…
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
Earlier quoted context omitted.
Internet Explorer tried to maintain multiple rendering engines. Every version from IE5 to IE11 (if you open the debug console you can switch rendering modes) And now they have Edge. It never took off. I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.
this is why I say it would have to be opt-in through something like a header or tag on the page in question (although I don't think doctype would work well for this). Existing sites would use the current engine and sites that explicitly stated they were for the new engine would be handled differently.
https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).a...
Earlier quoted context omitted.
But have you truly internalized it?
I still use rel="noopener noreferrer" on _blank links, but it's less of an issue than it was when first reported.
I've seen this article (OP) a few times already, and it keeps reminding me to add rel="noopener noreferrer" on whatever site/system I'm working with at the time. In fact I just did that yesterday when I saw this article, to set up a way to automatically add it for external links, in my current dev workflow.
Earlier quoted context omitted.
I still use rel="noopener noreferrer" on _blank links, but it's less of an issue than it was when first reported.
Could you elaborate on how it's less on an issue than before? Have browsers implemented some security strategies since the article was published? I've seen this article (OP) a few times already, and it keeps reminding me to add rel="noopener noreferrer" on whatever site/system I'm working with at the time. In fact I just did that yesterday when I saw this article, to set up a way to automatically add it for external…