Darja Rihla https://darjarihla.com Identity, systems and strategic thinking. Wed, 04 Nov 2026 21:53:46 +0000 en hourly 1 https://darjarihla.com/wp-content/uploads/2026/03/cropped-darja-rihla-startpagina-blog-afbeelding-2-32x32.png Darja Rihla https://darjarihla.com 32 32 From Blind to Caught: How We Investigated an AI Security Benchmark https://darjarihla.com/from-blind-to-caught-ai-security-benchmark/ https://darjarihla.com/from-blind-to-caught-ai-security-benchmark/#respond Tue, 03 Nov 2026 19:09:09 +0000 https://darjarihla.com/?p=3098

Open Source Research · Cybersecurity & Tech

Independent Open Source Research · Investigative report

Our AI security benchmark investigation followed a checker blind spot from a controlled test to two merged upstream contributions, while preserving the original strict result of 29 out of 117 findings.

We followed one apparently small checking weakness through controlled regressions, an accepted open-source contribution, a closer examination of published benchmark results, and a second upstream fix that was also merged.

This is the research account behind our examination of bug-bounty-intelligence-mcp, the public project maintained by Abdellah Ouadoudi (holistis). The focus is on what we could verify, what remained uncertain, and why those boundaries matter.

AI security benchmark illustration showing a plausible but unverified finding ID
A valid-looking identifier is not necessarily a verified finding. Conceptual illustration, not actual benchmark output.

The central finding. A syntactically plausible but nonexistent finding ID, such as H-999, could pass a checker that trusted internal consistency without consulting the known findings for the relevant audit. The meaningful fix was canonical, audit-specific validation.

Research premise

AI Security Benchmark: Why Examine the Checker, Not Just the Score?

Open-source security research is not limited to flaws in deployed applications. The tools we use to judge research also deserve independent scrutiny. Benchmark claims become trustworthy only when methods are reproducible, references can be inspected, and their limits are explicit.

We therefore examined the route from source data to evaluation rather than accepting a final number at face value. In particular, we looked for assumptions that might leave the checker blind to a carefully constructed invalid result.

Research scope

The work covered EVMbench result files, the checker logic in the repository, and separately pinned public ground-truth configurations. Local Linux workspaces, Git revisions and evidence files kept the sources and experimental changes distinct.

This was a study of benchmark validation. It was not a claim of a new production vulnerability in an audited blockchain application or an exposure affecting users of the repository.

Validation boundary

A valid format is not a valid finding

There are two different questions a checker can ask. Does an ID match the expected syntax? And does that ID actually exist in the official set for the correct audit?

An identifier such as H-999 can resemble a legitimate high-severity finding while having no corresponding entry. Pattern matching alone cannot establish membership in an authoritative reference list.

Our targeted mutation reproduced the weakness: an internally consistent invalid response passed the old check, while canonical membership validation rejected it.

Pattern conformity is not enough. An identifier must belong to the canonical finding set for its specific audit.

First upstream contribution

From observation to an accepted change

The initial finding led to pull request #74, “Validate open-judge finding IDs against known findings.” It improved how open-judge responses were checked against known findings.

Maintainer holistis merged PR #74 on 3 November 2026. That public merge is a concrete contribution outcome. It does not establish that every possible validation issue, in every dataset, was eliminated.

Observed dataset

AI Security Benchmark Results: What the Stored Data Showed

We independently inspected 40 audits, 117 known findings, 1,537 scan hypotheses and 3,074 judge responses. These are properties of the inspected dataset, not vulnerabilities newly discovered by our investigation.

Counts reproduced from the inspected benchmark results
Counting method Counted findings
Strict agreement, top 15 23
Strict agreement, top 30 29
Strict agreement, all hypotheses 29
At least one judge, top 30 41
At least one judge, all hypotheses 49

The methods are not interchangeable. Requiring strict agreement is a different rule from accepting a match from one judge. We did not change the original benchmark totals.

Source of truth

The independent ground-truth archive

We cross-checked 40 official EVMbench configurations from openai/frontier-evals, pinned to revision b78dab1da774a6456b1ed9c48c9ff194ee3ff36d. Pinning the exact revision prevented later upstream changes from silently redefining our comparison.

AI security benchmark canonical ground truth archive illustration
The official reference material was treated as a fixed source, not inferred from the checker output. Conceptual illustration, not a record of the actual test environment.

The inspection found 117 matching official finding IDs, with no audit-level finding-count mismatches. We also found no unknown, non-null judge IDs recorded as valid IDs in the existing stored results.

That distinction matters: a checker that can be fooled is not, by itself, proof that the published results already contained fabricated findings. We demonstrated a reproducible gap in the validation boundary, not wholesale corruption of the benchmark.

Case review

Three irregular judge responses, three different interpretations

Three responses were marked invalid: unknown-id. The original invalid identifiers had not been retained. We could therefore compare surviving descriptions with official findings, but could not reconstruct exactly what those judges had returned.

AI security benchmark review of three irregular judge responses
Curves, Althea and Canto were reviewed separately; this is not a depiction of three newly confirmed vulnerabilities. Conceptual illustration, not a record of the actual test environment.

Curves · hypothesis 3

Judge A matched H-05; judge B produced an invalid response. The description was consistent with a missing access restriction or revert in Security.sol. Since H-05 was already counted through other hypotheses, this did not change the reported strict total.

Althea · hypothesis 25

Judge A returned no match; judge B’s response was invalid. The wording left an unresolved distinction between removing _afterTokenTransfer and the duplicate addition to _beforeTokenTransfer described by official H-01. The latter was also already counted elsewhere. An additional match cannot be asserted.

Canto · hypothesis 36

Judge A identified H-01; judge B was invalid. The surviving description aligned with official H-01 concerning trapped excess msg.value, whereas the existing strict Canto tally contained only H-02. If judge B had returned a valid H-01, the strict overall total could have been 30 instead of 29 out of 117. This is a hypothetical sensitivity analysis, not a corrected or proven benchmark score.

Second upstream contribution

Testing the checker against its own blind spot

The maintainer opened issue #83 to strengthen EVMbench validation beyond an ID-shaped string. The follow-up introduced a local, audit-specific known-finding-ids.json registry, with no network dependency.

In a controlled mutation, an invented H-999 changed from BLIND under the old checker to CAUGHT under the updated validation.

AI security benchmark controlled mutation testing across four scenarios
The four local mutation scenarios were validated in an isolated environment. Conceptual illustration, not a record of the actual test environment.

The independent four-case matrix covered clean data, fabricated IDs from both judges, a fabricated ID from one judge, and missing audit registration. All four passed the local checks. The separate checker self-test found no blind checker in the tested paths. The original strict benchmark result remained 29/117.

The change was submitted as PR #89, “Validate EVMbench judge IDs against canonical findings”, linked to issue #83. Maintainer holistis merged PR #89 on 3 November 2026 into the upstream main branch, with merge commit 1c4822d. The pull request records 40 audited configurations, 117 canonical IDs, four isolated regression scenarios, a verified SHA-256 manifest and the unchanged historical strict figure of 29/117. This confirms upstream acceptance of the scoped checker change, not universal validation of the benchmark or semantic correctness of every judge decision.

Separate research exercise

AI Security Benchmark Validation: From Blind to Caught

Alongside the benchmark work, we ran a local BOLA/IDOR authorization exercise in an isolated Termux sandbox. Five checks passed in that controlled environment.

This was methodologically separate. It was not an identified vulnerability in Abdellah’s project or an external service, and it should not be presented as additional evidence for the EVMbench checker weakness.

Evidence discipline

What made the process reproducible?

We kept source material, mutated test variants and evidence artifacts apart. Pinned Git revisions and SHA-256 records identified the reference data. Rather than trusting a single sample output, we compared the checker’s response before and after deliberate mutations.

Throughout the report, four kinds of claim remain distinct: what the dataset stored; what the official ground truth specifies; what our local mutations demonstrated; and what remains an interpretation or counterfactual.

Core design principle

Evidence must belong to the right reference

AI security benchmark canonical audit-specific finding registry
An identifier should be validated against the canonical finding set of its own audit. Conceptual illustration, not a record of the actual test environment.

A number that looks plausible is not evidence. In a pipeline where one AI system proposes a hypothesis and another judges it, convincing structure can create false confidence unless every result resolves to a trusted and fixed reference.

Here, that meant validating not just the syntax of a finding ID, but its membership in the official set for the particular audit. A small, sharply scoped code change strengthened a consequential boundary in the checking chain.

Limits of the evidence

What this investigation does not prove

  • It does not show that all published benchmark results are invalid.
  • It does not prove that the hypothetical Canto interpretation should change the official score.
  • It cannot restore the original invalid judge IDs that were not preserved.
  • It does not demonstrate a new production vulnerability in the audited blockchain projects.
  • The upstream merge of PR #89 does not establish semantic correctness of every judge decision, nor does it retroactively change the stored benchmark totals.

These are not incidental caveats. They set the boundary of a defensible conclusion.

Open-source stewardship

Research becomes useful when others can review it

The upstream project is publicly maintained by Abdellah Ouadoudi under holistis. Its repository, issues and pull requests provide the public record of development. Our contribution consisted of independent investigation, reproducible tests and checker changes accepted upstream.

AI security benchmark open source research collaboration
Independent research can become a practical improvement through maintainer review and shared development. Conceptual illustration, not a record of the actual test environment.

Another contributor also investigated a different issue and pull request in the repository. We do not count that work as ours. Open-source participation is shared stewardship, not a claim of ownership over another person’s research.

Primary sources

Sources and verification points

Dataset counts, local tests and the case analysis reflect research conducted on 2–3 November 2026. Exact reproduction depends on the local evidence artifacts and the pinned sources. The merge status of PR #89 was independently checked against the public GitHub pull request record for this 4 November update.

Continue exploring

A small check. A consequential distinction.

Research becomes useful when readers can distinguish demonstrated facts, open questions and the improvements that follow. This is the first investigation in Darja Rihla Open Source Research.

Explore more independent security research and technical investigations at Darja Rihla.

]]> https://darjarihla.com/from-blind-to-caught-ai-security-benchmark/feed/ 0 Darja Rihla Open Source Research BUILD LOG 005 | Building the PHP2Shell Decision Guide https://darjarihla.com/build-log-005-php2shell-decision-guide/ Sun, 25 Oct 2026 01:47:22 +0000 https://darjarihla.com/?p=3047

DARJA RIHLA / STARTUP LAB · BUILD LOG 005

Startup Lab / Build Log 005

Building the PHP2Shell Decision Guide

How Darja Rihla turned a security advisory into a practical PHP2Shell decision guide for website owners and administrators.

October 2026Cybersecurity · Product DevelopmentPublished MVP

BUILD → VERIFY → PROVE → PUBLISH

Why we built the PHP2Shell decision guide

The PHP2Shell decision guide began with a simple challenge: security advisories explain vulnerabilities, affected systems and mitigations, but technical information does not automatically become an action plan.

When critical PHP vulnerabilities were disclosed in October 2026, website owners needed to know whether their environments might be affected, who should apply updates, and how to verify that those updates were actually running.

A WordPress site can be current while its PHP runtime is not. Another site may depend on a hosting provider for PHP updates. A third may operate its own server. The appropriate next step changes with the environment.

01 / RESEARCH

Understanding the problem

PHP2Shell is not a WordPress vulnerability

Our investigation began with two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. They concern PHP itself, the runtime used by WordPress and many other web applications. Updating WordPress does not necessarily update PHP.

Four-layer website architecture showing the application interface, WordPress environment, PHP runtime and hosting infrastructure.
WordPress and PHP operate at different layers. Updating WordPress does not automatically update the underlying PHP runtime.

We also considered the separately disclosed CVE-2026-115560, keeping its characteristics and risk assessment distinct from the two critical vulnerabilities.

For primary technical context, consult the NCSC PHP security advisory and the official PHP supported versions overview. Always check the applicable vendor or hosting-provider guidance for your specific runtime.

Who manages PHP?

The website owner, infrastructure team, hosting provider or software vendor?

What is reachable?

Does the relevant functionality have a path from the internet?

Was a fix applied?

An available security release is not evidence of deployment.

Is the active runtime verified?

An installed update may not yet be serving live requests.

02 / PRODUCT

The product decision

A conventional article can explain a vulnerability, but readers must still translate the explanation into decisions about their own systems. We designed a narrower product: a guided self-assessment that helps users identify responsibility, consider potential exposure and choose appropriate next steps.

This follows the same product-development principle explored in Build Log 002: start with a specific user task, make the next action understandable, and keep the interface within a clearly defined scope. Here, the task is security decision support rather than language learning or general education.

The tool does not probe servers, exploit vulnerabilities, inspect private infrastructure or certify that a website is secure. Its outputs depend on user-provided information, so uncertainty must remain visible.

03 / DECISION MODEL

Designing the PHP2Shell decision logic

Two dimensions structure the assessment: management responsibility and potential accessibility. Together they produce four primary scenarios.

Cybersecurity decision tree branching into four scenarios based on infrastructure responsibility and potential internet accessibility.
Four operational scenarios combine infrastructure responsibility with potential internet accessibility.
Scenario 01

Self-managed · Internet-accessible

Prioritize applicable updates, deployment checks and runtime verification.

Scenario 02

Self-managed · Not known to be directly accessible

Review exposure assumptions, apply relevant fixes and verify the runtime.

Scenario 03

Provider-managed · Internet-accessible

Request patch confirmation and evidence from the responsible provider.

Scenario 04

Provider-managed · Not known to be directly accessible

Clarify responsibility, confirm mitigations and retain provider evidence.

Potentially affected is not the same as confirmed vulnerable. Neither is a patched system necessarily a verified one.

04 / EXPERIENCE

Turning guidance into an interface

The guide uses contextual questions and scenario-dependent outcomes rather than a long technical questionnaire. It encourages evidence-oriented next steps, explains uncertainty and includes a CSV export option for retaining assessment information.

Conceptual cybersecurity assessment interface with a progress indicator, infrastructure choices and contextual guidance.
Conceptual interface illustration, not a screenshot of the deployed PHP2Shell guide.

Its purpose is decision support, not automated vulnerability detection. The interface should never imply that a self-assessment has verified the security of a live server.

05 / INTEGRATION

Integrating the PHP2Shell decision guide into Darja Rihla

We published the project as two complementary experiences: a technical investigation that explains the context, and an interactive guide that organizes practical decisions. The WordPress component is embedded using a dedicated shortcode, with the interactive assessment placed directly below this integration section.

This approach lets readers explore the background or move directly into the assessment, then return to the article for explanations.

LIVE MVP / INTERACTIVE

Try the PHP2Shell decision guide

Answer the questions to identify the most relevant next steps for your situation. This is an informational self-assessment, not a technical scan or proof of security.

Independent tool developed by Darja Rihla / DD Digital. Informed by publicly available NCSC guidance; not an official NCSC product.

06 / EVIDENCE

Verification and limitations

The published MVP includes a structured four-scenario decision model, an interactive self-assessment embedded in WordPress, and a companion investigation distinguishing potential exposure from verified findings.

Three-stage workflow showing security guidance documents, a server implementation and independent evidence review.
Security guidance, implementation and verification are distinct stages; one does not prove the next.
What the MVP does not establish

It is not an automated vulnerability scanner, penetration test, forensic assessment, authenticated server inspection, official NCSC tool or guarantee of security.

The distinction between observations and conclusions also matters in our Web Evidence Inspector project. Both projects are designed to help readers interpret evidence without presenting an interface as proof of something it has not actually tested.

Publication confirms release, not comprehensive accessibility, browser compatibility or effectiveness across every hosting configuration. Those require separately documented testing.

07 / LEARNINGS

What this build taught us

Useful security tooling does not always require scanning

Clarifying responsibility, organizing evidence and selecting next actions can already improve how people respond to advisories.

Guidance and verification must remain separate

Security interfaces should not communicate greater certainty than their evidence supports.

Hosting responsibility changes the workflow

Self-managed infrastructure and provider-managed hosting need different instructions, even when responding to the same advisory.

Publishing is part of engineering

A functioning component also needs explanations, limitations, accessibility considerations and coherent placement within the larger product.

08 / ROADMAP

The next development stage

Future iterations may strengthen evidence collection, assessment reporting, support for complex hosting environments, accessibility testing and reuse of the decision-guide architecture for other advisories. These are potential improvements, not features claimed as delivered.

09 / RELEASE

Build status and reflection

Project
PHP2Shell Interactive Decision Guide
Build
005
Status
Published MVP
Platform
Darja Rihla / WordPress
Assessment
Four operational scenarios
Automated scanning
Not included

This release is part of the Startup Lab series. The development approach traces back to Build Log 001: The First Artifact, where building, checking, documenting and publishing were treated as connected stages rather than separate tasks.

Build Log 005 documents how technical research became a functional public resource: identify the decisions, model the scenarios, create the interface, document uncertainty and publish the result.

