Scope Brazil2026ElectionFilter to viewers in Brazil - #64
Conversation
Brazil2026ElectionFilter is added to the For You pre-scoring chain
unconditionally and never reads the viewer's country, so it currently
applies to every viewer in every country rather than to the viewers the
Electoral Court order covers.
The scoping mechanisms already exist and were simply unused:
- ScoredPostsQuery carries country_code
- Filter::enable(&self, query) gates a filter per request, and is
honoured by the pipeline at candidate_pipeline.rs:352
Eight other filters in the same chain already use enable() for this
purpose (VideoFilter, TopicIdsFilter, NewUserMinEngagementFilter,
InventoryHoldoutFilter and others).
Unknown or empty country codes leave the filter disabled, matching the
existing convention for legal withholding in visibility-filtering, where
viewer_in_withheld_country returns false when the viewer country is not
known.
Adds tests for the enabled, disabled, case-insensitive and unknown-country
cases. Existing tests call filter() directly and are unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Hi. |
|
Per AI: "The fundamental premise of Brazilian electoral law is that a recommendation engine is an active publisher, not a passive host. When an algorithm selects a political post and injects it into a user’s "For You" or "Home" feed, it is a deliberate act of algorithmic promotion. Therefore, the TSE mandates that any platform utilizing a recommendation system must remove reported candidate profiles and their organic content from algorithmic distribution altogether." From Twitter's POV, being an "active publisher" might make it easier to sue for libel and so on. From everyone else's view, it's too bad Twitter can't just ditch their highly-flawed recommendation engine & let tweets stand on their own. |
Brazil2026ElectionFilternever reads the viewer's country, so as written it applies to every For You request in every country rather than to the viewers the Electoral Court order covers.Evidence
should_removetakes only the candidate and the viewer's follow list (filter L1363), and the filter is added to the pre-scoring chain unconditionally (pipeline L368).Both mechanisms needed to scope it already exist and are unused:
ScoredPostsQuerycarriescountry_code(query.rs L46)Filter::enable(&self, query)gates a filter per request (filter.rs L21) and is honoured by the pipeline (candidate_pipeline.rs L352)Eight other filters in the same chain already use
enable()for exactly this:VideoFilter,TopicIdsFilter,NewUserMinEngagementFilter,InventoryHoldoutFilterand others.There is also a layering signal. Every other jurisdiction-scoped rule in the repo lives in
visibility-filteringand checks viewer country. No filter inhome-mixer/filters/reads viewer country at all, so this is the only geo-scoped rule in a service with no geo-scoping convention.Change
Adds an
enable()override gating the filter oncountry_code == "br", case-insensitively.Unknown or empty country codes leave the filter disabled, which matches the existing convention for legal withholding:
viewer_in_withheld_countryinvisibility-filtering/rules/tes_rules.rsreturnsfalsewhen the viewer country is not known. Happy to invert that to fail-closed if you would rather over-apply than under-apply on unknown geo.Adds four tests. Existing tests call
filter()directly and are unaffected.If this is intentional
Applying globally does guarantee compliance regardless of geolocation accuracy, which matters with VPNs and travel. If that is the reasoning, please close this, though a comment recording the decision might be worth adding, since the surrounding conventions read the other way.
Caveat
home-mixerships noCargo.toml, so I could not compile or run the tests. The file isrustfmt --checkclean under edition 2021. Verification of the change is on you.