Control Groups (cgroups) for the Web? | Hacker News Reader

Control Groups (cgroups) for the Web?

igvita.com

84 pointsrbanffy26 comments

If this existed, I would implement it today. Even better then that, I would insist that our tag manager implement it.

This goes beyond display ads. Your standard ecommerce site is littered with tags from all sorts of things and each one carries risk. You might be running any/all of the following:

- Web behavior analytics tags (Mixpanel, Heap, Optimizely, Google Analytics, etc)

- Site performance tags (New Relic, etc)

- Conversion tracking tags (Adwords, Facebook, + a thousand little ad market platforms)

- Remarketing tags (Facebook, etc)

- Social sharing tags (Facebook, Twitter)

- SSO tags (Facebook, Twitter, Google)

- On-site survey tags

- Live chat tags

... and more

Listing them out now makes me realize how absurd the situation has become with third party tags on our site. Having this feature would go a long way in protecting our site's performance from bad actors.

Or you could just use a self-hosted open source analytics platform, and not worry about the cacophony of bullshit you just mentioned.

Ok, sure. That lets me strike Google Analytics from the list. And of all the vendors on that list, Google is the one I distrust the least.

The reality is that to compete, we need to measure changes to our product, we need to buy advertising, and we need to track the efficacy of our marketing spend. Each of these tags drives value for someone in the organization. Yes, we could create our own A/B testing tools and get rid of Optimizely or build an in-house ad server to handle conversion tracking. But the truth is, those things cost time, money, and software engineers, all of which are in short supply. As we scale up, we have found opportunities to make things first party but we can't (and shouldn't) attempt to rebuild every third party service on our own.

In aggregate, I have no doubt that these tags negatively impact the end customer experience. But going scorched earth isn't the answer. Implementation of a tag manager, careful monitoring of front-end performance, and diligent review and removal of unneeded tags is the balanced approach.

> As we scale up, we have found opportunities to make things first party but we can't (and shouldn't) attempt to rebuild every third party service on our own.

So, you just want to whine then. You acknowledge a problem but are unwilling to do anything to solve it.

Thanks for confirming that.

What problem is this trying to solve? Having a single webpage with full control of the device, but limiting how many resources the ads on it can take? I guess that could be useful on the mobile web. However, the proposed solution is still way too low-level for web developers.

If the problem you're trying to solve is that web pages take up way too many resources (they do), control must be exerted by the browser, on the user's behalf. The only input the web developer should be able to provide is what to prioritize when resources are curtailed. Ideally, all web pages should be stopped completely when they are not the active tab, with background processing allowed for specific purposes, such as receiving notifications for messaging, or playing music. But then the specification should allow the developer to indicate what they need the resources for, instead of just saying "I want some CPU just because". And the primary concern should be how to keep developers from just saying "I want ALL the resources ALL the time" by default until the whole scheme is useless.

>What problem is this trying to solve? Having a single webpage with full control of the device, but limiting how many resources the ads on it can take?

Restricting ad resource usage is the only non-niche answer I've imagined. You could make arguments that games could prioritize input/networking over refresh rate using something of this sort, but it seems like there should be a better mechanism for those kinds of applications -- especially since this proposal would require you to separate your JS into multiple subresources to take advantage of it AFAICT.

Assuming their motivation was in fact to restrict resource usage by ads, I'm not sure this is the right way to go about it. Perhaps if your ad network can't serve resource efficient ads you should change ad networks (or pressure your current ad network to improve).

Ha. I really do love that one Alan Kay quote

> The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. -- Alan Kay.

This is just another example of how the browser should have been built as an OS instead of an app.

No, it's an example of how operating systems have failed to offer consistent ABIs; causing people to build applications in a document viewer.

> This is just another example of how the browser should have been built as an OS instead of an app.

That makes no sense. Should Email be an OS? Should IM/Chat be an OS? Hey its 2016 we don't need to dual boot, we can run VMs.

So everything is an OS into and of itself, nothing interoperates with anything else, and you can say "Look MA, no RAM".

ChromeOS is the closest we have to the idea of "the browser should have been an OS", and frankly its a fucking terrifying idea.

> ChromeOS is the closest we have to the idea of "the browser should have been an OS", and frankly its a fucking terrifying idea.

I think the intended meaning of "OS" was more like "self-contained environment for executing code", rather than "single, user-facing shell on top of hardware drivers", i.e. think Smalltalk image rather than ChromeOS, Windows, Linux+GNU+Gnome, OSX, etc.

