Week 11 Lab: Lab 11 — Break the Rule

Attack a queueing system from the inside. Find the exploit, cost it, then design the version that survives you.

17 May 2027

Before the lab#

Pick a real system with a rule you think you could beat. Nothing illegal, and nothing you intend to actually do — this is analysis, not fieldwork.

In the lab#

Attack. In groups, take each system and find the exploit. Be specific. “You could game it” is not an answer; “split a 14-item basket into two 7-item baskets and use the express lane twice, saving four minutes at a cost of thirty seconds” is. Every self-reported priority rule has one of these, and half the systems in the room will turn out to have an exploit that requires no dishonesty at all, just attention.

Cost it. What is the exploit worth per use? What proportion of users would have to find it before the rule stops working? Some rules survive being widely known and some collapse; the difference is worth more than the exploit itself.

Defend. Now design the counter. Then — and this is the part groups skip — state what the counter costs the honest users. Verification is friction, and friction lands on everybody, including the people who were never going to cheat. A rule hardened against a rare exploit at the price of an extra check for everyone is frequently a bad trade, and you should be able to say roughly when.

Present. Four minutes per group. The room votes on which counter it would actually accept as a customer, which is a different question from which one is most effective, and the gap between those two votes is the point of the lab.

Afterwards#

Design briefs are due at the end of week 12. If your design has a rule that sorts on anything a user tells you, today should have convinced you that you need a paragraph on what happens when they lie.