Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require noopener in links and window.open() #94

Open
johnwilander opened this issue Oct 19, 2021 · 7 comments
Open

Require noopener in links and window.open() #94

johnwilander opened this issue Oct 19, 2021 · 7 comments
Assignees

Comments

@johnwilander
Copy link
Collaborator

We should require links to have rel="noopener" and window.open() be called with the noopener window feature to make sure that there is no covert, cross-site communication channel back to the opener over which tracking information can be sent.

Ping @csharrison and @johnivdel for consideration in Attribution Reporting API.

@johnwilander johnwilander self-assigned this Oct 19, 2021
@johnwilander johnwilander added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 19, 2021
@johnwilander johnwilander changed the title Require noopener in links and window.open()< Require noopener in links and window.open() Oct 19, 2021
@SOV37
Copy link

SOV37 commented Oct 22, 2021

Dawn

@annevk
Copy link

annevk commented Dec 7, 2021

It might be simpler to default to noopener if the attribution attributes are present? Similar to target=_blank, except you would not allow it to be overridden.

@johnwilander
Copy link
Collaborator Author

It might be simpler to default to noopener if the attribution attributes are present? Similar to target=_blank, except you would not allow it to be overridden.

I had the same thought some time after filing this. Requiring the developer to opt in to noopener makes it explicit and known to them instead of implicit and a side effect. I could go either way.

@AramZS
Copy link

AramZS commented Dec 9, 2021

I agree, defaulting to noopener mode makes the most sense to me if that's the way the system is intended to work. Long term it seems to me that if it is always active, which I think is what we are discussing here(?), then having to add it as a property to every use seems to be messy?

@csharrison
Copy link

Sorry I missed this originally. This seems reasonable to me, and I can also bring it up in the attribution reporting api WICG meeting next week.

@npdoty
Copy link

npdoty commented Dec 9, 2021

in either approach, how will/should the developer learn why something is broken? does one way make it easier to put a debug warning into the console?

@csharrison
Copy link

in either approach, how will/should the developer learn why something is broken? does one way make it easier to put a debug warning into the console?

I think either case should be easy to signal to developers with a console error.

@TanviHacks TanviHacks removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants