From 5d129074590d62a00969715721ecfb4fcc98714b Mon Sep 17 00:00:00 2001 From: safenestdev Date: Wed, 26 Aug 2026 08:12:09 +0200 Subject: [PATCH] docs: describe video profanity as a capability, not a mechanism Public changelog should never explain exactly how a detection gap could be exploited. Rephrased to describe what shipped without the evasion-path detail. --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 123ce78..47b10d7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,7 +11,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - **`categories` on `VideoAnalysisResult`.** `analyzeVideo` already computed a deduped list of visual harm categories across every flagged frame server-side, but only folded it into the free-text `rationale` string — no field existed to read it from without parsing `frame_results` yourself. A client integration that expected a top-level `categories` field (matching every other detection endpoint) got silent empty results instead of an error. **Requires the API deployed on or after 2026-08-26.** -- **`flagProfanity` on `analyzeVideo`, and `profanity` on `VideoAnalysisResult`.** Closes the evasion path left open by shipping profanity on `analyzeImage` alone (2.28.0): burning the same text into a video frame instead of a still image previously never reached the word-list check. The API already runs OCR per frame for video (same vision call as the image endpoint) — it's now aggregated across every frame that has text and checked the same way, with identical precedence to `flagProfanity` elsewhere: explicit per-request value wins, otherwise the account's `default_flag_profanity` setting applies. Only meaningful when at least one frame actually contains OCR text — a video with no on-screen text never gets a `profanity` field regardless of this flag. **Requires the API deployed on or after 2026-08-26.** +- **`flagProfanity` on `analyzeVideo`, and `profanity` on `VideoAnalysisResult`.** Extends the `flagProfanity`/`profanity` pair from `analyzeImage` (2.28.0) to video: the same free, deterministic, additive word-list check now also runs on video, with identical precedence to `flagProfanity` elsewhere — explicit per-request value wins, otherwise the account's `default_flag_profanity` setting applies. Only meaningful when the video actually contains on-screen text; a video with none never gets a `profanity` field regardless of this flag. **Requires the API deployed on or after 2026-08-26.** ## [2.29.0] - 2026-08-26