Google launches new “portal” HTML element • Hacker News Board

Re: Google launches new “portal” HTML element

#261

Post by sinancan2 » Sat, May 11, 2019, 8:30 PM UTC

y4mi wrote: post #98

giobox wrote: post #48

Earlier quoted context omitted.

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 mad…

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.

https://www.privateinternetaccess.com/helpdesk/kb/articles/w...

Re: Google launches new “portal” HTML element

#262

Post by pdxww » Sat, May 11, 2019, 10:55 PM UTC

dillondoyle wrote: post #207

prepend wrote: post #142

“Google says portals allow users to navigate inside the content they are embedding --something that iframes do not allow for security reasons.” 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 t…

It says that it only allows postMessage for cross domain communication. 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…

Luckily, uBlock Origin can block all portal tags entirely.

Re: Google launches new “portal” HTML element

#263

Post by gshdg » Sun, May 12, 2019, 2:04 AM UTC

Diti wrote: post #184

rahuldottech wrote: post #57

> portals can be pre-loaded while the user scrolls through a page Let's be real here. This can already be done though "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-…

Clunkier? To me, this new tag proposal screams AMP, which Google wants to remain fast.

Speed is not the only measure of clunkiness.

Re: Google launches new “portal” HTML element

#264

Post by tatersolid » Sun, May 12, 2019, 2:25 AM UTC

codemac wrote: post #119

skymt wrote: post #60

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.

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…

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

Re: Google launches new “portal” HTML element

#265

Post by Touche » Mon, May 13, 2019, 5:29 PM UTC

andrekandre wrote: post #213

Touche wrote: post #101

Earlier quoted context omitted.

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?

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 b…

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