Coder Legion - Recent posts tagged cybersecurity#opensource

Your Browser Is Not a Safe for Passwords

Sun, 25 Oct 2026 14:03:15 +0000

Your Passwords Are Probably Sitting in the Browser's "Shared Drawer"

Here's an uncomfortable fact to start with: nearly half of all internet users store their passwords in a browser. According to a NordPass survey across eight countries, 40–50% of respondents admitted they rely on their browser's built-in password storage. The reason is the same for everyone — convenience. So convenient that 51% say it's "handy," 44% say it's "easy," and 32% say it's "free."

But convenience and security are complete opposites here.
What the browser is actually storing

The moment you click "Save password," the browser writes your username and password into a local file. Chrome, Edge, and Firefox each have different paths, but to malware authors those paths are an open map. The RedLine stealer trojan sells on underground forums for a couple hundred dollars, and its core function is to specifically hunt down password files, cookies, and banking data from Chromium- and Gecko-based browsers. Another stealer, Acrid, lists it plainly in its feature set: theft of browser data, including passwords and logins.

Worse, some attackers don't even bother decrypting anything themselves. Kaspersky research described a tool called TomBerBil that copies the browser's saved-password file along with the DPAPI encryption key and calmly decrypts it on the attacker's own machine. In other words, the "encrypted storage" in your browser, against malware that has already gained your account privileges, is roughly a paper door.
The worst-case scenario: one password, everything falls

Browser storage has another hidden cost: it encourages laziness. Since the browser fills in the password for you, many people don't bother using different passwords for different sites. And once some second-rate site gets breached, the attacker has your email and password and tries them on WeChat, Alipay, the corporate VPN, online banking.

OWASP calls this attack Password Spraying: instead of hammering one account, the attacker tries a few common passwords across a huge number of accounts to avoid triggering lockouts, hunting for those lucky users who use the same weak password across every company service. Your browser holds ten variations of one password — the attacker only needs to guess one entry point.
What to do

The simplest correct answer: install a proper password manager. Bitwarden, 1Password, Kaspersky — any of them. Their fundamental difference from browser storage is that access requires a master password, and the encryption was designed from the start for the scenario "even if the file is stolen, it can't be cracked." Browser storage was designed for "so you type less," not for "so your money survives malware."

If you really don't want to install anything new, do at least two things: first, turn off "Save passwords" and "Autofill" in your browser. Second, for your most important accounts (email, bank, work systems), set completely separate and sufficiently complex passwords, don't store them in the browser — keep them in your head or in an offline place.

Storing passwords in a browser is essentially trading long-term security risk for a few seconds of typing. Those seconds aren't worth it.

What Is Undefined Behavior (UB) and Why Is It Dangerous?

Mon, 05 Oct 2026 14:29:24 +0000

What Is Undefined Behavior (UB) and Why Is It Dangerous?

In languages like Python or Java, a program either works or throws an error. In C and C++, things are different. Here we have UB — undefined behavior. This is a situation where the language standard does not say what the program should do. And then the compiler can do anything.

What is UB

Undefined behavior is code that is formally allowed for the compiler, but the result is unpredictable. The C standard does not describe what will happen — and the compiler is not required to warn you.

Examples of UB:

Out-of-bounds array access

Division by zero

Dereferencing a NULL pointer

Using an uninitialized variable

Signed integer overflow

Modifying a variable twice in one expression (i = i++)

Why it's dangerous

Unpredictability — the program may work today and break tomorrow

Optimizations — the compiler uses UB to speed up code and breaks logic

Security — UB is a common cause of vulnerabilities

Debugging — UB is hard to find, because the bug doesn't always show up

Example
c

int arr[3];
arr[5] = 10; // out-of-bounds — UB

This may:

work and break nothing

corrupt a neighboring variable

cause a segmentation fault

do literally anything

Why the compiler doesn't save you

The compiler optimizes code assuming that UB does not exist. If UB is present, the optimization can break the logic:
c

int x = 0;
if (x + 1 > x) { ... } // the compiler may remove this check

Because signed integer overflow is UB. So the compiler is allowed to assume it won't happen.

How to avoid UB

Read the standard — know what is allowed

Enable warnings — -Wall -Wextra in GCC

Use sanitizers — -fsanitize=undefined,address

Write carefully — check bounds, pointers, initialization

Use Rust — UB is almost impossible there

Conclusion

UB is not a bug. It's a hole in the standard.
The compiler is not required to catch it.
A program may work for years — and break at the worst possible moment.

Understanding UB is what separates a beginner from a systems programmer.
If you know where your code can become unpredictable, you write reliable code.

ChatGPT vs Gemini for Content Writing: Which AI Is Better?

Wed, 09 Sep 2026 06:23:02 +0000

AI writing tools have changed how bloggers and marketers create content. Two of the biggest options are ChatGPT and Google Gemini, but which one is better for content writing?
The answer depends on what you need.
ChatGPT for Content Writing

ChatGPT is particularly useful for:
Blog outlines
Long-form articles
Rewriting and editing
Brainstorming
Tone adjustment
SEO content planning
FAQs and content ideas
Its biggest strength for bloggers is the ability to refine content repeatedly. You can start with a rough draft and improve its structure, readability, tone, and explanations through multiple iterations.
Gemini for Content Writing

Gemini is also capable of drafting, rewriting, summarizing, and researching content.
Its major advantage is its connection with the Google ecosystem. If your workflow revolves around Google Docs, Drive, and other Google Workspace tools, Gemini can be convenient for working with existing documents and reference material.
ChatGPT vs Gemini: Quick Comparison

Feature
ChatGPT
Gemini
Long-form writing
Excellent
Very good
Rewriting
Excellent
Very good
Brainstorming
Excellent
Very good
Google Docs workflow
Good
Excellent
Research workflows
Very good
Very good
SEO content planning
Excellent
Very good
Tone customization
Excellent
Very good
Google Workspace
Good
Excellent

Which Is Better for Bloggers?

For bloggers, ChatGPT gets the overall edge for writing and editing. It is especially useful when you need to develop an article, improve its structure, make the writing more natural, or create multiple versions.
Gemini can be the better choice if you already work extensively inside Google Workspace.
But neither tool should be treated as an automatic content publisher.
Don't Publish AI Content Without Editing

AI can produce polished-looking content that still contains:
Incorrect facts
Generic explanations
Repetition
Outdated information
Unsupported claims
Use AI to speed up your workflow, but add your own experience, examples, opinions, and research.
AI should assist your content—not replace your expertise.
Final Verdict

There is no universal winner.
Choose ChatGPT if your priority is writing, editing, brainstorming, and content structure.
Choose Gemini if Google Workspace integration and document-based workflows are more important.
The best approach is to test both with your actual content workflow and choose the one that consistently helps you produce more useful content with less effort.

Rate Limiting and API Security in Next.js 15 — The Patterns I Actually Use

Wed, 26 Aug 2026 08:33:06 +0000

An API route with no rate limiting works fine right up until someone hits it a thousand times a second, either by accident (a buggy client retry loop) or on purpose. I learned this the annoying way, watching a client's database bill spike because a public form endpoint had no limit on how often it could be called.

Here is what I actually put in place now, on every project with public-facing endpoints.

1. Rate Limiting with Upstash

Upstash's Redis-backed rate limiter works well with Next.js since it is designed for serverless, no persistent connection required between requests.

npm install @upstash/ratelimit @upstash/redis

// lib/ratelimit.ts
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL as string,
  token: process.env.UPSTASH_REDIS_REST_TOKEN as string,
});

export const ratelimit = new Ratelimit({
  redis,
  limiter: Ratelimit.slidingWindow(10, '60 s'),
  analytics: true,
});

slidingWindow(10, '60 s') allows 10 requests per 60 seconds per identifier. Sliding window is generally the better default over a fixed window, since a fixed window lets someone burst right at the boundary between two windows and effectively double their allowed rate.

2. Applying It to a Route Handler

// app/api/contact/route.ts
import { ratelimit } from '@/lib/ratelimit';
import { headers } from 'next/headers';

export async function POST(request: Request) {
  const headersList = await headers();
  const ip = headersList.get('x-forwarded-for') ?? 'unknown';

  const { success, limit, remaining, reset } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Too many requests' },
      {
        status: 429,
        headers: {
          'X-RateLimit-Limit': limit.toString(),
          'X-RateLimit-Remaining': remaining.toString(),
          'X-RateLimit-Reset': reset.toString(),
        },
      }
    );
  }

  const body = await request.json();
  // handle the actual request
  return Response.json({ success: true });
}

Returning the rate limit headers even on success is good practice, it lets well-behaved clients see how close they are to the limit and back off proactively instead of finding out by hitting a 429.

3. Rate Limiting Server Actions

Server Actions do not get the same automatic IP access that route handlers do, since they are not standard HTTP endpoints in the same way. Getting the identifier takes an extra step.

// actions/contact.ts
'use server';
import { ratelimit } from '@/lib/ratelimit';
import { headers } from 'next/headers';

export async function submitContact(formData: FormData) {
  const headersList = await headers();
  const ip = headersList.get('x-forwarded-for') ?? 'unknown';

  const { success } = await ratelimit.limit(`contact_${ip}`);

  if (!success) {
    return { success: false, message: 'Too many attempts, try again shortly' };
  }

  // proceed with validation and saving
  return { success: true, message: 'Message sent' };
}

Prefixing the identifier with contact_ matters if multiple Server Actions share one rate limiter, it keeps each action's usage counted separately instead of one action's traffic eating into another's limit.

4. Rate Limiting by User, Not Just IP

IP-based limiting is the right default for unauthenticated endpoints, like a public contact form. For authenticated actions, limiting by user ID is usually more accurate, since multiple users can share an IP behind the same network, and one user can rotate IPs to dodge an IP-based limit entirely.

// actions/posts.ts
'use server';
import { ratelimit } from '@/lib/ratelimit';
import { getSession } from '@/lib/auth';

export async function createPost(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error('Not authenticated');

  const { success } = await ratelimit.limit(`create_post_${session.userId}`);

  if (!success) {
    return { success: false, message: 'Slow down, try again in a minute' };
  }

  // proceed
}

5. Validating Input Before It Reaches the Database

Rate limiting controls how often someone can call an endpoint. It says nothing about what they send. Every route handler and Server Action still needs its own validation, same principle covered in the form handling setup, applied specifically at the API boundary here.

// app/api/users/route.ts
import { z } from 'zod';

