Open Source Signal #111 / Сигнал відкритих джерел

Editorial frame

What this is: A weekly tool radar for public-interest OSINT. Each item separates tool output from evidentiary conclusion and records access, provenance, privacy and reproducibility limits.

What this is not: Doxxing, stalking, credential hunting, leaked-database abuse, private-person deanonymization, unsafe facial recognition, live targeting, unauthorised access, penetration testing or an AI-generated verdict.

Rubric map

🧰 Tool of the Week

🗂️ Tool Discovery

🏢 Corporate Identity

🗄️ Web Archive Discovery

🗺️ Historical Geography

🧾 Media Metadata

🛡️ Evidence Capture

🧰Tool of the WeekІнструмент тижня

#01

OpenOSINT 2.29.0 adds RDAP and keeps AI-assisted investigation useful only when tool calls, provenance and network boundaries remain explicit

Source: OpenOSINT / PyPI / project changelog · Version 2.29.0 released 17 September 2026; checked 19 September 2026

What happened

OpenOSINT 2.29.0 added a structured RDAP domain-lookup tool. The preceding 2.28.0 release also changed the web UI so server-held provider keys are not used for callers when the service is bound to a non-loopback interface, and remote use disables the breach-search path. The project exposes a CLI, REPL, web interface and MCP server, and its newer graph layer stores FollowTheMoney-style entities with statement-level provenance and a human review queue for possible same-as matches.

Why it matters

The interesting part is not that an LLM can call OSINT tools. It is that the project is moving toward inspectable tool execution, provenance-bearing graph records, non-destructive entity matching and explicit network-exposure rules. Those properties make an agent easier to audit than a chat transcript containing unsupported conclusions.

How to use it

Run it locally for bounded public-source tasks, preserve raw tool outputs and provenance, and require human approval before accepting entity matches. Treat every pivot as a new query with its own scope; disable or omit modules that are unnecessary for the research question.

Limits

An orchestration layer does not make underlying sources complete or correct. Some bundled capabilities are dual-use and inappropriate for ordinary public-interest research. LLM planning can still choose a poor pivot or over-interpret a result, so the evidence layer must remain separable from the agent's narrative.

OpenOSINT 2.29.0 додає RDAP і лишається корисним для AI-дослідження лише тоді, коли виклики інструментів, походження даних і мережеві межі явно зафіксовані

Джерело: OpenOSINT / PyPI / project changelog · Версію 2.29.0 випущено 17 вересня 2026; перевірено 19 вересня 2026

Що сталося

OpenOSINT 2.29.0 додав структурований пошук доменів через RDAP. Попередня версія 2.28.0 також змінила вебінтерфейс так, щоб серверні ключі провайдерів не використовувалися для зовнішніх запитів, якщо сервіс слухає не лише loopback-інтерфейс; для віддаленого режиму вимикається й пошук у витоках. Проєкт має CLI, інтерактивний режим, вебінтерфейс і MCP-сервер, а новіший графовий шар зберігає сутності у форматі FollowTheMoney з походженням тверджень і ручною чергою перевірки можливих збігів сутностей.

Чому це важливо

Цінність тут не в самому факті, що LLM може викликати OSINT-інструменти. Важливіше, що проєкт рухається до перевірюваних викликів, графових записів із походженням, неруйнівного зіставлення сутностей і явних правил мережевого доступу. Такий агент краще піддається аудиту, ніж чат із висновками без видимих джерел.

Як це застосувати

Запускайте локально для чітко обмежених завдань із відкритими джерелами, зберігайте сирі результати й походження даних та вимагайте ручного підтвердження перед прийняттям збігів сутностей. Кожен перехід до нового об'єкта оформлюйте як окремий запит зі своїми межами; непотрібні модулі вимикайте.

Обмеження

Оркестраційний шар не робить первинні джерела повними чи правильними. Частина вбудованих можливостей має подвійне призначення й не підходить для звичайного суспільно важливого дослідження. LLM усе ще може обрати хибний напрямок або переоцінити результат, тому доказовий шар має залишатися відокремленим від тексту агента.

