Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address limits on unconstrained inputs #520

Merged
merged 7 commits into from
Jan 16, 2023
Merged

Address limits on unconstrained inputs #520

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5c28a2d
Address limits on unconstrained inputs
annevk Jan 9, 2023
815c387
acknowledge that limits are a tracking vector
annevk Jan 9, 2023
09074df
say quite a bit more about limits
annevk Jan 10, 2023
f971dee
Update infra.bs
annevk Jan 11, 2023
9f883f8
final review nits + my own
annevk Jan 11, 2023
b8e8f5a
nit + acks
annevk Jan 12, 2023
c645968
reword the end
annevk Jan 16, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions infra.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,39 @@ as well as the single algorithm would. Therefore performance is best left as a f
over.

annevk marked this conversation as resolved.
Show resolved Hide resolved

<h3 id=algorithm-limits>Avoid limits on algorithm inputs</h3>

<p>A document using the Infra Standard generally should not enforce specific limits on algorithm
inputs with regards to their size, resource usage, or equivalent. This allows for competition among
user agents and avoids constraining the potential computing needs of the future.

<p tracking-vector>Nevertheless, user agents may impose <a>implementation-defined</a> limits on
otherwise unconstrained inputs. E.g., to prevent denial of service attacks, to guard against running
out of memory, or to work around platform-specific limitations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inspired by #520 (comment):

Suggested change
out of memory, or to work around platform-specific limitations.
out of memory, or to work around platform-specific limitations. Specifications should define what
happens when input exceeds such an <a>implementation-defined</a> limit.

I'm not sure that's exactly the right wording or location.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can require this. At the very least it should be a follow-up discussion. E.g., consider out-of-memory. Currently implementations can impose limits and throw an exception or they can let the entire process crash. We wouldn't want specifications to constrain that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's already "should" rather than "must", but maybe with "if doing so is reasonable"? I agree that we won't be able to do it in all cases, but I wanted to encourage people to try. Even in the case of memory limits, something should specify the type of error thrown if one is thrown.

I have no problem making that a follow up discussion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#523.


<p class=note>Global resource limits can be used as side channels through a variant on a resource
exhaustion attack, whereby the attacker can observe whether a victim application reaches the global
limit. Limits could also be used to fingerprint the user agent, but only if they make the user agent
more unique in some manner, e.g., if they are specific to the underlying hardware.

<p class=example id=example-algorithm-limits>An API that allows creating an in-memory bitmap might
be specified to allow any dimensions, or any dimensions up to some large limit like JavaScript's
<code>Number.MAX_SAFE_INTEGER</code>. However, implementations can choose to impose some
<a>implementation-defined</a> (and thus not specified) limit on the dimensions, instead of
attempting to allocate huge amounts of memory.

<p class=example id=example-algorithm-limits-language>A programming language might not have a
maximum call stack size specified. However, implementations could choose to impose one for practical
reasons.

<p>As code can end up depending on a particular limit, it can be useful to define a limit for
interoperability. Sometimes, embracing that is not problematic for the future, and can make the code
run in more user agents.

<p>It can also be useful to constrain an <a>implementation-defined</a> limit with a lower limit.
I.e., ensuring all implementations can handle inputs of a given minimum size.


<h3 id=algorithm-declaration>Declaration</h3>

<p>Algorithm names are usually verb phrases, but sometimes are given names that emphasize their
Expand Down Expand Up @@ -1995,12 +2028,16 @@ Chris Rebert,
Daniel Ehrenberg,
Dominic Farolino,
Gabriel Pivovarov,
Ian Hickson,
Jakob Ackermann<!-- das7pad; GitHub -->,
Jake Archibald,
Jeff Hodges,
Jeffrey Yasskin,
Jungkee Song,
Leonid Vasilyev,
Maciej Stachowiak,
Malika Aubakirova,
Martin Thomson,
Michael™ Smith,
Mike West,
Ms2ger,
Expand Down