6 ms·

Am I reading this wrong, or is Google pushing a fairly complex element with substantial security considerations into HTML exclusively to solve their UX problems

by skymt 7y ago

Am I reading this wrong, or is Google pushing a fairly complex element with substantial security considerations into HTML exclusively to solve their UX problems with AMP and the pre-load search carousel? Like this seems like it would be a fair amount of work for browsers to implement, and Google is the only party who would benefit.

deleted 7y ago
[deleted]
ccnafr 7y ago
No, you're right. Portal is effectively iframe without all the security protections.
- Ajedi32 7y ago
  It's kinda the opposite actually. iframes didn't provide sufficient security to do the sort of things Google wanted to be able to do with them, so they had to design a new standard with better protections: https://github.com/WICG/portals/blob/master/explainer.md#why-do-we-need-a-new-html-tag-why-not-use-iframe https://github.com/WICG/portals/blob/master/explainer.md#why...
- Touche 7y ago
  I don't understand the cynicism people have for this idea. All they did was say "wouldn't it be cool if you could have nice animations in between pages" and built a proof-of-concept. It's not a finished product. They aren't forcing it into a standard. It's a demo of something that would be cool. So why the heck are people opposed to that?
  - vernie 7y ago
    Well you certainly can't raise a stink after it's in the standard.
    - Touche 7y ago
      My point is, portal isn't "an iframe without all the security protections." portal is a demo of animating between pages. What it becomes from there is completely flexible.
      - bzbarsky 7y ago
        Things are not "flexible" once they have been shipped on by default, typically. Changing behavior or removing at that point becomes very hard, requiring usage measurements, etc.
        Touche 7y ago
        This is not on by default.
        bzbarsky 7y ago
        Yes, I am aware. But that's related to how happy Google is with it, not to whether it's standardized in any way.
      - skymt 7y ago
        Animation isn't the point of the portal element, it's to allow cross-site navigation to an embedded page without reloading.
  - amiga-workbench 7y ago
    IE5 has proprietary page transition animations, works pretty nicely actually. https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_11/webauthors/12_11_98_4.html https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_...
  - andrekandre 7y ago
    when you are google, unilaterally releasing and pushing a major new feature for “the web” has an entirely different meaning and implication to it compared to, sadly, mozilla, or some other player (even apple to some extent) because of their huge market/mind share. in that scenario “wouldn’t it be cool” is not a good enough reason, and for a major feature such as this, skepticism is healthy and warranted... the “web browser” is slowly being transformed into “the google browser” and we have no one to blame but ourselves
    - Touche 7y ago
      The consensus opinion seems to be, from this thread and elsewhere, "While Google is not doing anything wrong by standards in this case, because they have the power/potential to do something wrong by standards we must oppose this as well."
mysterydip 7y ago
Isn't this why we have the W3C, so standards don't get made unless multiple people benefit? This seems like Microsoft with IE6 all over again.
- ahupp 7y ago
  > This seems like Microsoft with IE6 all over again. IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok. In general I think building browser-specific features, seeing what works, and only then standardizing is a much better path than starting with W3C.
  - news_to_me 7y ago
    No it isn't. It leads to fragmentation of the platform, and pretty soon you'll start seeing "Works best in Chrome!" tags on websites, because developers are too lazy to implement fallback solutions where <portal> (or whatever other proprietary extension) isn't supported.
    - moreira 7y ago
      I already see them all the time, but this time dressed up as “please upgrade to a modern browser. But not Firefox. Not Safari. Definitely not Edge.”
      - ddalex 7y ago
        Perhaps Edge. A recent version.
  - altfredd 7y ago
    > IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok. That depends on one's definition of "ok". I don't think that modern web is ok.
- Ajedi32 7y ago
  No, the purpose of the W3C is to make sure we don't end up with multiple slightly different, mutually incompatible variations of the same thing. It's not meant to be a gatekeeper for new features. That said, Portals _are_ going through the normal W3C process for experimental features via the Web Incubator Community Group: https://wicg.github.io/portals/ https://wicg.github.io/portals/