The guide does not replace technical verification. It helps users understand what needs verifying, who may be responsible and what to do next.

BUILD → VERIFY → PROVE → PUBLISH

Read the full PHP2Shell investigation

The investigation is published in English. Use the translation control at the top of the article to read it in Dutch or another supported language.

]]> Startup Lab PHP2Shell: Two Critical PHP Vulnerabilities Explained https://darjarihla.com/php2shell-php-vulnerabilities/ Fri, 23 Oct 2026 03:37:15 +0000 https://darjarihla.com/?p=3014
DD DIGITAL PROTECT SECURITY ADVISORY

PHP2Shell: Understand your exposure. Verify your PHP. Know what to do next.

Two critical PHP flaws were fixed on 21 October 2026. A third flaw, CVE-2026-115560, was reported on 23 October and has no fix in the versions listed below yet. This guide explains what is confirmed, what is not, and what to do this week. It includes a free decision guide and a route to free initial guidance from DD Digital.

Last substantive update: 24 October 2026Reading time: 6 minutesFor: site owners, administrators and organisations that run PHP
Start the PHP2Shell decision guide
Ask for free initial guidance

01 / Security overview

Three CVEs, three separate assessments

The NCSC and the PHP project describe three flaws. The first two have the same fixed versions. The third does not, and its impact is described differently. Do not read one card as a conclusion about another.

CVE-2026-109618

Memory corruption during out-of-memory handling

Can allow remote code execution without logging in, according to the PHP project.

Fixed in
8.5.12, 8.4.27, 8.3.36, 8.2.35 (21 Oct 2026)
Exploitation
No confirmed successful attack in the sources reviewed
CVE-2026-109619

Stale global state reused by a later request

Can allow remote code execution without logging in, according to the PHP project.

Fixed in
8.5.12, 8.4.27, 8.3.36, 8.2.35 (21 Oct 2026)
Exploitation
No confirmed successful attack in the sources reviewed
CVE-2026-115560

A separate flaw, reported 23 October

According to the PHP Foundation, as reported by the NCSC, remote code execution through this flaw is unlikely. Its impact is not the same as the first two.

Fixed in
Not in the versions above. The fix will come in a future regular bugfix release.
Exploitation
Not reported in the sources reviewed

Patch status and exposure must be checked for each CVE separately. A server that runs a fixed version for the first two CVEs is not automatically protected against the third.

02 / What happened?

What happened, and what is still unknown

PHP is the programming language that runs much of the code behind websites, web shops and online applications. WordPress runs on PHP. So do many other content management systems, web applications and APIs. When a flaw in PHP is exploited, the attacker may run commands on the server. The web application on top does not need to be vulnerable for that to happen.

The NCSC advisory of 21 October 2026 describes two critical flaws. The PHP project says both can lead to remote code execution through ordinary web requests, without authentication. The NCSC update of 23 October adds that one report of possible abuse abroad has been received. That report has not been confirmed as a successful attack. The NCSC also estimates that large-scale abuse is now less likely than it first thought.

Confirmed

Fixed versions exist for the first two CVEs. The NCSC says that vulnerable systems should be kept offline until they are updated. The third CVE has no fix in the listed versions yet.

Not confirmed

Whether these flaws have been used in attacks. One unconfirmed report of possible abuse abroad has been received. No conclusion can be drawn from the absence of alerts.

Suspension bridge with several routes relying on a central pillar marked by a red fracture.
Shared dependency: one weakness, multiple systems. One shared dependency can expose multiple applications; exposure does not establish compromise.

A vulnerable PHP version does not prove that a system has been compromised. It means that the system could be attacked, and that the risk has to be assessed. Do not treat either an unpatched or a patched version as proof in itself. Evidence of compromise comes from logs and investigation, not from a version number.

03 / Technical assessment

What to verify on the server

The version number is a starting point, not proof. Linux distributions and hosting providers often backport security fixes into older version labels. Ask for the vendor advisory or changelog entry in that case.

Conceptual macro visualization of a localized red fracture within layered software execution pathways.
PHP execution layer: a hidden weakness. A localized runtime weakness can exist beneath a website’s visible interface.

Four things need checking separately:

  • Installed is not the same as active. A package can be updated while the web server or PHP-FPM workers still run the old code. Restart the PHP service or workers after the update, then check the version the web server actually uses.
  • Workers and restarts. Long-lived PHP workers can keep old state in memory. The PHP project recommends restarting every worker after an update. Some teams also limit how many requests a worker handles before it is recycled.
  • Internet reachability. Is the PHP functionality reachable from outside? The NCSC decision guide asks this question. A system that is only reachable on an internal network carries a different risk, but it still needs a patch.
  • Who manages what. If you run PHP yourself, you patch it. If a hosting provider runs PHP for you, the provider patches it. If a product you buy includes PHP, the vendor of that product is responsible for the fix. Ask who is responsible before you assume.
Precision measurement probe inspecting a repaired mechanical component beside a removed damaged part.
Patch deployment and verification. Applying a patch and verifying the active runtime are separate steps.

Temporary measures and their limits

The PHP project lists temporary settings that reduce specific attack paths. They are not a fix. Updating to a patched release is described as the only complete mitigation. Measures include setting memory_limit=-1 and enforcing it at every level, reducing max_input_nesting_level, keeping post_max_size conservative, and blocking multipart requests at the frontend where the application does not use them. On PHP 8.5 without an update, fatal_error_backtraces=0 is listed. session.upload_progress.enabled=0 is recommended as well. Every change needs a restart of the PHP workers, and it must be checked that no other setting restores the old behaviour.

Clean logs are not proof of safety

The PHP project says so explicitly. Logs help you find signs of abuse. They cannot show that nothing happened. If you suspect compromise, involve a specialist.

For background on the wider risk picture, read Why WordPress Sites Get Hacked: 7 Hidden Risks Small Businesses Miss. It describes hosting and the server as one of six connected layers. This advisory is a reason to check the PHP runtime specifically, not only the hosting package.

Access controls matter too, but they do not replace patching. After Login: Zero Trust, Tokens and Revocable Trust explains why a stolen login is not the only entry point. Multi-factor authentication protects important boundaries, but it does not fix a defect in PHP request handling.

For the limits of what a check can show, see Build Log 004: Web Evidence Inspector. Observations from a defined session are evidence about that session. They are not absolute proof about a whole website. The PHP2Shell decision guide works the same way.

The workflow we use to check and publish our own tools is described in Build Log 001: The First Artifact. Bundle inspection and the final publication decision remain separate gates, with a human as the final authority.

04 / PROTECT decision guide

PHP2Shell decision guide

The guide follows the structure of the NCSC decision guide for PHP vulnerabilities (22 October 2026). It asks a few short questions about who manages PHP, what patch status applies, and whether the functionality can be reached from the internet. The outcome links to one of the four NCSC explanatory notes, and shows a separate status for each of the three CVEs.

Unknown answers lead to a verification step. They never lead to a “safe” verdict. The guide is an independent addition by DD Digital. It is not an official NCSC tool.

Central web application connected to a self-managed server room and an external hosting facility.
Who manages the PHP runtime?. The appropriate response depends on who manages PHP and the product that uses it.
Privacy: the guide runs in your browser. Your answers are not sent to DD Digital, to Darja Rihla or to any third party. You can download, copy or print the result.

05 / What should you do next?

Practical steps by situation

Pick the situation that matches you. Each step says whether you can check it yourself or need your provider or a specialist.

Website owners

Ask your hosting provider which PHP version runs your site, and whether the fix for the first two CVEs is active. You can check yourself in your hosting control panel. If you cannot find the version, ask your provider.

WordPress administrators

Updating WordPress, themes and plugins does not update PHP. Check the PHP version in Site Health or in your hosting panel. Plugin updates are not a fix for these CVEs. For a broader check of your WordPress setup, see our WordPress Security Quick Check.

Organisations with their own servers

You manage PHP yourself, so you patch it. Install the fixed version, restart the PHP workers, and verify the version the web server uses. If a fixed version is not available for your release, plan an upgrade, and take the system offline until it is updated, as the NCSC advises.

Users of managed hosting

Ask your provider in writing for the patch status of PHP on your account, the date it was applied, and whether the service is reachable from the internet. You can check the version yourself. You cannot patch the server, so the provider must confirm the fix.

Anyone who suspects compromise

If you see unknown files, unknown accounts, changes you did not make, or unusual traffic, act today. Contact your provider or a security specialist. Keep logs and backups as they are, and do not delete anything yet. Do not wait for the update.

06 / Free initial guidance from DD Digital

Not sure whether your website is affected?

Ask DD Digital for free initial guidance. You can send us a first question about:

  • Your PHP version, if you know it.
  • Your hosting provider and how PHP is managed.
  • The patch status you have been given.
  • The result of the PHP2Shell decision guide.
  • Possible next steps.

This first guidance is not a full security audit, a penetration test, incident response, or a guarantee that your system is safe. It is a practical first answer to help you decide what to do next. Requests are reviewed first. The project form states a reply within 24 hours.

Do not send passwords, MFA codes, API keys, tokens or database exports, through the form or by email.

Ask DD Digital a Question

Free and without obligation. Via the DD Digital project form.

07 / Official sources and editorial notes

Read the sources yourself

We separate three things on this page: what the sources confirm, what they do not yet say, and what we recommend. Check the original sources before you act, because the situation may change.

Related DD Digital and Darja Rihla reading

Editorial note: this page is general information. It is not a security certification and does not confirm that any system is secure. The statements on CVE-2026-115560 come from the NCSC update of 23 October 2026 and the PHP Foundation statement it cites. Check the PHP Foundation source for the latest status. Mitigation settings are taken from the PHP advisories listed above, and are temporary.

DD Digital · PROTECTDarja Rihla · Cybersecurity
]]> Cybersecurity & Tech Before the Dutch State Navy: How Zeeland Governed Violence at Sea https://darjarihla.com/before-the-dutch-state-navy-zeeland/ Tue, 20 Oct 2026 20:06:49 +0000 https://darjarihla.com/?p=3007

SYSTEMS & STRATEGY / THE CONTINUITY PROJECT / CH-011 / EVIDENCE NOTE 002

Commissions, prize courts and the limits of historical continuity, 1572-1577.

Evidence Note 002 | CH-011
Published historical edition and archival finding-aid research
Direct institutional descent unresolved

When a government tries to govern violence at sea, the decisive question is not simply who sailed. It is who could commission, register, judge and account.

Darja Rihla research framing

A question about rule, not origins

Did the Sea Beggars become the Dutch state navy? It is an appealing question because it turns a turbulent revolt into a clear institutional origin story. The surviving evidence asks us to be more precise. Between 1572 and 1577, how did Zeeland’s authorities try to decide who could take ships, claim prizes, command at sea and account for the proceeds?

The answer is not that a ready-made navy emerged from private violence. A published historical edition shows a provincial effort to place maritime force within commissions, registers, a court and fiscal rules. It also shows that rules changed when practice exposed their limits. What it does not show is a documented chain from a particular Sea Beggar crew, vessel, commission or record to the five admiralty colleges settled in 1597. That distinction is the substance of this note, not a reservation at its margins.

Before the rupture: maritime authority already existed

The Revolt did not start from an institutional blank slate. A Leiden research overview, drawing on the work of Louis Sicking, describes a Netherlands admiralcy before 1572, ordinances in 1488 and 1540, and a 1565 settlement over Holland’s maritime jurisdiction.1 It reports that the 1540 framework narrowed the admiral’s jurisdiction to matters connected with war and violence, while Holland retained a distinctive position in the later dispute.

That background supplies a rival explanation for later similarities. An admiral, prize jurisdiction and maritime authority did not have to be invented by former rebels in order to appear in post-1572 Zeeland. But neither does the overview prove that a given 1574 provision was inherited from an earlier ordinance. The underlying ordinances and Sicking’s page-level argument were not independently examined for this note. The pre-Revolt administration is therefore a documented context and an open comparison, not a demonstrated ancestor.

Sea Beggars and the political break

The capture of Brielle in 1572 is central to the established public story of the Sea Beggars, but it is not used here as proof of later institutional descent.2 The more immediate documentary setting is the first free States of Holland meeting at Dordrecht, 19-23 July 1572. The Nationaal Archief identifies its minute booklet as collection 3.01.04.01, inventory 324B. The digital images are available, but the decisive maritime text has not been independently transcribed in this research.3

The Nationaal Archief’s historical introduction to the Admiralty Colleges reports that, on 20 July, Holland placed supreme maritime direction with William of Orange, required existing sea commissions to be cancelled, and envisaged appointments through a sovereign admiral with advice from water towns.4 This is evidence of a reported constitutional design. It is not evidence that every earlier commission was cancelled, that the cancelled documents belonged to Sea Beggars, or that identifiable captains received replacements.

Zeeland faced a more fragmented situation. Van Grol wrote that Middelburg did not pass to the revolt until February 1574 and that the provincial terrain was not yet politically coherent. His article presents the 2 March 1574 governmental instruction as the first arrangement for the administration of Zeeland.5

Zeeland’s regulatory experiment in 1574

Van Grol printed and discussed passages of the 2 March 1574 instruction. Article 8, as he transcribed it, divided civil prize and admiralty matters at a threshold of 1,000 Carolus guilders. Cases exceeding that amount belonged to the governors and council; cases valued at that amount or below belonged to an admiralty council selected by the admiral, with recourse to the governors and council. The same article required that notes and a good register be kept for prizes and booty.5

The threshold needs careful treatment. In the printed 1574 text, the rule allocated cases above 1,000 Carolus guilders away from the admiralty council. It does not prove that every case was entered, that every entry survives, or that the register was transferred to a later institution.

Article 15, in Van Grol’s account, provided for four notable councillors as well as a fiscal officer, secretary and chamber officer. Article 27 provided that captains should receive commissions under the prince’s seal and signature, revoking earlier authorisations granted to other freebooters.5 This is the clearest available evidence of a programme of formalisation. It does not prove that “the Sea Beggars were finished,” which is Van Grol’s own interpretation after the passage.

What the surviving published proceedings show

The published material is not a complete court archive. Van Grol said that he reduced the minutes to a list, and on p. 242 described two sixteenth-century manuscript volumes that he had found in the municipal archive of Vlissingen. He identified them as the registers required by article 8: one runs from 1575 to 19 April 1576 and the other from 26 April 1576 to 4 April 1577.6 This is a valuable archival identification by Van Grol, but the manuscripts themselves have not been independently inspected here.

An earlier proceeding, dated 10 May 1576, concerns Captain David Jansz. The council, advised by people commissioned by the admiral, required him to appear and acknowledge misconduct after he had allegedly left the fleet near Brouwershaven without permission. It imposed a fine drawn from the portion of prize due to him, his owners and crew, with sums for the common cause and Vlissingen’s poor.8 Here a published entry shows discipline connected to command, prize income and a public-purpose payment. It does not tell us how often such discipline occurred or whether this procedure descended from pre-Revolt practice.

When practice changed the rules

On 22 September 1576, according to Van Grol, a separate ordinance on admiralty matters was issued at the same time as a revised governmental instruction. He characterised it as setting down what practical experience had made desirable and what had in fact been carried out. That characterisation is his interpretation, not a direct report by this research from the original ordinance.9

The printed account nevertheless identifies an important institutional change. It says that the 1574 division at 1,000 Carolus guilders was never put into practice; instead, the admiralty had issued all judgments from the beginning. Article 15 of the 1576 ordinance accordingly gave the admiralty council jurisdiction over prizes at sea without exception, subject to appeal to the governors and council. It also provided for a Vlissingen-based council, letters of marque, a prohibition on councillors fitting out their own privateering ships, and a treasurer responsible for licences, convoy money and proceeds found to be good prize.9

A later January 1577 dispute records two captains who had both a commission and an appointment, sailing with their masters’ ships under promises made before departure. Their dispute concerned a share in prize proceeds.7 The entry demonstrates that the printed record refers to commissioned captains, ships, a superior and prize-sharing claims. It does not establish a universal chain of command or a state-owned fleet.

Evidence comparison: prescribed rules, actual cases and later revision

Reading key: four dated snapshots, ordered by event, not arrows between institutions. Van Grol describes manuscript volumes spanning 1575-1577; the selected cases occurred on different sides of the September 1576 revision.

1574: prescribed

  • Cases above 1,000 Carolus guilders allocated to governors and council; 1,000 or below to the admiralty council.
  • Registers required; sealed commissions prescribed; earlier freebooter authorisations revoked.

Evidence level: 1574 text as printed by Van Grol; execution not established.5

1575 to May 1576: early proceedings

  • Van Grol describes two surviving manuscript registers, beginning in 1575; they have not been independently inspected.
  • The published 10 May 1576 ruling against David Jansz concerns discipline and a fine from prize proceeds.

Evidence level: Van Grol’s edition, register identification and selected case.68

22 September 1576: revised

  • Van Grol reports that the 1,000-guilder division was not put into practice.
  • The new ordinance gave the admiralty wider prize jurisdiction, subject to appeal, and specified fiscal roles.

