Sold separately · runs on your own machines
Tide
Ingests your traffic and continuously surfaces the attack in progress: which resource pool is hitting you, when the volume rises,
which slice of the business it targets — reconstructed along a timeline into evidence you can
check yourself. All of it runs inside your network; your traffic never leaves it.
The other product is Pulse self-hosted (brings IP risk scoring onto your own machines) ·
compare the two
Your data never leaves your environment
Lookups and traffic observation both happen inside your network and nothing is sent back to us.
The delivered binaries contain no external domain names, and your security team can verify that
with the script we ship.
Attack resources reconstructed along a timeline
More than a score: which attack resource pools this traffic came from, when the volume rose,
how large and how widely shared they are — plus an evidence report the other side can check.
See a real detection report (in Chinese) →
Whether to block is your call
The product only advises, and deliberately ships no hard blocking action. Whether to act, by what
means, and when to lift it are all decided inside your own systems.
The problem it solves
Looking up an address you already suspect is not the hard part — the hard part is not knowing which ones to look up.
Attackers rotate addresses far faster than people spot them; by the time someone reports that a
channel's numbers look wrong, that wave is usually over.
Tide works the other way round: instead of waiting to be asked, it watches your traffic itself and
surfaces where the anomaly is happening — which attack resource pool just appeared, which slice of the
business has drifted from its own normal — then reconstructs it into a timeline you can check. Your job
becomes deciding what to do, not finding it first.
Why the conventional approach cannot see it
Existing risk and anomaly detection is nearly always aggregated along your business dimensions: is this channel's risk rate off, has that placement's conversion dropped. The trouble is that the attacker's resources are not distributed along your business dimensions — one pool's traffic is spread across several channels, and each share is small enough to vanish into the noise.
Change the aggregation dimension and the same traffic goes from invisible to obvious. That is exactly what the resource-side channel does.
On the same data, what each channel detected
Not an estimate: measured on a full replay across 21 customers, 165 million requests and three days. The resource side detected 192 events, the business side 9; 103 of those are structurally invisible when aggregated by business slice.
The resource side needs no business dimensions from you at all — it judges the attacker's resources, which is our dimension.
Which is why we suggest starting with the collector
With zero business dimensions, most of the product's value is already there. Business dimensions buy you granularity of response —
without them you can only act on a whole resource pool; with them you can say “throttle traffic
from pool X on channel A”, narrowing the blast radius from the whole pool to one slice of one
channel. That is what makes throttling safe to turn on — but it is step two.
Two detection channels, one of which needs no changes from you
The business side judges how far the risk rate has drifted from your own normal and needs business
dimensions from you; the resource side judges which attack resource pool is hitting you and needs only
an address and a timestamp — our dimension, which produces results with no changes on your side.
| Channel | What you supply | Time to first result | What it answers |
|---|
| Resource side | Address + timestamp | about 1 hour |
Which attack resource pool is hitting you, and whether it is new or has suddenly scaled up |
| Business side | Additional dimensions such as channel or placement | about 1 week |
Which business slice's risk rate has drifted from its own normal |
Why we suggest starting with the resource side
The resource side judges the attacker's resources, not the shape of your business — it needs no business identifiers from you, so it produces conclusions with no changes on your side. We ran a full replay against our own observations: aggregating by business slice is structurally invisible to resource pools that are small but persistent — and that is exactly the gap this channel fills.
Business dimensions do not decide whether something is detected, but granularity of response:
without them you can only act on a whole resource pool; with them you can say “throttle traffic
from pool X on channel A”, narrowing the blast radius from the whole pool to one slice of one
channel. That is what makes throttling safe to turn on — but it is step two.
You do not have to take our word for it: within the first week you can compare what each channel
detected, in your own environment.
Deployment
From receiving the package to the first conclusions is usually within a day; the business side needs enough baseline, about a week.
-
Install and start the service
Unpack to /opt/tide, fill in one tide.env (licence name, Redis address, database path),
install the systemd unit, then curl /healthz to check health. Four commands, with a literal script in the package.
-
Wire up intelligence mirror sync
With internet access, install the sync timer; on an isolated network, import over offline media.
This step cannot be skipped — a few days after the mirror stops updating the detection rate reaches zero while the service looks perfectly healthy.
-
Ingest traffic: collector first, do not rush to change code
collector tidecollect needs no code changes and can be live the same day; an SDK means code changes and a release.
Run the collector for a week before deciding on the SDK — measured across 21 customers and 165 million requests,
a deployment with zero business dimensions still detected 192 resource-side events, 103 of them structurally invisible under business-slice aggregation. Business dimensions buy granularity of response, and that is step two.
-
Wait for the baseline
The resource side starts working in about an hour; the business side needs enough days to estimate
what normal looks like, about a week. On delivery day the business side is recorded as
“preconditions not yet met” rather than “failed”, and the checklist tells
you how many days remain.
-
Acceptance
One tide-adm acceptance runs every verifiable item and prints a per-item checklist with counts.
What gets signed off is per-item verification results, not a feature list — anything only we could
prove is not an acceptance item.
What is delivered
One self-contained tar package; you need only Linux and Redis. No internet access required, and no access to ip99.com.
Three binaries
tide service, tide-adm operations tool, tidecollect log collector.
Statically compiled Go with no external domains and no outbound dependencies, enforced by invariant tests at build time.
Three SDKs
Go / Java 8+ / Node 12+, each a single file with no dependencies, ready to copy into your codebase.
A common porting contract guarantees they never harm the host application.
Local intelligence mirror
Delivered with the product and updated continuously: we issue watermarked incremental packages per
licence and your side pulls and imports them on a timer. The health check distinguishes
“the channel is broken” from “we have not published a new package”.
Acceptance criteria you can verify yourself
One command runs every verifiable item and reports pass/fail per item.
The parts we cannot let you verify yourself (the false-positive upper bound, intelligence coverage)
are listed separately as declarations,
not mixed in with the passes。
Reference specification
The numbers below are measured, not estimated. Your specification is computed from your traffic and declared dimensions; the product ships the command that computes it.
| Item | Measured | Notes |
|---|
| Intelligence mirror memory | 3.76 GB | Follows the size of the intelligence set, not your traffic |
| Query throughput | about 850 QPS per core | 3,300 QPS measured on 4 cores, P99 27 ms |
| Detection database on disk | 4.4 MB – 24.5 GB | Determined by the cardinality of your business dimensions; the spread can be thousands of times |
| Service process memory | < 300 MB | Aggregates are flushed per window, so it is largely independent of traffic volume |
Where the capability ends — written into the acceptance criteria
The product ships with acceptance criteria that state, in writing, the two things we cannot let you
verify for yourself — rather than listing only the strengths.
False-positive upper bound
We publish the false-positive upper bound for each score band, how it was derived and what it assumes.
It is an unlabelled upper bound and is not the same as a measurement on your business — that would
require you to send back your own labels.
Intelligence coverage and freshness
We publish what share of your traffic we cover, the evidence freshness windows, and how often sources are re-observed.
A score of 0 means “no verifiable evidence”, not “safe” — not detected is not the same as cleared.