obsidian-vault/work/ashby-reviews/EP2-Candidate-848-review.md

EP2 TD Review - Candidate 848

Scores

1. Does the solution proposed effectively solve the goal of the project?
   3

   Yes. The proposal covers the actual MVP: fetch and store TDS with ETag validation, generate third-party WebKit content rules through TrackerRadarKit, support a current-site protection toggle, reload after protection changes, and provide an allowlist screen. It also starts from BareBonesMobileBrowser, which matters. This is not written as if the candidate can simply drop into the full DuckDuckGo browser architecture unchanged.

2. Can they break down the project and extract what's important and de-risk the project?
   3

   This is one of the stronger parts of the submission. The candidate identifies the places where this feature can fail in ways users would actually notice: first navigation before rules are installed, offline first launch, failed TDS download, failed rule compilation, allowlist state drifting away from compiled state, cache misses, and WebKit's rule-count ceiling. The embedded TDS baseline is the right call. It means first launch with no network still has a protected path, which was the big calibrated gap in Candidate 7a2.

   The phased plan is also sensible: prove blocking behavior first, then build the data lifecycle, then the toggle and allowlist UI.

3. Are different approaches being considered with pros/cons and are the choices justified?
   3

   The tradeoff analysis is specific and useful. They explain why WKContentRuleList fits better than Safari extensions, WKNavigationDelegate interception, NSURLProtocol, or DNS/VPN filtering. They also compare ETag refresh against always downloading, compiled-list lookup against recompiling, exact-host allowlisting against eTLD+1, embedded TDS against download-only startup, and fail-closed behavior against best-effort behavior.

   The choices are tied to real failure modes, not just generic pros/cons. That is exactly what I want from this kind of technical design.

4. Are they able to technically apply good practices to solve the problem and demonstrate they understand the language/platform?
   2

   The platform understanding is clearly strong. Good signals include WKContentRuleListStore lookup before compile, deterministic identifiers that include the inputs affecting rule output, off-main TDS decoding / JSON encoding / rule compilation, commit-after-compile allowlist mutations, atomic TDS+ETag persistence, and a behavioral test strategy based on observing whether a controlled tracker endpoint receives a request.

   The concurrency point is worth being precise about: the candidate does not propose compiling rules on the main thread. The submission explicitly says JSON encoding and compilation run off the main thread, with only userContentController application and UI work on the main actor. Given the TDS size and compile cost, that is the right direction.

   I am still scoring this as a 2 rather than a 3 because the implementation handoff is not quite concrete enough for the starter app. The original prompt asks for enough detail that another engineer with zero context could implement tracker blocking. The design says the first navigation is gated behind .ready, but it does not spell out how BareBonesMobileBrowser actually enforces that: where a pending URL is stored, how address-bar submissions are blocked or queued, what happens to back/forward/reload while .loading, and whether this sits in a view model, coordinator, or navigation delegate. For a browser, that wiring is not a small detail. It is the part that prevents the user from accidentally loading before rules are applied.

   Two other details should be treated as decisions needing approval rather than implementation defaults: raising the scaffold's deployment target, and offering a catastrophic "Continue without protection" path.

5. Is the document well-structured and easy to understand/read?
   3

   The document is dense, but it is dense in a useful way. It moves cleanly from problem statement to risks, decisions, scope, architecture, flows, storage, concurrency, UI states, and testing. The tables and scenario matrix make the failure behavior easy to audit.

Total

14 / 15

Overall Recommendation

3 - Yes

Feedback to Share With Candidate

Strong submission overall. The embedded TDS baseline, deterministic WKContentRuleListStore identifiers, lookup-before-compile path, off-main JSON/rule-list work, and commit-after-compile allowlist transaction are all solid choices for this feature. They show you understood that this is not just about generating rules. It is about keeping the applied rule list, stored inputs, and UI state consistent even when downloads or compiles fail.

The test plan is also a good sign. Verifying tracker blocking by checking whether a controlled endpoint receives a request is the right kind of proof here, since WebKit does not give us a neat callback for blocked subresources.

The main thing I would tighten before implementation is the BareBones integration detail. The design says navigation is gated behind .ready, but I would like to see the exact mechanics: where the pending navigation lives, how address-bar submits/back-forward/reload are handled while rules are compiling, and which object owns that state. That is the bit that makes the privacy guarantee real in the starter browser.

A couple of policy-ish items also need clearer framing. Moving off the scaffold's iOS 13 target may be reasonable, but it should not be assumed as part of the technical path. Same for the catastrophic "Continue without protection" option: that needs product/security agreement, not just an implementation decision.

Calibration Notes

Compared with Candidate 7a2, this submission closes the main calibrated gaps:

• It handles first launch with no network by bundling an embedded TDS baseline.
• It discusses WKContentRuleListStore reuse explicitly and designs identifiers around the inputs that affect compiled output.
• It treats allowlist changes as a state consistency problem, not just a UI toggle.
• It includes recovery paths for bad downloads, bad compiles, stale cache, and catastrophic store failure.
• It considers exact-host allowlisting and validates that choice against DuckDuckGo behavior.

The score comes down on technical practices because the design stops one step short of showing how the loading gate is enforced in the actual starter browser UI. The idea is right. The integration detail is the missing piece.

Against the original prompt, the submission covers the requirements well: TDS download/storage, third-party-only blocking, allowlist toggle and reload, allowlist screen, scope, tradeoffs, error handling, performance, architecture, and testing. The main prompt gap is the final instruction: the document should be detailed enough for an engineer with zero context to implement tracker blocking. The core design is there, but the exact starter-app integration path is still too implicit.