# Guidelines for delivery of Chrome behavior over the Internet
**Summary**: It's OK to deliver _content_ to Chrome dynamically over the internet,
but Chrome behavior should be a part of the Chrome binary or delivered via
Component Updater.
There are several reasons for this:
* TLS is insufficient to prove categorically that the behavior comes from the
Chrome organization (due primarily to the risk that malware, enterprise
security software, or governments have arranged to install extra TLS root
certificates). So you'd need to build a custom signature verification scheme.
This is hard (per the mantra "don't roll your own crypto"). The code is
fiddly; you'd need to sustain processes for key rotations, revocation,
detecting private key compromise etc.
* Even if the transport is secure, a compromised server could show fake Chrome
UI and spoof websites.
* Users expect Chrome behavior to be part of the Chrome download, and are
surprised when it dynamically changes. Chrome does support dynamically
changing behavior in several ways, such as the Variations framework. But
these mechanisms are well-documented and controlled by e.g. enterprise
policies, so it's better to use one of them than re-inventing the wheel
-- and they conveniently support out-of-band signing. Dynamic behavior
also adds a combinatorial factor which makes it harder to test or fuzz
Chrome, or to put in place simple reliable security defenses which apply
universally.
What do we mean by 'behavior'? 'Behavior' is anything that a reasonable user
would consider to be 'part of Chrome' as opposed to content displayed by
Chrome. So, the feed of articles is definitely 'content' whereas the settings
pages are 'behavior'. Web pages themselves are 'content' but any action which
the browser applies to those pages is 'behavior'. Generally speaking, code
which runs in the browser process is likely to be 'behavior'. Configuration
information is likely to be 'behavior' too if it meaningfully alters Chrome's
functionality.
A solution is available for fairly-dynamic Chrome behavior:
[Component Updater](https://chromium.googlesource.com/chromium/src/+/main/components/component_updater/README.md).
Components can be updated without an update to Chrome itself, which allows
them to have faster or desynchronized release cadences. (The same [signing
technology](https://g3doc.corp.google.com/company/teams/chrome/intelligence/serving_on_device_models.md?cl=head)
can be used elsewhere, but this should be avoided if possible
because component updater has documentation and controls such as enterprise
policies that might need to be replicated for per-feature signing and code
delivery schemes).