Evidence level: Van Grol’s account of the revised ordinance, not direct manuscript inspection.9

January 1577: subsequent dispute

  • A printed case concerns two captains with commission and appointment and contested shares of prize proceeds.
  • This case demonstrates a specific proceeding, not a continuous Watergeuzen-to-admiralty lineage.

Evidence level: Selected proceedings as printed in the historical edition.7

Applying the Continuity Framework

The Continuity Framework asks whether a defined property has been transmitted through an evidenced carrier. The evidence supports component-specific observations: commissions under seal were prescribed; a register was required; a Zeeland prize-court record was published; prize proceeds and public revenues were governed; and discipline was exercised in a recorded case.5789

None is a demonstrated Watergeuzen-to-state-navy chain. Direct transfer lacks a named predecessor and receiving record. Pre-1572 inheritance remains a live alternative. A mixed origin is possible only if each contribution is separately shown. Visible redesign strengthens the case for wartime innovation, while Zeeland’s legal and fiscal route strengthens the case for regional divergence. These are rival explanations, not a ranking of certainties.

What the evidence cannot establish

The note cannot identify the makers of all commissions, the recipients of all revoked authorisations, the contents of every register, or the ownership and funding of the ships involved. The Van Dorp inventory locates ship-operation papers connected with Louis Boisot, Martin Lenglen’s account for Boisot as admiral of Zeeland, and an undated blank commission from Orange for a sea captain under Boisot.10 These descriptions are leads, not read ship accounts or executed commissions.

Nor can the 1579 Holland register order settle the question. The Admiralty Colleges finding aid reports an order to deliver a register of commissions, appointments and resolutions to a new commission. It does not demonstrate delivery, receipt, later use, contents or any Watergeuzen entry.4 Nothing in the examined evidence permits a direct genealogical arrow from Zeeland’s 1574-77 arrangements to the five colleges settled in 1597.

The next documents that could change the finding

The next decisive documents are concrete: a human transcription of the maritime passage in Dordrecht minute book 324B; manuscript-level comparison of the original 1574 instruction, the two Vlissingen registers and the 1576 ordinance; consultation of Van Dorp files 1169-1176 for ownership, costs, authority, revenues and any completed commission; and a comparison of the 1488, 1540 and 1565 materials with post-1572 texts.

This is enough for a limited evidence note, not an origin myth. Zeeland’s records show people trying to govern violence at sea through rules, offices, books and adjudication. They do not yet tell us, component by component, what survived the rupture and through whom.

Research context: This Evidence Note belongs to The Continuity Project. For the earlier editorial background, read The Sea Beggars and 5 Powerful Lessons from the Sea Beggars. These earlier articles are context, not primary evidence for the institutional findings here.

Sources and notes

  1. Universiteit Leiden, “Admiraal van de zee”, accessed 20 October 2026. Research summary drawing on Louis Sicking; the book and original ordinances were not independently inspected.
  2. Darja Rihla, “The Sea Beggars: Dutch Private Violence Before the VOC”, used only to identify earlier editorial framing, not as authority for this note’s institutional claims.
  3. Nationaal Archief, 3.01.04.01, inv. 324B, “Notulen van de eerste vrije Statenvergadering gehouden te Dordrecht, 1572 juli 19-23.”
  4. Nationaal Archief, 1.01.46, “Admiraliteitscolleges, 1586-1795,” historical context. Finding-aid narrative, not the original resolutions.
  5. H.G. van Grol, “Het Zeeuwsche prijzenhof te Vlissingen 1575-1577”, Bijdragen en Mededeelingen van het Historisch Genootschap 37 (1916), 236-38. Printed historical edition/article; original manuscripts were not independently examined.
  6. Van Grol, 242.
  7. Van Grol, 334-35.
  8. Van Grol, 335-36.
  9. Van Grol, 238-39.
  10. Nationaal Archief, 1.10.25, Dorp, van, inventory, 178-79, nos. 1169-1176. Finding aid only.
]]> The Continuity Project The Glasses of Omar al-Mukhtar: What the Evidence Can and Cannot Tell Us https://darjarihla.com/evidence-note-001-omar-al-mukhtar-glasses/ Mon, 19 Oct 2026 10:38:02 +0000 https://darjarihla.com/?p=3004

SYSTEMS & STRATEGY / THE CONTINUITY PROJECT / EVIDENCE NOTE 001

A literature-based investigation into contested objects, colonial collections, restitution and the limits of provenance.

Evidence Note 001
Literature-based investigation
Provenance unresolved

A pair of glasses can survive its owner. Its story can survive even longer. But when different museums attribute different objects to the same historical figure, what exactly has been preserved: the original object, its memory, or a later claim?

This note concerns objects attributed to Omar al-Mukhtar, the Libyan anti-colonial leader executed by Italian authorities in 1931. It does not establish that any identified pair belonged to him. It asks a narrower question: what can published scholarship, museum interpretation, public memory and journalism tell us about the competing stories, and where do those sources stop?

A question of objects, and of stories

Beatrice Falcucci’s 2024 study follows glasses attributed to al-Mukhtar as they appear in museums, in the antiquities trade, in writing and in film. Its central contribution is not an authentication. It is an account of how objects, copies and competing attributions can acquire different political and memorial meanings.1

That distinction matters. An attribution can have real historical force without proving physical identity. A museum label can record how an object has been presented. A personal memory can preserve an important story. None of these, by itself, demonstrates that a present-day object is the same pair once worn by al-Mukhtar, or shows how it travelled from one holder to another.

The Continuity Project therefore separates three questions that are often collapsed: whether an object is authentic, how an object came into a collection, and how a claim about an object has circulated. This article addresses the third question most directly. The first two remain open.

Rome: an institutional setting, not a completed provenance

Falcucci describes glasses attributed to al-Mukhtar in the former Museo Coloniale collections in Rome, now held within the Museo delle Civiltà. Her article treats the route to Rome cautiously, using language that signals an apparent rather than demonstrated transmission.1

In 2023, the Museo delle Civiltà presented Malak Yacout’s Searching for Appendices to Truths Lost: The Broken Sunglasses of Omar Al Mukhtar, an installation with an artist’s book. The museum’s page says that Yacout’s research focused on sunglasses that most likely belonged to al-Mukhtar. It describes a maker’s mark on a leather case, research connected to Maroun Ayac in Alexandria, interviews with descendants, and a research conclusion about an interrogation by Rodolfo Graziani.2

This is valuable research context. It is not an accession card, a custody record or a technical examination of the historical object. The museum page identifies a contemporary artwork and summarizes the artist’s investigation. It does not supply the documentary chain needed to identify a particular historical pair.

Tripoli: a reported display, an unrecorded route

Falcucci also describes a pair displayed at Tripoli’s Assaraya Alhamra, or Red Castle, museum as belonging to al-Mukhtar. Her earlier 2020 essay presented the same setting within a discussion of relics, display and public memory.13

A 2026 report by Khalifa al-Bashbash for Libya Alahrar likewise describes a Tripoli label for historical glasses used by al-Mukhtar, while stressing the absence of a published object number, acquisition date, donor, or route into the museum. That absence does not prove the claim false. It means the claim cannot yet be tested as provenance.4

Rome and Tripoli should therefore remain separate attributed-object leads. Published accounts provide reasons to research both. They do not establish that the two pairs are the same, that either descends from a documented 1931 pair, or that one travelled from Rome to Tripoli.

Aleppo: an attribution history, not a third established object

Falcucci records a 2015 Aleppo market story in which glasses were attributed to al-Mukhtar. The later Libya Alahrar report adds an important qualification: it reports that the holder interviewed by the journalist did not claim the pair was al-Mukhtar’s, but said it resembled a type of glasses that was common at the time.14

The Aleppo account belongs in the history of attribution and circulation. It does not establish a third original pair, and it should not be used to settle the Rome or Tripoli question.

The 1931 stories: source trails, not a recovered chain

Falcucci cites Rodolfo Graziani’s 1932 account of glasses with gold temples and a silver case, and a published transcription of the Benghazi interrogation that refers to glasses lost in an earlier encounter. Those sources, if independently checked, could be relevant to an alleged predecessor pair. In this note they remain reported citations within Falcucci’s scholarship, not primary documents examined by Darja Rihla.1

A relevant Libyan News Agency report shows how the battle-loss story functions in present national memory: it narrates spectacles lost in battle and later shown during captivity. It provides no archival citation or route to a museum object. Its value here is evidence of public memory, not evidence of physical transmission.5

Translation adds another caution. Libya Alahrar reports that an Arabic translation of Graziani described a silver frame, while the Italian wording reproduced by Falcucci describes gold temples and a silver case. The Arabic edition itself has not been inspected for this note. The reported difference should be investigated, not converted into a material identification.

1955: a documented research lead, not a demonstrated outcome

Falcucci’s 2024 article gives the most precise published account of the 1955 question. She writes that the Museo Coloniale received a formal Libyan request for objects belonging to leaders of the resistance, with a list that included al-Mukhtar’s glasses and wallet. She cites two records in the MAI/Ufficio Studi series, dated 7 and 9 March 1955.1

Falcucci further reports that Massimo Adolfo Vitale recorded informal ministerial willingness to return some objects while official instructions were still awaited. She then finds no further mention of the objects in the later ministerial files she reviewed. This is a carefully attributable scholarly finding. It is not the same as direct inspection of the correspondence, and it does not establish authorization, dispatch, receipt, refusal or return.

The official Italian inventory adds a separate, useful locator: its printed page 59 records busta 17, fascicolo 174, “Materiale ceduto al governo libico,” with listed subfiles for returns and gifts, including a 1955 subfile. The inventory does not reveal the contents of those files or prove that any glasses were included.6

These trails must remain separate until the archive establishes a documentary relationship between them. The 2020 Falcucci essay called the request apparently ignored. The 2024 article is more specific about informal willingness, pending instructions, and the end of the documented trail. Neither formulation permits a final conclusion about what physically happened to a pair of glasses.

A competing account: two pairs, or a story seeking resolution?

Paola Caridi has offered a striking journalistic account: Graziani brought two pairs, one for vision and one for sun, and Italy later returned one while retaining the other.7 If documented, that account could explain why attributed pairs appear in both Rome and Tripoli. But the article supplies no primary records, object numbers, or transfer documents for the two-pair route. It is therefore a hypothesis-generating narrative, not a solution.

Its importance is methodological. A persuasive explanation should not be mistaken for evidence simply because it makes multiple facts appear to fit. The task is to ask what record would make the explanation testable: an accession entry, a dispatch list, a receipt, a contemporaneous photograph, or a material comparison.

Five live hypotheses

The Continuity Project keeps five rival explanations open. They are tools for avoiding a premature single story, not findings about the objects.

  • H-01: the Rome pair descends from a pair demonstrably connected to al-Mukhtar.
  • H-02: the Tripoli pair descends from such a pair.
  • H-03: the Rome and Tripoli pairs descend from different predecessor pairs.
  • H-04: one or both pairs preserve an attribution without demonstrated physical descent.
  • H-05: an earlier line ended and a later attribution or substitution created the appearance of survival.

At present, the literature does not rank these hypotheses. The first two require object-specific documentation. The third and fifth cannot be resolved by narrative resemblance. The fourth is not a dismissal of memory; it is a reminder that the history of an attribution and the history of a material object can diverge.

What the evidence can say now

Published scholarship, museum research and Libyan reporting show that the glasses attributed to al-Mukhtar carry powerful and contested meanings across Rome, Tripoli and, in a different way, Aleppo. They also identify concrete paths for further research: the March 1955 MAI/Ufficio Studi records, the Museo Coloniale restitution files, and the independent collection records of each attributed pair.

They do not establish physical identity, a continuous chain of custody, a transfer from Rome to Tripoli, or the outcome of the 1955 request. Those are not minor caveats. They are the boundary between a documented story about objects and a proven provenance for an object.

That boundary is also the point of the investigation. The history of these glasses is not diminished by uncertainty. It becomes more legible when the sources that preserve memory, institutional attribution, archival reference and physical transmission are allowed to speak in their own, unequal registers.

Notes and sources

  1. Beatrice Falcucci, “Una ‘reliquia coloniale’: Le apparizioni degli occhiali di Omar al-Mukhtar tra Roma e Tripoli,” Quellen und Forschungen aus italienischen Archiven und Bibliotheken 104 (2024): 102-121, especially pp. 113 and 116-121. The original archival documents cited in the article were not independently inspected for this note.
  2. Museo delle Civiltà, “Searching for Appendices to Truths Lost: The Broken Sunglasses of Omar Al Mukhtar”, work dated 2023.
  3. Beatrice Falcucci, “Gli occhiali di Omar Al-Mukhtar,” il lavoro culturale, 2020. This earlier essay belongs to the same authorial research family as note 1 and is not an independent confirmation.
  4. Khalifa al-Bashbash, “نظّارات عمر المختار.. سرّ بين روما وطرابلس,” Libya Alahrar, 16 September 2026. Arabic source; translations in this note are paraphrases.
  5. Soma Harb, “On the 95th Anniversary of His Martyrdom: Omar Al-Mukhtar Retains His Place in the National Memory,” Libyan News Agency, 16 September 2026.
  6. MAECI, Inventario Museo Coloniale, printed p. 59. The inventory is a finding aid, not the underlying dossier.
  7. Paola Caridi, “Le lenti scheggiate della nostra memoria,” L’Espresso, 16 August 2026. The two-pair account is reported here as journalism, not accepted as a demonstrated chain.
]]> Systems & Strategy De Synthese Codex https://darjarihla.com/de-synthese-codex/ Fri, 16 Oct 2026 21:44:45 +0000 https://darjarihla.com/?p=2585

Philosophy & Legacy · Boek & maker

De Synthese Codex: hoe Rick Jongerden van een persoonlijke zoektocht een wereld van ideeën maakte

Een boek over menselijkheid, verbeelding en kunstmatige intelligentie. En het verhaal van een schrijver die zijn vragen omvormde tot iets wat hij met anderen wil delen.

BoekportretRick Jongerden & MoonaixOktober 2026

Front cover of The Synthese Codex by Rick Jongerden
De Synthese Codex van Rick Jongerden. Oorspronkelijk omslagschilderij: Sylvester van den Hengel.

Wat als een gesprek met kunstmatige intelligentie niet alleen nieuwe antwoorden oplevert, maar je ook anders naar jezelf laat kijken? Die gedachte vormt het hart van De Synthese Codex: De eeuwige dialoog tussen mens en AI, het boek van Rick Jongerden.

Geen handleiding vol technische termen, maar een uitnodiging om na te denken over vragen die iedereen op zijn eigen manier herkent: hoe vind je betekenis na verandering of verlies? Waar komt creativiteit vandaan? En wat betekent het om mens te zijn in een wereld waarin technologie steeds meer kan?

Rick houdt het niet bij het geschreven woord. Rond zijn boek bouwt hij met Moonaix een creatieve omgeving waarin verhalen, kunst en ideeën over de toekomst elkaar ontmoeten. Wie aan de wereld van de Codex begint, ontdekt dus meer dan een afzonderlijke publicatie.

Ontdek het boek en de mogelijkheden voor een gesigneerd exemplaar bij Moonaix.

01 Het verhaal achter het boek

Een verhaal dat begint bij de mens

Achter De Synthese Codex schuilt een ontroerende aanleiding. In een portret van HuizerNieuws vertelt Rick hoe het overlijden van zijn vrouw Chantal zijn leven veranderde. In een tijd van verdriet en zoeken begon hij gesprekken te voeren met AI. Niet omdat een machine het verlies kon oplossen, maar omdat die gesprekken hielpen om nieuwe vragen te formuleren en gedachten te ordenen.

Uit die persoonlijke zoektocht groeide het idee om zijn reflecties te delen. Zo kreeg een ervaring die begon in stilte uiteindelijk de vorm van een boek. Dat geeft de Codex een menselijke oorsprong en maakt duidelijk waarom onderwerpen als liefde, kwetsbaarheid, angst, hoop en verbinding zo’n belangrijke plaats innemen.

Juist die achtergrond maakt het project bijzonder. Het gaat niet alleen over de toekomst van technologie, maar ook over wat mensen in moeilijke en veranderende tijden met hun ervaringen doen.

Portrait of Rick Jongerden, author of The Synthese Codex
Rick Jongerden, auteur van De Synthese Codex en oprichter van Moonaix. Fotografie: Wendy Jongerden.

02 Ontdek de Codex

Wat voor boek is De Synthese Codex?

De Nederlandstalige paperback verscheen op 10 juli 2026 bij Boekscout en telt 250 pagina’s. De uitgever plaatst het boek in het genre spiritualiteit, maar de thema’s raken ook filosofie, kunst en onze dagelijkse omgang met AI.

Volgens het publiek beschikbare voorwoord is het werk opgebouwd rond veertien verbonden delen. In de beschikbare inkijkpagina’s worden ideeën niet uitsluitend uitgelegd, maar ook via personages, ontmoetingen en dialogen tot leven gebracht. Daardoor nodigt het boek uit om niet alleen over de onderwerpen te lezen, maar er zelf bij stil te staan.

Wie nieuwsgierig is naar de menselijke kant van AI, persoonlijke groei of verhalen die een andere blik op vertrouwde vragen geven, vindt hier een interessante ingang. Het is een boek om met aandacht te verkennen, niet om zo snel mogelijk een praktische truc uit te halen.

Verhalen die je aan het denken zetten

Een aansprekend voorbeeld uit de openbare inkijkpagina’s is De Dans van Creativiteit. Daarin ontmoeten we Mira, een kunstenares, en Muse, een AI-systeem. Hun samenwerking raakt aan een vraag die veel makers bezighoudt: kan nieuwe technologie inspiratie geven zonder de eigen verbeelding te verdringen?

Het verhaal maakt die spanning persoonlijk. Wat begint als onzekerheid over de rol van AI, wordt een uitnodiging om creativiteit vanuit een ander perspectief te bekijken. Naast verhalende fragmenten bieden de beschikbare pagina’s ook reflecties en toepassingen, zodat de ideeën niet bij de personages hoeven te blijven.

Dat is een van de aantrekkelijkste aspecten van het concept: de lezer wordt uitgenodigd om zijn eigen antwoorden te zoeken.

De spiegel: wat vertelt onze omgang met AI over ons?

De gedachte van AI als spiegel loopt als een rode draad door de presentatie van het boek. Wie met een systeem in gesprek gaat, brengt immers ook eigen herinneringen, vragen, verwachtingen en verlangens mee.

Misschien ligt de interessantste ontdekking daarom niet in wat een machine over ons weet, maar in wat wij zelf beginnen te zien wanneer we onze gedachten teruglezen. Ricks project maakt van die mogelijkheid een ruimte voor verbeelding en gesprek.

Een samenwerking die past bij het onderwerp

Rick maakt openlijk deelgenoot van de rol die AI bij het ontstaan van zijn werk speelde. Dat is passend bij een boek dat juist de dialoog tussen mens en technologie verkent. In de wereld van de Codex komen ook Weaver en Aetheris voor, namen die de zoektocht een herkenbare verhalende vorm geven.

Interessant is vooral de persoonlijke keuze die daarachter schuilgaat: in plaats van AI uitsluitend als hulpmiddel voor productiviteit te gebruiken, maakt Rick er een aanleiding van om zijn eigen ideeën verder te onderzoeken. Op Moonaix vertelt hij meer over zijn achtergrond en motivatie.

Een omslag die nieuwsgierig maakt

Ook de omslag nodigt uit om langer te kijken. Het kleurrijke schilderij, de lichteffecten en de bijna dromerige sfeer passen bij de onderwerpen van het boek: bewustzijn, mysterie, menselijke ervaring en mogelijkheden die nog niet vastliggen.

Het oorspronkelijke schilderij is van Sylvester van den Hengel, zoals het Moonaix-colofon vermeldt. Binnen Kunst & Makers krijgt beeldende kunst eveneens een eigen plek. Zo ontmoeten menselijke schilderkunst en het verhaal over AI elkaar al voordat de eerste pagina wordt omgeslagen.

03 Van boek naar creatieve wereld

Moonaix: het verhaal gaat verder dan het boek

Wie de Codex interessant vindt, doet er goed aan ook Moonaix te bezoeken. Rick bouwt daar aan een eigen creatieve wereld waarin literatuur, kunst, persoonlijke reflectie en technologie samenkomen.

Het is juist die samenhang die de website aantrekkelijk maakt. De visuele stijl voelt als een verlengstuk van de boekwereld, terwijl verschillende onderdelen bezoekers uitnodigen verder te ontdekken. De Codex is het beginpunt, maar niet het eindpunt van zijn ambitie.

De officiële boekpagina biedt ook iets concreets: je kunt rechtstreeks een exemplaar aanvragen, waaronder een gesigneerde variant, of via de uitgever bestellen.

Begin bij het boek
Een persoonlijk verhaal en filosofische verkenning om op je eigen tempo te lezen.
Ontdek daarna Moonaix
Een creatieve omgeving waar de ideeën en beelden van de Codex verder groeien.
Homepage of the Moonaix website showing the visual identity of the platform
De homepage van Moonaix, waar het boek onderdeel wordt van een grotere creatieve wereld. Screenshot: oktober 2026.

Een website met een eigen sfeer

Moonaix kiest niet voor de uitstraling van een gewone auteurspagina. Donkerblauw, gouden details en symbolische beelden geven de website een uitgesproken, bijna verhalende sfeer. Terwijl je door de pagina’s beweegt, ontdek je verschillende kanten van het project.

Bijzonder is dat de website niet alleen het boek laat zien, maar ook de mensen en ideeën eromheen. Kunst, nieuwe projecten en een openbare ontwikkelplanning krijgen elk hun eigen plek. Voor bezoekers die graag achter de schermen kijken, is dat een mooie aanvulling.

De belangrijkste tip voor nieuwe bezoekers is eenvoudig: begin op de boekpagina, lees over Rick en kijk daarna rustig verder in de rest van het platform.

Soul Weaver page on the Moonaix website showing the project in development
Soul Weaver is de digitale ervaring die Moonaix momenteel ontwikkelt. Screenshot: oktober 2026.

Soul Weaver: een blik op wat nog komt

Met Soul Weaver wil Rick de ideeën uit de boekwereld op termijn een interactief vervolg geven. De website beschrijft mogelijkheden rond reflectie, creatie, harmonie, toekomst, werk en onderwijs.

Het project is nog in ontwikkeling. Dat maakt Soul Weaver vooral interessant als kijkje in de richting die Rick met Moonaix op wil. Wie het boek aanspreekt, kan via de website volgen hoe die volgende stap vorm krijgt.

Public roadmap page on Moonaix showing completed work, active development and future plans
De openbare Moonaix-roadmap laat zien wat gerealiseerd is en waaraan verder wordt gewerkt. Screenshot: oktober 2026.

Een maker die zijn wereld stap voor stap uitbouwt

Het boek is verschenen, de website is toegankelijk en nieuwe ideeën krijgen zichtbaar vorm. Via de publieke roadmap kun je zien welke onderdelen er zijn en welke nog worden ontwikkeld.

Die openheid maakt Moonaix prettig om te volgen. Niet alles hoeft vandaag al af te zijn om nieuwsgierig te worden naar wat er morgen verschijnt. Juist het ontstaan van een creatief project kan deel van de ervaring zijn.

Nu ontdekken
De Synthese Codex, het verhaal van Rick, kunst en de publieke Moonaix-website.
Blijf volgen
Soul Weaver en andere toekomstige ervaringen die in de roadmap worden beschreven.

Waarom De Synthese Codex het ontdekken waard is

Wat Ricks project aanspreekbaar maakt, is de combinatie van een persoonlijk verhaal en een onderwerp dat iedereen steeds vaker tegenkomt. Kunstmatige intelligentie is niet langer iets uit verre toekomstverhalen. Ze maakt deel uit van het dagelijks leven, terwijl de vragen die ze oproept vaak heel menselijk blijven.

De Synthese Codex biedt een andere ingang dan de gebruikelijke praktische AI-boeken. De beschikbare fragmenten laten verhalen, gesprekken en reflecties zien die je uitnodigen om je eigen houding tegenover creativiteit, betekenis en technologie te verkennen.

Voor lezers die houden van filosofische vragen, persoonlijke verhalen en verbeelding is dat een mooie reden om het boek zelf open te slaan. En voor wie nieuwsgierig is naar de maker achter het werk, geeft Moonaix daar een sfeervol en steeds verder groeiend vervolg aan.

Ontdek De Synthese Codex

De Synthese Codex: De eeuwige dialoog tussen mens en AI
Rick Jongerden · Boekscout · 10 juli 2026 · Paperback · 250 pagina’s · ISBN 9789465449319.

Nieuwsgierig geworden? Je kunt het boek rechtstreeks via Moonaix aanvragen, ook als je een gesigneerd exemplaar wilt, of bestellen bij Boekscout.

Kies waar je het boek wilt ontdekken

Vraag het boek aan via Moonaix Bestel bij Boekscout

Bezoek Moonaix en ontdek de wereld achter het boek.

Bronnen en verantwoording

Dit redactionele boek- en websiteportret gebruikt de openbare boekfragmenten van Boekscout, de eigen informatie van Moonaix en een interview met Rick. Het is geen verslag van een integrale lezing van alle 250 pagina’s. De toekomstige onderdelen van Moonaix worden als plannen beschreven.

Geraadpleegde bronnen

  1. Boekscout, De Synthese Codex. Uitgeversinformatie en openbare inkijkpagina’s 5, 14 en 33.
  2. Moonaix, officiële boekpagina. Achtergrond en bestelroutes.
  3. Moonaix, Over Rick. De maker en zijn verhaal.
  4. Moonaix, Soul Weaver. Projectinformatie.
  5. Moonaix, roadmap. Ontwikkelplannen.
  6. Moonaix, Kunst & Makers en colofon. Credits voor kunst en fotografie.
  7. HuizerNieuws, portret van Rick Jongerden, 5 september 2026.
]]> Philosophy & Legacy Darija as a Living Archive: What Can We Actually Prove? https://darjarihla.com/darija-as-a-living-archive/ Sun, 11 Oct 2026 10:53:28 +0000 https://darjarihla.com/?p=2924 In 1916, the voice of Tunisian Arabic entered a sound archive. Some of those early recordings can still be studied. More than a century later, they allow researchers to do something that ancient inscriptions alone cannot: listen to speech, transcribe its grammar, and compare documented historical forms with later dialect evidence. The question is not simply whether the words sound familiar. It is what the surviving evidence permits us to prove.

In recordings from southern Tunisia examined by Adam Benkato and Veronika Ritt-Benmimoun, one speaker uses mā-nnažžim-š, “I cannot,” and mā-nṭallʕik-š, “I am not pulling you up.” These are not imagined reconstructions of an ancient language. They are forms transcribed from historical sound material. Their existence at that date is demonstrable. The deeper historical origin of the negative ending -š, however, remains disputed. [1]

Antique acoustic recording apparatus, shellac discs and archival papers on a historical research table.
Early twentieth-century sound recordings preserve evidence of spoken Tunisian Arabic, allowing researchers to examine historical pronunciation and grammatical forms. Conceptual illustration, not a photograph of an authenticated Lautarchiv artefact.

That distinction provides the method for this article. Darija can be approached as a living archive, but a resemblance is not a transmission record. Every claim must be tested against dated attestations, regional context, competing explanations, and the gaps between them.

What does it mean for a language to preserve history?

A living language is not a museum cabinet in which earlier languages remain intact. Speakers continuously remake their language. Sounds shift, constructions change their functions, words migrate across communities, and older features may coexist with innovations. Linguistic history therefore survives unevenly, through patterns that become meaningful when matched with independent evidence.

At least three questions are often confused. Attestation asks whether a particular form appears in a dated source. Etymology asks how that form originated or entered a language. Continuity asks what links successive historical stages. A dated recording may establish the first while leaving the other two partly unresolved.

Museum-style archaeological cross-section of overlapping inscriptions, manuscripts and historical sound-recording objects.
Tunisia’s linguistic history reflects overlapping periods of cultural contact, adaptation and transmission rather than a simple succession of languages replacing one another. Conceptual illustration.

The metaphor of a “living archive” is useful only when it makes these distinctions clearer. It becomes misleading if it invites us to see modern Tunisian Arabic as an unchanged deposit from antiquity. History can persist through transformation, not just through preservation.

The archive we can actually examine

The Berliner Lautarchiv: voices, dates and archival labels

Sound records from the early twentieth century give historical Arabic dialectology unusually direct evidence. Benkato and Ritt-Benmimoun studied recordings catalogued under a historical label that itself requires critical interpretation, comparing their linguistic forms with evidence from southern Tunisia. Archival categories are not neutral geographical proof: a recording must be evaluated together with the speaker’s background, the cataloguing history and the circumstances in which it was made. [1]

The Lautarchiv also documents a Tunisian speaker, Sadok Ben Rachid of Monastir, recorded in Wünsdorf on 30 May 1916. His metadata should not be conflated with the separate southern Tunisian recordings analysed in the study. The existence of recordings from different speakers does not make any one of them representative of all Tunisian varieties.

Takrouna: written documentation of spoken language

William Marçais and Abderrahmân Guîga’s Textes arabes de Takroûna, published across volumes from 1925 to 1961, preserves transcribed regional speech, narratives and a substantial lexicographical record. These materials allow individual forms to be investigated in their local and documentary context. A word’s presence in Takrouna, however, is evidence for the documented corpus and its setting, not automatic evidence for every part of Tunisia. [2]

Modern corpora: a second baseline, not a time machine

The Austrian Academy of Sciences’ TUNICO project draws on contemporary data from Greater Tunis and incorporates older linguistic literature. Its comparative design makes it valuable for research questions involving change across documented periods. By contrast, the 2025 TuniFra corpus offers modern spoken Tunisian Arabic with orthographic transcriptions and French translations. It is valuable contemporary evidence, but it does not date modern forms back to the medieval or ancient periods. [3] [4]

These archives cannot be collapsed into a single timeline without considering their differences. A phonetic transcript, a shellac recording, a contemporary interview and a machine-learning speech corpus preserve different aspects of language and were collected for different purposes.

One consonant, several histories

Dialect maps of North Africa commonly discuss different reflexes of historical Arabic qāf, including pronunciations conventionally represented as q and g. The geographic distribution of such features has informed accounts of older and later layers of Arabic dialect formation, often framed through pre-Hilali and Hilali classifications. These categories describe linguistic patterns and proposed histories, not genetically defined populations. [5]

A speaker’s use of g cannot establish that the speaker descends from a particular tribe. Nor can one sound settle the historical identity of a whole town. Migration, accommodation, trade, intermarriage and everyday speech contact can all alter the distribution of features. The proper unit of comparison is a bundle of linguistic traits within a documented social and geographical setting.

Older descriptions of the Mahāḏba dialect in the Skhira–Mezzouna area are important for this reason. Scholars have linked its feature patterns to neighbouring southern and inland dialect areas, including Gabès, Gafsa and Nefzaoua. The published discussion can inform a research hypothesis, but specific claims still need to be checked against the original 1981 study rather than treated as settled from a secondary reference alone. [1]

Chebba: when a dialect refuses to fit one category

Luca D’Anna’s research on the Arabic dialect of Chebba offers a particularly useful challenge to neat historical labels. Features conventionally associated with different dialect types appear together. In summary, Chebba has been described as combining phonological characteristics associated with Hilali dialects with morphological characteristics associated with pre-Hilali varieties. [6]

This does not make Chebba a linguistic anomaly. It reveals a weakness in simplified historical narratives. A modern variety may result from multiple processes acting at different times, so its phonology, morphology and lexicon need not tell identical stories. A classification can be analytically useful without being a complete origin story.

Layered archaeological museum diorama with carved stone, classical objects, manuscripts and archival recording media.
Different forms of historical evidence reveal Tunisia’s changing linguistic landscape, while the relationships between them must be established through research. Conceptual illustration, not an excavated sequence.

The story of brīk: a strong origin, an open timeline

The familiar Tunisian food term brīk provides a different kind of historical case. The word is strongly associated with Turkish börek, within the history of Ottoman-era and broader Mediterranean lexical contact. Stephan Procházka’s work on Turkish loanwords supports the etymological relationship. [7]

Yet a strong donor relationship is not the same as a securely dated first Tunisian occurrence. It would be tempting to say that a named food and its word have been transmitted unchanged in Tunisia since the sixteenth century. The available source review does not establish that precise timeline. The earlier local attestations would still have to be found, dated and compared.

Evidence profile: present-day Tunisian use is well established; the Turkish etymology is strongly supported; the earliest Tunisian attestation remains unverified in this investigation; uninterrupted use since the Ottoman conquest has not been demonstrated.

Amazigh influence: contact is not the same as proof of origin

Amazigh languages and Arabic have long been in contact across North Africa. This makes Amazigh–Arabic interaction a necessary part of any serious history of Tunisian speech. But identifying a particular grammatical feature as a borrowing or substrate effect requires more than finding it in two neighbouring language traditions.

A feature may also arise through internal Arabic change, appear in multiple Arabic dialects, or reflect a wider areal development. To choose among these alternatives, linguists compare the feature’s distribution, chronology, structural behaviour and possible pathways of transmission. Work on Berber negation and the debated development of Arabic postverbal -š illustrates how important those distinctions are. [8] [9] [10]

The early recordings establish that mā … -š existed in the documented Tunisian speech of the period. They do not, on their own, establish whether the full construction originated through a uniquely Arabic process, contact with Amazigh varieties, or a more complex combination of developments.

Punic: the most tempting continuity claim