tool-of-weekai-agentrdapmcpprovenancehuman-review

🗂️Tool DiscoveryПошук інструментів

#02

OSINT.dev treats tool discovery as a taxonomy and source-registry problem rather than another unversioned bookmark list

Source: OSINT.dev · Public technical preview, checked 19 September 2026

What happened

OSINT.dev is a curated technical platform that currently exposes 17 macro-categories, 60 categories and 54 cross-cutting tags. Its source registry lists 24 tracked upstream sources, including Bellingcat's Toolkit, Common Crawl, Copernicus Data Space, GLEIF, OpenSanctions, ExifTool and official API documentation. The site explicitly distinguishes the timestamp of a tool record from a fresh audit of the tool itself.

Why it matters

The failure mode of most OSINT directories is silent decay: a link survives while pricing, coverage, API behaviour or safety properties change. A catalogue that records source provenance, taxonomy and access level can be monitored and diffed more systematically.

How to use it

Use it to discover candidates, then open the upstream documentation and verify current behaviour before a real investigation. Record which catalogue entry led you to the tool, but cite the primary tool or data provider for substantive findings.

Limits

The platform labels itself a technical preview. Editorial inclusion is not a guarantee of future availability, completeness or suitability for a specific jurisdiction or investigation.

OSINT.dev розглядає пошук інструментів як задачу таксономії та реєстру джерел, а не як ще один невірсіонований список закладок

Джерело: OSINT.dev · Публічне технічне прев'ю, перевірено 19 вересня 2026

Що сталося

OSINT.dev — кураторська технічна платформа, яка зараз показує 17 макрокатегорій, 60 категорій і 54 наскрізні теги. Реєстр містить 24 відстежувані джерела, серед яких Bellingcat Toolkit, Common Crawl, Copernicus Data Space, GLEIF, OpenSanctions, ExifTool та офіційна документація API. Сайт прямо попереджає: дата запису про інструмент не означає, що сам інструмент щойно пройшов новий аудит.

Чому це важливо

Типова проблема OSINT-каталогів — тихе старіння: посилання живе, а ціна, покриття, поведінка API чи безпекові властивості вже змінилися. Каталог із походженням запису, таксономією та рівнем доступу значно легше системно перевіряти й порівнювати в часі.

Як це застосувати

Використовуйте каталог для пошуку кандидатів, але перед реальною роботою переходьте до первинної документації й перевіряйте поточну поведінку інструмента. Можна фіксувати, через який запис ви його знайшли, але змістовні висновки посилайте на первинний сервіс або постачальника даних.

Обмеження

Платформа сама позначає себе як технічне прев'ю. Наявність у каталозі не гарантує майбутню доступність, повноту чи придатність для конкретної юрисдикції або розслідування.

tool-discoverycataloguetaxonomysource-registrymaintenance

🏢Corporate IdentityЮридичні особи

#03

GLEIF's API resolves legal entities, identifiers and reported ownership relationships without turning a fuzzy name match into corporate proof

Source: Global Legal Entity Identifier Foundation · Official API documentation, checked 19 September 2026

What happened

The GLEIF API exposes the LEI search engine through filters, full-text and field-specific queries, fuzzy matching of names and addresses, and relationship data for legal entities. It also maps related identifiers such as BIC and ISIN and is backed by GLEIF's Golden Copy reference data.

Why it matters

Corporate investigations often break when names are treated as identifiers. LEI gives a stable entity key and can expose reported parent-child relationships, making it useful as a reconciliation layer between company registers, sanctions records, procurement data and financial disclosures.

How to use it

Store the LEI, legal name, jurisdiction, registration identifier, entity status and relationship record separately. Use fuzzy search only to generate candidates; confirm the final entity with identifiers and jurisdiction-specific records.

Limits