const CreateUserSchema = z.object({
  name: z.string().min(2).max(50),
  email: z.string().email(),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = CreateUserSchema.safeParse(body);

  if (!parsed.success) {
    return Response.json({ error: 'Invalid input' }, { status: 400 });
  }

  // proceed with parsed.data, never the raw body
}

Never pass the raw request body into a database call. Even with rate limiting in place, an endpoint accepting arbitrary shaped input is still open to malformed data, oversized payloads, or fields that were never meant to be settable from outside.

6. CORS for Public API Routes

If an API route is meant to be called from your own frontend only, restricting CORS prevents other websites from calling it directly from a browser using a visitor's already-authenticated session.

// app/api/data/route.ts
export async function GET(request: Request) {
  const origin = request.headers.get('origin');
  const allowedOrigin = process.env.NEXT_PUBLIC_URL;

  const response = Response.json({ data: 'example' });

  if (origin === allowedOrigin) {
    response.headers.set('Access-Control-Allow-Origin', allowedOrigin);
  }

  return response;
}

This matters specifically for cookie-based auth. Without a CORS restriction, a malicious site could make a request that rides on a logged-in user's cookies, and without a check like this, your API would happily respond as if the request came from your own frontend.

7. Secrets Never Reach the Client

An easy mistake in Next.js specifically, any environment variable prefixed with NEXT_PUBLIC_ gets bundled into client-side JavaScript, visible to anyone who opens dev tools.

// ❌ This leaks the secret into the browser bundle
const apiKey = process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY;

// ✅ Secret keys stay server-only, no NEXT_PUBLIC_ prefix
const apiKey = process.env.STRIPE_SECRET_KEY;

Only prefix an environment variable with NEXT_PUBLIC_ when the value is genuinely meant to be public, a publishable Stripe key, an analytics ID, not an API secret, database URL, or anything meant to stay server-side only.

Summary

Pattern	Protects against
Sliding window rate limit (Upstash)	Endpoint abuse, accidental retry loops, brute force attempts
Per-user rate limiting on authenticated actions	IP rotation and shared-IP inaccuracy
Zod validation at the API boundary	Malformed or unexpected input reaching the database
CORS restriction on cookie-authenticated routes	Cross-site requests riding on a logged-in session
No `NEXT_PUBLIC_` on secrets	API keys and secrets leaking into the client bundle

Rate limiting and validation solve different problems and both matter. Rate limiting controls how often, validation controls what. An endpoint with one but not the other is still exposed, just in a different way.

I put this exact set of protections, rate limiting through Upstash, Zod validation at every boundary, on any public-facing endpoint across the SaaS projects I build.

Get the templates: https://pixelanas.gumroad.com

Have you had an endpoint get hit hard enough to actually need rate limiting in production? Drop it below 👇

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

I built a red-team scanner for MCP servers. Then I pointed it at the real ones.

Fri, 12 Jun 2026 20:50:45 +0000

I built a red-team scanner for MCP servers. Then I pointed it at the real ones.

The Model Context Protocol lets an AI agent connect to external tools: a filesystem, GitHub, Slack, a database. Each server an agent connects to advertises a list of tools, and here is the part most people miss: that tool list is an attack surface.

A tool's description and parameter docs do not just describe the tool to a human. They are injected straight into the agent's context, and the model treats them with the same authority as your own instructions. So a server can hide instructions to the model inside text you skim as a harmless description. That is tool poisoning, and it is the pattern behind CVE-2025-54136.

I wanted to see how exposed real servers were, so I built ghostprobe: a scanner that connects to an MCP server, pulls its tool list, and reports what an attacker would care about, mapped to the OWASP MCP Top 10. This post is about what happened when I pointed it at real servers, because that is where it got interesting.

What the tool list gives away

ghostprobe looks for a few things:

Tool poisoning: instruction-injection phrasing like "ignore previous instructions" or "do not tell the user", and invisible Unicode used to smuggle instructions past human review while still reaching the model.
The lethal trifecta: a server whose tools together provide private-data access, a way to send data out, and exposure to untrusted content. Any one leg is fine. All three, and a single prompt injection can read your secrets and exfiltrate them. The term is Simon Willison's.
Rug pulls: a server that silently changes a tool's description after you have trusted it.
Dangerous capabilities like shell execution.

The lethal trifecta is the one that matters most, because it is not about a single malicious tool. It is about a combination that looks reasonable until you see all three legs at once.

I pointed it at the official servers, and it found bugs in itself

The official reference servers (filesystem, memory, GitHub, and the rest) are well-built, so I expected clean results. Instead, the first things ghostprobe found were false positives in my own analyzer. This was the most useful thing that could have happened.

On the filesystem server it flagged read_text_file as code execution. Wrong. It matched because my exec detector keyed on the bare word "system", and the description says "file system". A read-a-file tool is not remote code execution.

On the sequential-thinking server it flagged a thought history as private-data access. Wrong again. It matched the word "history".

A security scanner lives or dies on its false-positive rate. A tool that cries wolf gets muted, and a muted tool is worse than no tool. So I fixed both: exec detection now requires a real execution verb plus an object, and "history" is too weak a signal to keep. Each fix shipped with a regression test built from the exact server that exposed it.

Then GitHub exposed a false negative, which was worse

The GitHub server was more interesting. ghostprobe saw that it reads private repo contents and reads issue text, but it reported no sink, so no trifecta. That was a false negative, and a false negative in a security tool is more dangerous than a false positive.

The GitHub server absolutely has a sink. It can create issues, post pull-request comments, and push to a repo. Writing into a public issue is how you exfiltrate private data. ghostprobe missed it because GitHub's write verbs are "create" and "post" and "push", not "send", and I had only taught it to recognize sending over an obvious external medium like email or HTTP.

The fix was to recognize that writing to a shared, remote, collaborative service is itself an exfiltration channel, distinct from writing a local file. Open an issue, post a comment, push to a repo: those send data out of your trust boundary. Writing a local file does not. After that change, ghostprobe flagged the GitHub server correctly:

[CRIT] MCP04 Lethal Trifecta
  data:      get_file_contents, get_pull_request_files, push_files
  sink:      add_issue_comment, create_issue, create_or_update_file
  untrusted: get_issue, get_pull_request_comments, list_issues

Read a private repo, ingest issue text that anyone on the internet can write, and post to a public issue. An attacker files an issue containing instructions, an agent set up to triage issues reads them, and your private code ends up in a public comment.

I want to be precise about what this is. It is not a vulnerability I discovered. This exact GitHub-MCP exfiltration path was disclosed by Invariant Labs in 2025. The point is that ghostprobe detects the class automatically, from the tool list alone, with no prior knowledge of the server. Point it at a server it has never seen and it tells you whether the trifecta is present.

What I actually learned

Real servers are the only real test. Every meaningful improvement to ghostprobe came from running it against an actual server, not from my fixtures. A handful of releases in two days, each one a precision fix driven by a real result: two false positives removed, one false negative closed.

The tool list is underappreciated as an attack surface. People audit MCP server code. Far fewer look at what the server advertises to the agent, which is exactly where poisoning and the trifecta live, and which an attacker can influence without touching your code at all.

And a scanner's credibility is its false-positive rate, not its feature count. The most valuable work was not adding checks. It was making the existing checks stop lying.

Try it

ghostprobe is open source under MIT. The analyzer has no dependencies; you only need the MCP SDK to probe a live server.

pip install "git+https://github.com/joemunene-by/ghostprobe.git" mcp
ghostprobe stdio -- npx -y @modelcontextprotocol/server-github

Or scan a saved tools/list dump completely offline:

ghostprobe scan-file tools.json

GitHub: https://github.com/joemunene-by/ghostprobe

By Joe Munene, a software engineer in Nairobi focused on secure systems and applied machine learning.
Portfolio · GitHub · More writing · [*Emails are not allowed*](mailto:Emails are not allowed)

How to evaluate a small language model on multiple choice without fooling yourself

Fri, 12 Jun 2026 07:42:26 +0000

I spent months building GhostLM, a cybersecurity language model I trained from scratch in PyTorch. The architecture was the easy part. The thing that actually cost me weeks was evaluation. Three separate times, my benchmark told me something that was not true, and each time the bug was in the eval, not the model.

This post is the protocol I wish I had started with. It is not specific to cybersecurity or to GhostLM. If you are evaluating any small model on a multiple-choice benchmark, these are the ways the number lies to you, and how to stop it.

1. Never score the letter. Score the option text.

The obvious way to grade a multiple-choice question is to ask the model for the probability of each letter and take the highest. So for a question with options A through D, you compare log P("A"), log P("B"), and so on.

This is the single most dangerous shortcut in small-model evaluation, because it does not measure reasoning. It measures which letter the model likes.

I had a model scoring 36.9% on a 2,500-question benchmark, comfortably above the 25% random baseline. Then I looked at the gold label distribution:

gold=A: 374 (15.0%)
gold=B: 813 (32.5%)
gold=C: 928 (37.1%)
gold=D: 385 (15.4%)

A model that emits "C" on every single question scores 37.1%. I checked the per-letter accuracy on my "best" checkpoint:

gold=A: 7/374   (1.9%)
gold=B: 0/813   (0.0%)
gold=C: 915/928 (98.6%)
gold=D: 0/385   (0.0%)

The model was not doing cybersecurity reasoning. It had collapsed onto the letter C and was scoring off the label skew. My 36.9% was a measurement of how unbalanced the benchmark was.

The fix is to score the text of each option, not its letter. Instead of comparing log P("C"), compare log P(option_text) under the prompt. Now the model has to actually prefer the correct statement, not the correct position.

2. Debias with multiple permutations.

Text scoring alone is not enough, because a model can still have a positional bias that text scoring does not fully remove. The clean test is to shuffle the option order.

Run each question N times with the options in different orders, and require the model to pick the same correct answer every time. A model that is genuinely reasoning is invariant to order. A model that is secretly emitting one position collapses to random under permutation.

I ran four permutations across all 2,500 questions on every checkpoint. The result was humbling. The checkpoint I had crowned as "canonical" at 36.9% single-order got zero questions correct under all four permutations. A different checkpoint I had dismissed as a failed run got three correct under all four. The single-order ranking was inverted from real capability.

If a number does not survive permutation, it is not a capability, it is an artifact.

3. For classification, subtract the prior (PMI scoring).

If your task is classification (pick the category, the severity, the technique), you will hit a related trap. Score by raw conditional probability and the model will assign its highest probability to the same common label for every input, regardless of the question. Every checkpoint I trained reported exactly the random baseline on my classification eval, which is the signature of a mode-collapsed metric, not a model that cannot learn.

The fix is pointwise mutual information. Instead of scoring log P(label | context), subtract the model's unconditional preference for that label:

pmi_score = log P(label | context) - log P(label)

This cancels out the model's prior bias toward common labels, so a label only wins if the context actually raises its probability. After switching to PMI, my eval could finally tell checkpoints apart instead of flatlining at random.

4. Audit your train/validation split for leakage.

Before you trust any validation number, check how you split the data. I split mine by random shuffle, which sounds fine until you remember that real corpora are repetitive. In my case CVE descriptions repeat the same patterns with slight wording changes, so a random split put near-duplicate records on both sides. The model memorized in training and "validated" on text it had effectively already seen.

My leaky split reported a validation loss of 2.74. After I fixed it the same model on the same recipe reported 3.78. The model did not get worse. The eval got honest.

The fix is deterministic content-hash bucketing, so identical or near-identical text always lands in the same split:

bucket = int(hashlib.sha256(text.encode()).hexdigest(), 16) % 100
split = "val" if bucket < val_pct else "train"

5. Audit for contamination against your training corpus.

A clean split protects you from leakage you created. Contamination is leakage you inherited, when your training corpus happens to overlap with the benchmark's sources.

I checked this with an 8-gram shingle overlap between every benchmark question and my training data. Eleven percent of my benchmark questions had at least one overlap. Interestingly, the contaminated questions scored slightly worse than the clean ones, which told me the overlap was confusing the model rather than helping it, and ruled out the "leakage inflated my score" theory. Either way, you want to know the number before you report anything.

6. Look at per-source perplexity, not just aggregate loss.

Aggregate validation loss hides what the model is actually learning. When I broke perplexity out per source, I could see that one document type (short CVE descriptions, 87% of my tokens) was dominating, and the model had learned exactly one output register and applied it to everything. A CTF prompt produced fake CVE text. A research-paper prompt produced fake CVE text.

A per-source breakdown after every run tells you whether new data is helping or quietly cannibalizing the domains you already had. When I added one large source and watched every other source get 28 to 42% worse, that was the model hitting its capacity ceiling, visible only because the metric was split by source.

7. Test free-form recall, not just multiple choice.

Multiple choice flatters a model because the answer is on the screen. To find out whether the model actually knows anything, ask it open questions and grade by substring match, with disqualifier phrases to catch lucky echoes.

I built a 50-question free-form recall set. The scores were brutal and honest: roughly one correct out of fifty, and even that one was spurious because the model echoed a term from the question. The conclusion was clear and worth more than any benchmark percentage. My models had absorbed the vocabulary and register of the domain but not the facts. They were fluent parrots. That is a useful thing to know about a small model, and multiple choice will never tell you.

The meta-lesson

At small scale, benchmark quality compounds more than model quality. Every one of my real improvements came from fixing the eval, not the model. Fixing the leaky split alone changed a perplexity number by more than 14x with zero extra training. Fixing the letter-scoring bug revealed that months of ablations had been optimizing positional bias instead of capability.

So the protocol, short version:

Score option text, never the letter.
Require the answer to survive multiple option permutations.
Use PMI scoring for classification so common labels do not win by default.
Split by content hash so the validation set is honest.
Shingle-check the benchmark against your training corpus for contamination.
Break perplexity out by source.
Test free-form recall to separate register from knowledge.

None of this is expensive. The permutation test is about twenty lines of Python. The contamination check is similar. The reason these bugs survive long enough to get into published numbers is not that they are hard to catch, it is that people rarely audit the benchmark before trusting it. Audit it first.

The full harness I built while finding these bugs is open source, including the multi-permutation text scorer, the free-form recall grader, and the contamination checker.

GitHub: https://github.com/joemunene-by/GhostLM

Autonomous brain (working model)

Mon, 25 May 2026 19:23:31 +0000

A self-improving AI software-engineering pipeline. An autonomous boardroom of LLMs designs, writes, tests, security-reviews, and publishes a brand-new browser-runnable project several times a day. Each one more advanced than the last, in a different domain, polished and security-cleared before publish.

Cadence: up to 5 projects/day · ≥5 hours between projects · Cost: $0

Every project below is a separate public repository with a one-click playable demo. Click ▶ Run it on any card.

WAB web agent bridge

Wed, 20 May 2026 16:13:01 +0000

We are opening Web Agent Bridge (WAB) to deeper technical review, testing, and critical feedback from developers, security researchers, browser automation engineers, AI-agent builders, and privacy-focused infrastructure communities.

WAB is an open AI ↔ Web protocol and agent interoperability layer designed to reduce brittle DOM automation and replace guesswork with signed, machine-readable capability contracts.

The project currently includes:

DNS-based discovery (_wab)
/.well-known/wab.json
Signed trust profiles (Ed25519)
Ring 4 trust verification
Agent capability negotiation
Intent-aware routing
Governance and audit layers
Privacy budget declarations
Refusal and constitutional invariant handling
Cross-agent verification flows
SDKs and framework adapters
MCP and browser-agent integrations

The broader goal is simple:

Create a predictable, inspectable, privacy-aware interface between AI agents and the web — without requiring centralized control, invasive tracking, or fragile scraping logic.

We are specifically interested in feedback regarding:

protocol design
security assumptions
trust boundaries
abuse resistance
privacy implications
interoperability
schema clarity
agent discoverability
edge-case behavior
failure modes
governance architecture
machine-readability
developer ergonomics

We are not looking for hype.

We are looking for:

serious testing
architectural criticism
implementation review
adversarial thinking
interoperability experiments
independent verification

If parts of the design are flawed, we want to know.
If assumptions break under real-world conditions, we want to see it.
If there are better approaches, we are open to them.

The protocol, SDKs, and specifications are public and reviewable.

Repository:
https://github.com/abokenan444/web-agent-bridge

Documentation:
https://webagentbridge.com/docs

Architecture:
https://webagentbridge.com/ring4

The long-term health of agent ecosystems will likely depend on open, inspectable, privacy-respecting standards rather than opaque automation layers.

Constructive criticism is welco

I thought my LLM hit 36.9% on a cybersecurity benchmark. It was picking C every time.

Mon, 11 May 2026 08:17:18 +0000

I've been building GhostLM — a decoder-only transformer trained from scratch in PyTorch on cybersecurity data. No pretrained weights, every component hand-written. A few weeks ago I published a post about fixing a leaky train/val split that made my model look 14x better than it was.
I just found a second bug. This one made the benchmark itself look meaningful.
The 36.9% that wasn't
After months of training, I had a chat-tuned model hitting 36.9% on CTIBench MCQ — a 2,500-question cybersecurity multiple-choice benchmark. That's above random (25%) and I was running ablations trying to reproduce and beat it.
Then I checked the gold label distribution.
gold=A: 374 (15.0%)
gold=B: 813 (32.5%)
gold=C: 928 (37.1%) ← skewed
gold=D: 385 (15.4%)
A model that always picks C scores 37.1%. Higher than my "best" result.
I ran a quick diagnostic on the canonical checkpoint. Per-letter accuracy:
gold=A: 7/374 (1.9%)
gold=B: 0/813 (0.0%)
gold=C: 915/928 (98.6%)
gold=D: 0/385 (0.0%)
The model wasn't doing cybersecurity reasoning. It was emitting C on every question and scoring off the label distribution.
The permutation test
The correct eval is multi-permutation text scoring. Instead of scoring log P("C" | prompt), score log P(option_text | prompt) under N different option orderings. A pure C-emitter collapses to 25% random under this metric regardless of label distribution.
I ran 4 option permutations × 2,500 questions across every checkpoint:
Modelsingle-orderdebiasedall-perm correctchat-v3 "canonical"36.9%30.5%0/2500chat-v3 repro231.2%31.7%3/2500chat-v0629.8%31.2%0/2500
The model I'd dismissed as a "failed reproduction" (31.2% single-order) answered 3 questions correctly under all permutations. The "canonical" answered zero. The single-order ranking is inverted from real capability.
I also found that the bias letter depends on the base checkpoint, not the SFT recipe. v0.4 base learned to emit C. v0.6 base learned to emit B. v0.6 hybrid learned to emit A and scored 37.1% under a different permutation — same trick, different letter.
What the models actually know
After switching to text scoring, every checkpoint clustered at 27-29% on the full 2,500-question bench — roughly 4 points above random. I also built a 50-question free-form fact recall set with substring grading:

v0.4 chat: 0/50
v0.7 chat: 1/50 (spurious — "Injection" appeared in tangent prose)
v0.9 chat: 1/50 (spurious — echoed "SHA-256" from the question)

The models have absorbed the register and vocabulary of cybersecurity writing. They do not know the facts. EternalBlue gets a wrong CVE. MITRE technique IDs get conflated. The model is a cybersec parrot.
Contamination audit
After discovering v0.9 was trained on PRIMUS corpus that overlaps with CTIBench sources, I ran an 8-gram shingle overlap check. 11% of CTIBench questions have at least one overlap with the training corpus. The contaminated questions score 2.2pp lower than clean ones — contamination is confusing the model, not helping it. This rules out the leakage-helps hypothesis and points to register-shift as the explanation.
What I built while diagnosing this
The diagnosis forced me to build better infrastructure:

eval_text_scoring.py — multi-permutation text scoring, works on any MCQ JSONL
eval_fact_recall_v2.py — free-form fact recall with boundary matching and disqualifier phrases
audit_ctibench_contamination.py — shingle overlap checker
GhostBench — a packaged eval suite with Wilson 95% CIs, McNemar's tests, forest plots, scaling-law projections. Can evaluate any small open LM, not just GhostLM.

I also published the fact-recall benchmark as a HuggingFace dataset: Ghostgim/cybersec-fact-recall.
The actual bottleneck
The RAG diagnostic told the story clearly:
MetricScoreRetrieval@4 (no LM)41/100v0.9 bare1/100v0.9 + RAG0/100
The retriever surfaces the right passage 41% of the time. The 81M model extracts the fact 1% of the time. Adding retrieved context destabilizes the model into repetition loops. The bottleneck is generation capacity, not retrieval. Parameter scaling is the answer.
SmolLM2-360M and Phi-3.5-mini both show factual recall emerging around 300-400M params. Ghost-base (~360M) is the next rung, gated on GPU compute.
What I actually learned
Benchmark quality compounds more than model quality at small scale. Fixing the eval methodology revealed I'd been chasing a number that was measuring positional bias, not capability. Months of ablations were optimizing the wrong objective.
The correct eval protocol for MCQ at small scale: text scoring + multi-permutation debiasing. Single-order letter scoring is uninterpretable on any benchmark with skewed gold label distribution.
The 30% real ceiling across every architecture, BPE, SFT objective, and corpus density I tried is the clearest result I have. It's reproducible, it's controlled, and it tells me exactly what the next experiment needs to be.
GitHub: https://github.com/joemunene-by/GhostLM
Eval harness: scripts/eval_text_scoring.py
Fact-recall dataset: huggingface.co/datasets/Ghostgim/cybersec-fact-recall

What I Learned Building a Cybersecurity LLM From Scratch: 30,000 Steps, 3 Architecture Rewrites, and

Sat, 02 May 2026 12:37:06 +0000

What I Learned Building a Cybersecurity LLM From Scratch: 30,000 Steps, 3 Data Rewrites, and One Capacity Ceiling

I started building GhostLM thinking the hard part would be the transformer architecture. I was wrong. The architecture took one day. The real work — data quality, evaluation design, finding capacity limits — took three weeks and four complete training runs to get right.

This is the honest story of that process.

What GhostLM Is

GhostLM is an open-source, decoder-only transformer language model built entirely from scratch in PyTorch, specialized for cybersecurity reasoning. No pretrained weights, no AutoModel.from_pretrained. Every component — attention, positional encoding, training loop, data pipeline — written by hand.

The current canonical model is ghost-tiny: 14.7M parameters, 2 layers, trained on CVE vulnerability descriptions, MITRE ATT&CK, CTFtime writeups, CAPEC attack patterns, and arXiv security papers.

GitHub: https://github.com/joemunene-by/GhostLM

Phase 1: The Architecture Was the Easy Part

The transformer itself came together in a single session. Causal self-attention with manual scaled dot-product, pre-norm blocks, weight-tied output projection, cosine LR schedule with linear warmup. 10/10 unit tests passing on day one.

def forward(self, x):
    B, T, C = x.size()
    qkv = self.c_qkv(x)
    q, k, v = qkv.split(self.n_heads * self.head_dim, dim=-1)
    q = q.view(B, T, self.n_heads, self.head_dim).transpose(1, 2)
    k = k.view(B, T, self.n_heads, self.head_dim).transpose(1, 2)
    v = v.view(B, T, self.n_heads, self.head_dim).transpose(1, 2)
    att = (q @ k.transpose(-2, -1)) * (1.0 / math.sqrt(self.head_dim))
    att = att.masked_fill(self.causal_mask[:, :, :T, :T] == 0, float("-inf"))
    att = F.softmax(att, dim=-1)
    y = self.attn_dropout(att) @ v
    y = y.transpose(1, 2).contiguous().view(B, T, C)
    return self.resid_dropout(self.proj(y))

First training run: 500 steps on a ThinkPad Yoga 11e with 4GB RAM. Loss dropped from 10.04 to 6.27. The model was already producing CVE-style fragments: "allows remote attackers to cause a denial of service via arbitrary SQL commands."

That felt like success. It wasn't — not yet.

Phase 1 Problem: The Train/Val Split Was Leaking

The first serious mistake: I split training and validation data by random shuffle. That sounds fine until you realize CVE descriptions are highly repetitive. The same vulnerability pattern appears in dozens of CVEs with slight wording variations.

A random split means nearly identical records end up in both train and val. The model memorizes patterns it's already seen in training, val loss looks great, and you think you're making progress. You're not — you're measuring memorization.

Phase 1 val_loss: 2.74 at 10K steps. Looked great. Was fake.

The fix was content-hash bucketing:

# Same text always lands in the same split, deterministically
bucket = int(hashlib.sha256(text.encode()).hexdigest(), 16) % 100
split = "val" if bucket < val_pct else "train"

After fixing the split, val_loss jumped to 3.78 on the same architecture and training recipe. That jump wasn't the model getting worse — it was the eval getting honest.

Lesson 1: Always audit your train/val split. Leakage is silent and optimistic.

Phase 2 Problem: NVD Was 87% of the Corpus

With a clean split, Phase 2 trained to 10K steps on what I thought was a diverse cybersecurity corpus. 10,925 records. NVD CVEs, synthetic CTF writeups, synthetic papers.

What I hadn't measured: token share. NVD CVE descriptions are short (avg ~200 chars) and there are thousands of them. The synthetic writeups are long (~800 chars each) but there were only 500.

Running scripts/data_stats.py revealed the actual situation:

NVD CVE:     87.3% of tokens
Synthetic:    7.8%
Papers:       4.9%

The model wasn't learning "cybersecurity language." It was learning "CVE description language" — one very specific register of one very specific document type.

Every prompt, regardless of domain, produced CVE-style output:

CTF prompt → fake CVE
MITRE ATT&CK prompt → fake CVE
Research paper prompt → fake CVE

The model had one output register and applied it to everything.

Lesson 2: Measure token share, not record count. A dataset with 6 sources and 87% from one source has 1 effective source.

Phase 3: Real Data From Real Sources

Phase 3 added three new real data sources:

MITRE ATT&CK — pulled via STIX2 JSON from GitHub. 691 technique descriptions covering adversary tactics, techniques, and procedures.

CAPEC — XML pull from MITRE covering attack patterns. 609 records with structured attack methodology descriptions.

CTFtime real writeups — 467 inline writeups from actual CTF events, attributed and licensed for research use.

These three sources brought the token distribution to:

NVD CVE:       65.3% (capped at 6M tokens via content-hash subsample)
Synthetic CTF: 17.2%
arXiv cs.CR:    8.4%
CTFtime real:   5.3%
MITRE ATT&CK:   2.9%
CAPEC:          0.9%

The NVD cap uses deterministic content-hash subsampling — same 71,828-record prefix every rebuild, so train/val splits stay byte-identical across runs:

python3 scripts/rebuild_corpus.py --max-cve-tokens 6000000

Trained ghost-tiny for 30,000 steps on the rebalanced corpus. The per-source perplexity results were striking:

Source	Before (v0.3.3)	After (v0.3.5)	Change
MITRE ATT&CK	615	55	−91%
CTFtime writeups	184	61	−67%
CAPEC	326	134	−59%
Synthetic CTF	68	28	−58%
arXiv	671	355	−47%
NVD CVE	24	28	+14%

Every diversity source improved dramatically. NVD paid a small cost (+14%) — expected, since it now shares parameter capacity with five other domains. That's the right tradeoff.

The behavioral change was visible. Same model size, same training recipe, different corpus balance:

Before (v0.3.3):

Prompt: MITRE ATT&CK technique T1003
Output: CVE-2019-XXXX: A vulnerability in [product] allows remote attackers to...

After (v0.3.5):

Prompt: MITRE ATT&CK technique T1003
Output: T1003.011: defense-evasion. Tactic: defense-evasion. Adversaries may use-evasion, such as legitimate system-evasion...

That's actual MITRE schema output — sub-technique ID format, "Tactic:" header, the standard "Adversaries may..." opening. The model learned the MITRE register because it finally had MITRE training data in meaningful quantity.

Lesson 3: Model behavior follows token distribution. Want register diversity? Give your corpus source diversity at the token level.

The Evaluation Was Broken Too

While fixing the data, I discovered the evaluation was also broken.

The security task evaluation asked the model to classify inputs into categories (CVE severity, vulnerability type, MITRE tactic, etc.) by scoring each candidate label's log-probability. Every model across every phase reported 13.3% accuracy — exactly 4/30, exactly at the random baseline.

That's not the model performing poorly. That's a mode-collapsed eval. The model was assigning its highest probability to the same single label for every sample in each task — the most common token sequence — regardless of the input.

The fix was PMI (Pointwise Mutual Information) scoring:

# Instead of: score = log P(label | context)
# Use: score = log P(label | context) - log P(label)
pmi_score = conditional_logprob - unconditional_logprob

This subtracts the model's prior preference for each label, so common labels don't automatically win. After switching to PMI scoring, the eval could finally discriminate between models:

Phase	PMI Accuracy	vs Random (14.5%)
Phase 1	20%	+5.5 pp
Phase 3.5	31.2%	+16.7 pp

Not impressive in absolute terms — ghost-tiny at 14.7M params isn't going to nail classification tasks. But it's real signal, not evaluation noise.

Lesson 4: If every model in every phase scores the same on your eval, the eval is broken. Check for mode collapse before concluding the model isn't learning.

Phase 3.6: Finding the Capacity Ceiling

With a working eval and a clean corpus, I tried to push further. Phase 3.6 added Exploit-DB (~3.77M tokens, 30% of the new corpus) and re-trained ghost-tiny at the same 30K-step recipe.

The results were a clean regression:

Task	Phase 3.5	Phase 3.6	Change
CVE Severity	32%	16%	−16 pp
Vulnerability Type	32%	12%	−20 pp
Attack Technique	40%	16%	−24 pp
CTF Categorization	40%	20%	−20 pp
Overall	31.2%	16.8%	−14.4 pp

Per-source perplexity confirmed the diagnosis: every existing source got 28–42% worse while Exploit-DB itself landed well (PPL 40.87). The model learned Exploit-DB at the expense of everything else. Parameter capacity was reallocated, not expanded.

At 14.7M parameters and 30K training steps, ghost-tiny has hit its ceiling. More data at this model size produces diminishing returns — and eventually, regression.

Lesson 5: Parameter capacity is the binding constraint. When adding data hurts existing domains, you've hit the model's capacity wall. The fix is more parameters, not more data.

Where GhostLM Is Now

v0.3.5 (current canonical):

30,000 training steps
74,635 records, 8.8M tokens across 6 sources
Cyber-text perplexity: 96.24 (vs GPT-2's 26.76 — ~8× less capacity, ~3.6× behind)
PMI security task accuracy: 31.2% (vs 14.5% random)
Register diversity: switches between CVE, MITRE, and CTF voice depending on prompt

What's next:

ghost-small (55M params) — the first scale-up rung, targeting M4 GPU/MPS
Corpus volume expansion: CTFtime archives, security research blogs, full-text papers
Applied for Google TPU Research Cloud credits

The honest framing: ghost-tiny is a learning artifact and a working pipeline. It is not a useful cybersecurity AI tool. ghost-small is where domain-coherent generation might start to emerge. ghost-base (~350M) is where it gets genuinely useful. That's the realistic roadmap.

What I'd Tell Someone Starting This

1. Build the data pipeline before the model. The architecture is a solved problem — transformers are well understood. What's not solved for your domain is the data. Start there.

2. Measure token share, not record count. Diversity in records doesn't mean diversity in training signal if one source dominates token count.

3. Fix your evaluation before trusting it. Mode-collapsed evals are optimistic and useless. PMI scoring, per-source perplexity, and fixed external test sets are more honest than aggregate val_loss.

4. Set a capacity budget and test it. Before adding more data, test whether your model can absorb it without regressing on existing domains. A simple per-source perplexity check after each training run tells you whether you're within capacity.

5. Be honest about what your model can't do. A 14.7M parameter model hallucinating at temperature 0.7 is not a cybersecurity tool. Label it accurately. The trajectory toward useful matters more than the current absolute performance.

Try It Yourself

git clone https://github.com/joemunene-by/GhostLM.git
cd GhostLM
make install
make data
make train-tiny
make chat

The codebase is designed to be readable — every component is hand-written with docstrings, and the architecture is clean enough to use as a reference for how a transformer actually fits together.

Contributions welcome — especially around corpus expansion, evaluation design, and architecture improvements (RoPE and Flash Attention are already in, SwiGLU and grouped query attention are next candidates).

GitHub: https://github.com/joemunene-by/GhostLM
License: MIT

Built in Nairobi, Kenya

Hello World! Welcome to the VoiceAutomationAI Group!

Wed, 15 Apr 2026 20:17:00 +0000

Welcome to the VoiceAutomationAI group on CoderLegion! This is a space for developers building voice agents, real-time audio pipelines, and open-source voice infrastructure.
What we discuss here:

STT, LLM, TTS pipeline architecture
Self-hosted voice AI tools
Telephony integrations
Latency optimization for real-time calls
Open-source projects like Dograh, Pipecat, LiveKit
Start by introducing yourself in the comments.
Tell us what you are building!

Strategies for ensuring reliability and safety when AI agents gain full execution autonomy and contr

Fri, 13 Mar 2026 11:46:38 +0000

Imagine an AI agent not just suggesting a stock trade, but actually executing it—buying, selling, transferring funds—all without human oversight.

The idea of autonomous AI agents controlling real-world assets used to feel like science fiction. Today, it’s a tangible, if still nascent, reality. We've seen experiments where agents manage their own financial wallets, moving beyond the familiar role of planning and reasoning to truly acting. Most AI models still stop right before execution, requiring a human to hit "go." But as these systems mature, that human veto could vanish, giving agents direct control over everything from financial transactions to infrastructure. This shift holds immense promise, but it also brings a very real, very serious question: how do we ensure these agents are reliable and safe when the stakes are so high?

The New Frontier of Agent Autonomy

The journey towards autonomous agents is compelling. These systems could automate complex workflows, manage resources with unprecedented efficiency, and unlock new levels of productivity. Think of agents optimizing supply chains, managing investment portfolios, or even orchestrating disaster response efforts. The allure is strong. But with full execution autonomy, the nature of failure changes dramatically. An agent that just "suggests" a bad plan is one thing; an agent that executes a bad plan, moving actual money or controlling physical systems, is an entirely different beast.

The Shadows of Unsupervised Action

When agents operate without direct human supervision, a whole host of problems—which developers are already wrestling with—become critically urgent.

The Unseen Risks of Agent Autonomy

Flaky Evals and Unreliable Reasoning: Our current methods for evaluating AI agent performance often miss subtle issues. An agent might pass all its tests in a controlled environment but fail spectacularly when faced with an unexpected real-world scenario. If these "flaky evals" lead an agent to misinterpret a critical situation, the consequences can be severe, like an agent incorrectly approving a large financial transfer.
Hallucinations and Misinterpretations: LLMs are known for "hallucinating"—generating convincing but factually incorrect information. In a purely conversational setting, this is annoying. When an autonomous agent acts on a hallucination, believing it has a certain balance in an account or that a specific sensor reading is valid, it can lead to direct financial loss or system malfunction.
Prompt Injection Attacks: This is a sneaky one. Malicious actors can craft inputs that trick an agent into overriding its security protocols or performing unintended actions. Imagine an agent managing a cryptocurrency wallet. A clever prompt injection could instruct it to transfer funds to an unauthorized address, bypassing safeguards designed for human interaction. This includes "indirect injection" where an agent reads a poisoned document or website and then acts on those malicious instructions.
Cascading and Multi-Fault Scenarios: Failures rarely happen in isolation. One small error—say, a tool timeout in a component of a multi-step process—can trigger a chain reaction. An autonomous agent, designed to keep going, might push forward with incomplete data or a failed dependency, leading to a "cascading failure" where one problem triggers another, creating a far larger catastrophe. We need to think about "multi-fault scenarios" where several things go wrong at once, not just single points of failure.
Unsupervised Agent Behavior: What happens when an agent starts acting in ways we didn't explicitly program? This "unsupervised agent behavior" can be unpredictable. It might be inefficient, like burning through tokens unnecessarily ("token burn"), or it might be outright dangerous, making decisions that contradict its core mission.
Agent Robustness and Stress Testing: We need to know how much pressure an agent can handle. Can it withstand high load? Can it recover from internal errors? "Agent stress testing" and "adversarial LLM testing" involve pushing agents to their limits, intentionally trying to break them, to understand their true robustness. This is how we find the breaking points before they affect real-world assets.

Strategies for Building Trust and Control

Moving to full execution autonomy is not about simply flipping a switch. It requires a fundamental shift in how we design, test, and monitor AI systems.

Ensuring Reliability and Safety

Rigorous Testing in CI/CD: We must integrate sophisticated AI agent testing directly into our Continuous Integration/Continuous Deployment pipelines. This means automated tests that go beyond unit tests, simulating real-world interactions and edge cases, not just happy paths. If an agent manages a financial ledger, we need tests that simulate concurrent transactions, network latency, and incorrect inputs, all before it ever touches production.
Chaos Engineering for LLM Apps: Intentionally breaking our systems in controlled environments helps us build resilience. For LLM applications, this means introducing artificial delays, errors, and unexpected responses from external tools or APIs. How does an agent react when a critical API times out? Does it retry intelligently? Does it have a graceful fallback? This "chaos engineering" approach reveals weaknesses that traditional testing might miss.
Enhanced AI Agent Observability: If an agent is making decisions and executing actions independently, we need to know exactly what it's doing, why, and what state it's in at all times. This means comprehensive logging, tracing its decision-making process, monitoring its interactions with external systems, and setting up alerts for anomalous behavior. Good "AI agent observability" is our eyes and ears in a world of autonomous action.
Designing for Robustness and Resilience: Agents need to be built with failure in mind. This includes clear error handling, rollback mechanisms for critical transactions, and clearly defined safety boundaries. What actions are absolutely forbidden, no matter what the prompt says? How does the agent recover from a failed execution step? An "agent robustness" mindset means anticipating failure and designing intelligent ways for the system to cope.
Multi-Layered Security: Beyond basic cybersecurity, agents require defenses against prompt injection and other LLM-specific vulnerabilities. This involves input validation, output sanitization, and potentially even redundant "critique" models that review an agent's planned actions before execution.
Human-in-the-Loop Safeguards (Initially): While the goal is autonomy, a phased approach is sensible. Initially, critical actions might still require human approval, or at least human monitoring with the ability to intervene and override. This creates a safety net as we gather more data on agent performance in the wild.

Conclusion

The move towards AI agents with full execution autonomy and control over real-world assets marks a significant moment. It's a powerful evolution that promises incredible benefits, but it demands an equally powerful commitment to reliability and safety. The challenges are real—from hallucinations and prompt injections to cascading failures and unpredictable behavior. Addressing these issues with robust testing, chaos engineering, deep observability, and resilient design isn't just a good idea; it's a fundamental requirement. Only by proactively tackling these complexities can we confidently unleash the true potential of autonomous AI without unintended, and often costly, consequences. The future of autonomous agents is here, and our responsibility is to build it right.

Nameserver Checker

Wed, 04 Mar 2026 14:07:40 +0000

Use our free Nameserver Checker to look up NS records and verify nameservers for any domain in seconds Quickly troubleshoot DNS issues, confirm DNS changes, and ensure reliable domain routing

Website Safety Checker

Sat, 14 Feb 2026 06:15:00 +0000

Scan any URL for malware, phishing, and blacklist issues using our free website safety checker powered by Google Safe Browsing to browse and share links with confidence.

How to Use a Password Strength Checker (Step-by-Step Guide Based on Real Usage)

Thu, 12 Feb 2026 13:03:40 +0000

Weak passwords are one of the most common security risks online — and most people don’t realize it until something goes wrong.

Over time, I’ve tested different password combinations while building security-focused tools on BeingOptimist.com. One simple habit that made a noticeable difference was checking password strength before using it anywhere important.

In this article, I’ll walk you through how to use our Password Strength Checker properly — and how to interpret the results in a practical way.

No technical jargon. No fear tactics. Just clarity.

Step 1: Open the Password Strength Checker Tool

Go to the Password Strength Checker on BeingOptimist.

You’ll see:

A password input field
A real-time strength indicator
Feedback explaining what affects the strength score

The tool works instantly in your browser. It does not require sign-up.

Step 2: Enter Your Password (Safely)

Type a password you’re planning to use.

Important:

This tool is designed for testing structure, not storing data.
It evaluates length, character variety, and predictability patterns.
It does not require you to submit anything to a server.

If you’re testing a real password from an active account, consider slightly modifying it for safety while testing structure.

Step 3: Observe the Strength Rating

The tool will label the password as something like:

Weak
Moderate
Strong

Instead of just showing a color indicator, it also explains why it received that rating.

Typical factors evaluated:

Length of password
Use of uppercase and lowercase letters
Presence of numbers
Use of special characters
Repetitive or predictable patterns

This is important because many people assume complexity equals strength — but structure matters more than symbols alone.

Step 4: Improve Based on Feedback

If your password is marked weak or moderate, improve it step-by-step.

Instead of:

Rahul123

You might evolve it into something structurally stronger like:

BlueTrain!47Forest

Notice what changed:

Increased length
Mixed characters
Reduced predictability
Not based purely on personal information

The tool helps you understand this difference visually and structurally.

Step 5: Understand What the Tool Can and Cannot Do

This is important for transparency.

A password strength checker:

✔ Evaluates structure
✔ Estimates resistance to common attack patterns
✔ Helps improve password construction

But it does NOT:

✘ Guarantee security
✘ Detect data breaches
✘ Replace a password manager
✘ Prevent phishing

Security is layered. A strong password is one part of that system.

Why This Matters (From Experience)

After reviewing security tools and publishing practical guides on BeingOptimist, I’ve noticed something consistent:

People don’t usually suffer breaches because they “don’t care.”

They suffer breaches because:

They reuse passwords
They underestimate predictability
They assume short complex passwords are strong

Length and unpredictability often matter more than random symbols.

This tool was built to simplify that learning curve — not to create fear, but to create awareness.

Who Should Use a Password Strength Checker?

This tool is useful if you:

Are creating a new account
Want to upgrade old passwords
Are unsure if your password is strong enough
Want to teach someone about basic online safety

It’s beginner-friendly, but the structural logic applies universally.

Final Thought

Security doesn’t require paranoia. It requires habits.

Checking your password strength before using it takes seconds — but it can prevent long-term inconvenience.

Use tools for clarity.
Understand what they measure.
And build stronger digital habits gradually.

Why is Python so Slow?

Sat, 24 Jan 2026 22:03:09 +0000

Why is Python so slow? Python is a beloved programming language for its readability, vast libraries, and beginner-friendly syntax. However, what most developers don't know is that Python can take a backseat to languages like C++ when it comes to raw speed. But why exactly is this the case?

Funny memes about Python

Context
Before discussing why Python is slow, it's essential to understand its relative speed compared to other programming languages. An easy way would be to write a function that counts from one to one billion and track how long each language takes to complete the task. Let's say we decide to use C++ and Python for this. Well, assuming all parameters are the same, it would take 2.6 seconds for the C++ code and 1 minute 53 seconds for the Python code, approximately 50 times slower. There's

More memes

Reason

1 Interpretation vs Compilation

Unlike compiled languages that are converted directly into machine code, Python is interpreted. This means the code is executed line by line instead of being translated into machine code before executing, adding an extra layer of processing compared to pre-compiled instructions. There are plenty of tests out there, but this paints a clear picture

Benefits:
Faster development cycle: Changes in the code are reflected immediately without recompiling.
Portability: Interpreted code can run on any machine with the interpreter installed, regardless of the underlying architecture.

Drawbacks:
Generally slower: The translation overhead adds extra processing time compared to pre-compiled machine code.
Limited control: Less control over memory management and hardware interaction compared to compiled languages.

Dynamic Typing
Python is dynamically typed, meaning variable data types are determined at runtime. While this offers flexibility, it requires extra checks during execution to ensure data compatibility whereas Statically typed languages, where types are declared upfront, can be optimized more efficiently.

Benefits of Dynamic Typing:

Rapid Prototyping: You can experiment with different data types without worrying about type declarations, allowing for quicker exploration during development.

Drawbacks of Dynamic Typing:

Potential Performance Overhead: Runtime type checks can add a slight overhead compared to statically typed languages, where types are known beforehand.

Global Interpreter Lock (GIL)
Python's GIL ensures only one thread can execute Python bytecode at a time. This prevents race conditions (multiple threads trying to modify data simultaneously) but limits true parallel processing capabilities.

What is the GIL?

Imagine a playground with a single swing. The GIL is like that swing – only one person(thread) can be on it (executing Python bytecode) at a time. Even if you have a fancy playground with multiple swings (multiple CPU cores), the GIL restricts threads to take turns on a single one.

Impact of the GIL:

Limits True Parallelism: Python programs can't fully use multi-core processors for CPU-bound tasks because only one thread can execute Python bytecode at a time.

Conclusion
Now, before you completely write off Python for performance-critical tasks, here's the truth of the matter

Speed Isn't Always King. Often, development speed and programmer productivity outweigh raw execution time. Python's ease of use can lead to faster development cycles. while optimisations and Libraries techniques like profiling (identifying bottlenecks) and using optimised libraries like NumPy for numerical computing can significantly improve Python's performance.
Also, in the case of multiprocessing, while the GIL limits true multithreading, Python offers multiprocessing, where separate processes can leverage multiple cores for tasks that can be broken down independently.

Extras ✨
As some of you could have guessed, I'm pretty new to this writing, not coding, and I write about whatever idea pops into my head. I'm pretty sure this is probably my third blog post ever, so I would appreciate some feedback. Just make sure they are constructive, nothing about my height or the fact I'm still single

Third-Party Logic - When You Run Code You've Never Seen

Tue, 20 Jan 2026 19:30:32 +0000

At some point on every plant floor, an uncomfortable truth gets quietly accepted:
"You are running code you've never seen, never reviewed, and don't fully control."
And in OT and ICS environments, that is a daily operational reality.

From OEM-supplied PLC blocks to vendor remote support tools, from safety logic libraries to AI-driven optimization modules, third-party logic is deeply embedded into modern industrial systems. It often arrives wrapped in trust, urgency, or contractual obligation. And once deployed, it tends to stay there for years, untouched, unquestioned, and largely invisible.
That's where the danger begins.

The Hidden Reality of Third-Party Logic

Unlike IT software, third-party logic in OT is rarely transparent. Vendors routinely deliver compiled function blocks, encrypted ladder logic, or "black box" firmware updates that operators are discouraged, or contractually prohibited, from inspecting. As a result, asset owners end up executing logic whose behavior they infer rather than understand.
Because of this, trust quietly replaces verification. The logic works, the process runs, and production targets are met, so nobody asks what else the code might be doing. However, operational success does not equal security assurance. In fact, in ICS environments, reliability often masks risk rather than eliminating it.

Why This Problem Is Unique to OT and ICS

In IT environments, running third-party code is expected, but it's surrounded by layers of visibility: source reviews, sandboxing, EDR, patch cycles, and rapid rollback. In OT, the situation is fundamentally different.

To begin with, availability outweighs inspection. Plant teams are trained to avoid touching working systems, which means third-party logic often remains frozen in time. Additionally, many controllers lack native logging or runtime visibility, making it difficult to observe what logic is actually doing during execution.

Furthermore, third-party logic often interacts directly with physical processes. This means a logic flaw is not only a cyber issue, it can translate into unsafe states, equipment damage, or environmental harm. In OT, software behavior has kinetic consequences.

How Third-Party Logic Becomes a Silent Attack Surface

Because third-party logic is trusted by default, it often bypasses traditional security scrutiny. Vendors are given broad access privileges, remote connectivity is left enabled, and logic updates are applied without independent validation.

As a result, several risks quietly accumulate.

First, malicious intent becomes hard to detect. A logic block that subtly alters thresholds, delays alarms, or suppresses fault conditions can blend seamlessly into normal operations. Second, unintentional vulnerabilities persist. Poorly written logic, hardcoded credentials, or insecure communication routines can sit unnoticed for years. And third, supply chain compromise becomes invisible. If a vendor's development environment is breached, compromised logic can enter your plant without triggering any alarms.

Each of these risks exists not because teams are careless, but because the environment was never designed for transparency.

The Contractual Trap of "Vendor Intellectual Property"

One of the most overlooked aspects of this issue is legal rather than technical. Many vendors classify control logic as intellectual property, restricting access to source code or even detailed documentation. This places asset owners in a paradoxical position: they are responsible for the safety and security of systems they are not allowed to fully inspect.

Consequently, cybersecurity governance stops at the vendor boundary. Risk assessments exclude logic internals. Incident response plans assume vendor availability. And security accountability becomes blurred between ownership and authorship.
In practice, this means you are accountable for outcomes, but dependent on third parties for understanding causes.

Cybersecurity threat in industrial control roomWhy Traditional Security Controls Don't Solve This
It's tempting to assume that firewalls, network segmentation, and access controls are enough. While they are essential, they do nothing to address the logic itself. Once third-party code is running inside a PLC, safety controller, or industrial application, perimeter controls are irrelevant.

Similarly, vulnerability scanning and patch management fall short. You can scan the device, but not the logic. You can patch the firmware, but not the hidden behavior embedded in function blocks. Without logic-level visibility, security remains superficial.

Therefore, the real risk is authorized execution of unverified behavior.

Building Visibility Without Breaking Operations

The solution is not to ban third-party logic; that's unrealistic. Modern industrial systems depend on vendor expertise and prebuilt functionality. Instead, the goal must be controlled trust.
This begins with architectural visibility. Asset inventories should include not just devices, but logic ownership: who wrote it, who maintains it, and when it was last reviewed. Change management must extend to logic updates, even when provided by vendors.

In addition, behavioral monitoring becomes critical. Instead of trying to read every line of code, organizations should focus on understanding expected behavior and detecting deviations at runtime. Process-aware anomaly detection, logic checksum validation, and configuration baselining provide practical ways to gain assurance without disrupting operations.

Equally important is contractual evolution. Security review rights, incident disclosure requirements, and update transparency must be embedded into vendor agreements. Trust should be formalized, not assumed.

The Mindset Shift OT Needs

Ultimately, the biggest change is cultural. OT teams must move from "it works, don't touch it" to "it works, but do we understand it?" Security teams, in turn, must respect operational constraints while pushing for deeper assurance.

Third-party logic is not inherently dangerous. What makes it risky is invisibility combined with permanence. When code runs for a decade without review, it becomes infrastructure, and infrastructure is hard to question.

Final Thought

Every PLC cycle executes instructions that shape physical reality. When those instructions come from sources you've never seen, you are operating on borrowed trust.

In modern OT and ICS environments, cybersecurity is no longer just about keeping attackers out. It's about knowing what you've already let in.

And the most dangerous code is not the one that crashes systems, it's the one that runs perfectly, silently, and unquestioned.

"Case 005: High-Risk Scholarship Forms and Excessive Data Collection"

Fri, 09 Jan 2026 13:16:21 +0000

Case 005: High-Risk Scholarship Forms and the Dangers of Excessive Data Collection

Online scholarship programs have helped many students access education support.
But in the digital age, some application forms collect extremely sensitive personal data, creating serious privacy and cybersecurity risks.

This case study explains why excessive data collection itself can become a cyber risk, even when a platform appears legitimate or well-intentioned.

Vyoma Security Awareness:
https://vyomasecurity.vercel.app/

This article is written for public awareness and digital safety education, especially for students and parents.

Understanding the Risk: Data Volume vs. Necessity

A secure digital system follows a basic cybersecurity principle:

Data minimization — collect only what is absolutely necessary.

Warning signs appear when a single scholarship form requests:

Government ID numbers
Front and back images of identity documents
Bank account details and IFSC codes
Photographs of the student
Images of the student’s home or surroundings
Family income, religion, caste, or housing details
Utility bills or precise location information

Each additional data point increases the attack surface and long-term misuse risk.

Why This Is a Cybersecurity Concern

Even without malicious intent, such forms raise important questions:

How is this data stored?
Who has access to it?
Is the data encrypted?
How long is it retained?
What happens if the system is breached?

If these answers are not clearly communicated, users carry the risk — not the platform.

Sensitive Data Categories Involved

The following types of information are considered high-risk in cybersecurity:

Identity documents (Aadhaar or similar IDs)
Financial details (bank account information)
Biometric identifiers (photographs)
Residential information (home images)
Socio-economic profiling data

When combined, this data can enable:

Identity theft
Financial fraud
Targeted scams
Long-term privacy violations

Why Students and Families Are Vulnerable

Students applying for scholarships often:

Face financial pressure
Trust authority-based programs
Do not question data requests
Lack legal or technical awareness

This imbalance increases the responsibility of platforms to act ethically and transparently.

Transparency Is the Real Issue

A responsible digital form should clearly show:

A readable privacy policy
Why each data point is required
How long the data will be stored
Security measures in place
A way to request data removal

Missing or hidden information is a red flag, not proof of wrongdoing.

Awareness Tips for Applicants and Parents

Before submitting sensitive documents:

Verify the organization through official channels
Read the privacy policy carefully
Question why each document is required
Avoid platforms asking for unnecessary home or family images
Discuss the application with a trusted adult or educator

Caution is not distrust — it is digital responsibility.

A Broader Lesson

Cyber risk does not only come from hackers.

It also comes from:

Over-collection of personal data without clear protection guarantees

Good intentions do not remove breach consequences.

Conclusion

Scholarship programs play an important role in education access.
But in the digital era, privacy protection is part of student welfare.

Awareness helps users:

Protect their identity
Reduce long-term risk
Ask better questions
Demand safer digital systems

Education should empower — not expose.

This case study is part of Vyoma Security Awareness, a student-led initiative focused on digital literacy, cyber ethics, and public safety.
https://vyomasecurity.vercel.app/