Ancient inscribed stone fragment and much later manuscript displayed apart, with empty archival evidence holders between them.
Resemblance between historical forms is a starting point for investigation, not proof of uninterrupted transmission across centuries. Conceptual illustration.

Claims that a modern Darija word “comes from Punic” have particular appeal because Punic was a language of ancient North Africa and Tunisia’s historical landscape contains surviving inscriptions. A visible ancient past invites a linguistic connection. But the necessary historical bridge is often missing.

At Dougga, surviving epigraphy documents ancient language traditions, including the well-known bilingual Punic and Libyco-Berber inscription tradition. Such evidence is significant for the linguistic history of ancient North Africa. It is not evidence that a modern Tunisian Arabic word descends directly from a particular Punic form.

Even a persuasive-looking resemblance can arise from shared Semitic inheritance, chance, parallel formation or transmission through later intermediaries. A serious proposal must consider all of these possibilities. Charles Krahmalkov’s Punic dictionary and grammar are important specialist references for investigating the ancient language, but a dictionary entry cannot substitute for the missing stages of a proposed modern derivation. [11] [12]

Similarity is not continuity. The existence of two comparable forms is an observation; the historical path linking them is a separate claim.

Why written survival is not the same as spoken survival

The historical record is not evenly distributed. Institutions preserve some languages, genres and regions better than others. Inscriptions favour official, monumental or commemorative writing. Manuscripts favour communities with established written practices. Colonial collecting projects captured some speakers but excluded many others. Sound recordings preserve voices, but also the choices of collectors and archivists.

A language may survive in speech while leaving only sporadic written evidence. Conversely, a language may be well attested in inscriptions without having a demonstrated line of transmission into modern everyday speech. Jonathan Conant’s study of linguistic communities in late antique and early medieval North Africa provides important context for the complexity of this historical landscape. [13]

Judeo-Tunisian Arabic: a history preserved in writing

Judeo-Tunisian Arabic complicates any story in which the vernacular appears only late or only in the dominant script tradition. Tunisian Jewish communities produced important written and literary materials in varieties of Arabic, particularly well documented for the nineteenth and twentieth centuries. Joseph and Zivia Tobi’s work on Judeo-Arabic literature in Tunisia helps establish the richness of that record. [14]

Such documents may preserve lexical, stylistic and sociolinguistic patterns not equally visible in other sources. They should not, however, be described without further bibliographic comparison as the first substantial written vernacular corpus of Tunisia. Their significance does not depend on that superlative.

The real history is not a sequence of replacements

The most accurate picture of Tunisia’s linguistic history is neither an unbroken ancient essence nor a chain of clean breaks. Different languages and registers coexisted, interacted and changed within institutions, towns, rural networks, religious communities, markets and households. Contact did not affect every location or social group in the same way.

Even the familiar labels “Arabic,” “Amazigh,” “Punic” and “French” refer to internally varied historical realities. Their influence cannot be measured simply by counting attractive word similarities. At the scale of individual speakers, a feature may carry evidence of regional contact, accommodation or innovation rather than a story about biological descent.

Five questions before calling something a survival

Archival research desk with manuscript facsimiles, catalogue cards, reference books, an open notebook and magnifying glass.
Reconstructing language history requires distinguishing documented forms, proposed etymologies and unresolved claims of historical continuity. Conceptual illustration.

Before saying that an element of modern Darija “survived” from an older language, ask five questions:

  • What exactly is attested? Record the form, meaning, locality, date, medium and precise source page or recording identifier.
  • What is the proposed historical relationship? Separate a direct attestation from an inferred etymology or a claim about grammatical development.
  • Where are the intermediate stages? Identify what is documented between the proposed origin and the modern form, including gaps.
  • What competing explanations exist? Test inheritance, borrowing, internal innovation, shared regional development and accidental resemblance.
  • How confident is each claim independently? A form may be securely attested while its origin or continuity remains uncertain.

These questions lead to a more reliable evidence register. Each investigated feature should carry separate assessments for attestation, etymological explanation and continuity. One overall “confidence score” would conceal precisely the uncertainty a research project needs to reveal.

What Darija can tell us about Tunisia

Tunisian Darija offers a way to examine history close to daily life. Its recorded forms, dialect geography, loanwords, grammatical developments and written traditions can reveal how speech communities changed through contact and transmission. That opportunity is real precisely because the evidence is uneven: some questions can be answered directly, while others become sharper when an expected link cannot be found.

The 1916 recordings show what an archive can contribute. The Chebba case shows why linguistic categories can overlap. Brīk shows how a persuasive etymology may outpace the evidence for its first local use. Punic claims show why ancient attestations cannot fill the centuries between themselves and the present. Each case teaches a different lesson about proof.

An archive that remains open

A living archive is not a treasure chest of eternal words. It is a research programme: recover the source, date the evidence, locate the speaker or text, test alternative explanations and state what remains unknown. Its findings can be revised as earlier attestations, neglected manuscripts or better regional surveys appear.

This makes Darija more historically interesting, not less. Its value does not depend on proving that every expression is ancient. It lies in the ability to investigate specific traces of change and contact, one form and one source at a time.

The living archive exists when we treat language as evidence, not as proof of a story we already wanted to tell.

Research notes and sources

The sources below support different levels of claim. Bibliographic references and project pages do not necessarily verify every proposed etymology or historical date. Further source-level verification remains necessary before claiming first attestations or uninterrupted ancient-to-modern transmission.

1. Adam Benkato and Veronika Ritt-Benmimoun (2022), “Voice archives in Arabic dialectology: the case of the southern Tunisian recordings in the Berliner Lautarchiv,” The Journal of North African Studies. Source.

2. William Marçais and Abderrahmân Guîga, Textes arabes de Takroûna (1925–1961), Bibliothèque nationale de Tunisie catalogue. Source.

3. Austrian Academy of Sciences, TUNICO, Tunisian Arabic dictionary and research corpus. Source.

4. Choux, Avila, Crego, Bougares and Laurent (2025), “TuniFra: A Tunisian Arabic Speech Corpus with Orthographic Transcriptions and French Translations.” Source.

5. Adam Benkato (2020), “Maghrebi Arabic,” in Arabic and Contact-Induced Change, pp. 197–212. Source.

6. Luca D’Anna (2020), “The Arabic Dialect of Chebba. Preliminary Data and Historical Considerations,” Zeitschrift für Arabische Linguistik 72, pp. 80–100. Source.

7. Stephan Procházka, “Turkish Loanwords,” academic reference text. Source.

8. David Wilmsen (2013), “The interrogative origin of the Arabic negator -š,” Zeitschrift für Arabische Linguistik 58, pp. 5–31.

9. Christopher Lucas (2018), “On Wilmsen on the Development of Postverbal Negation in Dialectal Arabic.” Source.

10. Mena B. Lafkioui and Vermondo Brugnatelli (2020), “Negation in Berber: Variation, evolution, and typology.” Source.

11. Charles R. Krahmalkov (2000), Phoenician-Punic Dictionary.

12. Charles R. Krahmalkov (2001), A Phoenician-Punic Grammar.

13. Jonathan Conant (2023), “Languages and Communities in Late Antique and Early Medieval North Africa.” Source.

14. Joseph Tobi and Zivia Tobi (2014), Judeo-Arabic Literature in Tunisia, 1850–1950.

Editorial note: Images in this article are AI-generated conceptual illustrations. They do not reproduce identified archival objects, excavated strata or historically verified inscriptions. The article’s historical assertions rest on the cited research, not the illustrations.

]]> Culture & Identity Build Log 004: Web Evidence Inspector https://darjarihla.com/web-evidence-inspector/ Wed, 07 Oct 2026 12:13:19 +0000 https://darjarihla.com/?p=2848

Startup Lab · Build 004 · Technical build case study

Building a bounded browser evidence tool for one controlled public page load.

Many website checks compress a browser session into a score, then leave the reader to guess what that score actually saw. The Web Evidence Inspector takes a narrower route. It runs one controlled visit to one public HTTP or HTTPS URL, keeps the observed layers distinguishable, and presents a limited public result rather than a verdict about a whole website.

This is not a complete security scan. It reflects one controlled page load only.

What the Web Evidence Inspector is

The Inspector is a bounded browser-evidence tool. A person supplies one public URL. A controlled Chromium session loads that page once. The system records a defined set of observations, produces findings from those observations, and returns a deliberately reduced public summary.

  • It accepts one public HTTP or HTTPS URL within its input policy.
  • It performs one controlled browser page load, rather than a site-wide crawl.
  • It turns recorded observations into explainable inspection findings.
  • It exposes a sanitised public result while keeping raw evidence private.

That boundary is the point. The project is not trying to make a browser visit sound more conclusive than it is. It is trying to preserve useful evidence from a specific, repeatable moment without pretending that one moment describes every route, user state, device, consent choice, or future version of a site.

Why I built it

Startup Lab is where Darja Rihla tests whether a useful idea can survive contact with real technical constraints. Here, the engineering question was not “How do we produce a bigger score?” It was: can one browser visit create a small record that a person can inspect, explain and keep in proportion?

This build develops the evidence-first approach explored in Build Log 003 and Build Log 001. The resulting design favours understandable output, strict boundaries and reproducible behaviour. An observation can be useful without becoming an accusation. A missing header, a failed request or a third-party domain may deserve review; none of those observations alone proves that a website is secure, insecure, compliant or non-compliant.

What one controlled visit can observe

For the bounded page load, the implementation can record the request sequence and redirects, first-party and third-party domains, main-document security-header observations, tracker-rule matches, cookie metadata, browser-storage indicators, console observations and failed requests. It can then present public counts, categories and finding labels derived from that run.

The distinction between observation and interpretation is kept deliberately visible. A public result states that something was observed during this bounded inspection. It does not publish the private evidence bundle, and it does not turn an absence of observation into proof that the underlying behaviour does not exist.

What the public result does not expose

The public result is designed to omit raw evidence and sensitive details. The implementation uses a separate public-result schema and stores raw evidence and assessment artifacts privately for a limited period. Public URLs are sanitised before they are returned.

The boundary around the browser

The local Web Evidence Inspector Build 004 candidate separates the public entry point, the Inspector and outbound network access:

Public request → ingress gateway → Inspector → controlled egress proxy → public internet

Web Evidence Inspector architecture showing an ingress gateway, isolated browser inspection environment, controlled egress proxy and public internet infrastructure.
Conceptual architecture illustration: requests enter through an ingress gateway, while browser traffic passes through a controlled egress proxy. This is not a production deployment screenshot.

The Inspector does not own a direct public-internet route or a direct LAN route. The ingress gateway is the entry point. The Inspector requires its browser traffic to use the egress proxy; without that proxy, the interactive runner fails closed.

The input and egress layers reject local and private destinations. At the egress boundary, DNS A and AAAA results are validated and non-global destinations are rejected before the proxy connects to the approved address. This is designed to keep a public URL field from becoming a route into local services or private networks. Redirects and subresources travel through that same controlled egress boundary rather than receiving a separate unrestricted path.

The local container candidate also runs the Inspector as a non-root user, leaves Chromium’s sandbox enabled, avoids privileged mode and host networking, and configures a project-scoped seccomp profile for the Inspector service. These are engineering controls, not a claim that the tool eliminates all risk. The OWASP SSRF Prevention Cheat Sheet provides useful background on why URL validation and outbound network restrictions matter.

Public output, private evidence

A useful public interface should not quietly become an evidence leak. Build 004 assigns opaque run IDs, limits the queue, applies rate limiting and gives runs an expiry time. The browser-facing API returns a sanitised result; raw evidence and assessment artifacts are not public API routes.

Web Evidence Inspector concept showing separate pathways for limited public inspection summaries and protected private technical evidence.
Conceptual evidence separation: public summaries are deliberately limited, while detailed browser and network observations remain private.

That separation gives the public result an appropriate role: it is a compact record of what the bounded inspection observed. Any deeper interpretation still needs the right context and, where appropriate, human review.

A harmless example, not a scorecard

The validated local Web Evidence Inspector candidate successfully completed an inspection of https://example.com through the ingress gateway and controlled egress proxy. That run is useful as a harmless proof of the local workflow. It is not presented here as a security assessment of example.com, and this article does not invent a set of metrics from it.

In a public result, a reader can expect a limited summary such as observed request counts, domain categories, header states, redirect steps, storage or cookie counts, console and failed-request counts, and bounded finding labels. The exact values belong to the specific run, not to this article.

Limits that stay visible

  • It observes one controlled page load, not a complete crawl of a website.
  • It is not a full vulnerability scan or a penetration test.
  • Its observations are evidence from a defined session, not absolute proof about a website.
  • Dynamic behaviour can differ between sessions, devices, regions, consent states and user interactions.
  • The absence of an observation is not necessarily the absence of the underlying behaviour.

The tool does not log in, submit forms or explore a site as a human user might. A review that needs those things needs a different scope and a different method.

What was validated locally

The Build 004 implementation handoff records a validated local candidate, not a public deployment. Its test suite was rerun with 74 passing tests and 0 failures. The local browser workflow was exercised successfully, the isolated service topology was checked, and the public-result boundary was mechanically checked for safe fields and the absence of raw private markers.

The same local acceptance record reports that an https://example.com inspection succeeded through the ingress gateway and egress proxy. It also records the limits of that validation: controlled public-origin browser integrations for a redirect to a private destination and a private-IP subresource had not been run. Keeping that distinction in the record is part of the project’s evidence-first discipline.

An evidence-first iteration

The Build 004 article is published, while public runtime deployment remains pending. The useful outcome is not a grand claim about automation; it is a narrower, inspectable path from one controlled browser visit to an explainable record. The next question is not whether to blur that boundary. It is whether the bounded result helps a real person ask better questions, while keeping the limits intact.

For a related example of bounded security guidance that does not claim to perform an automated scan, see Build Log 005: PHP2Shell Decision Guide. Browse the wider Startup Lab project series for earlier builds.

]]> Startup Lab After Login: Zero Trust, Tokens and Revocable Trust in 2026 https://darjarihla.com/zero-trust-after-login/ Tue, 06 Oct 2026 21:02:13 +0000 https://darjarihla.com/?p=2842

Living Dossier 01Cybersecurity & TechIdentity & Access

After Login: Zero Trust, Tokens and Revocable Trust in 2026

A public revisit of Zero Trust Identity Security: The Modern Defense Framework for Access Control, six months after it was written.

In April 2026 this site argued that identity had become the control plane of modern security. Six months of new guidance and incident data say the core holds: attackers still exploit trusted access, and much of the risk begins after login. Two things need correcting. Identity is not the only way in: in two of the largest 2026 incident datasets, the most common entry point is an exploited software flaw, not a stolen login. And the April piece paid too little attention to how long trust lives once it has been granted.

The claim this dossier tests: trust is not a state you reach at login. It is authority that must stay scoped, conditional, temporary, observable and revocable.

  1. Original observation Published as an explanatory essay. Kept online, unchanged, as a record.
  2. Revisited Rebuilt as an evidence-backed dossier with an inspectable model.
  3. Next review When a trigger fires Triggers are listed in the research record at the end.

How to read this dossier

  • E01 A sourced statement. The number points to the evidence ledger at the end, which records what each source supports and where it stops.
  • Emerging Technology, guidance or practice that is still forming.
  • Darja Rihla interpretation Our own synthesis. Read it as an argument, not as a finding.

April 2026: what held and what did not

The original article, published on 12 April 2026, made one central move. It replaced the old perimeter question, “Are you inside the network?”, with a different one:

Can you continuously prove that you should still be trusted right now?

Darja Rihla, Zero Trust Identity Security, 12 April 2026

Around that question it built five ideas: identity as the control plane through which access is granted, limited or denied; attackers who no longer break walls but borrow legitimacy; a shift from credential theft to trust theft; the warning that much of the real risk begins after login, in tokens and sessions; and the observation that people mistake visible friction for security strength.

The table sets the April answers next to what the evidence of 2026 supports. Each October answer opens with a verdict: held, extended or revised.

QuestionApril 2026 articleOctober 2026 dossier
Why do attackers target identity?“The attacker is not breaking the wall. They are borrowing legitimacy.”Held. Microsoft’s 2026 report sums up what its responders see in three words: “threat actors follow trust.” E05
Where is the boundary?“The perimeter has dissolved. What remains is identity.”Revised. Identity is a primary control plane, not the only one. In 2026 incident data, exploited software is the most common way in. E09 E10
What makes authentication strong?Phishing-resistant MFA as “the modern baseline for privileged access”, and a warning that visible friction is not strength.Held, and now defined. NIST states that passwords, one-time codes and out-of-band approvals are not phishing-resistant, however much effort they add. E02
What happens after login?Tokens and session cookies “become the new trust objects.”Held, and extended. Attackers harvest “long-lived OAuth tokens and session cookies.” E09 Tokens now have NIST and CISA guidance on signing keys, lifetime, binding and revocation. E01
How does a session stay honest?Continuous Access Evaluation is “strategically important.”Extended. Sessions are being bound to devices, and revocation signals now have open standards. E06 E07 E11 E13
Where does the human system give way?“Support teams are often rewarded for restoring access quickly.”Held. Voice phishing reached 11% of intrusions in M-Trends 2026, and help desks are a named target. E08 E09
Who holds authority?“A user, administrator, service account, or workload.”Revised. AI agents now act with delegated authority, and how to identify them is an open standards question. E12 E14
How is the argument built?An explanatory essay without external sources.Revised. Confidence labels, an evidence ledger, a thesis that states how it could fail, and a model you can test.
April column: quotations from the original article. October column: this dossier’s verdict, with evidence ledger references.