Not every company has an LEI, and relationship records reflect the reporting framework and available reference data rather than a complete map of beneficial ownership. A fuzzy match is a search aid, not identity confirmation.

API GLEIF зіставляє юридичні особи, ідентифікатори та заявлені зв'язки власності без підміни корпоративного доказу нечітким збігом назви

Джерело: Global Legal Entity Identifier Foundation · Офіційна документація API, перевірено 19 вересня 2026

Що сталося

API GLEIF відкриває пошук у системі LEI через фільтри, повнотекстові й польові запити, нечітке зіставлення назв та адрес і дані про зв'язки юридичних осіб. Також доступні пов'язані ідентифікатори на кшталт BIC та ISIN; основою є еталонні дані Golden Copy GLEIF.

Чому це важливо

Корпоративні розслідування часто ламаються тоді, коли назву компанії використовують як ідентифікатор. LEI дає стабільний ключ сутності й може показувати заявлені зв'язки «материнська–дочірня», тому добре працює як шар зіставлення між реєстрами компаній, санкційними списками, закупівлями та фінансовою звітністю.

Як це застосувати

Окремо зберігайте LEI, юридичну назву, юрисдикцію, реєстраційний номер, статус сутності та запис про зв'язок. Нечіткий пошук використовуйте лише для формування кандидатів; фінальну сутність підтверджуйте ідентифікаторами й реєстрами конкретної юрисдикції.

Обмеження

LEI має не кожна компанія, а записи про зв'язки відображають правила звітності й доступні довідкові дані, а не повну карту бенефіціарної власності. Нечіткий збіг — це пошукова підказка, а не підтвердження тотожності.

corporate-identityleientity-resolutionownershipreference-data

🗄️Web Archive DiscoveryПошук у вебархівах

#04

Common Crawl's CDX index lets researchers find historical captures first and fetch only the records needed for evidence review

Source: Common Crawl · Official index service and documentation, checked 19 September 2026

What happened

Common Crawl provides a CDX URL index across its archived web collections. Researchers can query for URL patterns, identify captures and then retrieve the relevant archived records. The underlying crawl data and indexes are freely available through AWS Open Data; Common Crawl recommends its Columnar Index for large-scale filtering rather than overloading the interactive URL index.

Why it matters

Archive search and evidence retrieval are different operations. Querying the index first makes large historical-web investigations cheaper and more reproducible because the analyst can preserve exactly which collection, capture timestamp and record locator produced the evidence object.

How to use it

Record the Common Crawl collection, exact query, capture timestamp and record locator before downloading content. Hash the extracted evidence object and keep the raw archive reference so another researcher can repeat the retrieval.

Limits

Common Crawl coverage is selective and crawl-dependent. Absence from an index does not prove a page never existed, and an archived copy does not prove that the page's claims were true when published.

CDX-індекс Common Crawl дозволяє спочатку знайти історичні збереження, а вже потім завантажувати лише потрібні записи для доказової перевірки

Джерело: Common Crawl · Офіційний індекс і документація, перевірено 19 вересня 2026

Що сталося

Common Crawl надає CDX-індекс URL для своїх архівних вебколекцій. Дослідник може знайти потрібні адреси або шаблони адрес, визначити наявні збереження, а потім отримати відповідні архівні записи. Вихідні дані й індекси доступні через AWS Open Data; для масового аналізу Common Crawl радить Columnar Index замість перевантаження інтерактивного індексу URL.

Чому це важливо

Пошук в архіві та отримання доказового об'єкта — різні операції. Попередній запит до індексу здешевлює й робить відтворюванішими великі дослідження історичного вебу: можна точно зафіксувати колекцію, час збереження та локатор запису, з якого отримано матеріал.

Як це застосувати

До завантаження вмісту фіксуйте колекцію Common Crawl, точний запит, час збереження та локатор запису. Для вилученого об'єкта рахуйте контрольну суму й зберігайте посилання на сирий архівний запис, щоб інший дослідник міг повторити отримання.

Обмеження

