Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About rel=noopener

mathiasbynens.github.io

Post reply on HN
Print view View original

101–110 of 115 posts

Re: About rel=noopener

#101

Post by happyslobro »

gorhill wrote: post #89
happyslobro wrote: post #71

Earlier quoted context omitted.

So that's what's happening! With uBlock, all I see is a flicker on the browser's tab bar, and my history is gone. It's still annoyingly retarded.

I did try to provide a fix for the history-lost case for when a popunder is blocked, but in the end I had to give up because there was no way to make it work reliably (using current extensions API). [1] https://github.com/gorhill/uBlock/issues/1028

Ha, no worries, I wouldn't have expected an ad blocker to know that for me, the dead tab and this new tab are semantically one. I'm just glad that the bad tab is dead. It's the ad that I was calling retarded :p

Awesome work btw, it runs like greased lightning in FF nightly.

Re: About rel=noopener

#102

Post by mort96 »

colejohnson66 wrote: post #33
kalmi10 wrote: post #9

Earlier quoted context omitted.

To some extent.. Yes. The attacker can replace the current page with his own phising page. Of course, the hostname part of the url would change, but the user is unlikely to notice that.

Case in point: People still fall for things like `facebook.com.totallynotaphishingsite.com'

It's a huge difference between clicking on a random facebook.com.totallynotphishing.com link, and being on the legitimate facebook.com and having that tab automatically go to a phishing site while you're not looking.

Re: About rel=noopener

#103

Post by pdkl95 »

Strom wrote: post #93
pdkl95 wrote: post #83

Earlier quoted context omitted.

If your website breaks without Javascript, then it's the website's fault for not properly implementing progressive enhancement. Javascript is useful to enhance the page with better features, but the page itself should work without it. If you tools/framework make this hard or generate output that incompatible with progressive enhancement, then I suggest you find (or write) better tools.

I do wonder for how many sites does this actually make sense to do. Take the number of users who use NoScript and are not willing to turn it off when the site doesn't work without JS, and then take the subset from those who would actually be willing to pay for using the website. [1] Do these niche users really generate enough revenue to pay for the toolchain & work culture changes necessary to have this progressive e…

> makes sense to do

Do you use the pointer that fopen(3) returns without checking for NULL? Progressive enhancement is mainly error checking and handing failures gracefully.

> not willing to turn it off when the site doesn't work without JS

Why are you willing to make your business look shoddy and unprofessional? Running without javascript has always been an option, and always will be. Anyone that doesn't run the javascript obviously isn't expecting fancy features, but you should still show any text/images (or a basic form if that is relevant), probably along a suggestion that turning on javascript will probably improve their experience.

> changes necessary to have this progressive enhancement

That's the point - this shouldn't cost a lot, unless your tools are unusually braindead. Rails made progressive enhancement almost entirely transparent a long time ago. I believe there are several prerender-the-first-load plugins for several popular frameworks. If your tools aren't doing this for you (either automagically or otherwise), then those tools are missing important features.

> work culture changes

It is probably a good idea to pay any technical debt sooner, instead of tying even more projects to bad tools.

> users who use NoScript

NoScript users are NOT[1] the only group that will see your pages without Javascript. You don't control the client, which will always be unreliable.

Also, progressive enhancement isn't a boolean value; you should be checking for the availability of any feature you use. This may result in only partial support, which is probably better than no support (or a javascript error) if someone loads your page in an old browser or something unusual. The web is inherently a fluid environment, which makes defensive programming even more important.

> direct financial sense

What is the direct financial impact of showing people a broken website? Do you even analyze the server logs to find out how many people are impacted?

[1] http://kryogenix.org/code/browser/everyonehasjs.html

Re: About rel=noopener

#106

Post by bzbarsky »

homakov wrote: post #105
bzbarsky wrote: post #98

Earlier quoted context omitted.

Right, but now you have 20 years worth of content which depends on the current behavior....

On this particular behavior unlikely

What makes you think this is unlikely? On the contrary, I think it's _very_ likely there are things depending on it. I don't expect there to be a huge number of them, but I also expect them to disproportionately be in things like intranet deployments where it's hard to even get measurements. :(

Re: About rel=noopener

#107

Post by stormbrew »

bzbarsky wrote: post #97
stormbrew wrote: post #95

Earlier quoted context omitted.

I don't really see the problem with making this asymmetrical. The security implications of a frame navigating its parent and a parent navigating its child frame seem very clearly different to my mind. If you're suggesting it would be technically difficult, I'm extremely skeptical of that. The origin's relationship to the target frame should not be impossible to discern, and I'd be a little shocked if it isn't taken i…

The problem with making it asymmetrical is that in the case of two toplevel tabs (as opposed to frame and child) determining who's the "parent" and who's the "child" is a lot more complicated. > If you're suggesting it would be technically difficult, I'm extremely skeptical of that. I think it's technically difficult to establish parent/child relationships between toplevel windows, given opener disowning and so forth…

If that relationship weren't clear you wouldn't have a window.opener attribute to begin with.

That said, I'm also skeptical of legitimate uses for controlling the location of another top level window as well, so I'm fine with killing that option too.

Of course, I don't expect them to actually fix this, but I'm still waiting for a convincing argument that it should have been that way in the first place.

Re: About rel=noopener

#108

Post by Grom_PE »

Some time ago I was surprised that my Google Search page was replaced by something else after I returned from some spammy page (opened in another tab).

As the browser I use, Opera 12, also treats all links manually opened in the new tab as if they had target="_blank", giving them opener access, I decided to remove the window.opener altogether by replacing the "opener" string with "opera" in the opera.dll. This way it gets overwritten by the normal window.opera variable and is essentially hidden. So far I haven't encountered a site legitimately relying on this behavior.

Re: About rel=noopener

#109

Post by homakov »

bzbarsky wrote: post #106
homakov wrote: post #105

Earlier quoted context omitted.

On this particular behavior unlikely

What makes you think this is unlikely? On the contrary, I think it's _very_ likely there are things depending on it. I don't expect there to be a huge number of them, but I also expect them to disproportionately be in things like intranet deployments where it's hard to even get measurements. :(

A link with _blank + expected to change/interact with opener? Maybe there's a few, but most cross domain transports would use window.open() manually.

Re: About rel=noopener

#110

Post by bzbarsky »

stormbrew wrote: post #107
bzbarsky wrote: post #97

Earlier quoted context omitted.

The problem with making it asymmetrical is that in the case of two toplevel tabs (as opposed to frame and child) determining who's the "parent" and who's the "child" is a lot more complicated. > If you're suggesting it would be technically difficult, I'm extremely skeptical of that. I think it's technically difficult to establish parent/child relationships between toplevel windows, given opener disowning and so forth…

If that relationship weren't clear you wouldn't have a window. opener attribute to begin with. That said, I'm also skeptical of legitimate uses for controlling the location of another top level window as well, so I'm fine with killing that option too. Of course, I don't expect them to actually fix this, but I'm still waiting for a convincing argument that it should have been that way in the first place.

My point was that window.opener can be nulled out.

> I'm also skeptical of legitimate uses for controlling the location of another top level window as well

Happens all the time: open a popup, then navigate it to places. Not on web pages much nowadays, though it was more common in the past, but in various intranet apps? All the time.

Post reply on HN