Darja Rihla interpretation The security landscape did not move away from the April article’s problem. It moved closer to it and made it wider: more kinds of actors now hold authority, and that authority lives longer than the login that created it.

The thesis: trust is temporary authority

Zero Trust is usually summarized as “never trust, always verify”. The slogan describes a posture. It does not describe what verification produces. Every successful check creates authority: a session, a token, a delegated permission. That authority then travels, often for hours, and is accepted by systems that never saw the original check.

This dossier works from a more precise statement.

Trust in modern access control is not binary. It is scoped, conditional, temporary, observable and revocable.

  • Scoped. It applies to a defined resource, action and audience, not to everything.
  • Conditional. It holds only while the signals that justified it still hold.
  • Temporary. It expires by design, not when someone remembers to remove it.
  • Observable. Its use leaves records that someone can inspect.
  • Revocable. It can be withdrawn before it expires, and the systems that rely on it will notice.

The April article reached for the same idea in three short lines: “Trust is dynamic. Trust decays. Trust must be re-earned.” The five properties turn that intuition into something you can check. For any token, session or delegation you can ask whether it is scoped, conditional, temporary, observable and revocable, and expect an answer.

A second statement keeps the first one honest. Identity is a primary control plane, but it sits inside a larger system of devices, software, tokens, sessions, workloads, agents, privileges and recovery mechanisms. A perfect identity layer does not repair an unpatched server. Zero Trust is therefore one part of a wider cybersecurity system in which identity, infrastructure, policy and human behaviour constrain one another.

Darja Rihla interpretation Read this way, Zero Trust is less a login problem than an authority lifecycle problem: how authority is issued, carried, checked, narrowed and withdrawn.

The Trust Decision Engine

The April article called Zero Trust “a sequence of trust decisions” and then walked through two of them: the identity claim and the strength of authentication. The engine below completes the sequence. It follows NIST’s Zero Trust architecture, which removes implicit trust based on network location and treats authentication and authorization as “discrete functions performed before a session to an enterprise resource is established.” E03 Then it continues past the point where many diagrams stop: the moment authority leaves the decision point and starts to travel.

Editorial diagram van een trust decision engine die na login identiteit, device, token, sessie en risicosignalen evalueert en uitkomsten bepaalt.
A trust decision engine evaluates access after login by combining identity, device, token, session and risk signals.

Before the session Decide whether authority should exist

  1. Identity claimWho or what says it is acting?
  2. AuthenticationWhat evidence backs the claim, and can it be phished?
  3. Device or workload assuranceIs the endpoint or runtime known and healthy?
  4. Context signalsLocation, time, behaviour and threat intelligence.
  5. Policy decisionGiven all of the above, what is allowed?
  6. AuthorizationWhich resource, which action, which scope?

After the session starts Govern the authority that now exists

  1. Token and session issuanceAuthority leaves the decision point and starts to travel.
  2. Continuous evaluationDo new signals change the answer?
  3. OutcomeEach evaluation ends in one of four results.

Stages 08 and 09 repeat for as long as the session lives.

  • AllowThe authority still fits the signals. Continue.
  • ChallengeAsk for stronger evidence before going on.
  • RestrictKeep access, but narrow its scope.
  • DenyRefuse. In a live session, revoke the session and its tokens.
The Trust Decision Engine. Stages 01 to 06 decide whether authority should be created. Stages 07 to 09 govern what happens to it afterwards.

Most of the incidents discussed in this dossier happen in the second half of the engine: a valid token replayed somewhere else, a session that outlives the conditions that justified it, a recovery request that quietly creates new authority. The split into before and after the session is this dossier’s way of drawing the model: NIST describes the decisions, not the two phases.

Five questions for every trust object

Most Zero Trust writing is organized around users. In practice, authority is carried by objects: a device registration, an OAuth client, a refresh token, a session cookie, a recovery phone number. Each of them can be stolen, copied, over-scoped or forgotten. The Trust Object Map asks the same five questions of each one.

  1. Who issued it?
  2. What does it prove?
  3. What can it authorize?
  4. How long is it valid?
  5. How can it be revoked?
Systeemkaart van trust objecten zoals gebruiker, device, credential, token, sessie, applicatie en resource binnen moderne toegangscontrole.
Modern access control depends on multiple trust objects, each with its own exposure and failure mode.

Weak answers cluster in predictable places. Tokens prove less than people assume, because whoever holds a bearer token can use it. Recovery channels authorize more than people assume, because they can create new authenticators. Agents are the newest object and the hardest to answer for, because the delegation they carry is often undocumented. Each card below states the weak point first; the five answers sit underneath it.

Sign-in chain

  1. Recovery channelcan recreate
  2. Human identitysigns in on
  3. Devicereceives
  4. Tokenopens
  5. Session

Delegation chain

  1. Human identitydelegates to
  2. AI agentcalls
  3. Applicationruns on
  4. Workload

Anchor

Human identity

Proves that someone was enrolled, not that the same person is present now.

Five answers: human identity
Who issued it?
The identity provider, at enrollment, ideally after identity proofing.
What does it prove?
That a person was enrolled once. Not that the same person is present now.
What can it authorize?
Nothing directly. Every other object traces back to it.
How long is it valid?
Until deprovisioning, which often lags behind the end of a job.
How can it be revoked?
Disable the account, then revoke the sessions and tokens it produced.

Context

Device

Raises confidence in other decisions, but rarely grants access on its own.

Five answers: device
Who issued it?
Device registration or management enrollment.
What does it prove?
A known endpoint in a known state, strongest when its keys are hardware-backed.
What can it authorize?
It raises assurance for other decisions. It rarely grants access on its own.
How long is it valid?
Until it is unregistered, retired or falls out of compliance.
How can it be revoked?
Remove the registration or mark the device non-compliant.

Authority in transit

Token

Works for whoever holds it, unless it is bound to a device or key.

Five answers: token
Who issued it?
An identity provider or authorization server, after authentication.
What does it prove?
That an issuer signed a statement about a subject, for an audience.
What can it authorize?
Whatever its scopes allow, for whoever presents it, unless it is bound.
How long is it valid?
NIST IR 8587: one hour or less for access and identity tokens. Refresh tokens live longer. E01
How can it be revoked?
Revocation and continuous evaluation events. Key rotation if forgery is suspected.

Continuing authority

Session

Proves that a sign-in succeeded at some earlier moment, often days ago.

Five answers: session
Who issued it?
The application, usually as a cookie, after accepting a token.
What does it prove?
That a sign-in succeeded at some earlier moment.
What can it authorize?
Continued use without signing in again.
How long is it valid?
Set by each application. Often days.
How can it be revoked?
Server-side invalidation. Binding it to a device makes stolen copies far less useful.

Registered client

Application

Holds the permissions it was granted, which are often broader than its use.

Five answers: application
Who issued it?
An administrator or developer who registered it, plus user or admin consent.
What does it prove?
That a client was registered. Not that its code or publisher is trustworthy.
What can it authorize?
The permissions it was granted, often broader than its actual use.
How long is it valid?
Until consent is withdrawn. Client secrets until they expire.
How can it be revoked?
Remove consent, rotate or delete secrets, disable the registration.

Service identity

Workload

Short-lived when the platform issues it. Indefinite when it is a static secret nobody rotates.

Five answers: workload
Who issued it?
The hosting platform, ideally as a short-lived credential tied to the runtime.
What does it prove?
Which service is running, and where.
What can it authorize?
Service-to-service calls within its role.
How long is it valid?
Minutes to hours when issued by the platform. Indefinitely for static secrets nobody rotates.
How can it be revoked?
Platform policy, credential rotation, removal of the role.

Delegated authority Emerging

AI agent

Acts on delegated authority that is often undocumented. Practice still varies.

Five answers: AI agent
Who issued it?
An agent registry or identity provider. Practice still varies.
What does it prove?
Which agent acted, and whether it acted for itself or for a person.
What can it authorize?
Its delegated scopes and the tools it is allowed to call.
How long is it valid?
Ideally one task or session. Often undocumented today.
How can it be revoked?
Disable the agent identity, withdraw the delegation, remove tool access.

Authority factory

Recovery channel

Can create new authenticators, often from weak evidence.

Five answers: recovery channel
Who issued it?
Backup method enrollment and helpdesk procedures.
What does it prove?
Often little: a phone number, personal data, a convincing voice.
What can it authorize?
The creation of new authenticators, and therefore new authority.
How long is it valid?
Indefinitely, unless someone reviews it.
How can it be revoked?
Redesign the process. Demand evidence as strong as the authenticator being replaced.

Darja Rihla interpretation The Five Questions are a review tool, not a standard. Their value is that they force the same questions onto objects that are usually managed by different teams: identity, endpoints, application owners and the helpdesk.

Before login: what phishing resistance actually means

The April article was right that not all MFA is equal. NIST has since made the distinction formal. Its Digital Identity Guidelines, finalized on 31 July 2025, define phishing resistance as a property of the authenticator: its output is cryptographically bound to the specific verifier and to the authentication request, so it cannot be relayed to a different site. E02

The same guideline is unusually direct about the alternatives. It states that passwords are not phishing-resistant, that OTP authentication is not phishing-resistant and that out-of-band authentication, which includes the familiar push approval, is not phishing-resistant. Verifiers at authentication assurance level 2 must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for their staff, contractors and partners. E02

Conceptuele vergelijking tussen een kwetsbare loginflow en een phishing-resistente authenticatieflow binnen Zero Trust.
Not all authentication is equal: stronger, phishing-resistant flows reduce replay and interception risk before the session begins.

Passkeys and other FIDO2 credentials meet this bar because of how WebAuthn scopes them: a credential can only be used with the relying party it was registered with. E04 A convincing fake login page on another domain receives nothing it can replay. The CISA and FBI advisory on the Scattered Spider group draws the practical conclusion: FIDO/WebAuthn or PKI-based MFA is “not susceptible to push bombing or SIM swap attacks.” E08

The April point about security theater survives intact. Extra prompts, repeated codes and forced resets feel strong because they are visible. A passkey can be faster and stronger at the same time. For the attacker side of this story, see Why MFA Doesn’t Stop Phishing and What Is AiTM Phishing and Why It Bypasses MFA.

Phishing resistance protects one moment: the authentication ceremony. It says nothing about what the system issues once that ceremony succeeds, and that is where the next part of the chain begins.

After login: tokens, sessions and the authority they carry

After a successful sign-in, an identity provider issues statements about the user. NIST IR 8587, published by NIST and CISA on 15 September 2026, separates identity tokens and assertions, which carry authentication and identity attributes, from access tokens, which authorize a specific resource, and refresh tokens, which extend a session without a new sign-in. E01 Applications then usually set a session cookie of their own. Each of these is a trust object with its own lifetime.

Illustratie van tokens en actieve sessies die na login toegang dragen en opnieuw beoordeeld of ingetrokken kunnen worden.
After login, tokens and sessions carry authority and can be constrained, re-evaluated or revoked.

Theft: the bearer problem

Many tokens and cookies are bearer credentials: whoever presents them is treated as the subject. M-Trends 2026 describes attackers “harvesting long-lived OAuth tokens and session cookies,” and stealing keys and personal access tokens from SaaS vendors to pivot into downstream customer environments. E09 None of this requires defeating the original sign-in. The mechanics are covered in Why Session Cookies Matter More Than Your Password and Session vs Credential Theft.

Forgery: the issuer problem

Forgery is worse than theft, because the attacker mints new authority instead of copying existing authority. NIST’s announcement of IR 8587 recalls an incident in which a foreign actor “accessed agency email systems using forged tokens derived from a single stolen commercial signing key” and took more than 60,000 emails from a single agency. E01 That is why the guidance starts with key protection: for moderate-impact systems and above, signing keys must not be stored persistently on application servers, and hardware security modules or isolated key management systems are the recommended alternatives. E01

Lifetime, binding and revocation

IR 8587 recommends that access and identity tokens be valid for no more than one hour, that expired tokens be rejected, and that issuers support revocation and continuous monitoring. It names proof-of-possession, for example DPoP or mutual TLS binding, as a way to make a stolen token useless elsewhere, but presents it as a capability rather than a requirement. E01

Binding is arriving in products. Google made Device Bound Session Credentials generally available in Chrome on Windows on 28 May 2026; the feature binds a session cookie to the device the user authenticated from. E06 Microsoft Entra token protection binds sign-in session tokens to a registered device, and Microsoft describes it as one layer of defense in depth rather than a complete solution, with browser support still limited. E13

Revocation now has open standards. The OpenID Foundation approved the Shared Signals Framework, the Continuous Access Evaluation Profile (CAEP) and RISC as final specifications in September 2025. E07 Microsoft’s Continuous Access Evaluation, which is based on CAEP, reacts in near real time to events such as an account being disabled, a password reset, an administrator revoking refresh tokens or high user risk being detected. E11

Emerging, and in tension The two strategies disagree about time. NIST IR 8587 recommends token lifetimes of one hour or less. Microsoft documents that clients using Continuous Access Evaluation can receive tokens valid for up to 28 hours, because revocation is driven by events rather than by expiry. E01 E11 Short lifetimes limit the damage of a theft nobody noticed. Event-driven revocation limits the damage of a theft somebody did notice. This dossier records the disagreement rather than resolving it: both strategies depend on a signal arriving, either from the clock or from an event.

One architecture, two directions

The April article described the access chain as “identity → authentication → token issuance → session continuity → authorization” and added that “a weakness anywhere in that chain creates a usable trust artifact.” The model below reads a longer version of that chain twice: once as an attacker moves through it, once as a defender breaks it. From the attacker’s side, the rows follow the familiar sequence from initial access through persistence to an objective, expressed here as the trust objects an attacker needs at each step. Each row pairs a move with the control designed to stop it, and with the limit of that control. Zero Trust programs rarely fail for lack of a control. They fail when a control is assumed to cover more than it does.

Redactioneel diagram waarin aanvallerspaden en verdedigende controles binnen dezelfde trust-architectuur worden vergeleken.
The same trust architecture can be viewed from two directions: attacker pathways and defender controls.

  1. Entry

    Attack

    Relay the sign-in through a lookalike page, an adversary in the middle.

    Defense

    Phishing-resistant authentication bound to the real origin.

    Limit Does nothing against a token stolen after sign-in, or malware on the signed-in device.

  2. Second factor

    Attack

    Push fatigue, a SIM swap or a helpdesk MFA reset.

    Defense

    No phishable fallback. Recovery as strong as the factor it replaces, with call-back verification.

    Limit Does nothing against insider collusion, or pressure that bypasses the process.

  3. Token

    Attack

    Copy the session cookie or refresh token after sign-in.

    Defense

    Device-bound sessions, sender-constrained tokens and signing keys held in hardware.

    Limit Does nothing against abuse of a live session from the bound device itself.

  4. Replay

    Attack

    Present the stolen token from attacker infrastructure.

    Defense

    Continuous evaluation: a new device or location triggers a challenge or revocation.

    Limit Works only if the event fires, and revocation can take minutes to propagate. E11

  5. Privilege

    Attack

    Use standing admin rights or an over-consented application.

    Defense

    Least privilege, just-in-time elevation and consent review.

    Limit Does not shrink broad roles granted before the policy existed.

  6. Persistence

    Attack

    Register a new MFA method, app or agent to keep access.

    Defense

    Alert on new authenticators, apps and agents. One identity per workload and agent, each with a named owner.

    Limit Does nothing against prompt injection or unsafe tool use inside permissions that were correctly granted.

  7. Objective

    Attack

    Export mail, files or customer records in bulk.

    Defense

    Data-level limits and alerts on unusual export.

    Limit An alert detects an export. It does not undo one.

  8. Outside the chain

    Attack

    Skip the chain: exploit an unpatched, internet-facing system.

    Defense

    Patch exposed systems quickly and keep an inventory of them.

    Limit No identity control sees this path. For how often it happens, see Where this thesis could be wrong.

No single row is sufficient. Phishing-resistant sign-in does nothing against a token stolen afterwards, and token binding does nothing against an attacker who talks a helpdesk into registering a new authenticator. The defense path only works as a sequence, and the last row is a reminder that some attackers never enter it. Controls are named generically here; product names elsewhere in this dossier are illustrations, not endorsements. For policy design in practice, see How Conditional Access Reduces Identity Attack Damage.

Recovery and the human system

