Chrome is going to block interactive content in iframes

[wandrien]

https://chromium-review.googlesource.com/c/chromium/src/+/1675916

Should we reimplement the domain isolation via proxy, instead of the iframe-based solution?

[purplesyringa]

They don't say that they're going to block interactive content in iframes; they say that they're going to block interactive content in ad iframes. However, I have no idea how they are going to distinguish between normal content (e.g.: Facebook comments) and ads. If they're going to have a blacklist (or detect ads in a similar way), this change is not required.

[wandrien]

I guess they are smart enough to avoid blocking iframes located at 1) the same domain as the main page; 2) at 127.0.0.1. I quickly looked through the code in the commit and found no those kinds of checks. But maybe I missed something or it's handled somewhere else. So, let's see how will it be done in the release.

By the way, there was a prrof-of-concept SOCK5 proxy implementation for Zeronet somewhere, wasn't it? Or am I confusing something?

[purplesyringa]

By the way, there was a prrof-of-concept SOCK5 proxy implementation for Zeronet somewhere, wasn't it? Or am I confusing something?

Maybe there was, but I think that I've first heard about it from you... so maybe there was some confusion

[HelloZeroNet]

The iframe is not just for domain isolation, but also to display the wrapper that for example allows to display permission requests or the sidebar.

[wandrien]

The iframe is not just for domain isolation, but also to display the wrapper that for example allows to display permission requests or the sidebar.

If iframes get blocked, it will cause serious usability issues for ZeroNet. The user will have to manually navigate to the Settings page every time a zite needs permissions or for signing the content.

[wandrien]

It can be partially solved, if we add an API to display a Sidebar-like panel, but without any real privileges to do dangerous operations. When the user presses a button on the panel, the browser is redirected to the actual admin page, where the confirmation is displayed and then the required operation is performed.

Well, not an ideal solution, maybe there can be a better way.

[HelloZeroNet]

Btw pac files would more suited to do this, because it allows you to define the proxy based on the url: https://en.wikipedia.org/wiki/Proxy_auto-config

And it's already supported: https://github.com/HelloZeroNet/ZeroNet/commit/4ffd6427323945fcba734f60209c0d0dbdb7b4d5

[filips123]

This intervention unloads ads that are in the .1% of bandwidth usage, .1% of CPU usage per minute, and .1% of overall CPU time. The current numbers are 4MB network and 60 seconds CPU, but may be changed as more data is available.

They will block ad iframes that have been detected to use an "egregious amount of system resources". I'm not sure how will this look like but they already created patch and commit so someone can look to detection code.

This blocking of ads is again one of the Google decisions to make web better... 😂 But I'm sure they won't block ads on YouTube.

[wandrien]

This blocking of ads is again one of the Google decisions to make web better...

Better for Google itself, yes. Better for its own ad network.

[wandrien]

And it's already supported: 4ffd642

Doesn't seem to work as expected in the latest rev. Trying to debug...