Hacker News Reader

> "what about the obvious tracking issues?"

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.

Its completely different because now baz.com gets control over foo.com in an invisible way just by virtue of "linking" with a portal.

(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)

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.

Everyone seems to have just jumped into the 'Google is evil' bandwagon without even putting thought into it.

But the Portal element won't exacerbate this issue vs what sites are already doing with iFrames and custom JS.

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.

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.