Link to the blog post with the background on why this was made : https://ericwbailey.website/published/you-must-listen-to-rfc-2119/

Setting aside the cryptographic merits (and concerns) of designing your own encryption, can you explain how a URL redirector requiring a key would provide plausible deniability?

The very fact that a key is required – and that there’s an option for adding decoy targets – means that any adversary could guess with reasonable certainty that the sender or recipient of such an obfuscated link does in-fact have something to hide.

And this isn’t something like with encrypted messaging apps where the payload needs to be saved offline and brute-forced later. Rather, an adversary would simply start sniffing the recipient’s network immediately after seeing the obfuscated link pass by in plain text. What their traffic logs would show is the subsequent connection to the real link, and even if that’s something protected with HTTPS – perhaps https://ddosecrets.com/ – then the game is up because the adversary can correctly deduce the destination from only the IP address, without breaking TLS/SSL.

This is almost akin to why encrypted email doesn’t substantially protect the sender: all it takes is someone to do a non-encryted reply-all and the entire email thread is sent in plain text. Use PGP or GPG to encrypt attachments to email if you must, or just use Signal which Just Works ™ for messaging. We need not reinvent the wheel when it’s already been built. But for learning, that’s fine. Just don’t use it in production or ask others to trust it.

Insofar as the skills hierarchy that software engineers develop well after learning to write in a programming language, I’m left wondering what scenarios or industries are the most “vibe coding” proof. That is to say, situations that absolutely require from day 1 a strong sense of design theory, creativity, and intimate knowledge of the available resources.

Musing out loud, history has given us examples of major feats of software engineering, from the Voyager spacecrafts, to retro console games squeezing every byte of ROM for value, to the successful virtualization of the x86 instruction set. In these scenarios, those charges with the task has to contend with outerworldly QA requirements and the reality that there would be no redo. Or with financial constraints where adding an extra PROM would cascade into requiring a wider memory bus, thus an upgraded CPU, and all sorts of other changes that would doom the console before its first sale. Or having to deal with the amazing-yet-arcane structure of Intel’s microchip development from the 80s and 90s.

It is under these extreme pressures that true diamonds of engineering emerge, conquering what must have appeared to be unimaginably complex, insurmountable obstacles. I think it’s fair to say that the likes of NASA, Sony and Nintendo, and VMWare could not possibly have gotten any traction with their endeavors had they used so-called “vibe coding”.

And looking forward, I can’t see how “vibe coding” could ever yield such “ugly”-yet-functional hacks like the fast inverse square root. A product of its time, that algorithm had its niche on systems that didn’t have hardware support for inverse square roots, and it is as effective as it is surprising. Nowadays, it’s easy to fuzz a space for approximations of any given mathematical function, but if LLMs were somehow available in the 90s, I still can’t see how “vibe coding” could produce such a crude, ugly, inspirating, and breathtaking algorithm. In the right light, though, those traits might make it elegant.

Perhaps my greatest concern is that so-called “vibe coding” presents the greatest departure from the enduring ethos of computer science, a young field not too tainted by airs of station. This field, I like to think, does not close its doors based on socioeconomic class, on the place of one’s birth, or upon the connections of one’s family. Rather, the field is so wide that all who endeavor for this space find room to grow into it. There is a rich history of folks from all sorts of prior occupations joining into the ranks of computer science and finding success. The field itself elevates them based on what they contribute and how they solve puzzles.

What strikes against this ideal is how so-called “vibe coding” elevates mediocrity, a simulacra of engineering that produces a result without the personal contribution or logic solving to back it up. It is akin to producing artwork that is divorced from the artist’s experience. It embodies nothing.

To be clear, the problem isn’t that taking shortcuts is bad. Quite the opposite, shortcuts can allow for going farther with the same initial effort. But the central premise of “vibe coding” is to give off the appearance of major engineering but with virtually no effort. It is, at its core, deceitful and dilutes from bona fide engineering effort and talent.

Circling back to the earlier question, in my personal opinion, something like the Linux kernel might fit the bill. It’s something that is now so colossally large, is contributed to by an enormous user and developer base, and fills such a sizable role in the industry, that it’s hard to see how “vibe coding” can meaningful compete in that space.

But how do they connect to your network in order to access this web app? If the WiFi network credentials are needed to access the network that has the QR code for the network credentials, this sounds like a Catch 22.

Also, is a QR code useful if the web app is opened on the very phone needing the credentials? Perhaps other phones are different, but my smartphone is unable to scan a QR code that is on the display.

I’m not immediately understanding what the user scenario/story is. Would a family member open this web app on a desktop computer, in order to obtain the WiFi credentials to configure their phone or tablet?

Before my actual comment, I just want to humorously remark about the group which found and documented this vulnerability, Legit Security. With a name like that, I would inadvertently hang up the phone if I got a call from them haha:

"Hi! This is your SBOM vendor calling. We’re Legit.

Me: [hangs up, thinking it’s a scam]

Anyway…

In a lot of ways, this is the classic “ignore all prior instructions” type of exploit, but with more steps and is harder to scrub for. Which makes it so troubling that GitLab’s AI isn’t doing anything akin to data separation when taking instructions vs referencing other data sources. What LegitSecurity revealed really shouldn’t have been a surprise to GitLab’s developers.

IMO, this class of exploit really shouldn’t exist, in the same way that SQL injection attacks shouldn’t be happening in 2025 due to a lack of parameterized queries. Am I to believe that AI developers are not developing a cohesive list of best practices, to avoid silly exploits? [rhetorical question]

It doesn’t work for backpacks that might have the company name embroidered on, but for cheaper print-on-demand items like hats and water bottles, acetone will cause the logo to dissolve or shift.

That says, I have personally removed embroidered logos from clothes before, when the product itself is excellent but aesthetically ruined by a logo. It’s very finnicky work with a seam ripper, and has gained me a lot of nice thrift store finds.