A banner-presence assertion checks the wrong object: the DOM tells you a dialog rendered and a button exists, while the cookie jar tells you what the page actually did. Dropbox's framing is the same one, that a banner can look correct while the preference behind it is not being applied, which is why the assertion sits on the cookies rather than on the dialog [7].
Dropbox did not publish the size of the resulting matrix, so here is a floor. A user has three moves available, accept, decline, or customise [12]. Each move has to be observed at three points, before the selection, after it, and after a reload [7]. Across 200 surfaces [2] that is 3 x 3 x 200, or 1,800 cookie-state observations per full pass, before you add a single locale, region, or experiment variant [14]. For that arithmetic to transfer to your estate you need Dropbox's surface count and Dropbox's consent UI. If your banner offers a per-vendor toggle list instead of three buttons, the first factor is not 3, and the pass gets expensive in a hurry.
The design decision I would copy is keeping the classification out of the binary. The approved cookie list and the known exceptions live outside the auditor's source, so the Privacy team can revise them without engineers cutting a release [11]. That is the right coupling, because a legal taxonomy changes on legal's schedule and not on the deploy train. It also means that file is now the test oracle. An exception added because a cookie really is strictly necessary and an exception added because the audit was noisy on a Friday produce identical green results, so I would want per-entry ownership and reviewed diffs on that file before I trusted a clean run.
The expensive part of this build is not the browser automation. Dropbox says its Privacy and Engineering teams first had to agree which websites are in scope, what banner behaviour counts as a violation, and which third-party cookies and artifacts get tracked separately [9]. That agreement is a written inventory of every cookie you set and the reason you set it. A team that already has that inventory can get an auditor running quickly. A team that does not is buying a taxonomy project with a headless browser attached to it.
The part that decays is the target list. Dropbox notes that its URLs change constantly as pages launch, retire, redirect, localise, or get pulled into experiments [3], and the rule set has to distinguish a missing banner that is a defect from one that is expected on a page no longer in use [10]. So the suite carries two artifacts that rot in opposite directions: the set of URLs worth visiting, and the set of URLs excused from having a banner at all. A retired page stays retired until someone links to it from a campaign.
