6 ms·

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

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 off on my browser. Like third-party cookies, cross-origin access to just about anything is a bad idea.

beaconstudios 9y ago
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.
- Forge36 9y ago
  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.
  - beaconstudios 9y ago
    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.
    - kijin 9y ago
      Content-Security-Policy might be a good way to opt in to this kind of behavior.
    - manigandham 9y ago
      That's exactly what IE did with the `X-UA-Compatible` meta tag. It's just more work for both browsers and websites to manage, which is why it's not used anymore. https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).a...
- stephenr 9y ago
  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 https://w3c.github.io/webappsec-csp/#directive-disown-opener
  - beaconstudios 9y ago
    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.
    - stephenr 9y ago
      i feel like there must be an xkcd that sums up your suggestion...
      - illustrioussuit 9y ago
        https://xkcd.com/927/ https://xkcd.com/927/ Or mobile: https://m.xkcd.com/927/ https://m.xkcd.com/927/
        beaconstudios 9y ago
        I'm not sure that applies here but it could definitely suffer from the Second System Effect - https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- IncRnd 9y ago
  > 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.
  - beaconstudios 9y ago
    I'm not suggesting overloading it - just trying to come up with a fitting metaphor.
- lioeters 9y ago
  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.
  - core-questions 9y ago
    This could work, but ultimately it's just more and more duct tape. It's high time to start with a cleaner, more secure slate and let people migrate maintained applications over; the old stuff can run in a more secured, more limited sandbox.
discreditable 9y ago
> 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.
- metafunctor 9y ago
  Browsers should show a warning that a "possibly insecure legacy mode" is in use. If browsers enforce HTTPS in a similar way, I don't see why they shouldn't enforce better security elsewhere as well.

beaconstudios 9y ago

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.

Forge36 9y ago
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.
- beaconstudios 9y ago
  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.
  - kijin 9y ago
    Content-Security-Policy might be a good way to opt in to this kind of behavior.
  - manigandham 9y ago
    That's exactly what IE did with the `X-UA-Compatible` meta tag. It's just more work for both browsers and websites to manage, which is why it's not used anymore. https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).a...
stephenr 9y ago
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 https://w3c.github.io/webappsec-csp/#directive-disown-opener
- beaconstudios 9y ago
  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.
  - stephenr 9y ago
    i feel like there must be an xkcd that sums up your suggestion...
    - illustrioussuit 9y ago
      https://xkcd.com/927/ https://xkcd.com/927/ Or mobile: https://m.xkcd.com/927/ https://m.xkcd.com/927/
      - beaconstudios 9y ago
        I'm not sure that applies here but it could definitely suffer from the Second System Effect - https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
IncRnd 9y ago
> 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.
- beaconstudios 9y ago
  I'm not suggesting overloading it - just trying to come up with a fitting metaphor.
lioeters 9y ago
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.
- core-questions 9y ago
  This could work, but ultimately it's just more and more duct tape. It's high time to start with a cleaner, more secure slate and let people migrate maintained applications over; the old stuff can run in a more secured, more limited sandbox.

discreditable 9y ago

> 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.

metafunctor 9y ago
Browsers should show a warning that a "possibly insecure legacy mode" is in use. If browsers enforce HTTPS in a similar way, I don't see why they shouldn't enforce better security elsewhere as well.