xx_ns

Both projects have the same author.

I got the same vibe from

These are asciinema recordings of real terminal sessions, rendered as text rather than video. Playback caps idle pauses at two seconds and changes nothing else.

Thanks? This sounds like it's the LLM's response to the prompter, not something you should display on the page itself...

I think this is a slightly different problem. The absence of an optional field, if that's a legal state, is meaningful every time you use the type, so you encode it on the field: `phone: ValidPhoneNumber | null`. When it's not null you're still guaranteed a valid phone number. When it is null, that's a legal state you have to handle and which is domain logic, not validation you forgot to do.

The combinatorial explosion you're picturing only shows up if you make a separate type per combination of present fields, but you don't need to. An independent optional field stays one `T | null`. You only reach for distinct types when fields are correlated and present together because they represent a state, and then it's a discriminated union on a status field, which is N states, not 2^N.

This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective.

https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

That would've been a cool PoC to work on as well, but seems a fair bit more complicated than the BadUSB-style attack I ended up doing. Would've had to do a lot more RE to figure out how to interact with the whole microphone subsystem, I think.

A probe packet contains the MAC address as well as the list of all the past Wi-fi networks that your device has tried to join before, which can reveal a lot about you!

Generally, most modern devices send broadcast/wildcard probes precisely to avoid leaking the PNL. From what I know, directed probes are only sent for hidden APs.

From personal experience, there have been a few papercuts (mostly trying to figure out why runners aren't picking up jobs), but it isn't too hard to debug and the CI format is simple. When it works, it works well enough. It uses a similar workflow as GitHub actions. Some, but not all, actions are even interchangeable or at least portable from GitHub without much fuss.

I'm not from the US, so I hope you excuse my ignorance, but who exactly voted for mass surveillance or AI cameras?

I wish my city only had a single case like that. Unfortunately, in Tallinn, it is extremely common that a bike path is suddenly routed onto the curb, and that's when you're lucky. For some paths, the path just... ends, and you suddenly find yourself right in the middle of car traffic. Unfortunately, the city leadership is anti-bike and pro-car, and it shows in the infrastructure.

Paths where pedestrians and bikers (and other light transportation vehicles) are mixed are overwhelmingly common.

According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.

At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.

Usable enough to run a Linux DE on it! I did so on my blog: https://nns.ee/kindle

At least it's still right in spite of being down.

Good question! I wasn't too concerned about this, because the only way you could even interact with the OS where the server was running was via HTTP requests, which are fairly limited in nature. The OS or kernel itself wasn't directly exposed per se.

Just a little play on the recent HN post: https://news.ycombinator.com/item?id=46016902

Project that I did a few years ago. You might also be interested in the retrospective where I detail what all went wrong: https://blog.nns.ee/2025/04/01/modem-blog-retrospective/

Apologies, that's what I meant to say. I blame that on my lack of coffee today, my bad.

The author linked to the repo and the code is at https://github.com/seritools/castrol-honda-dinput-fix/blob/m...

Seems pretty straightforward. They hook DirectInputCreateA() and pass their own device enumeration wrapper with the offending flag removed.

I appreciated the footnote on filesize optimization as someone who's constantly trying to compulsively generate the smallest binaries possible.

Interesting article, thank you.

Am I missing something here? Colonial merchant ledgers and 18th-century accounting practices have been extensively digitized and discussed in academic literature. The model has almost certainly seen examples where these calculations are broken down or explained. It could be interpolating from similar training examples rather than "reasoning."

Their other blog post[1] shares some more information which seems like it's relevant.

From the post:

then i found this one:

https://juice.hackclub.com/api/get-roommate-data?email=dont@...

yep. no auth. just an email parameter. and what did it return?

full names. emails. phone numbers. flight receipts. all just by passing an email address in a URL.

i reported it through their security bounty program, made a bug fix pr (because apparently that's how you get things done around here), and maybe made the slight mistake of sharing the vulnerable endpoint in that group chat - which less than 10 people saw, for what that's worth.

The author then proceeds:

their security bounty program states minimum payouts for this kind of thing start around $150. but exposing passport numbers (which are classed as government documents) should bump it up significantly. apparently "responsible disclosure" means "don't tell anyone, even in a private chat" so they docked the entire payout.

I'm not sure why they're being seemingly sarcastic about responsible disclosure. Yes, responsible disclosure absolutely means that you disclose this to the vendor before disclosing it to anyone else. As someone who works as a penetration tester and security researcher (both at work and in my free time), in my opinion, there should be no confusion about what responsible disclosure is. You disclosing the vulnerability in public before the vendor has had the chance to fix or apparently even triage it is not "responsible disclosure" or a "slight mistake".

[1] https://kys.llc/blog/oops-leaked-your-passport

I pentest network devices (amongst other things) for a living, and the way these usually work is that they have dnsmasq running in the background and to accept user config values, templating is used to generate dnsmasq-specific configuration files which are then fed into dnsmasq. I cannot overstate how common this method is.

Some devices do this more securely than others. If you're able to inject newlines, it's highly likely that you can already achieve command execution by injecting directives. I wrote a bit about this technique here: https://blog.nns.ee/2025/07/24/dnsmasq-injection-trick/ (sorry for the self-plug). I think it's up to the device vendor to do this securely and not a concern for dnsmasq.

However, in this case, I feel like the concern is elsewhere and not the sole responsibility of the device vendors. Even if the vendor does templating securely, the vulnerable config options could still trigger the bug in dnsmasq itself and give some advantage to the attacker. Assuming the vulnerabilities themselves are legit, I'm finding it difficult to classify these issues as "bogus".

Not that I know of. We're a pretty tech-forward country, so it's hard to imagine anyone making physical carbon copies these days.

I'm in Estonia, and my bank issues debit and credit cards that are definitely embossed.

It acted as a proxy for the real npm site, which was the one to send the request, intercepting the code when the user inserted it.

And we get back to the original point of the article (sort of). Opening a magic link should authenticate the user who opened the magic link, not the attacker who made the application send the magic link.

bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in all likelihood using bcrypt.

Works over here.

Yes.

I'm a security researcher - no quotes. I write detailed, highly technical write-ups for all of the issues I discover, including reproduction steps, root cause analysis and suggestions for fixes. I follow all responsible disclosure guidelines + any guidelines that the company or entity might have for security disclosures.

It's disheartening when you put this amount of effort into it, it gets silently patched, and you get no recognition or even a "thank you". But I don't let it bother me too much. I'm doing this research mostly for myself and because I find it interesting. The fact that I'm disclosing the issues is me being a good citizen, but I shouldn't expect a pat on the head for every issue I disclose.

Being ignored always sucks. But it's still infinitely better than doing all of the above and being threatened with a lawsuit (which has, unfortunately, happened as well).

Thanks!

The slow startup times have usually been an xdg-desktop-portal issue for me in the past, might be worth looking into.

How have your experiences with this setup been so far? Any major pain points?

I'm not sure if I miss IRC, or the simpler times that were when I was actively on IRC. Maybe it's a bit of both. But there's definitely some niceties in modern messaging applications that you can't get in IRC.