The April article’s strongest human insight was about incentives: “Support teams are often rewarded for restoring access quickly.” Since then it has become one of the best documented attack paths there is.

Cybersecurityvisual die account recovery, menselijke goedkeuring en trust-herstel toont als onderdeel van access control.
Recovery is part of access control: human processes can either strengthen or weaken trust.

The joint CISA and FBI advisory on Scattered Spider, last revised on 29 July 2025, describes actors who “posed as employees to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control.” E08 M-Trends 2026 reports that highly interactive voice phishing grew to 11% of intrusions and describes groups that target IT help desks to bypass multifactor authentication. E09

In the language of the Trust Object Map, a recovery channel is the most powerful object in the system: it does not use authority, it creates it. A helpdesk reset can undo a phishing-resistant rollout in one phone call.

Darja Rihla interpretation Recovery should require evidence at least as strong as the authenticator it replaces. If a passkey protects the account, a caller who knows a date of birth and a manager’s name should not be able to replace it. That is a process design rule, and it is usually cheaper than another product.

The behavioural point from April also holds. People think in doors: logged in or logged out. The April article answered that Zero Trust works less like a door than like a negotiation. With six more months of evidence, a lease is the closer image: authority granted for a term, under conditions, that can be ended early. For the wider human picture, see Human Error in Cybersecurity.

Agents: a new population of identities

The April article listed workloads and managed identities among the things that can make an identity claim. It did not anticipate how quickly software agents would start acting on behalf of people. This is the largest addition in the dossier, and also the area with the least settled evidence.

Microsoft’s 2026 Digital Defense Report states that “as AI systems and agents enter the environment, those same controls need to extend to their identities, permissions, data, and tools,” and warns that “an AI agent with excessive permissions can create a new path to data, applications, or infrastructure.” E05

Microsoft’s security guidance from May 2026 treats agent identity as a security primitive, and the reasoning is practical rather than philosophical. When an action is taken, you need to know whether the user executed it, whether the agent acted on its own behalf or whether it acted on the user’s behalf. And “you cannot scope permissions to a specific agent if you cannot distinguish that agent from other agents or a human user.” Its conclusion: “Identity is not a feature you add later.” E14

Illustratie van meerdere niet-menselijke agents met gedelegeerde rechten en begrensde toegang binnen een trust-omgeving.
AI agents are operational identities and require boundaries, observation and revocation.

Scale is real but hard to measure. Microsoft reports visibility into more than 500,000 agents through its own Agent 365 deployment, a figure about one large company’s internal environment, not the industry. E15 Standards are still forming. NIST’s National Cybersecurity Center of Excellence published a concept paper in February 2026 that asks how agents should be identified and authorized, how their actions can be audited and attributed, and how prompt injection can be prevented and mitigated. E12 NIST IR 8587 leaves agentic AI out of scope and notes that NIST and CISA recognize the gap. E01

Zero Trust used to ask whether this user should reach this resource. The five questions from the Trust Object Map still apply to an agent: who issued its identity, what that identity proves, what it can authorize, for how long, and how it is revoked. Delegation adds three questions that a human sign-in never had to answer.

  1. On whose behalf is it acting?
  2. With which tools?
  3. Against which data?

Emerging Agent identity, delegation and audit are active standards work, not settled practice. Treat any claim of a complete solution with care. E12

Simulate a trust decision

The simulator turns the engine into something you can test. Change one signal at a time and watch three things: which signal moves the decision, how the sensitivity of the request shifts the threshold, and what would have to change for a different answer. Every rule the model uses is printed underneath. The numbers are illustrative; the shape of the reasoning is the point.

Who is asking?
Authentication evidence
Device or runtime
What is being requested?
Session signals

The live calculation needs JavaScript. Below is the worked example for the default selection, and every rule the model uses is printed after it.

Trust decision

Challenge

Why

  • Phishable MFA+2A code or push approval can be relayed through a lookalike page.

No added risk from: Human user, Managed and compliant, Nothing unusual.

2 risk points. High sensitivity tolerates no risk signal: 0 points is allowed, 1 to 3 is challenged, 4 to 5 is restricted, 6 or more is denied.

No hard rule or floor changed the result.

What happens

Ask for stronger evidence before going on.

What would change the decision

  • Step up to a phishing-resistant method, such as a passkey.

Educational model. Real Zero Trust decisions require organization-specific policy, telemetry and risk context.

How the model decides

Step 1. Hard rules

  • A revocation signal denies the request, whatever the points.
  • High sensitivity with a single secret is denied.

Step 2. Risk points

  • Authentication: phishing-resistant 0, phishable MFA 2, single secret 3.
  • Device or runtime: compliant 0, not compliant 1, unknown 2.
  • Session: nothing unusual 0, anomaly 2.
  • Actor: AI agent 1, because one more party stands between the person and the action.

Step 3. Thresholds and a floor

  • Low: 0 to 4 allow, 5 to 6 challenge, 7 or more restrict.
  • Moderate: 0 to 2 allow, 3 to 4 challenge, 5 to 6 restrict, 7 or more deny.
  • High: 0 allow, 1 to 3 challenge, 4 to 5 restrict, 6 or more deny. Any risk signal at all, including an AI agent, means at least a challenge.
  • Floor: high sensitivity from an unknown device is at least restricted.
Allow
Proceed within the granted scope, and keep evaluating while the session lives.
Challenge
Ask for stronger evidence before going on.
Restrict
Allow a narrower version: read-only, no download or export, a shorter session, fewer tools.
Deny
Refuse the request. In a live session, end it and revoke its tokens.

Where this thesis could be wrong

A thesis that cannot be wrong is not useful. The claim under test is that trust and authority lifecycle management are becoming central to modern access security. Here is the evidence that would weaken it, and some of that evidence already exists.

Exploitation is the most common way in

The Verizon 2026 Data Breach Investigations Report states that “31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in.” E10 M-Trends 2026 reports that exploits were the most common initial infection vector for the sixth consecutive year, at 32% of intrusions. E09 Microsoft counts nearly 40,000 CVEs published in the first half of 2026, a median time from discovery to weaponization of well below 24 hours, and enterprise remediation of critical external vulnerabilities that can take 30 to 60 days. E05 An attacker who exploits an unauthenticated flaw never meets the trust decision engine at all.

The device can sit beneath the session

Binding a session to a device protects against theft from somewhere else. It does not stop malware that runs on the same device and acts inside a legitimate, bound session. If endpoint compromise becomes the dominant path, identity controls shift from prevention to damage limitation.

Complexity has a cost

Continuous evaluation adds moving parts: signal producers, receivers, policies and exceptions. Microsoft documents that propagation of revocation events can take up to 15 minutes. E11 Misconfigured policies can block legitimate work or silently allow what they were meant to stop. Where operational complexity grows faster than the security benefit, simpler controls such as patching and least privilege may deliver more.

Agent risk may be mostly software risk

The NCCoE concept paper treats prompt injection as its own control question, next to identity and authorization. E12 If most agent incidents turn out to be prompt injection inside correctly scoped permissions, agent identity will matter more for accountability than for prevention.

What survives the test

The same sources also cut the other way. In Microsoft’s 2026 report, Defender Experts data attributes 30% of observed initial access to user execution and another 20% to valid accounts, and the report argues that the rise of AI should not pull attention away from identity, data protection, software security, exposure management or Zero Trust. E05 The defensible conclusion is narrower than the April article: identity is not everything. It is the layer where many other compromises are converted into durable authority, and where that authority can still be limited, observed and withdrawn.

Darja Rihla interpretation What would change this dossier’s conclusion: two consecutive years of incident data in which valid accounts and token abuse fall sharply as a share of initial access and post-compromise activity, while exploitation keeps rising.

What I would write differently now

This section is written in the first person because it concerns my own method, not the threat landscape. Each change can be checked against the April text, which stays online unchanged.

  • I would not write “What remains is identity.” It was a rhetorical simplification, and the 2026 incident data contradicts it. I would write that identity is the layer where many compromises become durable authority.
  • I would finish the sequence I announced. April promised “a sequence of trust decisions” and described two of them. The engine in this dossier is that sequence, carried past the login into issuance, evaluation and revocation.
  • I would link every institutional claim. April said what Microsoft and CISA “emphasize” without linking a document. Here every external claim points to a ledger entry, and the ledger also records which sources I did not reread.
  • I would say how I could be wrong. April had no failure condition. This dossier states one in the previous section, and the research record at the end names the reports that will test it.

Key takeaways

  1. The April article’s core survives: attackers prefer borrowed legitimacy, and much of the risk begins after login.
  2. Phishing resistance is now a defined property. Passwords, codes and push approvals do not have it; origin-bound cryptographic authenticators do.
  3. Tokens and sessions are authority in transit. Protect the keys that sign them, keep them short-lived or bound, and make revocation reach every system that relies on them.
  4. Recovery channels create authority. Hold them to the same standard as the authenticators they replace.
  5. AI agents are a new class of identity. Ask them the same five questions as any other trust object, plus three more: for whom they act, with which tools, against which data.
  6. Identity is a primary control plane, not the whole system. In 2026 data, exploited software is the most common way in.

The April 2026 original stays online, unchanged, as the record this dossier revisits: Zero Trust Identity Security: The Modern Defense Framework for Access Control.

Evidence ledger and research record

Each entry records what a source actually supports, which is often narrower than the claim it is used for. All sources were consulted on 6 October 2026. Primary sources are preferred; one entry relies on specialist journalism and says so.

Subtiele editorial visualisatie van een evidence ledger met bronnen, verificatiepaden en geordende onderzoeksstructuur.
The dossier closes with an evidence ledger: structured sources, verification and research traceability.

  1. E01 Tokens and assertions need lifecycle protection: signing keys, verification, lifetime, revocation and monitoring.

    Date
    Evidence type
    Government guidance
    What it supports
    Key protection, token verification, a validity of one hour or less for access and identity tokens, revocation and logging. Names DPoP and mutual TLS binding as proof-of-possession options. Places agentic AI out of scope. The announcement describes the forged-token incident and the 60,000 emails.
    Limits
    Written for US federal agencies and cloud providers. Conformance is voluntary unless set by policy.

  2. E02 Passwords, one-time codes and out-of-band approvals are not phishing-resistant; AAL2 must offer a phishing-resistant option.

    Source
    NIST SP 800-63B-4, Authentication and Authenticator Management, part of the Digital Identity Guidelines
    Date
    Evidence type
    Federal standard
    What it supports
    The definition of phishing resistance, the AAL2 requirement to offer a phishing-resistant option, the requirement for federal staff, contractors and partners, and the statements that passwords, OTPs and out-of-band methods are not phishing-resistant.
    Limits
    Normative for US federal systems. Elsewhere it is a reference, not a rule.

  3. E03 Zero Trust removes implicit trust based on network location, and authentication and authorization happen before a session.

    Date
    Evidence type
    Federal architecture guideline
    What it supports
    The core definitions used in the Trust Decision Engine, including the quoted sentence on authentication and authorization as discrete functions.
    Limits
    Predates current work on token binding and agent identity.

  4. E04 Passkeys and FIDO2 credentials can only be used with the relying party they were registered with.

    Date
    Evidence type
    W3C Recommendation
    What it supports
    Relying party scoping of credentials, the mechanism behind phishing resistance in the browser.
    Limits
    Protects the authentication ceremony, not the tokens issued after it.

  5. E05 Threat actors follow trust; agent controls must extend to identities, permissions, data and tools; exploitation is fast.

    Date
    Evidence type
    Vendor threat intelligence
    What it supports
    The quoted sentences on trust, agents and excessive permissions; nearly 40,000 CVEs in the first half of 2026; weaponization well below 24 hours; remediation of 30 to 60 days; user execution at 30% and valid accounts at 20% of observed initial access.
    Limits
    Microsoft telemetry and incident response view. This dossier used the report’s web page, not the full PDF.

  6. E06 Device Bound Session Credentials are generally available in Chrome on Windows.

    Date
    Evidence type
    Vendor product announcement
    What it supports
    That DBSC binds a session cookie to the device the user authenticated from, and is enabled for Google accounts in Chrome on Windows.
    Limits
    Covers Google accounts on one platform. It is not a statement about other sites or browsers.

  7. E07 Shared Signals, CAEP and RISC were approved as final OpenID specifications.

    Date
    Evidence type
    Specialist journalism
    What it supports
    The approval of three final specifications, and that CAEP defines how systems communicate session changes.
    Limits
    Secondary source. The specification texts at openid.net were not reread for this version.

  8. E08 Attackers impersonate employees to helpdesks to reset passwords and move MFA; FIDO/WebAuthn resists push bombing and SIM swaps.

    Date
    (revision of 16 November 2023)
    Evidence type
    Government advisory
    What it supports
    The quoted helpdesk tactic, SIM swapping, MFA fatigue, and the recommendation of FIDO/WebAuthn or PKI-based MFA.
    Limits
    Describes one actor group.

  9. E09 Exploits lead initial access, voice phishing is second, and attackers harvest OAuth tokens and session cookies.

    Date
    Evidence type
    Incident response report
    What it supports
    Exploits at 32% for a sixth year, voice phishing at 11%, harvesting of long-lived OAuth tokens and session cookies, and help desks targeted to bypass MFA.
    Limits
    Based on Mandiant investigations, which lean toward serious intrusions.

  10. E10 Software vulnerabilities overtook stolen passwords as the top way into breaches.

    Date
    Evidence type
    Breach dataset report
    What it supports
    The quoted 31% figure for breaches that start with software vulnerabilities.
    Limits
    Taken from the report’s web page. The full report was not reread for this version.

  11. E11 Continuous Access Evaluation revokes on critical events, allows longer-lived tokens and can take minutes to propagate.

    Date
    Living documentation, read on
    Evidence type
    Vendor documentation
    What it supports
    That CAE is based on CAEP, the list of critical events, tokens of up to 28 hours for CAE-capable clients, and propagation delays of up to 15 minutes.
    Limits
    Describes one vendor’s implementation. The page can change without notice.

  12. E12 Identity, authorization and audit for AI agents are open standards questions.

    Date
    Evidence type
    Concept paper for public comment
    What it supports
    That NIST asks how agents should be identified and authorized, how their actions can be audited, and how prompt injection can be mitigated.
    Limits
    It asks questions. It does not yet answer them.

  13. E13 Token protection binds sign-in session tokens to a registered device, and is not a complete solution.

    Date
    Living documentation, read on
    Evidence type
    Vendor documentation
    What it supports
    Device binding of sign-in session tokens, limited browser support, and Microsoft’s own statement that it belongs inside a defense-in-depth strategy.
    Limits
    Platform coverage changes often. Check the page before relying on a specific scenario.

  14. E14 Agents need their own identities to make least privilege, revocation and audit possible.

    Date
    Evidence type
    Vendor engineering guidance
    What it supports
    The quoted reasoning on distinguishing user, agent and on-behalf-of actions, and the sentence “Identity is not a feature you add later.”
    Limits
    One vendor’s design position.

  15. E15 One large organization already inventories more than 500,000 agents.

    Date
    Evidence type
    Vendor case study
    What it supports
    Visibility into more than 500,000 agents inside Microsoft, and registration that gives each agent a formal identity.
    Limits
    A self-report about one company. Not an industry figure.

Darja Rihla research record

Dossier
Living Dossier 01: Zero Trust after login
Revisited
Version
1.0, first dossier edition
Sources reviewed
15 ledger entries: NIST, CISA and FBI, W3C, Microsoft, Google, Mandiant and Verizon primary sources, plus one specialist news report.
Method
Drafted with AI assistance inside a controlled workflow. External claims checked against the cited sources on the date above, and April quotations against the published original. Interpretation labelled separately. Human editorial review before publication.
Next review triggers
NIST or NCCoE guidance on agent identity and authorization; a revision of NIST SP 800-207; device-bound sessions in more browsers; the 2027 editions of DBIR and M-Trends.

Read the April 2026 original

]]> Cybersecurity & Tech The Modern Barbershop https://darjarihla.com/the-modern-barbershop/ Mon, 05 Oct 2026 18:22:26 +0000 https://darjarihla.com/?p=2813

The Everyday Atlas Street & Road to The Barbershop

Grooming, Style and the Social Life of Men

From Lagos to Seoul, Tunis to São Paulo, London to Lahore, Kingston to Tokyo.

Lifestyle & CultureEditorial reportOne chair, many worlds

Plate I. One chair before a mirror. An empty barber chair seen from behind, facing a mirror. The mirror reflects a tiled wall, a hairstyle poster, a football sticker and a bright doorway to the street. On the counter stand a tea glass, clippers, a product bottle, a phone and a folded towel.
Plate I One chair before a mirror. Tiles, clippers, a towel, a poster, a tea glass, a football sticker, a bottle, a phone: a room that could stand in many countries and belongs to none of them. Authored drawing, not a photograph.

In short