Покриття Common Crawl вибіркове й залежить від конкретних обходів. Відсутність сторінки в індексі не доводить, що її ніколи не існувало, а архівна копія не доводить правдивість опублікованих на ній тверджень.

web-archivescommon-crawlcdxhistorical-webreproducibility

🗺️Historical GeographyІсторична географія

#05

OpenHistoricalMap makes geography time-aware, which can prevent present-day maps from being projected backward into older events

Source: OpenHistoricalMap · Official project and API pages, checked 19 September 2026

What happened

OpenHistoricalMap is a community-led map of changes in human and physical geography across time. Its underlying data can be downloaded or queried through open APIs; the project also provides Overpass-style exports and regularly updated bulk data. The project says its data are dedicated to the public domain except where noted otherwise.

Why it matters

A road, railway, boundary, building name or settlement geometry visible today may not have existed in the same form at the date of an older photograph, testimony or incident. A time-aware map can generate better historical geolocation candidates and expose anachronisms.

How to use it

Treat OHM as a candidate-generating layer. Record feature dates and source tags where present, compare with contemporary maps or imagery, and preserve the queried data snapshot for the relevant time window.

Limits

Coverage and dating depend on community contributions and source quality. A mapped historical feature is not automatically authoritative, and absence from the map is not evidence of absence on the ground.

OpenHistoricalMap додає до географії часовий вимір і допомагає не проєктувати сучасну карту назад на події минулих років

Джерело: OpenHistoricalMap · Офіційні сторінки проєкту та API, перевірено 19 вересня 2026

Що сталося

OpenHistoricalMap — спільнотний проєкт, що картографує зміни людської та фізичної географії в часі. Вихідні дані можна завантажувати або отримувати через відкриті API; доступні також Overpass-подібні вибірки та регулярні повні дампи. Проєкт заявляє, що дані передано до суспільного надбання, якщо окремо не зазначено інше.

Чому це важливо

Дорога, залізниця, межа, назва будівлі чи геометрія поселення, які видно сьогодні, могли не існувати в такому вигляді на дату старого фото, свідчення або події. Карта з часовим виміром допомагає формувати кращі історичні геолокаційні гіпотези й помічати анахронізми.

Як це застосувати

Використовуйте OHM як шар для формування гіпотез. Фіксуйте дати об'єктів і позначені джерела, якщо вони є, звіряйте з картами чи знімками відповідного періоду та зберігайте вибірку даних для потрібного часового вікна.

Обмеження

Покриття й датування залежать від внесків спільноти та якості джерел. Нанесений історичний об'єкт не стає автоматично авторитетним доказом, а відсутність на карті не доводить відсутність на місцевості.

historical-geographymappinggeolocationopen-datatime

🧾Media MetadataМетадані медіа

#06

ExifTool remains useful when metadata are preserved as fields with provenance, not treated as an authenticity verdict

Source: ExifTool · Official version history and documentation, checked 19 September 2026

What happened

ExifTool reads and writes metadata across a wide range of media and document formats. Its 2026 development history includes expanded timed-GPS decoding, Exif 3.1 tags, Garmin FIT support, stricter metadata validation and several security fixes. The tool can expose timestamps, camera and device fields, embedded GPS, editing metadata and format-specific maker notes when those fields are actually present.

Why it matters

Metadata are strongest as structured leads that can be compared with scene content and source history. Keeping exact tag names and raw values avoids the common mistake of turning one convenient field such as DateTimeOriginal or GPS into a complete account of where and when an image was made.

How to use it

Hash and preserve the original file first, run ExifTool read-only for the initial extraction, save the exact command and output, and corroborate decisive fields with visual chronology, source history and independent location evidence.

Limits

Metadata may be stripped, rewritten, inherited during export or deliberately falsified. Social platforms often remove fields. Tool output therefore supports a metadata claim, not the truth of the depicted event.

ExifTool лишається корисним, якщо метадані зберігати як поля з походженням, а не перетворювати на вердикт про автентичність

