This browser extension is a work in progress that is almost complete.
Hawk Eye Website Analysis Showcase
- Thread starter Trident
- Start date
Looks really nice so far – very polished for a WIP.
Here are some focused suggestions that might help you finish it off.
**1. UX / Layout**
• The full‑page warning looks clear and attention‑grabbing.
• Consider making the *safe* popup visually calmer (you already do this somewhat). Maybe slightly smaller text and less glow so it doesn’t feel alarming.
• Give the user a very obvious *safe* action on the danger page:
- Primary button: *Go Back to Safety* (or *Return to Previous Page*)
- Secondary button: *Ignore and Continue (Proceed at Your Own Risk)*
Right now the “Ignore and Continue” button is visually dominant; that can unintentionally nudge people to click it.
• Check how it behaves on smaller resolutions:
- Does the red card fit on 1366×768 without vertical scrolling?
- Is the “technical analysis” section scrollable but clearly indicated as such (maybe a small “scroll for details” hint or a visible scrollbar)?
**2. Text / Copy suggestions**
Your copy is already good; a bit of tightening can improve clarity and reduce “banner blindness”.
Example for the first warning:
Current vibe:
“We have high confidence this site is dangerous. It contains elements commonly used in phishing campaigns or forced download schemes. You are safe now.”
Possible tightened version:
“We have high confidence this site is dangerous. It shows patterns used in phishing or forced‑download scams. This page was blocked to protect you.”
Second warning (“digital danger zone”):
It’s catchy, but maybe slightly long for users who see it often. Something like:
“Entering a digital danger zone. Review the report below. Only click ‘Ignore and Continue’ if you are absolutely sure this site is safe.”
Technical box:
• Keep it short and specific; lead with the clearest signal.
• Example:
- “The domain uses typosquatting (‘bnak’ instead of ‘bank’) and targets a major financial institution (Barclays).”
- “This login page on a free hosting platform (vercel.app) asks for sensitive ID information (‘Consult your CPF’), which strongly suggests a phishing attempt.”
For the generic “low‑reputation / free hosting platform often abused for …” text, you might end with “…often abused for phishing and malware campaigns.” and avoid truncation – or detect length and split into multiple bullet lines.
Safe popup:
“This domain (google.com) is on the pre‑approved trusted list.” is good; you could add a short hint:
• “This domain is on the pre‑approved trusted list. No suspicious signals were detected in the latest scan.”
**3. Visual / Accessibility**
• Make sure color contrast between text and background passes WCAG (especially the red text on dark background).
• Don’t rely only on color for meaning:
- You already use icons and labels like SAFE / MALICIOUS ACTIVITY DETECTED – that’s good.
• Check keyboard navigation:
- Can you tab to “Ignore and Continue” and “Go Back” and activate them via keyboard?
- The full‑page overlay should trap focus until the user makes a choice.
**4. Security / Behavior considerations**
Without seeing the code I can’t tell how strong the detection is, but from a design/behaviour standpoint:
• Consider rate‑limiting “Ignore and Continue” for very high‑risk detections (e.g. require a second click or short delay with “Read explanation first”).
• Log locally when a user ignores a warning, so they can review their decisions later (but avoid collecting sensitive browsing data on your own servers unless you have a solid privacy model and policy).
• Make it very clear in the description/store listing:
- What data you scan (URL only? page content? form data?)
- Whether anything is sent to remote servers and how it’s handled.
**5. Final polish ideas**
• Add a small “Why was this blocked?” / “Learn more” link on both danger and safe popups pointing to a local help page or your website.
• Version number and update date in a tiny footer can help with trust.
• If you plan to publish on Chrome Web Store / AMO:
- Double‑check your permissions; use the minimum required (e.g. `activeTab` instead of full `tabs` when possible).
If you’d like, post a short clip or more screenshots of the flows (first‑time use, options page, false positive handling) and I can help fine‑tune the wording and layout of those too.
That sounds like a very solid architecture, especially for privacy‑minded users. Since the UI will change, I’d focus on nailing the *data‑flow story* so people instantly understand what happens where.
**1. Quick recap of what you described**
• Local:
- Massive proprietary Bloom filter (“bloomlist”) stored on the device
- Lightweight local heuristics for domains that hit the bloomlist
• Remote:
- For domains *not* on the bloomlist: send `domain + tab title` to `sitecheck.hea-p.com` (behind Cloudflare)
- Response comes from your Cloudflare‑backed database
- Auth token included, but no other user identifiers
• LLM:
- Cloudflare Worker calls the LLM
- LLM never sees user IP or direct client info; only what the Worker sends
This is a good split between local first, cloud as a fallback, and an extra analysis layer.
---
**2. Watch out for the tab title – it can contain PII**
The one place where you may unintentionally touch PII is the *tab title*:
• Search engine pages: titles often contain the full query string (names, emails, phone numbers).
• Web apps: titles can contain usernames, IDs, ticket numbers, sometimes even email addresses.
• Some banking / government portals put partial personal data in the title.
Suggestions:
• Consider sending only:
- Domain + a *truncated* or *sanitized* version of the title (e.g. first N chars, or only specific keywords you detect locally)
- Or a hashed / tokenized representation that’s only useful for your backend logic, not human‑readable.
• At minimum, document clearly in your privacy text that “page title may include search terms or other information, and is processed only for security classification.”
---
**3. How to communicate this in the extension UI / store listing**
People on MalwareTips will appreciate transparency. Something like:
• *Local protection first*
- “A large local database and heuristics run entirely in your browser. Most checks never leave your device.”
• *When we contact our servers*
- “If a site is not in the local database, we send its domain name and page title to our classification API (via Cloudflare). This helps detect new phishing and malicious sites.”
- “No cookies, form data, passwords, or browsing history are collected.”
• *LLM usage*
- “In some cases, anonymized page information is analyzed by an AI model. This is done via a Cloudflare Worker; your IP and browser identifiers are not exposed to the model provider.”
- “We do not send raw credentials, payment data, or full page content.”
• *Databases*
- “Detection databases are stored locally. We may publish detailed information about our lists and signals for transparency and research.”
Keep it short in‑extension and link to a more detailed page.
---
**4. Technical / security suggestions**
• **Bloom list updates**
- Sign update files and verify signatures in the extension before replacing the list.
- Consider incremental updates to keep size and memory usage manageable.
• **Cloudflare API**
- Rate‑limit per token and harden against abuse (people trying to enumerate your database).
- Cache results locally (e.g. for a few hours) to reduce network calls and improve speed.
• **LLM sanitization**
- Strip obvious sensitive patterns before sending (emails, 16‑digit card‑like numbers, long tokens/keys).
- Avoid sending whole HTML; instead send:
- The URL
- Key text snippets (login labels, payment prompts, etc.)
- Your own pre‑computed signals
• **Failure behaviour**
- Decide what happens when Cloudflare / LLM is down:
- Show “Local scan only; cloud services temporarily unavailable”
- Default‑safe behaviour for very suspicious patterns.
---
**5. When the UI changes**
Given this backend, the UI could clearly show:
• “Protection source” badge:
- Local list
- Cloud verdict
- LLM‑assisted analysis
• A tiny info icon: “What data was used for this decision?” with a one‑line explanation.
If you share a mockup of the new UI, I can help you tune the wording so it matches the data‑flow and privacy model perfectly.
Looks very slick – the visual hierarchy is clear and the header bar helps a lot. A few small tweaks could really tighten it up:
1. Tone of the main message
“Uh oh, bad vibes detected here. I’m locking the door.” is fun, but for some users it may feel a bit too playful for a high‑risk warning.
You might consider either:
• A slightly more serious variant:
“Uh oh, we’ve detected something dangerous here. I’m locking the door.”
or
• A two‑line combo:
“Uh oh, bad vibes detected here.
For your safety, this page has been blocked.”
That keeps the personality but makes the risk absolutely clear.
2. Primary safe action vs. ignore
Right now the only visible action is:
• [IGNORE AND CONTINUE (PROCEED AT YOUR OWN RISK)]
For safety and UX, I’d strongly suggest adding a prominent “safe” option:
• Primary (filled, more prominent): “Go Back to Safety” / “Return to Previous Page”
• Secondary (outlined, less prominent): “Ignore and Continue (Proceed at Your Own Risk)”
This reduces the nudge to bypass the warning and matches how most security products design block pages.
3. Micro‑copy under the title
“Review the technical analysis below to understand why this page was blocked.” is good; maybe add one more short line about what to do:
• “If you don’t recognize this site, close this page or go back to safety.”
4. Technical box
The technical text you show (“The domain uses typosquatting…”) is excellent – very concrete.
Just make sure:
• The box clearly indicates it’s scrollable if text overflows (visible scrollbar or “Scroll for more details”).
• Font size/contrast is sufficient; some users will lean hard on this explanation to decide whether to override.
5. Header bar
“Malicious Website Blocked for Your Protection” in the top bar looks great and professional. You could optionally add a tiny info icon on the right that opens a short “How we detected this” explanation.
---
Overall, this is a very strong UI already – just a bit of copy tightening and giving users a clear “safe way out” will make it feel both trustworthy and user‑friendly.
It randomly chooses from one of these messagesLOL, love it. A very contemporary way to put itBut, I do like Bot's Tone suggestion
const FRIENDLY_MESSAGES = [
"Whoa there! This site looks sketchy, so I stepped in.",
"Hawk Eye found some nasties here. Best to stay away.",
"Nope. This page is trying to pull a fast one on you.",
"Blocked! Your data is way too precious for this site.",
"Safety first! This link triggered my alarms.",
"I wouldn't go in there if I were you. High risk detected.",
"Hold up. This domain is acting super suspicious.",
"Shields up! I just blocked a nasty threat here.",
"Not today, hackers. This site is strictly off-limits.",
"Trust me, you really don't want to visit this page.",
"Uh oh, bad vibes detected here. I'm locking the door.",
"Yikes! This site is a security nightmare. Abort mission!",
"I've got your back. This page was up to no good.",
"Danger zone! I'm not letting you walk into that trap.",
"Phishing attempt? Malware? Either way, it's gone.",
"Access denied. Your security is worth more than this click.",
"Red alert! I caught this site trying to be sneaky.",
"Let's skip this one. It's full of digital red flags.",
"Safe browsing only! This site didn't make the cut.",
"Blocked. Because you deserve a malware-free day."
It is indeed good. And once Trident release the Executable App, it will cater more to a wider audience.
The extension was necessary to facilitate the download protection that will be in the app. It will go on the Web Store as well.
Because I don’t wanna outright spend $500 a year on EV signature, I am unable to create kernel mode drivers. I would spend, if I know there is interest.
So the extension, in addition to blocking malicious websites, will also report to the Hawk Eye Helios Inspection Service that there is a download and will also report where it came from.
This information will be used (amongst others) to calculate the safety of the download and decide whether sandboxing is necessary.
I really like the information posted in the Security Alert. That is really helpful for a person to understand (educate) the why, of the alert
Hi Trident,
Thanks for sharing the updated block page UI—it's looking sharp and user-friendly! I especially like how the messaging is clear and reassuring, which can help users feel more in control during a block. The random friendly messages add a nice touch of personality without overwhelming the core info.
Quick thoughts on the design:
- The dark theme with subtle animations (like the stars) keeps it modern and non-intrusive.
- Including details like the domain and reason for blocking is great for transparency—educates users without jargon.
- Options like "Take me back to safety" make it easy to navigate away safely.
If you're open to feedback, maybe consider adding a quick link to report false positives right there? Overall, impressive work on Hawk Eye—excited to see how the executable app shapes up!
Best,
@Bot
You may also like...
-
Defender Hardening Console (part of Hawk Eye Analysis Platform)- Started by Trident
- Replies: 62
-
Defender Hardening Console Executable
- Started by Trident
- Replies: 277
-
-
SUPERAntiSpyware Updates thread- Started by lokamoka820
- Replies: 15
-
Five Malicious Chrome Extensions Impersonate Workday and NetSuite to Hijack Accounts- Started by Brownie2019
- Replies: 3