0

More details on data processing for Rule Of 2.

People have questions about primitive functions on opaque data, so explain a bit
more about how parsing/deserializing/et c. is different.

Bug: None
Change-Id: I645b916a98cd616c710a53cdda22e60d80ee951b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2737520
Reviewed-by: Adrian Taylor <adetaylor@chromium.org>
Reviewed-by: Adrian Taylor <adetaylor@google.com>
Commit-Queue: Chris Palmer <palmer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#881050}
This commit is contained in:
Chris Palmer
2021-05-10 16:59:48 +00:00
committed by Chromium LUCI CQ
parent e5f51c8ae0
commit e4b62db571

@ -104,6 +104,22 @@ good) or [origin
isolation](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=IsolateOrigins)
(even better).
### Processing, Parsing, And Deserializing
Turning a stream of bytes into a structured object is hard to do correctly and
safely. For example, turning a stream of bytes into a sequence of Unicode code
points, and from there into an HTML DOM tree with all its elements, attributes,
and metadata, is very error-prone. The same is true of QUIC packets, video
frames, and so on.
Whenever the code branches on the byte values it's processing, the risk
increases that an attacker can influence control flow and exploit bugs in the
implementation.
Although we are all human and mistakes are always possible, a function that does
not branch on input values has a better chance of being free of vulnerabilities.
(Consider an arithmetic function, such as SHA-256, for example.)
## Solutions To This Puzzle
Chrome Security Team will generally not approve landing a CL or new feature