skybrian 7y ago
If you're reading about this looking for how Google might misuse it, and that's what you see, then it seems like you're reading it as you intended. This isn't surprising. Many things can be read more than one way with only a little imagination. But there are other ways to read things. Like, how could I use that on my site? I'm thinking it might be fun to do something like the infinite zoom that Scott McCloud wrote about. Or more practically, it would let everyone put site previews next to links, like Twitter and Facebook do, without needing a big infrastructure. Or you could think about how arbitrary hackers could misuse it. The security issues seem a bit concerning. But I suppose it could be blocked like iframes?
- skymt 7y ago
  It's true that I could be lacking imagination. Because to me the portal proposal reads like it's simply moving the implementation of Google's AMP carousel into the browser in order to solve the address-bar problem. Your suggested use cases aren't terribly convincing, I'm afraid. Zooming UIs are perfectly possible using existing web technology. It would be interesting to have a standard way to embed Twitter/Facebook-style preview cards, but portals aren't it. A portal would just display a small portion of the page, which wouldn't be terribly useful unless the page is designed to reformat itself when displayed inside a portal viewport. If you want link previews now, there's nothing stopping web application developers from fetching the Open Graph metadata themselves.
  - skybrian 7y ago
    Sorry about that, I didn't mean you have little imagination, but rather that any reading of a tech spec requires a bit of imagination. It doesn't seem all that unreasonable for a web page to show a preview if the window size is small enough. You could do that with a media query. And then when it goes full-screen, it would already be loaded and that would just be a resize. This would take cooperation from web sites.
    - skymt 7y ago
      No worries. I really was sincere with my original question of whether I was missing useful potential applications. Building richer cross-site interactions into web standards and browser interfaces is an intriguing idea. A more dynamic model of hypertext, where the browser intelligently displays linked-to content. Even though portals are a highly limited version of that idea, Google has a high chance of getting them standardized and implemented by competing engines, so hopefully more useful applications can be found.
codemac 7y ago
Serious question: what are the substantial security considerations? I've been embedding websites in a tiddlywiki instance for todos as a test run, and I was surprised how much every website now tries to avoid/stop iframes due to the fact they aren't a "root" element. This type of HTML element would allow me to build a web application that actually leverages other websites w/o click jacking. This is so powerful, it's what makes emacs and other ubiquitous interfaces so powerful. Leveraging other content But maybe that's a pipe dream? Maybe that should be an application outside of the browser? Curious if there are any resources on the security implications of < portal >
- tatersolid 7y ago
  > I was surprised how much every website now tries to avoid/stop iframes due to the fact they aren't a "root" element. JS-based “iframe busters”, then X-Frame-Options, and now Content-Security-Policy should be ubiquitous. We started “busting iframes” in they early 2000s in the banking industry for security reasons. Preventing being an iframe child protects your site from phishing via click-jacking your login screen, and also prevents “stealing” of your content by spammy aggregation sites.
sebazzz 7y ago
Like HTTP signed exchanges, these are solutions for problems Google has.
- ddalex 7y ago
  would be funny if Google would code for somebody else's problems
- skybrian 7y ago
  While they are solutions to problems Google has, with some work, they can perhaps also be solutions to problems many other websites have, using browsers not written by Google. That's the benefit of making something a standard.

by skymt 7y ago

deleted 7y ago

[deleted]

ccnafr 7y ago

No, you're right. Portal is effectively iframe without all the security protections.

Ajedi32 7y ago
It's kinda the opposite actually. iframes didn't provide sufficient security to do the sort of things Google wanted to be able to do with them, so they had to design a new standard with better protections: https://github.com/WICG/portals/blob/master/explainer.md#why-do-we-need-a-new-html-tag-why-not-use-iframe https://github.com/WICG/portals/blob/master/explainer.md#why...
Touche 7y ago
I don't understand the cynicism people have for this idea. All they did was say "wouldn't it be cool if you could have nice animations in between pages" and built a proof-of-concept. It's not a finished product. They aren't forcing it into a standard. It's a demo of something that would be cool. So why the heck are people opposed to that?
- vernie 7y ago
  Well you certainly can't raise a stink after it's in the standard.
  - Touche 7y ago
    My point is, portal isn't "an iframe without all the security protections." portal is a demo of animating between pages. What it becomes from there is completely flexible.
    - bzbarsky 7y ago
      Things are not "flexible" once they have been shipped on by default, typically. Changing behavior or removing at that point becomes very hard, requiring usage measurements, etc.
      - Touche 7y ago
        This is not on by default.
        bzbarsky 7y ago
        Yes, I am aware. But that's related to how happy Google is with it, not to whether it's standardized in any way.
    - skymt 7y ago
      Animation isn't the point of the portal element, it's to allow cross-site navigation to an embedded page without reloading.
- amiga-workbench 7y ago
  IE5 has proprietary page transition animations, works pretty nicely actually. https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_11/webauthors/12_11_98_4.html https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_...
- andrekandre 7y ago
  when you are google, unilaterally releasing and pushing a major new feature for “the web” has an entirely different meaning and implication to it compared to, sadly, mozilla, or some other player (even apple to some extent) because of their huge market/mind share. in that scenario “wouldn’t it be cool” is not a good enough reason, and for a major feature such as this, skepticism is healthy and warranted... the “web browser” is slowly being transformed into “the google browser” and we have no one to blame but ourselves
  - Touche 7y ago
    The consensus opinion seems to be, from this thread and elsewhere, "While Google is not doing anything wrong by standards in this case, because they have the power/potential to do something wrong by standards we must oppose this as well."