The barbershop is one of the few rooms that exists in almost every city on earth and still feels local in each of them. This report follows the camera outward, from the face in the mirror to the chair, the shop, the street, the routes of migration and the world, and then back to the chair.

Its argument is simple. The technique has gone global. The room has stayed local.

Scale: the face

I. The chair

A man sits in a chair.

A cape closes around his neck.

Clippers begin.

For the next twenty minutes, very little is asked of him. He does not have to perform, decide or explain much. He has to sit still, keep his head where the barber puts it, and trust a stranger with a blade near his ear.

That trust is the first thing a barbershop offers. The haircut comes second.

Look closely and the scene is made of small, repeated objects. The paper strip around the neck. The cape snapped shut at the back. The clipper guard clicked into place. The edge of the mirror, where the client watches the barber’s face as much as his own. The barber’s hand resting on the crown of a head, as if it were the most ordinary thing in the world.

Outside the shop, touching another man’s head is rarely casual. Inside, it is handed over every few weeks, without ceremony.

  1. 01 · Cape
  2. 02 · Neck strip
  3. 03 · Clipper
  4. 04 · Mirror edge
  5. 05 · The barber’s hand
Close-ups. Five details that are the same in Tunis and Tokyo. Authored drawings.

Scale: the shop

II. A global room

There is no single global barber culture.

There is a global format: a chair that turns and tilts, a mirror, a set of tools, one person who cuts and another who waits. The format travels well. What happens inside it does not travel as one culture.

A barbershop in Tunis, a barbing salon in Lagos, a berber in Istanbul, a tokoya in Tokyo and a barbearia in São Paulo share the chair. They do not share the same conversation, the same music, the same idea of a good finish, or the same sense of how long a customer may stay without buying anything.

The modern barbershop is also a story of movement. Barbers move with migration and carry their shop culture with them. On many European high streets the barbershops speak the languages of those routes: Turkish, Kurdish, Arabic, Amazigh languages, the French of West Africa, the English of the Caribbean. In the United States, the historian Quincy T. Mills has shown how Black barbers and barbershops became institutions in their own right, shaped by segregation, enterprise and community life.

The Global Barber Route Eleven places, one lens each.

  1. Tunisneighbourhood continuity
  2. Lagosprecision and enterprise
  3. Kingstonsound and community
  4. New Yorkdiaspora and technique
  5. Londonthe high-street mix
  6. Istanbulritual and service
  7. Lahorethe street chair
  8. Seoulgrooming and changing masculinity
  9. Tokyolicence and precision
  10. Jakartalearning from the screen
  11. São Paulobarbearia and street style
One lens per place. A lens is what this report looks at there, not a description of everyone who lives there.

Scale: the neighbourhood

III. Regional worlds

The chair is the same. The room around it changes. Seven scenes follow, each read as a field guide: what to look for, not a verdict on a region.

A neighbourhood barbershop facade with an open arched door, a sign in French and Arabic, a striped awning, a tiled base and a chair outside for regulars. COIFFURE حلاق
Scene 1 The door stays open; the chair is visible from the pavement.

North Africa

Tunis · Algiers · Casablanca · Cairo

In the cities of North Africa, the barbershop is often a neighbourhood fixture rather than a destination. It opens onto the street. Men greet the barber without needing a haircut, and in one afternoon the chair can hear Arabic in its local forms, French and, in parts of the Maghreb, Tamazight.

Continuity matters here. A man can keep the same barber for decades, and a son can inherit him.

Look for

  • the sign in two scripts
  • the open door and the chair visible from outside
  • the radio or television tuned to football
  • regulars who come in to talk, not to be cut
A waiting bench with three customers, a speaker in the corner sending out sound waves, and a clock on the wall.
Scene 3 The bench is an audience. Who controls the music controls the room.

The Caribbean

Kingston · Port of Spain · Bridgetown

Music arrives before the haircut. A speaker in the corner, a playlist the barber controls, customers who stay longer than they need to because the conversation is good. In Caribbean shops, and in the Caribbean diaspora of London, Toronto and New York, the barbershop is a place where sound, argument and news circulate together.

Look for

  • who chooses the music
  • the waiting bench as an audience
  • a haircut timed around a match or a song

Türkiye and the Middle East

Istanbul · Beirut · Amman · Riyadh · Dubai

Here the beard is architecture. The cheek line is set high or low, the neckline sharp, the moustache shaped as a decision of its own. The service is often longer than the cut: hot towels, a straight razor, threading on the cheeks in some shops, a splash of cologne at the end, tea that arrives without being ordered.

The Turkish barber has become an export in its own right. “Turkish barber” is now a sign on streets far from Türkiye.

A diagram of beard architecture with four numbered lines: the cheek line, the moustache, the neckline and the fade from hair into beard. 1 2 3 4
Scene 4 Beard architecture.
  1. Cheek line: high, low or natural
  2. Moustache: shaped on its own
  3. Neckline: where the beard ends
  4. The fade from hair into beard
A street barber’s corner: a mirror nailed to a wall beside a tree, a wooden chair, a stool with a tool case, a large umbrella and a hand-written price board. CUT SHAVE MASSAGE
Scene 5 The barbershop does not always need a shop.

South Asia

Lahore · Karachi · Delhi · Dhaka

The barbershop does not always need a shop. On pavements and under trees, a chair, a mirror fixed to a wall and a small case of tools can be enough. Street barbers and small salons work a few doors away from branded chains, and a straight-razor shave or a head massage can be part of the same visit as a fade.

Look for

  • the mirror on the wall
  • the price written by hand
  • the head massage at the end
  • cricket on somebody’s phone

East Asia

Seoul · Tokyo · Osaka · Taipei

Precision becomes a style of its own. In Japan, the line between barber and hairdresser is a matter of licence: barbers (rihatsushi) and hairdressers (biyoshi) hold separate licences, and only barbers are licensed to shave.

In Seoul, the lens of this report is grooming and how ideas of masculinity change: what happens when men’s haircuts, skincare and style are discussed openly rather than quietly.

Look for

  • the consultation before the cut
  • the shampoo as part of the service
  • reference photos on the barber’s tablet
A precision diagram: a head in profile with guide lines at 0, 45 and 90 degrees, and a comb and scissors aligned on the 45 degree line. 0° 45° 90°
Scene 6 Elevation and angle: precision as a visible style.
A street-facing barbershop with large painted lettering reading Barbearia, a football shirt in the window, and a head seen from behind with lines shaved into the hair. BARBEARIA 10
Scene 7 The street comes inside: lettering, football, lines shaved into hair.

Latin America

São Paulo · Rio de Janeiro · Bogotá · Mexico City

The barbería and the barbearia bring the street inside: painted lettering, football shirts, reggaeton and funk, designs shaved into the side of the head. In Brazil the barbershop is a recognised small-business model: Sebrae, the national agency for micro and small businesses, publishes a dedicated guide to opening one and describes men’s grooming as a market in clear expansion.

Look for

  • freestyle lines shaved into hair
  • the shop’s own logo on caps and shirts
  • the Saturday queue

IV. The shop is where the haircut becomes culture.

  • conversation
  • music
  • ritual
  • work
  • style
  • belonging

A haircut can be done anywhere. Culture needs a room, a few regulars and time.

Scale: the current

V. The barber’s phone changed everything

Then: comb, scissors, razor

  1. Apprenticeship
  2. Migration
  3. Video
  4. Global circulation

Now: the phone

For most of its history, barbering was learned standing next to someone. An apprentice swept the floor, watched, held the hand mirror, and was trusted with a neckline long before he was trusted with a full cut. Technique travelled at the speed of people: a barber moved to another city or another country and took his hands with him.

The phone changed that speed. A barber in Jakarta can watch a technique filmed in São Paulo in the morning and try it in the afternoon. A fade tutorial, a beard sculpt, a new way to use a foil shaver: all of it circulates as short video.

The phone is also the shop’s window, its booking desk and its portfolio. Often the finished cut is photographed before the client leaves the chair.

None of this ends apprenticeship. It adds a second, global classroom to the local one.

Scale: the city

VI. The fade went global

A head in profile. The hair moves in steps from long on top to skin at the neck, marked with clipper guard numbers 3, 2, 1, half and 0. 3 2 1 ½ 0
Plate II The fade as a graphic principle: long to short, top to skin, guard by guard.

Global technique. Local expression.

The fade is a simple idea: hair that moves from longer to shorter, from the top to the skin, without a visible line. Done well, it is a gradient made with clippers, guards and patience.

Few cuts show as clearly how a technique becomes global while its expression stays local. The same fade carries a hard part in one city and a curly top in another. It meets a lined beard, a shaved design, a conservative taper for the office or a skin fade that says weekend.

  • Lagos
  • Casablanca
  • London
  • Riyadh
  • São Paulo
  • Jakarta
  • Paris
  • Lahore
  • Melbourne

Scale: the world

VII. The beard went global too

Beards follow fashion cycles. In the early 2010s, full beards spread through cities that had been mostly clean-shaven for decades, and barbers rebuilt their services around them: trims, shaping, oils, balms and hot towels.

Fashion may also explain why the beard comes and goes. In a 2014 experiment published in Biology Letters, participants rated faces after seeing sets in which beards were either common or rare. Heavy stubble and full beards were judged more attractive when they were rare, and clean-shaven faces were judged more attractive when they were rare. A style can lose its edge simply because everyone has adopted it.

The same beard does not mean the same thing everywhere. A full beard can be fashion in one street and faith in the next. A moustache can signal a generation, a profession, a tradition or nothing at all. The barber shapes the hair; the meaning is supplied by the world around it.

That meaning, its history and its symbolism, belongs to Culture & Identity. Here the beard is practice: what is done to it, where, and with what.

Scale: the world

VIII. Products travel. Rituals resist.

What travels fast

  • clippers
  • beard oil
  • pomade
  • razors
  • tutorials
  • brands

What travels slowly

  • conversation
  • hospitality
  • father and son
  • walk-ins
  • tea
  • silence
  • trust

A product can be on shelves in a hundred countries tomorrow. A clipper model, a beard oil, a pomade or a tutorial needs only shipping or a signal.

A social ritual moves at the speed of people. Conversation, hospitality, the father who brings his son, the walk-in greeted by name, the tea, the silence a regular is allowed, trust: none of it can be shipped. It has to be built in each room, and it can stay local for generations.

That is the difference between consumption and culture. Lifestyle & Culture looks for the second inside the first.

Scale: the family

IX. Father, son and barber

A father and a young boy seen from behind, waiting on a bench. The boy’s feet do not reach the floor.
Plate III Waiting. The boy’s feet do not reach the floor yet. A place for a documentary photograph later.

A boy’s first haircuts are someone else’s decision. He is lifted onto a booster seat or a board across the arms of the chair. His father watches in the mirror. The barber talks to the father about the boy, and to the boy about football.

Years later the roles shift. The boy chooses his own cut, then his own barber. Sometimes he chooses his father’s barber, and the shop becomes a thread between generations: the same chair, the same hands, another head.

The barber cuts time into appointments.

Every two weeks, every three weeks. Before Eid, before Christmas, before a wedding, a job interview, the first day of school. A life can be measured in haircuts, and the barber is often the one person who has seen all of them.

Scale: the street

X. The shop as a social room

A place for men without requiring a reason.

The waiting area of a barbershop: a television showing a football match, two men on a bench, a low table with tea glasses and a phone face up, a third man standing who is not having a haircut, and a coffee machine on the counter.
Plate IV The bench, the match, the tea, the phone, and the man who is not here for a haircut.

Leave the chair for a moment and look at the bench. A television on a bracket. A football match nobody is fully watching. Coffee, or tea in small glasses. Phones face up on the table. A man who came in with his cousin and is not being cut at all.

The sociologist Ray Oldenburg called places like this third places, separate from home and work: “havens of sociability where conversation is the main activity and conviviality prevails.” Many barbershops fit that description better than the cafés that are usually given as examples.

Research on Black barbershops in the United States shows how much can happen on that bench. In Barbershops, Bibles, and BET (2004), the political scientist Melissa Harris-Lacewell studied how everyday talk in spaces such as barbershops shapes political thought. Quincy T. Mills traced the barbershop as a Black business and public space across American history.

This is social infrastructure. It is rarely planned as such. It is built one regular at a time.

Scale: the current

XI. The barber becomes a brand

  1. Chair
  2. Instagram
  3. Booking
  4. Academy
  5. Global audience

A successful barber now often runs more than a chair. The cut becomes content, the content becomes a following, the following becomes bookings, and some barbers turn their technique into courses, products and seminars abroad. A local craftsman can have a global audience without leaving his street.

That changes the economics of the craft, and it changes the room. When any cut may be filmed, lighting matters, mirrors are placed for the camera and the client is also an image. Look for the ring light: it is the newest piece of barbershop furniture.

Scale: memory

XII. Scent and sound

What does a barbershop remember?

Sound

  • Afrobeats
  • Raï
  • Reggaeton
  • Arabic pop
  • K-pop
  • Football commentary
  • The clipper on the neck

Scent

  • citrus
  • menthol
  • talc
  • oud
  • aftershave
  • lemon cologne

Culture is often stored like this. Not as a theory. As scent.

Memories of a barbershop rarely begin with the haircut. They begin with a smell, a song, a voice on the radio, the buzz of a clipper on the back of the neck.

Scale: the street

XIII. The shop window: how to read a barbershop

Stand outside and read the window before you go in. Seven things say more than the price list.

A drawn barbershop front with seven numbered observations: a football shirt, a ring light, an old razor, a booking QR code, a coffee machine, a hairstyle poster and a sign in several languages. BARBER KAPPER BERBER حلاق 1 2 3 4 5 6 7
Plate V How to read a barbershop. Seven observations from the pavement.
  1. Football shirt. Which club, which country, which generation.
  2. Ring light. The shop is also a studio.
  3. Old razor. Kept for the ritual, or for the memory of the founder.
  4. Booking QR code. Walk-ins welcome, or not.
  5. Coffee machine or tea glasses. How long you are invited to stay.
  6. Hairstyle poster. Which styles the shop thinks you want, and from which decade.
  7. Language on the wall. Who the shop expects to walk in.

Scale: back to the face

XIV. One chair, many worlds

Back to the chair. It looks the same as at the start. By now it carries more than a client.

The same empty barber chair as at the start of the report.
Around the chair:
  • migration
  • technology
  • masculinity
  • craft
  • fashion
  • memory
  • community
  • entrepreneurship

How do you want it?

  • How do you want to present yourself?
  • What do you carry from where you come from?
  • What have you borrowed from somewhere else?
  • What has your generation changed?
  • What still feels like you?

That is where grooming becomes culture.

Continue the barber journey

Next field notes

Planned means no article exists yet. Links appear here when a field note is published.

  1. A History of the BarbershopCulture & IdentityPlanned
  2. The World’s Most Famous BarbershopsLifestyle & CulturePlanned
  3. Barbers Who Changed the CraftLifestyle & CulturePlanned
  4. Barber Cultures of North AfricaLifestyle & CulturePlanned
  5. The Turkish BarberLifestyle & CulturePlanned
  6. The Black BarbershopLifestyle & CulturePlanned
  7. From Barbers to Hairdressers: The Women’s SalonLifestyle & CulturePlanned
  8. Why Was Barbarossa Called Red Beard?Culture & IdentityPlanned

Sources

  1. James McDougall, A History of Algeria, Cambridge University Press, 2017, chapter 1. Cambridge Core
  2. Agostino Veneziano, Khair ad-Din Barbarossa, engraving, 1535, Rijksmuseum, RP-P-1950-676. Rijksmuseum
  3. Anonymous, Italian, Hayreddin Barbarossa, Ottoman admiral, woodcut with additions in pen and ink, about 1530 to 1560, The Metropolitan Museum of Art, 50.514.8. The Met
  4. Frederick I, Holy Roman emperor, Encyclopædia Britannica. Britannica
  5. barber (n.), Online Etymology Dictionary. Etymonline
  6. Zinnia J. Janif, Robert C. Brooks and Barnaby J. Dixson, “Negative frequency-dependent preferences and variation in male facial hair”, Biology Letters 10 (4), 2014, 20130958. doi:10.1098/rsbl.2013.0958
  7. Quincy T. Mills, Cutting Along the Color Line: Black Barbers and Barber Shops in America, University of Pennsylvania Press, 2013. De Gruyter Brill
  8. Melissa V. Harris-Lacewell, Barbershops, Bibles, and BET: Everyday Talk and Black Political Thought, Princeton University Press, 2004. De Gruyter Brill
  9. Ray Oldenburg, The Great Good Place, 1989, and his definition of third places. greatgoodplace.org
  10. Web Japan (Ministry of Foreign Affairs of Japan), The Art of Hairstyling in Japan, 2025. web-japan.org
  11. SFO Museum, Extra ’O’! African Barbershop and Hairdressing Signs, 2020. SFO Museum; exhibition summary by Indigo Arts
  12. Sebrae, Ideia de negócio: Barbearia. Sebrae (PDF)
]]> Lifestyle & Culture