Fraudnode

Control plane with a memory

Orca starts sessions, signs internal calls, keeps policy close, and remembers what happened. The browser never receives service secrets, Spider does not become a business rules department, and the site gets one clean contract instead of a drawer full of cables labeled maybe.

Parser runtime

Spider sends raw evidence; Orca turns it into stable blocks the site can read: IP, TCP, TLS, HTTP, JS, GEO, DNS, blacklist, UDP/QUIC, and anomaly. Each block can be ok, partial, missing, or error, because reality sometimes arrives late and wearing a fake mustache.

T0 first, T1 when the plot thickens

T0 is the fast lane: TCP, TLS, HTTP, JS, and quick enrichment for an early decision. T1 is the extended lane: DNS, UDP, QUIC, reputation, and heavier follow-up. Orca keeps those stages separate so the product can be fast without pretending every slow signal is already home.

Storage without drama

For Checker and demo/trial flows, Orca stores raw envelopes, normalized blocks, audit traces, and analyzer results. For high-throughput B2B, it can run compact or no-persist modes. Same contract, different appetite. Like ordering coffee for a meeting, but nobody argues about oat milk in the API.

Replay is not a party trick

Snapshots carry artifact versions, correlation IDs, timing, missing blocks, and deterministic replay metadata. That means a later anomaly check can run from the stored evidence instead of asking the user to please blink, reload, and reproduce Tuesday.

B2B is a different tempo

The website can show a full checker story, but B2B often wants the short answer before checkout loses patience. Orca supports compact T0 checks, async T1 callbacks, quotas, key ownership, and tenant isolation, while keeping Spider and Penguin behind the curtain where service secrets belong.

Data plane, not theater

Orca may hand out the session and policy, but the client collection path goes straight to Spider. That matters. If collection traffic is politely dragged through a control-plane proxy, the good fingerprints stay at home and send a blurry postcard. Spider sits where the packets actually arrive.

L3-L7 live ingress

Spider collects the transport stack as one story: TCP/IP envelope, TLS fingerprints, HTTP/1.1, HTTP/2, headers, Akamai-style HTTP/2 hints, and browser runtime evidence. It is not trying to guess the client from a single hat. It checks the hat, the shoes, the receipt, and the handwriting on the receipt.

DNS probe zone

DNS is where we decided not to rent a mystery box and call it science. Spider watches our own probe zone, sees which resolvers actually come knocking, keeps the request trail, and hands Orca enough structure to say what happened without waving incense over a third-party screenshot. Resolver topology, ECS hints, client echo, ASN/ISP context, and geolocation from our internal enrichment service all move through the same pipeline.

UDP and QUIC are side quests with receipts

UDP is checked through a session-bound STUN flow: Spider opens a port, watches the browser try to reach it, answers when it can, and only calls UDP detected when packets really crossed the room. QUIC/HTTP3 lives beside Spider as a sidecar, so a failed H3 probe does not burn down the rest of the collection.

Artifacts Orca can trust

Spider exports versioned artifacts with status, missing blocks, capture health, timing, replay metadata, and correlation IDs. That gives Orca something better than a shrug: a snapshot it can store, show in Checker, use for B2B T0, enrich later in T1, and replay without asking the visitor to perform the same little dance again.

Heuristics, not a borrowed oracle

Penguin is built around deterministic heuristics and pattern study, not an LLM verdict and not a secret answer copied from someone else's paper. The patterns are refined against our own observed traffic: millions of sessions and more than eight million technical documents from different networks, clients, and masking habits.

Correlation beats fortune telling

Penguin is designed to compare the same session from several angles: TCP, TLS, HTTP, JS, DNS, WebRTC-style origin clues, geo context, and history. One signal can be noisy. Five signals disagreeing in the same direction is less of a coincidence and more of a meeting with minutes.

Device profile first

Before Penguin calls something risky, it builds a technical portrait: probable OS, browser, device type, confidence, and why each layer voted that way. TCP may hint at the operating system, TLS may hint at the client family, HTTP/2 may tell a different bedtime story, and the final detector has to be the adult in the room.

Anomaly classes with reasons

The anomaly layer is not a single giant lever. Proxy, VPN, bot, unusual fingerprint, DNS mismatch, and profile-switching checks each produce their own evidence. The final class can be Clean, Possible Proxy, Possible VPN, Proxy, VPN, Bot, or a combined masking story, with reasons attached instead of dramatic fog.

The second pass checks the homework

After the base detectors and anomaly blocks make their decisions, Penguin has a final-question layer. It gathers detector output, proxy/VPN/bot/unusual signals, blacklist context, and OS-change risk, then asks the deeply annoying but useful question: did we solve the problem correctly, or did one clever clue bully the rest of the class?

History has a memory

Penguin does not only ask who you are right now. It asks who this IP, fingerprint, and linked origin looked like before. If last week the same trail was Windows/Chrome and today it is an exotic mobile stack with a new story, the history layer keeps the receipt. A shaved head does not grow dreadlocks by Thursday.

OS changes are not hand-waved away

The OS-change logic compares current final profile and user-agent profile against recent local history and linked IP/WebRTC-style history. One profile switch may be normal. Many switches inside tight geo/AS windows are the sort of thing a system should remember before politely stamping Clean.

Fast path and full notebook

The Penguin shape separates pure detection logic from runtime adapters. Fraudnode can use the full notebook with stored rows, history, and reports. B2B can run the same domain logic in a fast stateless path, then attach persistence only when the customer or policy asks for it. Same math, different backpack.

TCP as reusable domain logic

The TCP refactor plan starts with a clean block: input object in, weighted hints out, final TCP verdict returned. Quick path, TTL, cap length, options order, window scale, source port, TCP window, uptime, MSS, and organization hints become reusable logic instead of a database-shaped maze.