Джерело: ExifTool · Офіційна історія версій і документація, перевірено 19 вересня 2026

Що сталося

ExifTool читає й записує метадані у великій кількості медіа- та документних форматів. У змінах 2026 року є розширене декодування часових GPS-даних, підтримка тегів Exif 3.1 і Garmin FIT, суворіша перевірка метаданих та кілька безпекових виправлень. Інструмент може показувати часові мітки, дані камери й пристрою, вбудований GPS, сліди редагування та специфічні maker notes — якщо ці поля справді є у файлі.

Чому це важливо

Метадані найкорисніші як структуровані зачіпки, які можна порівнювати зі змістом сцени та історією джерела. Збереження точних назв тегів і сирих значень допомагає не перетворювати одне зручне поле на кшталт DateTimeOriginal чи GPS на повну відповідь про місце й час створення знімка.

Як це застосувати

Спочатку порахуйте контрольну суму й збережіть оригінальний файл, первинне вилучення робіть у режимі читання, збережіть точну команду та результат, а ключові поля підтверджуйте візуальною хронологією, історією джерела й незалежними даними про місце.

Обмеження

Метадані можуть бути видалені, переписані, успадковані під час експорту або навмисно підроблені. Соцмережі часто прибирають частину полів. Отже, результат інструмента підтверджує твердження про метадані, а не правдивість зображеної події.

metadataexifmedia-verificationgpsprovenance

🛡️Evidence CaptureЗбереження доказів

#07

Hunchly turns ordinary browser research into a timestamped capture trail, but collection provenance still does not prove page truth

Source: Hunchly · Official product pages, checked 19 September 2026

What happened

Hunchly automatically records the URL, timestamp and hash for pages visited during research and creates page captures that can be tagged, searched and assembled into reports. The product is designed around a browser-based audit trail rather than relying on researchers to remember which screenshots to save after the fact.

Why it matters

The evidentiary gain is procedural: it makes the collection path inspectable and reduces selective screenshotting. For fast-changing pages, a continuous capture trail can show what the researcher actually saw and when.

How to use it

Create a case before browsing, keep capture enabled only for the relevant research session, tag decisive pages, export the report and preserve the underlying case data. For high-value evidence, independently archive the decisive source and record any login or personalization context that could affect what was displayed.

Limits

A browser capture can preserve what was displayed without proving that the content was accurate, complete or shown identically to other users. Logged-in research can also collect sensitive material unintentionally, so case scope and retention rules matter.

Hunchly перетворює звичайне браузерне дослідження на журнал із часовими мітками, але походження збереження все одно не доводить правдивість сторінки

Джерело: Hunchly · Офіційні сторінки продукту, перевірено 19 вересня 2026

Що сталося

Hunchly автоматично фіксує URL, часову мітку й контрольну суму сторінок, відкритих під час дослідження, та створює копії, які можна тегувати, шукати й збирати у звіти. Логіка продукту побудована навколо браузерного журналу дослідження, а не на надії, що аналітик наприкінці згадає, які скриншоти треба було зберегти.

Чому це важливо

Доказова цінність тут процедурна: шлях збирання стає перевірюваним, а ризик вибіркового скриншотингу зменшується. Для сторінок, що швидко змінюються, безперервний журнал показує, що саме дослідник бачив і коли.

Як це застосувати

Створюйте окрему справу до початку браузингу, вмикайте збереження лише на релевантну сесію, позначайте ключові сторінки, експортуйте звіт і зберігайте вихідні дані справи. Для важливих доказів додатково робіть незалежне архівне збереження й фіксуйте контекст авторизації або персоналізації, який міг впливати на показаний вміст.

Обмеження

Браузерне збереження може показати, що саме відображалося на екрані, але не доводить точність, повноту чи однаковість цього вмісту для інших користувачів. Під час роботи під авторизацією можна ненавмисно зібрати чутливі дані, тому межі справи й правила зберігання важливі.

evidence-capturebrowserhashingaudit-trailpreservation