About our writing

Editorial team

PhishEye publishes under team bylines rather than individual ones. Our threat research documents live criminal infrastructure, and naming individual researchers on that work creates risk for them without making the findings any more verifiable. What makes a finding credible is the evidence and the method, both of which we publish.

Bylines

PhishEye ResearchThe PhishEye Research team documents active phishing infrastructure, attacker tradecraft, detection signals, and reproducible investigation methods.Threat intelligence · Phishing infrastructure · Detection research
PhishEye TeamThe PhishEye team writes the product, comparison, and practitioner guidance on this site, drawing on the brand-protection work the company does for customers.Brand protection · Takedown operations · Vendor evaluation

What each byline covers

PhishEye Research publishes original investigations into live phishing infrastructure. Those posts are measurements first: we enumerate, resolve, read certificates and record what answered us on a stated date, then say what the evidence does and does not support. They are written to be reproducible, so the method is described in enough detail for a reader to run it themselves and disagree with us.

PhishEye Team covers everything else: practitioner guides, product documentation, buyer-facing comparisons and case studies. This material draws on the takedown and monitoring work we do for customers rather than on original research, and where it discusses our own product against a competitor it is written by an interested party and should be read that way.

How we write

Evidence is separated from interpretation. Research posts carry a table stating what we verified ourselves, what was supplied to us, and when. Anything that is inference rather than observation is labelled in the text.
Measurements say where they were taken. A result that depends on our vantage point, such as what a host returns to a request, is reported with that vantage point named, because someone testing from elsewhere may see something different.
Sources are linked, and preferred primary. Where a claim rests on a protocol, a registry or a company's own guidance, we link that rather than a summary of it.
Product claims are ours, not neutral. Comparison and alternatives pages are written by a vendor with an interest in the outcome. Validate them during your own evaluation.

Corrections

We correct published work in place rather than quietly, and say what changed. Research on live infrastructure moves quickly, and a finding that held when we published it can stop holding a day later. Where an article has been materially revised it carries an updated date, and where a conclusion has been withdrawn the article says so rather than deleting it.

If you believe something we published is wrong, tell us and we will check it. Get in touch.