Google launches new “portal” HTML element
zdnet.com
zdnet.com
> Furthermore, portals can also overwrite the main URL address bar, meaning they are useful as a navigation system
Isn't this already possible with iframes and target="_top" / target="_parent"? You can also use the <base>-Tag inside the iframe.
> The advantage over using Portals over classic links is that the content inside portals can be pre-loaded while the user scrolls through a page, and be ready to expand into a new page without having the user wait for it to load.
What? What about the vast majority of links that appear in-line, in text (think Wikipedia). What about the increased bandwidth usage for pre-loaded pages I don't intend to visit? What about the obvious tracking issues? What about the further increased difficulty for users to even tell which page they are actually on, if the transition to another page is now smooth and not clear-cut?
This article makes it seem like <portal> magically removes all the security concerns people had for decades with iframes, which imho is not the case at all.
frankly, tracking seems to be a primary purpose of the portal tag. it takes the imperative away from the user so that the server can make the decision about what you see and how intrusive it can be. the point seems to be to shift control to google.
I honestly don't see how the server gets any more "power" than it already did.
We already have enough issues with tracking pixels, but now we'll have to worry about multiple sites worth of trackers (which I'm sure google will do their absolute best to obfuscate behind the background network call and other sandboxing shenanigans)? No thanks.
(and you can be sure that anyone that dosen't allow google to "portal" their pages will be damnatio memoriae'd into oblivion on results pages)
Uncharitably, this probably just gives Google more ability to track/control your interaction with sites that it links you to.
These already exist. You can do <link> prefetch now ...
But I THINK they are doing preload now as well so the DOM can be pre-cached.
I mean you could do it on your own site but most people try to make sites FASTER not slower.
I still don't grok the main advantages of Portals though.
If not, just get blokada from f-droid. It uses 1-3% energy over the day on my phone, but saves around 15% by filtering ads
Ads ads ads everywhere. How do people actually live day-to-day with mobile browsers that have no true adblocking capability? Using mobile Chrome is like taking a stroll through a plague ward.
It’s, uh, really not that bad. I rarely notice banner ads and the like. If a particular site gets really egrigious, I leave the site.
I suspect that after using Adblock for years, your brain has forgotten how to ignore them.
As for the "But how do we pay for all these free things then?" counterargument, I'd suggest voluntary restraint on the part of website creators. I can live with a few modest JPEG-only banner ads hosted directly from the site I'm visiting. If a site promises to not use animated images, streaming video, streaming audio, any sort of trackers, any sort of third-party content, and if they keep the screen-real-estate ratio of ads to content relatively low, then I'll whitelist them in a heartbeat.
I just don't think this is a workable model for most users. "You want me to do extra work so I can see some (admittedly nonintrusive) ads? No way, figure out your own business." Honestly, if I started using an adblocker I'm not sure I could force myself to make that effort per website.
I really wish uBlock Origin at least had the option to enable a blacklist model—ie, no sites ever have their ads blocked by default, but as soon as a site annoys me, I can go into my adblocker and disable their ads.
It effectively does have this capability. Just disable all the standard filter lists, and manually add one's own entries to the "my filters" section.
This method has the added benefit of enabling other useful privacy features that don't directly relate to display advertising, like killing off the nastiness of hyperlink auditing, CSP reports going to 3rd parties, prefetching, and remote fonts.
We could make the same argument: you've spend years without adblock, and they have worn you down to the point where you accept active mental blocking of highly distracting ads. And even then you say sometimes it's bad enough for you to leave the site.
Why would you ever spend time on a site that did these things? Even if you have an adblocker, why would you use such a site on purpose?
Yeah, I never understood why people purposefully visit sites full of ads and then complain that the sites they visit are full of ads. It seems like a pretty simple problem to solve. And yet, even among the tech crowd, people seem to struggle with it constantly.
I'd wish I had your ability to "rarely notice banner ads", but I don't, so I complain.
I guess you got used to it. I also had the chance to re-discover how many ads are everywhere on the web thanks to firefox addons outage, and I was very surprised. Honestly, smartphones screen are already quite small (even more when the keyboard pops out) and with all the ads the actual useful surface of the screen gets ridiculously tiny.
I couldn't imagine that chrome on mobile doesn't have an way to block ads, and still has such a huge user base.
Again, not trying to convince anyone here, I just don't feel comfortable with it personally.
I hadn't heard of Fenix but it seems I'll have to try that soon.
I switched to Brave for mobile and it is amazing. Super easy to block scripts and other tracking without hijacking your DNS or requiring ad blockers/pi-holes etc.
Such is the reality of using an OS made by an advertising firm I guess.
EDIT: and there is no reason to use a different browser on the phone and desktop, Firefox is available on desktop too. :P
But it doesn't work if you're using a VPN... So it's an either pi-hole or blokada situation
https://www.privateinternetaccess.com/helpdesk/kb/articles/w...
I used to have four adblockers on my laptop (two operating systems x 2 browsers), one on my smartphone, one on an additional smartphone I use... and how do I stop my TV and my ebook reader from serving me ads?
Pi-hole requires little to no maintenance, and offers a lot of benefit. Two people have purchased their first Raspberry Pis after I've slipped in "oh and BTW, no ads will load while you're connected to this network" after giving them a WiFi password.
Firefox has a desktop version too. Works well.
Pretty much. When the developers only use the latest phones, on a company (or unlimited) plan, connected to 4G LTE with full bars, this is what you get. Google seems determined to hide network latency with its various prefetching efforts, but since I'm paying for bandwidth, I'd rather just wait the extra couple of seconds.
Google makes money off companies whose goal is to keep you in a mindless state of flow. Having to wait for a page to load disturbs that flow, making it more likely for you to realize you're being monetized and/or just wasting your time, and should do something else instead.
Users will get portal-ed to a result page (with the browser's url bar showing foo.com, instead of google.com), but the user will be tracked the entire time from google, since they would be still on google.com.
I can see a lot of value in serving a mobile ad, and then having clicks open this overlay experience which was pre-loaded.
I tried to use it for a month 2 years ago and switched back to Google.
Now it has been 3 months and I don't notice -- which is a very good thing!
https://help.duckduckgo.com/duckduckgo-help-pages/results/so...
Or, it would show pages with just 2 out the 3 search terms I give it. And guess which word they'll leave out? The word that makes the search specific instead of broad... god effing damnit!
Portals are essentially iframes, but once activated they become the top level origin.
Google is completely open about their intentions. Citation from https://github.com/WICG/portals/blob/master/key-scenarios.md:
> After being activated, a portal opened by the news aggregator will now receive the input events. This means that it will have to co-operate with the news aggregator in order to maintain the desired user experience.
Why exactly does it _have_ to cooperate? And _how_ can it cooperate? Will it be enough to include a script from parent domain? Will analytics be part of "desired user experience"? Will parent domain ban a site from it's index for trying to "break out"?
It is essentially impossible to build relationships of mutual trust to the point when one website can freely embed another... unless one party has overwhelming power advantage. Who is the target auditory of <portal>? What "news aggregator" has enough leverage to make pages switch back to it as told to? If such "aggregator" existed, I would not trust it to make web browsers or dictate, how they should work.
Exactly: the integration requires cooperation from both websites, and there is zero reasons, why child website would want to cooperate. Unlike, say, using Google Analytics, letting user leave you via <portal> tag is against website's best interests.
https://venturebeat.com/2019/05/09/google-creates-dedicated-...
Let's be real here. This can already be done though <link> "prefetch" and "preload" [0].
This is just Google introducing more pointless tech that will make webpages clunkier for no good reason. Honestly, I can't think of a single purpose this serves that isn't already fulfilled by existing web tech.
[0]: https://stackoverflow.com/questions/49491193/how-can-i-preem...
https://github.com/WICG/portals/blob/master/explainer.md#faq...
https://github.com/WICG/portals/blob/master/explainer.md#alt...
Heh, "we considered this but it's hard to do in Chrome".
But they don't give a shit if <portal> is hard to do in Gecko, of course.
Portals are user-visible, so the browser can't defer the load.
This is a good thing. Many are on metered connections and have data caps.
I love how they gloss over the security issue here. This is the equivalent of “we made a new Ajax that can call from different domains.”
Reading through the article, I don’t see the security restriction addressed at all. I expect that this gets worked on when google submits this to the w3c to be made part of html.
[0] https://developers.google.com/web/updates/2018/11/signed-exc...
BUT I'm concerned it doesn't mention similar sandbox and feature policies as iFrame. It also mentions that it will allow the 'child' to know if it's inside a portal with window.portalHost but at least this github mentions you can minimally declare no-referrer https://github.com/web-platform-tests/wpt/blob/master/portal...
Wouldn't the concern be ads ( I assume this is what this feature is intended for especially on mobile )? If there are no similar restrictions as a iframe safeFrame I can see a ton of ad scams that take advantage...
But that seems to be exactly what it does: look at the image at the top of the article, the address bar clearly changes to the portal-target's location. I think that's what they mean by "can be navigated into".
Having built-in page previews is actually a useful feature but without the other useful feature of
"play video" -> "click video to open page" -> "video continues playing while the rest of the real page renders around it" -> "you are now really on the other page with no connection to the previous page"
it seems like the business motivation for this was to embed more content in Google Search while keeping Google branding in the background.
Even if we assume you use AMP, package it with signed exchange, and Google SERP displays it then, yeah, your site could appear with no extra network request to your site. The lack of network requests isn't that different to old school HTTP proxies but with better specs and security. AMP has analytics and stuff so if you want to count visits, go do that.
I think the problem these technologies are meant to solve is making navigating between pages take under a hundred milliseconds and appear much faster by being able to preview/animate them. That would be good.
Yeah, new technology is not without cost and risks but Google turning the web into a walled garden isn't high on my list of risks.
For example, engineers hope that when a user is
navigating a news site, when they reach the bottom
of a story, related links for other stories are
embedded as portals, which the user can click and
seamlessly transition to a new page.
So this example really doesn't make it clear to me why we need this new element?
(Besides, if a page has several dozen links, exactly how many of them can you afford to preload before that activity starts bogging things down? The ZDnet article talks about this behavior replacing all links, which doesn't make a whole lot of sense to me...)
Its a modernized ifame. It seems like they can't introduce some of these features without breaking the security features of iframes.
With them dominating browser share, they can now push tags like this that only make ads more annoying.
Geez we so badly need a more balanced browser landscape.
OTOH, they grew up indoctrinated to Google and so refuse to see the water coming slowly to a boil.
"No other browser vendor has expressed interest in supporting the Portals" -- but Google is releasing it in Chrome anyway.
It changes the fundamental nature of the WWW as linked documents. Embrace, Extend, Extinguish. The only conclusion I can come to about things like AMP and portals is that Google is actively trying to kill the Web.
> "Google engineers hope that their new Portals technology will take over the web and become the standard way in which websites transition between links."
That's already happening to an extent with local AMP caches of outbound links 3rd party links on AMP enabled pages at cloudflare.
15 years ago, it was common for website owners to ask you to "make all links open in a frame" so that the original site could keep a frame on top of all the other content. That was probably only stopped by JavaScript snippets to break out of frames. Portals is the same kind of idea -- give power to the sites that link out (like Google) at the expense of the smaller sites that receive links.
The difference is made crystal-clear in the draft [1]:
> Every browsing context has a portal state, which may be "none" (the default), "portal" or "orphaned"... "orphaned": top-level browsing contexts which have run activate but have not (yet) been adopted
In other words, the original google.com document will be kept active in background (in "orphaned" state) and the child document can continue to interact with it by using Javascript after "adopting" it (at which point roles reverse and google.com becomes child document itself).
In theory the specification allows child document to ignore parent and let browser close it, completing transition. It also allows to perform graceful switching between child and parent, keeping each in control as long as it remains top document.
In practice, child portals will run Javascript, written by Google, and will be subject to Google's complete discretion. The distinction between first-party and third-party scripts will be erased, effectively letting Google run analytics on third-party domain, and send results back from it's own domain via Javascript proxy.
<portal> doesn't feel like something that will ever be supported in Safari.
Dart ran natively in Chrome once. Why doesn't it now? Because webdevs didn't care enough to write native Dart on the front-end.
They're doing this in the open through the W3C WICG process [1]. They're not doing this as they see fit.
> for their own purposes.
Open standards are available for anyone to use and benefit from. That they may have had a use case in mind when defining the spec does not invalidate it; rather, it reinforces it and shows its value.
I really don't see a significant difference. They can pretty much propose whatever they see fit through WICG and implement it in Chrome as they see fit.
By the way, this isn't a standard by any reasonable definition of the word.
One way of looking at it is that the standardization process is "propose and implement whatever you want, but it doesn't become a standard until another browser implements it and consensus is achieved".
This is a direct response to the problems of the W3Cs old way of defining large, pie in the sky, standards without any implementation, and then only much later realizing that they were bad.
Google are now where microsoft were when they launched IE6, adding features as they see pleased to support their own products and revenue.
Back then the web population was savvy and not so reliant on microsoft that they could jump to firebird/firefox/opera when things got really bad.
The modern web users don't have that option because google are far more dominant now than microsoft ever was.
Back then people would joke about their grandma being "stuck" on IE6, but that's the level of technical aptutide of the whole web now. Just ordinary people wanting to get on with their own business.
Back in '02 chances are you'd be re-install XP all the time and during one of those installs a technician could install firefox (or later chrome) and you'd be set up. That doesn't happen now, OSes "just work" and people aren't changing their browser.
At peak (in ~2003-2005) IE had over 90% of global browser market share. Chrome on desktop has between 60 and 70, and afaik less on mobile, and less in the US. So, no.
> That doesn't happen now, OSes "just work" and people aren't changing their browser.
Given that chrome doesn't come on any popular desktop OS by default, this seems unlikely. If people weren't changing their browser, Safari, FF, or Edge would be the most popular due to coming by default on OSX, most linux distros, and Windows by default. (how popular is CrOS?)
> No, given chrome's market share other browsers are forced to implement it or people will consider those browsers broken.
There's a pretty decent history of this not happening.
I also don't really think your idea of how the web was used is a true reflection of reality. I was an elementary school kid back in 2002 and was using netscape and IE 4? 5? at the time, in school. I certainly had no clue how to jump to firefox or opera, nor did I know how to re-install the OS. Nor did my teachers.
I don't think the average web user back then was as savvy as you're thinking. Perhaps the average web user you hung around was, but that's just your social circles.
No, it has about 60% on both mobile and desktop, not counting the derivatives (like Edge and Opera). Considering that both of those markets grew significantly since IE6 days, that makes Chrome more dominant than IE ever was.
And you seem to assume that an average consumer installs stuff on his own after the OS installation, which is not the case with less tech-savvy people I know. They usually give it to someone a bit more tech-savvy to do post-install tasks, and those always include an installation of a different browser. Every single second-hand computer available in my country's market comes with a cracked version of Windows, MS Office and a different browser. Tech-savvy ones just reinstall the OS, non-tech-savvy ones continue using the defaults — the defaults set up by someone else.
No. Dominance is a function of market share, not market size, that's silly. Otherwise I could argue that Firefox is also more dominant than IE ever was, since it's got more users than peak IE. Same with Safari. But then 3 browsers would simultaneously be more dominant than the one that controlled 95% of the market at its peak. Neat.
>At peak (in ~2003-2005) IE had over 90% of global browser market share. Chrome on desktop has between 60 and 70, and afaik less on mobile, and less in the US. So, no.
The parent post was comparing Google and Microsoft, not just Chrome and IE.
WHATWG's and W3C's track record as wannabe standardization bodies is incredibly poor considering that it has seen Opera and MS drop out of browser development alltogether, and that web standards are so fsckng complicated it's infeasible to develop a browser from scratch again, ever. I mean, that's exactly the situation that a standard is meant to prevent.
It's time for a real standardization org to step in, and for society to sit at the table when it comes to decide on the primary means for digital communication.
Sure they are. It's already part of Chromium.
https://cs.chromium.org/chromium/src/content/browser/portal/...
It's been there since at least last August.
Start at https://www.chromestatus.com/features/schedule you can drill down from there, for each feature, you can see links to W3C, WICG, TC'39, or whatever repositories, complete with discussion, and status from other browser vendors.
Yes, Chrome has shipped proprietary API features "on by default" before without buy-in from everyone else (e.g. NaCL), but so has Mozilla. The question is, are these the exception, or the rule?
And in my view, most of the Web's evolution in the past few years has been way more open and participatory than the 90s/00s Netscape/IE era.
They launched the draft on the 2nd and implemented the tag on the 10th. I'd hardly call that going through the open process. That's a move to save face.
So why the heck are people opposed to that?
https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_...
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
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.
That depends on one's definition of "ok". I don't think that modern web is ok.
That said, Portals _are_ going through the normal W3C process for experimental features via the Web Incubator Community Group: https://wicg.github.io/portals/
W3C is a joke. The modern web is, like the old web, run by the dominant browser vendor. Calling it an open standard is just marketing.
If you want to contribute, there's a repo full of issues that's completely public: https://github.com/WICG/portals/issues
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?
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.
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.
Embedded youtube videos could support a navigation to the video page where the video just animated from the embed to its in-page position while continuing to play.
Embedded twitter posts could be clicked on to do the same sort of transition. Really this sort of thing applies to all kinds of media embeds.
Amazon ads could do the same sort of transition to the advertised item.
Basically, this could allow multiple different domains to coordinate to get some of the fluidity that you can build on a single page. Ex. you could develop a federated social network of many different providers (or video sharing or whatever) while retaining the UX of interacting with a single thing.
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 >
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.
People are giving up long-term technology freedom for short-term, beginner's convenience.
Easier development = more developers.
This is marketed as being similar to the iframe tag, but it's really an attack on the a tag.
Sounds fishy and they’re trying to project this under a UX umbrella.
you wouldn't even know you're not leaving it, because the address bar changes
> address bar, meaning they are useful as a navigation
> system, and more than embedding content --the most common
> way in which iframes are used today.
Well, this looks like the next hack/scam feature. I really hate to think of the sort of rubbish that this will cause.
> Google says portals allow users to navigate inside the
> content they are embedding --something that iframes do not
> allow for security reasons.
Surely this is exactly why the "portal" shouldn't do this either? Why not work towards fixing the security issues of the iframe?
Regarding pre-loading content in links, they could just implement this in the browser if they think it's really that important. This will destroy your mobile data.
I really wish they had sat down and discussed this with other browser teams to flesh it out. I think part of this is in getting the jump on other browsers, this really will take a long time to implement securely.
It took mere ~25 years in the industry to see things making rounds and old ideas coming back as new, unironically. X Terminal and "network computers" → browser, JVM → WASM, CGI → serverless, Modula/Oberon → Go; now <iframe> → <portal> and the whole idea around it.
>This is a proposal for enabling seamless navigations between sites or pages. In particular, this proposal enables a page to show another page as an inset and perform a seamless transition between an inset state and a navigated state.
Like clicking on an ad ?
I do not want to return to the days of incompatible browsers (to the degree it was) even if they now publish a draft of how it works - the goal is compatibility, not POTENTIAL compatibility.
> We wish to give user agents as much flexibility as possible to isolate the host and guest browsing contexts (in implementations, in separate processes), even when the active documents may be same origin-domain. To make this possible, we intend not to expose the Document or WindowProxy of the guest contents, via the IDL attributes on HTMLIFrameElement, by using access to named windows, or by indexed access to window.frames. Without such access, communication can be be guaranteed to be asynchronous and not require shared access to JavaScript objects. Those operations which don't apply to portal contexts would all need to be modified to throw an appropriate exception in such cases.
[1]: https://github.com/WICG/portals/blob/master/explainer.md
What's less natural is that so many other browsers/frameworks chose to be based upon it (like every Electron app in the world, Opera, Silk, Microsoft Edge real soon now™). Apart from Safari or Firefox, there aren't really many alternatives anymore.
I'm not just talking the talk here: I've spent significant amout of time (years) in implementing SGML and an SGML grammar for HTML5 [1].
Web devs and evangelists of the world, you brought this on yourselves.
To talk of a browser vendor "launching" a new element is also ridiculous - Google have no authority to "launch" an element for the web as if it were some product they decided to update. Article title is poor in this respect.
Looking at the actual spec:
> This specification extends [HTML] to define a new kind of top-level browsing context, which can be embedded in another document, and a mechanism for replacing the contents of another top-level browsing context with the previously embedded context.
1) Why not an iframe? 2) Why not a link to the iframe src?
Or is the link here from within the iframe? Surely that's possible already with a postMessage and a window.location change. I don't understand the benefits here.
Is the sole purpose of this to avoid a HTTP request?
https://news.ycombinator.com/item?id=17776456
If the SRI hash on the data-uri could restrict the content of the portal to a trusted HTML document (containing SRI hashes for the scripts it referenced), then navigating "into" the portal would allow the browser to display the URL of the origin site, and run JavaScript in that context, with the TLS indicator visible.
This would allow us to pin specific versions of web apps (if they were structured this way), and those apps could be subject to independent audit. Specifically, it would then be impossible for a compromised host to silently "upgrade" you to a new malicious version of the web app (or even downgrade you to an earlier version).
Also, the preview problem... you could really just use an image as a link if you wanted to. Less convenient, that's true. But meh, this tag seems to offer little extra (to me).
Perhaps "portals" are the solution (?)
Just like they don't allow putting their pages in iframes:
https://jsfiddle.net/yea0jvxL/
But I would not be surprised if they put all search results in portal links and therefore keep all users on their site.
Now that Chrome is quickly becoming (if not has outright become) the new Internet Explorer, I wonder what browser will come out in a few years to be the next Chrome?
"The advantage...is that the content inside portals can be pre-loaded while the user scrolls through a page, and be ready to expand into a new page without having the user wait for it to load."
My brain translated it to this:
"The advantage...is that advertisements can be pre-loaded while the user scrolls through a page, and be ready to add to Google's revenue without having the user to wait for it to load."
How is an HTML tag a technology?