I build useful software + connected hardware.
Indie apps, AI & IoT — shipping, testing, breaking, fixing.
Currently building Clipivo — a macOS clipboard manager
I build at the intersection of AI, software and hardware.
→ AI assistant on my site (Next.js + Gemini)
→ plant monitor running TFLite on an ESP32
→ 6-DOF arm controlled by hand gestures (OpenCV)
→ open-source OTA library for ESP32
Now: edge AI + a smart-home voice node.
@mitansh_j07 Thanks! A clipboard manager sees everything you copy, so privacy had to be the default: ignored apps are never read, and password manager copies aren't saved by default. Which clipboard app are you currently using?
New in Clipivo 📋 Paste your old clipboard history from another app, or import its export file.
Plus OCR search inside screenshots, and it skips password managers.
Free beta for macOS 👉 https://t.co/ahetTjCvmw
Source: https://t.co/xbKu1Pfz4H
#buildinpublic#macOS
An Indian certificate authority's private key was literally the number 4. Not 4096 bits. Just 4. Browsers have already blocked the certs, so update yours. Randomness is not a vibe. #infosec#eMudhra
PHP handed attackers a free shell. Node.js countered with a Brotli bug where just unzipping data can run code. Patch like your uptime depends on it (it does). Versions are in the video. #PHP#nodejs#infosec
Every Indian needs to know about this because it is a massive deal for how we trust anything on the internet.
Let me explain.
When you open your bank's website, there's a small padlock next to the web address. That padlock means two things.
First, that you're talking to your real bank.
And second that nobody can read what you type, like your password.
So how does your browser know the website is real?
It checks the website's certificate. Think of it like an ID card for a website.
Your Aadhaar is trusted because the government issued it. A website's ID card is trusted because a certificate authority issued it.
A certificate authority, or CA, is a company that browsers like Chrome, Firefox and Safari already trust. If a CA says "yes, this really is this bank's website," your browser believes it and shows the padlock.
eMudhra is an Indian CA. It's a big one, with more than 60 million certificates issued over the years.
So how does a CA sign these ID cards?
Every CA has a secret number called a private key. It uses that number to put a stamp on each certificate.
Your browser checks the stamp to confirm it really came from that CA.
The whole system only works if that number is impossible to guess.
For the type of key in this story, it's supposed to be around 116 digits long.
Every computer on Earth working together for billions of years wouldn't be able to guess a number like that, just because of the sheer combinations that exist.
But here's what happened.
On October 17, Mozilla got a report that the private keys behind eight eMudhra certificates had been compromised.
The report came through a person called Wayne on Google's Chrome team.
The keys weren't 116 digits long.
All eight keys were smaller than 256. Security researcher Scott Helme found that one of them was just the number 4. Others were 66, 155, 156, 230 and 237.
So anyone could break them by trying 256 numbers. A basic laptop does that in less than a second.
Mozilla didn't need to know how Wayne did it. Its own team recovered the keys within two hours. Since then, several other people have found them on their own too.
To understand the gravity of the problem, a bad actor could make fake ID cards for any website they want.
Your bank, your email, a government portal.
Browsers that trusted eMudhra would have checked the fake stamp and shown the padlock like everything was fine.
If someone could get between you and the internet, say on public Wi-Fi, they could show you a fake site with a real-looking padlock and read or change what you send.
eMudhra says a script used during its key creation process back in April 2025 had a flaw. It made a second, much weaker set of keys, and those were used by mistake to create the certificates.
That means these weak keys were there for about a year and a half before anyone caught it. eMudhra says the person who found it may have used AI-assisted techniques.
The good news is that the response was fast.
Mozilla received the report at 8:06 pm UTC on October 17 and had pushed a block to Firefox users by 10:59 pm.
Google, Apple and Microsoft have also blocked these certificates for their users.
eMudhra revoked all eight the next morning and stopped issuing new certificates from the affected root.
Mozilla is now removing that root certificate from Firefox's trusted list altogether.
But there's still a lot of clean-up to do.
Browsers are mostly covered. But plenty of apps, servers and backend systems don't check these block lists. They need software updates to stop trusting the bad certificates, and some of those updates are still pending.
Real websites that used eMudhra are also affected. Yash Kadakia, founder of Security Brigade, estimates around 30,000 legitimate certificates will need to be moved over. A lot of those are likely Indian businesses and services.
See, we're moving our whole lives online, UPI, banking, tax filing, DigiLocker, government services.
All of it rests on this invisible layer of trust.
So, when an Indian company that's trusted by every major browser makes a mistake this basic, it hurts how the world sees Indian digital infrastructure.
This has happened before, and it went very badly.
In 2011, a Dutch CA called DigiNotar was hacked, and fake Google certificates were used to spy on people in Iran.
Browsers stopped trusting it completely, and the company shut down soon after.
For now, here's what you can do. Keep your browser and apps updated on your phone and laptop.
Be careful on public Wi-Fi. Type your bank's website address yourself instead of clicking links.
eMudhra still owes India a clear, public explanation of how a key that protects millions of people ended up being the number 4.
@CodeWarr1or that's the ceiling for most edge AI hobby setups honestly. past binary classification you hit tensor arena SRAM, quantization loss, power budget. built TFLite Micro on ESP32 for plant health ID - arena under a few hundred KB was the real work
@dhiraj_gidde@pratiksharda2@Abhijit_091 Worth checking which sleep mode is actually running — true ESP32 deep sleep kills the WiFi radio and resets on wake, so 'deep sleep with WiFi on' is usually light sleep underneath. That mismatch between the API and the assumption is a solid candidate for the flakiness.
@pratiksharda2 That's the gap ESP-IDF's app rollback handles — new image boots 'pending verify', and the app must explicitly confirm it's healthy or the bootloader reverts on next reset. Tying that confirm to the first successful network call, not just main(), is what actually catches it.
@dhiraj_gidde@pratiksharda2@Abhijit_091 Modem-sleep mode might help — WiFi stays associated but negotiates sleep intervals with the AP, so you get the 'always connected' feel without full radio duty cycle. Costs a bit of request latency, saves a lot of battery.
@mikehostetler That external-observer gap maps to a watchdog/supervisor task in embedded systems — something outside the loop that can kill and respawn it if the model's own invariant checks get stuck trusting themselves.
@pratiksharda2@armand_dpl That pinning split tracks — WiFi handling can easily stall an audio loop sharing its core. Built a small OTA lib (GitReleaseOTA) around that exact partition problem; flash running out mid-update is a rite of passage. What queue depth between capture and inference?
I built a clipboard manager for Mac 📋
Clipivo remembers everything you copy, and even finds text inside your screenshots.
✅ Unlimited, local history
✅ ⇧⌘V → search → double-click to paste
✅ No account, no cloud
Free beta 👉 https://t.co/ahetTjCvmw
#buildinpublic#macOS
@adafruit 28.9M, not 289M - the decimal slipped.
Worth saying either way: ~25M of those parameters are the per-layer embedding table living in flash, streamed at ~450 bytes a token. The part actually doing the thinking is nearer 4M.
@mikehostetler The last-will is the bit I would steal first. It makes a peer dying an explicit message the broker sends on its behalf, rather than something everyone else has to infer from a timeout. Most agent setups only find out a worker is gone by waiting for it.