Skim v1.0.9 — "Nice Try, Phish" 🎣
The one where Skim learns to smell a phishing email from across the room — and does it all locally, offline, without phoning a single reputation service. Your inbox, now with a healthy sense of suspicion. 🕵️
✨ New
Phishing detection, built right in. Skim now quietly vets every message for the classic tells and warns you before you click something you'll regret. 🛡️
Sender checks — reads SPF / DKIM / DMARC results, catches "reply goes to a totally different domain" tricks, spots when the friendly display name hides a stranger's address, and flags lookalike domains (paypa1.com, we see you). 👀
Link checks — a link that says one thing but opens another, user@evil.com sleight of hand, and raw-IP links get stopped cold. Shorteners, plain http, punycode, weird ports and endless subdomains get side-eye too — but only when the sender already looks shady, so your newsletters full of tracking redirects don't set off alarms. 🔗
A link gate — click a suspicious link and Skim tells you where it actually goes and lets you bail or proceed. No more mystery destinations.
"Check for phishing" with AI — one tap to have Skim AI read the sender, the auth results, and the links, then explain the whole thing in plain language. 🪄
All of it deterministic, all of it offline. No thresholds to tune, no data leaving your machine.
🧹 Housekeeping
Bigger, prettier screenshots and a Windows Store build for the landing page. 📸
New DB migration (0008) to stash sender-auth signals we already fetch at sync time — no extra network chatter.
The usual pile of Rust cargo fmt'd into submission, plus fresh strings across all 11 languages. 🌍
👉 Grab it here: https://github.com/nikserg/skim/releases/tag/v1.0.9
Replies
the deterministic no-thresholds-to-tune approach is a good call for something running fully offline, less room for a model to hallucinate a false sense of security. but the checks you listed (SPF/DKIM/DMARC, lookalike domains, link mismatches) all assume the phishing email is coming from outside your trusted senders. what about the business-email-compromise case, where the attacker has actually compromised a real account you already trust and everything passes auth cleanly because it genuinely is that person's account? does Skim have any angle on that one or is it out of scope for now?
Skim
@omri_ben_shoham1 Great question — BEC is exactly the case where authentication-based signals go blind, by definition: the mail genuinely is from that account, so SPF/DKIM/DMARC pass honestly and sender history looks perfect.
Two things in Skim still apply there, though:
The link-level checks don't care who the sender is. Display/target mismatch ("paypal.com" text pointing elsewhere), raw-IP hosts, and the user@host trick fire on every message, trusted sender or not — and the hover preview + click-time gate work on all mail. A compromised account still has to point its credential-harvest link somewhere, and that's where we catch it.
We deliberately never show a "verified ✓" badge. Passing auth earns you nothing visually in Skim — no green checkmark, no trust indicator. That was a conscious call precisely because of the compromised-account case: we didn't want Skim vouching for a message just because DMARC passed. Absence of warnings ≠ endorsement.
What we honestly don't catch deterministically: the link-free BEC — "hey, wire the payment to this new account, I'm in a meeting." No URL, clean auth, known sender. That's a content/behavior problem, and heuristics that try to solve it (writing-style baselines, request-anomaly detection) get noisy and invasive fast — wrong trade for a minimalist local client. Our current angle there is the optional AI check: you can ask Skim AI about any message, and it reasons about the content itself (urgency patterns, unusual payment requests, tone shifts). But it's user-initiated, not automatic — we'd rather stay silent than train people to ignore warnings.
So: partially covered by design, honestly out of scope for the rest — for now.
@Nikita Zarubin that's a genuinely thoughtful line to draw, no verified badge so passing auth never reads as an endorsement. one middle ground worth asking about though: would you ever auto-trigger the AI check (not show a verdict, just run it silently) on a narrow keyword trigger like "wire", "payment details changed", "gift cards", instead of leaving it fully user-initiated? seems like the link-free BEC case is exactly the one where a user has no reason to think to ask.