Profile
Analysis
Analysis profile intelligence connects person, company, institution, and other entity coverage for readers comparing the subjects behind BTW.MEDIA reporting. The page helps compare public profiles, related events, evidence packs, role changes, operating footprints, governance exposure, organisational links, and market relevance while keeping organisation and people records distinct from ordinary news chronology. Readers can understand the subject behind the headline, the evidence supporting that profile, and the infrastructure or market relationships that make the profile relevant. They can see who or what the profile represents, which public sources support it, how it connects to companies, markets, governance bodies, or events, and what changes may deserve continued attention as the subject evolves.
History
The Delete That Waited for Goodbye: How POP3 Separated a Mark from an Irreversible Removal
The server answers `+OK message 4 deleted`. Then the cable comes out before the client says `QUIT`. On the next connection, message 4 is back. POP3 did not contradict itself: the positive reply had accepted a reversible mark inside one session, while actual removal belonged to a…
ICANN
A Valid Inbox Is Not a Title Deed: The Four Proofs ICANN’s Accuracy Rules Keep Separate
ICANN’s registration-data rules can test whether a field is well formed and whether somebody answers an email or telephone call. Those are useful controls. They are not the same as proving who controls the registrar account, still less deciding which person or company has the…
History
The Bytes That Had to Wait for Permission: How IMAP Literals Traded a Round Trip for a Resource Boundary
An IMAP client could finish a line with `{11}`, announce exactly how much data came next—and then stop. The eleven octets were not late, lost or flow-controlled by TCP. They were waiting for a one-character reply from the server: `+`. That pause turned a count into a permission…
History
The Checkpoint That Was Not a Byte Number: How FTP Learned to Resume a File
Midway through an FTP transfer, a reply could appear on the control connection: `110 MARK ssss = rrrr`. It did not say that a certain number of bytes had arrived. It joined one position understood by the sending system to another position understood by the receiving system—and…
History
The Empty Query That Listed Everyone: How Finger Made Human Presence a Network Reply
Send no name, no password and no command word—only a carriage return and line feed—to a remote service on port 79. In the original Finger protocol, that empty line asked the host to list everyone currently using it. The exchange was tiny. The disclosure could include a room…
History
The Second Connection Asked Who Owned the First: How IDENT Bounded a Username's Authority
A server has already accepted one TCP connection when it opens another in the opposite direction. On that second connection it sends two port numbers to the first host and asks a narrow question: which local user owns the first connection? IDENT made that answer useful for logs.…
History
The Time Packet That Was Not Time: How NTP Kiss-o'-Death Made Refusal Actionable
The reply fits the familiar NTP shape and even belongs to a request the client just sent. Yet its timestamps must not adjust a clock. Stratum 0 and the four letters `RATE` turn the packet into something else: a server's bounded request for less traffic, delivered inside the…
History
The File Did Not Come From Port 69: How TFTP Bound a Transfer to Chosen Endpoints
A packet trace of a correct TFTP read begins with a small surprise. The request goes to UDP port 69, but the first block of the file comes back from another port. That change is neither drift nor a second service. It is the moment the protocol replaces a public door with a…
History
The Question SMTP Learned Not to Answer: How VRFY Separated Address Acceptance from Directory Disclosure
In 1982, a remote machine could ask an SMTP server to `VRFY Smith` and receive Fred Smith’s full name and mailbox. The command was useful because it made a mail problem inspectable. It was dangerous for the same reason: a transport service had become a public directory, one…
History
The Server Returned the New Name: How UIDPLUS Made IMAP Mutation Verifiable
The upload had succeeded. The message was in the mailbox. Yet the client still lacked the one fact it needed for its offline ledger: which UID had the server assigned? Before UIDPLUS, a positive result could confirm the mutation while withholding the durable local reference…
History
The Command That Gave Away the Connection: Why SMTP Replaced TURN with ETRN
A mail host called its provider and asked the line to turn around. The server could then send queued messages back over the same connection. The convenience hid an authority transfer: the caller had spoken a host name, but the protocol had not proved that it was entitled to…
History
The Deadline the Relay Could Not Reset: How SMTP DELIVERBY Made Time Travel with the Message
A page that is useful at 16:58 can become an intrusion at 17:01. SMTP knew how to retry, but not why a message's value might expire. DELIVERBY let the sender attach a shrinking time obligation without buying priority or commanding another operator's queue.
History
The Identifier That Outlived Its Number: How POP3 UIDL Let a Client Remember Across Reconnection
On Monday a retained message is number 2. By Tuesday the message ahead of it has disappeared, so the same item is number 1. POP3 could name the position needed for this session, but an intermittently connected client needed something else: evidence that the message it saw after…
History
The Error Code That Asked the Blocker to Identify Itself
HTTP 451 could make a legal obstacle visible and name who enforced it. It could not compel disclosure, validate the demand or expose a block below HTTP.
History
The Last Uncompressed Line: How IMAP COMPRESS Changed Every Byte That Followed
The server's answer looked ordinary: a tag, `OK`, a short confirmation, then CRLF. That line was ordinary for the last time. If the client had asked for IMAP compression, the next server octet no longer belonged to the visible command language at all. A single successful reply…
History
The Greeting That Had to Be Repeated: How STARTTLS Reset SMTP Trust
The first greeting crossed the network in the clear. So did the client's name and the server's list of abilities. When SMTP added encryption without abandoning its old port, the protocol could not simply wrap that conversation and pretend it had always been protected. It had to…
History
The Credential That Could Not Sign the Message: How SMTP AUTH Bounded Submission Identity
A password could open a mail submission gate. It could not sign the letter that passed through it. SMTP AUTH became useful precisely because the protocol kept those propositions apart: this client authenticated here; this account may act in certain ways; this message claims a…
Global Institutional
linuxptp and the control loop behind precision time
linuxptp turns a Linux host, hardware clock and network timing source into a precision-time system. Its daemons coordinate IEEE 1588 state, packet timestamps, servos and system clocks, but software alone cannot manufacture accuracy: the result still depends on NICs, oscillators…
Academics
Laurent Vanbever and the network that must be tested while it changes
Laurent Vanbever’s work treats network configuration as executable software whose failures can emerge before, during or after deployment. From safe routing migrations and configuration synthesis to runtime BGP detection and energy-aware operations, his research at ETH Zurich asks…
History
The Address That Could Not Be Downgraded: How SMTPUTF8 Made the Route Part of the Name
An accented display name could cross old email systems because it was decoration around an ASCII address. A non-ASCII mailbox name was different: it was the destination itself. SMTPUTF8 made every relay prove that it could carry that identity without inventing another one.