At first glance, this seems really cool. Then I remember it's Google we're talking about here. Somehow I feel like this is something they can use to benefit their search engine and/or AMP-style efforts. Keep more users within their controlled environments rather than officially navigating to a real website elsewhere. Also seems like potential phishing problems could arise. Can someone explain to me how this portal element to actually great and not just great for Google?
>Keep more users within their controlled environments rather than officially navigating to a real website elsewhere
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".
Right but rather than making a seamless transition between pages they made it a subpage of the parent.
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.
This. It can allow you to see the google results and navigate from them seamlessly without actually leaving the top-level domain. It effectively captures the entire audience. There will be no more Internet, it's going to be a Google portal (like AOL) with Google keywords, and will "borrow" the content from everybody else.
How do you define "actually leaving"? Because after navigating to the portal, it occupies the whole viewport and becomes the main document with your site's URL.
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.
It took me a few months to realize that when I browse google with my iPhone and click a link, it's not actually taking me to that site, just loading it in an iframe. Weird and unnecessary, except in the eyes of Google's margins.
The scrolling issues were due to a Safari bug. Unfortunately, Apple does not allow its users to install non-buggy browsers on their devices. I hate Apple devices with a passion.
At the end of the day, web standards are nothing more than advisory and Google own a clear majority of browser market share. Who is going to stop them?
If mobile app store revenues can be used as a metric for revenues on the web generally, iOS users are a valuable demographic to target, even if they are the minority. If your website doesn't work in Safari, you're going to lose revenue.
<portal> doesn't feel like something that will ever be supported in Safari.
IE6 lost that battle because it stagnated - it wasn't just not keeping up with new standards, it wasn't innovating in general. We don't know if it turned out the way it did, if Microsoft kept proactively extending HTML in new IE versions. But given that this is largely what was happening in the IE/NN mortal combat era that preceded IE dominance, I'd expect "this browser best works in ..." to make a comeback. And, indeed, it's increasingly common to see websites explicitly say that they want Chrome. Especially new Google projects...
It's not up to Google, it's up to web developers. If they find <portal> useful they'll implement it which forces FF/Safari to create their own implementations.
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.
> They're doing this in the open through the W3C WICG process [1]. They're not doing this as they see fit.
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.
That's how modern web standards are done. If people like it, other browsers will adopt it and then the standard will too. If people don't, they won't. But every browser runs nonstandard features as part of experiments to implement new things.
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.
No, given chrome's market share other browsers are forced to implement it or people will consider those browsers broken.
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.
> The modern web users don't have that option because google are far more dominant now than microsoft ever was.
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.
> Chrome on desktop has between 60 and 70, and afaik less on mobile, and less in the US. So, no.
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.
> Considering that both of those markets grew significantly since IE6 days, that makes Chrome more dominant than IE ever was.
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.
>> The modern web users don't have that option because google are far more dominant now than microsoft ever was.
>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.
So-called "Web Standards" processes and organizations have been a fairy tale for a long time now. W3C is a pay-as-you-go puppet organization dominated by Google. You can see who calls the shots just by considering that the W3C-HTML 5.3 and SVG 2 specs have been abandoned. WHATWG was also funded and is sponsored by Google, and made an aggressive attempt at usurpating de-facto power over web standardization with a vulgar, staged anti-establishment "HTML5 rocks" campaign. The dominating browser and mobile platform (again, Google) can do what they want anyway. Now they turn to W3C again as a fig leaf for their not-so-stealth operation to become the web.
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, if it gets approved as a standard. Why not go look at the history of other HTML, CSS, and JS API additions, and the way they were staged, and what percentage shipped without agreement from other stakeholders?
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're doing this in the open through the W3C WICG process [1]. They're not doing this as they see fit.
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.
Do they use their internet dominance to invent a bunch of complex html elements so google becomes the only one being able to parse html effectively in the future? I hope not.
I don't think Google can be wholly blamed for that dominance. It's only natural that they would want to invent their own web rendering engine and with it they can pretty much choose what they do.
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.
IMO it's not so much about blaming or other moralistic category a la "Google is evil" than it is about whether we're going to accept and let happen the Googlification and appification of the web. If we do, than we (as in humanity) must look elsewhere now for our communication needs. Think about how involved the web in everyday life is (in education, personal communication, public services, contracts, law, webmail, ecommerce, etc. etc.). If we accept that this medium is going to slip away and out of control for no good reason, then we need to specify something with a more specific scope for preserving digital documents, contracts, transaction manifests etc. that is also fully able to represent existing (static or dynamic) HTML content.
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].
It's the natural consequence of people clamoring to turn a simple hypertext engine into a full on application VM. Feature upon feature was piled on, producing a gigantic ludicrously complicated garbage fire the likes of which simply cannot be replicated by mortals, and to ensure this whoever is on top will keep adding to the garbage fire so no one can ever catch up.
Web devs and evangelists of the world, you brought this on yourselves.
Depending on how it interacts with SRI, there is one interesting use case that could be supported. Imagine you had a data-uri / bookmarklet which loaded a <portal> of a web app, using the ideas discussed here:
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).
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.
Perhaps it's not a very good description, but isn't that just a link? That sounds a lot like a link to me?
So this example really doesn't make it clear to me why we need this new element?
I think it's largely a user experience thing. Because the "portal" has already been loaded and rendered, you don't need to add the delay of loading the new page at the point of navigation.
But if performance boosts from preloading are all you want, you could just add a 'preload' attribute to the usual <a> tag. The stated rationale of supporting spiffy transitions seems a bit more sensible, though, given how many hooks this has into browser UI, I'd be interested in seeing the limits on what, say, a malicious ad network could do with it.
(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...)
Can someone explain to me the innovation here, besides some page-transition eye-candy?
> 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.
With regards to bandwidth from pages you do not want to visit, sites can already include content that you do not care about in the page manually as part of the initial HTML or later via AJAX. In fact, the use case for portals covers this in that news sites commonly add other IMO irrelevant articles at the end of articles that I am reading.
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.
How is prefetching taking the imperative away about what you see? You can click or not click. As for "tracking", the website could already ping as many servers as it wanted in the background, it's not like it can do anything new here.
I honestly don't see how the server gets any more "power" than it already did.
If I go to foo.com, I generally expect that bar.com, baz.com, and qux.com are not also loading.
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.
As you mention, foo.com could just as well have pixel trackers/scripts from bar.com, baz.com and qux.com. Nothing about portals makes it any more or less of an issue than it already is.
baz.com doesn't take control over foo.com, and it's not invisible. You click on a link and the domain changes, it's as old as the internet itself. The only difference is that the new page will be embedded into the old one, instead of there being a clear cut transition.
The main limitation on using frames/iframes for different sections of the same UI was that they couldn't impact the primary URL, which means if you click a link in one of them, then reload the page, the frame gets reset to its default view. Charitably, I can see some small benefit to the idea of having "frames but they aren't bad", instead of having every JS framework reimplement its own view routing.
Uncharitably, this probably just gives Google more ability to track/control your interaction with sites that it links you to.
> 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?
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.
But is it "google launches" or "google proposes"? I think semantic details matter a lot here. The article is written in a way that it makes it look like W3C does not exist.
Agreed. There's one line about a drafted standard, along with a note that no other browser vendor has expressed interest.
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.
>Google engineers hope that their new Portals technology will take over the web and become the standard way in which websites transition between links.
This is marketed as being similar to the iframe tag, but it's really an attack on the a tag.
It's kind of funny, how mobile today is a big part of traffic and this will only increase, yet while the mobile experience is already terrible, especially in chrome with no script blocker, google constantly works at making it even worse, with preloading of undesired, external content. Does Silicon Valley not have data caps? I guess they never have bad reception, though. So at least the malicious add that preloaded in the background can transition you seamlessly to a new page. As quick as if you newer saw the content you intended to. Progress! :-D
The recent extension-disabling problem made me realize how awful the unfiltered web is. Trying to use mobile Chrome for the first time ever was a dreadful experience. I legitimately had no idea that mobile Chrome doesn't have any extension capability whatsoever. I always assumed it was a Firefox-style unified experience where the same desktop extensions worked on mobile. I was horrified to discover otherwise.
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.
Exactly. Technology exists to solve problems. One of the greatest problems in today's world is the metaphorical tsunami of advertising sewage flooding our mental shorelines. Browser-based adblockers neatly solve that problem.
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.
> 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.
>I really wish uBlock Origin at least had the option to enable a blacklist model
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.
Is this per the ad network / server, or per domain like the whitelist? I would have assumed the former, but if it works like the whitelist that's great!
I've had a similar experience as the GP, and I find it awful that autoplay videos will follow you around the page, pop-up modals will interrupt you in the middle of reading something, and ads will take up 40% or more of the page, loading between paragraphs while reading. It's hugely distracting to me.
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.
I've had a similar experience as the GP, and I find it awful that autoplay videos will follow you around the page, pop-up modals will interrupt you in the middle of reading something, and ads will take up 40% or more of the page, loading between paragraphs while reading. It's hugely distracting to me.
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?
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.
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 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.
It's not so much ads being annoying as ads completely blocking the content. A lot of sites are completely unusable on a phone; a malicious ad redirects the browser to a scam almost immediately. That's how looking at a link from the Facebook application works, but opening it in Brave gets you the site you want minus malvertising.
The way I see it, without an adblocker there is the potential that I will notice an ad. With an adblocker, that potential is completely gone. That's a big difference.
Again, not trying to convince anyone here, I just don't feel comfortable with it personally.
Firefox on my phone crashes ALL the time. I can't load 3 web pages without it crashing. Is Android doing this on purpose? I just cannot get firefox mobile to work, sadly.
This has not been my experience. I've been using Firefox for a while now with way too many tabs open and I've not encountered a crash. Or at least not one I remember. It could perhaps be some hardware it doesn't work well with? Or maybe it struggles with certain sites that I happen not to visit?
I hadn't heard of Fenix but it seems I'll have to try that soon.
I haven't used Firefox on Android in 6 months or so but it was pretty stable for me.
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.
Counter data point: I've had it running with 100+ tabs open for at least 2 months now. Yes, it gets restarted when my phone does - or when I need the resources for something else, or doing updates, but it's working great. Motorola Moto G second gen, running LineageOS...
It’s a real shame you still can’t install a third party content blocker easily in the default browser on Android. Setup a VPN and PiHole for sure works, but my goodness what a lot of effort when simpler approaches exist, even on Safari on iOS... I’m aware other browsers exist that can do this, but this basically forces me to use a different browser on my phone versus my desktop.
Such is the reality of using an OS made by an advertising firm I guess.
Fortunately on Android you at least can install another browser - Firefox. Works great - well, most of the time... but using it for a day without extensions makes me appreciate it even more.
EDIT: and there is no reason to use a different browser on the phone and desktop, Firefox is available on desktop too. :P
That's why I pointed out the second option (blokada). It's just a matter of installing it and you've got Android wide adblock, which mostly works even in non-website contexts
But it doesn't work if you're using a VPN... So it's an either pi-hole or blokada situation
Check out the "MACE" function of Private Internet Access VPN as well. It may work out well. I've recently started it on desktop and mobile, and disabled any other blockers. There may be other VPNs with similar functions but I don't know yet.
I know it sounds complicated, but it's a one-step process that only increases to pay off the more devices are connected.
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.
This new element will likely not show up as a negative on any site analysis reports... a sneaky way to make your site "appear" faster but still be a resource hog.
> Does Silicon Valley not have data caps? I guess they never have bad reception, though.
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 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.
It's been a few years, but IIRC I had poor reception on the Google Campus with AT&T. Some spots with poor coverage by SJC too. Probably folks are just always on wifi.
One imagines that a hotbed of tech would have great cell coverage. However, it’s also a hotbed of NIMBYs and the sort of people who think cell phones give you cancer, making it hard to construct more cells.
What are you talking about? There are cell towers everywhere. The CA senate in 2017 voted to remove local rights to govern their placement. 5G is rolling out everywhere. 5g radio transmitters on streetlights broadcasting continuously next to children's bedrooms. There was once safety concern over cell towers' placement. That is no more. We made the transmitters more powerful, but now they're smaller. So they go everywhere. "NIMBYS" have no say in what happens. It doesn't matter whether people think "cell phones give you cancer". The FCC doesn't care about anyone's safety. And people come on the internet rallying against some straw man they invented to showcase how silly it is to be concerned about the health effects of new technology.
The reason for a new element, rather than just tacking this behavior onto `iframe` seems to be backwards compatibility [1].
> 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.
"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."
I had to double-check that it's not an article form 1999 or something, when everyone was building "portals", with a very similar premise of having everything in one place [1].
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.
The example they give seems bad to me.
I'm fine just seeing the title of a news post and clicking that as a normal <a> tag.
I don't need to see a miniature version of the post that I then need to click on to read anyway.
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).
> portals can be pre-loaded while the user scrolls through a page
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.
It's not pointless at all. It makes the Web platform more complicated to implement, which, as the company that owns the leading browser, is in Google's interest. The more complicated the platform becomes, the harder and more expensive it will be for any potential competitors to ship a product that can challenge Chrome.
More importantly, as it seems to require an implementation of native UI and not just rendering, it will harm browsers that are currently Chromium based.
Link prefetch/preload puts the loading under the control of the browser. The user can't see whether it loads or not, so the browser can make intelligent decisions about when to load it or whether to even load it at all.
Portals are user-visible, so the browser can't defer the load.
What I don't understand is that many websites frame-bust to prevent phishing and click-jacking attacks on their content. But if Google wants to be accessible through portals, they'll have to open themselves up to the same phishing and click-jacking vulnerabilities, right?
264 comments
[ 123 ms ] story [ 417 ms ] threadBut 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.
We are, 10s of millions of users (if not 100s).
<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.
1: https://wicg.github.io/portals/
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.
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].
[1]: http://sgmljs.net/blog/blog1701.html
Web devs and evangelists of the world, you brought this on yourselves.
People are giving up long-term technology freedom for short-term, beginner's convenience.
Easier development = more developers.
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).
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.
> 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)
hahahaha. O goog you are so transparent.
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.
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.
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
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.
> 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
"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."
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.
[1]: https://en.wikipedia.org/wiki/Web_portal
Yeah. Not interested.
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 (?)
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.