Tensions in Practice: A fixed operation in tension with legitimate query choice¶
Query construction · values and operators
A catalogue contains four records: red-small, red-large, blue-small and blue-large. A simple search lets users supply a color and size but always requires both to match. A richer search also lets them explicitly choose “both” or “either.” The useful extension changes the operation through a declared field; words inside a color value remain literal data.
Keep the operation fixed
Offer one predictable conjunction without exposing a user-selectable operation grammar.
Support legitimate alternatives
Let a user ask for either matching color or matching size through a bounded operation choice.
Why these aims pull against each other
A fixed template cannot express the legitimate either-condition query. Supporting it adds a control input and an evaluator contract that must remain distinct from ordinary values.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Fixed conjunction
Bind color=red and size=small to the fixed AND query.
- What it protects
- Only one operation shape needs to be exposed and maintained.
- What it costs
- The user cannot request the three-record OR result through this feature.
- When it fits
- The product intentionally offers conjunction-only search and does not need user-selected alternatives.
Illustration note: The finite setting and values are editorial assumptions, not measured effects or recommended operating settings. The fixed template is assumed correctly implemented. An input value spelling “OR” is still a literal value, not an instruction.
Declared operators
Expose a typed choice containing only AND and OR, separately from bound color and size values; the sketch selects OR.
- What it protects
- The user can express both conjunction and disjunction without treating value text as executable structure.
- What it costs
- The additional operator grammar, permission scope and evaluation paths require implementation and ongoing maintenance.
- When it fits
- Both operations are authorized product capabilities, and every relevant interpreter preserves the declared value/control distinction.
Illustration note: The finite setting and values are editorial assumptions, not measured effects or recommended operating settings. This is an editorial bounded query language, not arbitrary user code or a proof of security for downstream parsers.
What this illustration does—and does not—establish
Control/Data Channel Confusion Control / Data Channel Confusion: Zero Surface versus Lost Expressiveness (Sign/Direction) supplies the legitimate expressiveness issue. The catalogue and two typed operators instantiate its narrow explicit capability path.
- No real service, exploit payload or universal security guarantee is described.
- The allowed operation set is fixed by the server in this model; user control of the evaluator itself would change the boundary.
- Supporting OR does not require accepting executable text inside data values.
Source entries
Control / Data Channel Confusion
Control / Data Channel Confusion: Zero Surface versus Lost Expressiveness (Sign/Direction) supplies the conflict examined here.
Zero Surface versus Lost Expressiveness (Sign/Direction)
Diagnostic: ask whether any intended behaviour requires data to reach control; where it does, the design needs a *narrow, explicit* capability path (the intended crossing) rather than total separation, distinguishing the authorised channel from the confused one — pure isolation can break the feature, not just the attack.
Structural Tensions
Diagnostic: ask whether the adversary can affect *how* the parser is built, not just what it consumes; where they can reach the construction (a configurable query template, a user-editable tool definition), the structural guarantee is void because the boundary marker is no longer out of their reach.