It's not like we didn't try: https://en.wikipedia.org/wiki/Java_applet

I watched yesterday Dan Kaminsky's surprisingly related DEF CON 23 talk [0], where he presents a approach to UI security such that one can embed a paypal iframe without the ability of the website to hijack it. In that context, I view the proposal as a way to combat ad stuffing. A site could give guarantees that the ad neither clogs up the browser and could guarantee that the ad is visible.

Plus, the same mechanism could be used to keep the browser responsive, simply by only allowing a tab 95% of the available resources instead of all resources. (And if it is done right, a site could also forbid something like unmuted autoplay videos, by just not giving the ressources to an ad at first.)

I really like the suggestion. It is only an improvement on the 95% of all sites which try to play nice, but an improved experience on most websites is a overall win.

[0] https://www.youtube.com/watch?v=9wx2TnaRSGs

Hopefully the author only means to bring relative shares in from cgroups - absolute limits seem like they would only serve to throttle the browser for no good reason. If you do want to throttle a browser tab, let the user do this in the browser. No reason for that to come from the page markup.

Also, is it realistic that web publishers will have to intentionally deprioritize ads and tracking etc relative to the main site/application? I imagine some people (ad networks) might not be too impressed with this.

Maybe a cool PoC of this would be an "adblocker" type browser extension/feature that automatically deprioritizes known ad/tracking content, but still displays it eventually. Then again, forced "async" or "defer" might be able to achieve this too without a complicated framework.

How about gimme a button to disable CSS3 fonts and HTML5 canvas, webGL and shit, like we used to with Flash.

This overall article made me realize that since modern browsers can use one process per webpage, maybe we should try and run such process in cgroups in order to limit their resource usage.

Maybe this could solve the "facebook makes my fan explode" problem.

It's just an idea.

If we had unprivileged cgroup subtree management in the Linux kernel (which is something that I submitted patches for, but were rejected) then you could actually use cgroups on GNU/Linux with a browser not needing any privileges.

How does that applies to devices with vastly different CPU and network capabilities? Example: my old dual core Galaxy S2 on a 3G connection and my 8 core laptop with 100/50 Mbs fiber. Both are Linux and have cgroups (I googled and Android has them.) I expect the browser to ignore any recommendation on that phone and use 100% of the resources every time. That could change, at least for the network, when the phone is on WiFi. On the other side newer octa core phones on LTE could honor the recommendations every time. One problem is that mobile networks can perform very differently even in the same very small area, just add a couple of meters and one thick wall and performances drop. I wonder if the browser can cope with this variability (probably yes) and if it's worth the trouble to implement the extra performance checks and logic. Is this going to be a desktop only technology?

Another problem is the developer: we could pick horrible choices for those limits and break the usability of the site for everybody but us. We need some tools or heuristics to make sensible choices. It's an extra layer of testing, to be automated by simulating different performance profiles. Should those different profiles reflected into the recommended limits, similar to media queries?

A much simpler solution might look like a whitelisted set of domains/domain patterns that are given priority for network and CPU usage. For example, a meta tag on every page that lists your domain and CDN domain as "primary", and every other domain is then aggressively rate-limited by the browser.

I would love to try something like this.

My use case: I work at a company with a lot of engineers working on our website. Most of our important pages have lots of code from different teams loaded on them - arguably, far too much. We are trying to make it so that different teams code runs parallelized, so failures and slowness are completely independent- but this only makes sense on the back end; in js, it's far too easy for a few slow components to slow down our whole website.

I already use cgroups to limit chrome, though i believe this has little effect when things are leaking. Would prefer official notifications like "this website/extension is bloated garbage" or "warning jquery! amateurs ahead!".

I'd rather have an option to control chrome's memory usage (--memory-model isn't good enough) and discarding of active tabs—always swapping like nuts, might as well use it...

The web is in a complexity spiral. Please don't. If you worry about 3rd party code (which you should), don't embed it.

The idea is nice, but the implementation is really bad. It makes no sense at all to mix CPU control with the hierarchical structure of a DOM tree. Hierarchically different parts of a webpage may use the same (CPU) resources.

To me it makes little sense without parallel script execution and full multithreading support in JavaScript. And I'm not sure that's the way to go, current execution model saves us a lot of trouble.

You could run the problematic script under your own JS interpreter.

And so further turning the browser into an operating system.

Just use Web Workers and let the OS do the scheduling.

Reply on news.ycombinator.com