mysterydip 7y ago

Isn't this why we have the W3C, so standards don't get made unless multiple people benefit? This seems like Microsoft with IE6 all over again.

ahupp 7y ago
> This seems like Microsoft with IE6 all over again. IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok. In general I think building browser-specific features, seeing what works, and only then standardizing is a much better path than starting with W3C.
- news_to_me 7y ago
  No it isn't. It leads to fragmentation of the platform, and pretty soon you'll start seeing "Works best in Chrome!" tags on websites, because developers are too lazy to implement fallback solutions where <portal> (or whatever other proprietary extension) isn't supported.
  - moreira 7y ago
    I already see them all the time, but this time dressed up as “please upgrade to a modern browser. But not Firefox. Not Safari. Definitely not Edge.”
    - ddalex 7y ago
      Perhaps Edge. A recent version.
- altfredd 7y ago
  > IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok. That depends on one's definition of "ok". I don't think that modern web is ok.
Ajedi32 7y ago
No, the purpose of the W3C is to make sure we don't end up with multiple slightly different, mutually incompatible variations of the same thing. It's not meant to be a gatekeeper for new features. That said, Portals _are_ going through the normal W3C process for experimental features via the Web Incubator Community Group: https://wicg.github.io/portals/ https://wicg.github.io/portals/

skybrian 7y ago

If you're reading about this looking for how Google might misuse it, and that's what you see, then it seems like you're reading it as you intended. This isn't surprising. Many things can be read more than one way with only a little imagination. But there are other ways to read things. Like, how could I use that on my site? I'm thinking it might be fun to do something like the infinite zoom that Scott McCloud wrote about. Or more practically, it would let everyone put site previews next to links, like Twitter and Facebook do, without needing a big infrastructure. Or you could think about how arbitrary hackers could misuse it. The security issues seem a bit concerning. But I suppose it could be blocked like iframes?

skymt 7y ago
It's true that I could be lacking imagination. Because to me the portal proposal reads like it's simply moving the implementation of Google's AMP carousel into the browser in order to solve the address-bar problem. Your suggested use cases aren't terribly convincing, I'm afraid. Zooming UIs are perfectly possible using existing web technology. It would be interesting to have a standard way to embed Twitter/Facebook-style preview cards, but portals aren't it. A portal would just display a small portion of the page, which wouldn't be terribly useful unless the page is designed to reformat itself when displayed inside a portal viewport. If you want link previews now, there's nothing stopping web application developers from fetching the Open Graph metadata themselves.
- skybrian 7y ago
  Sorry about that, I didn't mean you have little imagination, but rather that any reading of a tech spec requires a bit of imagination. It doesn't seem all that unreasonable for a web page to show a preview if the window size is small enough. You could do that with a media query. And then when it goes full-screen, it would already be loaded and that would just be a resize. This would take cooperation from web sites.
  - skymt 7y ago
    No worries. I really was sincere with my original question of whether I was missing useful potential applications. Building richer cross-site interactions into web standards and browser interfaces is an intriguing idea. A more dynamic model of hypertext, where the browser intelligently displays linked-to content. Even though portals are a highly limited version of that idea, Google has a high chance of getting them standardized and implemented by competing engines, so hopefully more useful applications can be found.

codemac 7y ago

Serious question: what are the substantial security considerations? I've been embedding websites in a tiddlywiki instance for todos as a test run, and I was surprised how much every website now tries to avoid/stop iframes due to the fact they aren't a "root" element. This type of HTML element would allow me to build a web application that actually leverages other websites w/o click jacking. This is so powerful, it's what makes emacs and other ubiquitous interfaces so powerful. Leveraging other content But maybe that's a pipe dream? Maybe that should be an application outside of the browser? Curious if there are any resources on the security implications of < portal >

tatersolid 7y ago
> I was surprised how much every website now tries to avoid/stop iframes due to the fact they aren't a "root" element. JS-based “iframe busters”, then X-Frame-Options, and now Content-Security-Policy should be ubiquitous. We started “busting iframes” in they early 2000s in the banking industry for security reasons. Preventing being an iframe child protects your site from phishing via click-jacking your login screen, and also prevents “stealing” of your content by spammy aggregation sites.

sebazzz 7y ago

Like HTTP signed exchanges, these are solutions for problems Google has.

ddalex 7y ago
would be funny if Google would code for somebody else's problems
skybrian 7y ago
While they are solutions to problems Google has, with some work, they can perhaps also be solutions to problems many other websites have, using browsers not written by Google. That's the benefit of making something a standard.