
Control Groups (cgroups) for the Web? - rbanffy
https://www.igvita.com/2016/03/01/control-groups-cgroups-for-the-web/
======
teej
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.

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

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

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

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

~~~
lenish
>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).

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

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

------
yk
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](https://www.youtube.com/watch?v=9wx2TnaRSGs)

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

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

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

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

------
pmontra
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?

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

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

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

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

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

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

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

------
gpvos
And so further turning the browser into an operating system.

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

