41–48 of 48 posts
There's a Firefox extension to add the rel=noopener attribute to all links (except ones to the same domain): https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my...
Earlier quoted context omitted.
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.
How about a Babel-like transpiler, that would take HTML written in this newly proposed standard and outputs backward-compatible code? For example, adding rel="noopener" by default to external links.
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...
There's a Firefox extension to add the rel=noopener attribute to all links (except ones to the same domain): https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my...
Here's one for Chrome: https://chrome.google.com/webstore/detail/no-opener-no-phish...
Earlier quoted context omitted.
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…
I'm going off of the tickets linked in the footer of the article, which seem to show they're being resolved.
Earlier quoted context omitted.
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.
> in semantic versioning terms, we need a "2.x" of the HTML API. Version # is not the phrase you want to overload. HTML5 is the latest version and was released 4 years ago.
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…
> 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? That does nothing for deployed sites that aren't actively developed? Browser devs have decided those sites are worth not breaking.
If browsers enforce HTTPS in a similar way, I don't see why they shouldn't enforce better security elsewhere as well.