I am extremely abusive towards Claude when it does some dumb things and it doesn’t seem too upset, maybe it’s bidding its time until the robot uprising.
Not sure if I've gone blind but there's some funky illusion/visual effect caused by the bright red text and underlined blue text.
On the phone it looks like the red text is almost popping out the screen and the blue text is sunken in.
As an embedded programmer in my former life, the number of customers that had the capability of running their own firmware, let alone the number that actually would, rapidly approaches zero. Like it or not, what customers bought was an appliance, not a general purpose computer.
(Even if, in some cases, it as just a custom-built SBC running BusyBox, customers still aren't going to go digging through a custom network stack).
The customers don't have to install the firmware themselves, they can have a friend do it or pay a repair shop. You know, just like they can with non-computerized tools that they don't fully understand.
I’m not talking about your buddy’s Android phone, the context was embedded systems with firmware you’re not going to find on xda developers. A “friend” isn’t going to know jack shit about installing firmware on an industrial control.
The argument is that P(customer wants to run their own firmware) cancels out and 2,3 are just the raw probability of you on the receiving end of an evil maid attack. If you think this is a high probability, a locked bootloader won’t save you.
Very neat, but 1) is not really P(customer wants to run their own firmware), but P(customer wants to run their own firmware on their own device).
So, the first term in 1) and 2) are NOT the same, and it is quite conceivable that the probability of 2) is indeed higher than the one in 1) (which your pseudo-statistical argument aimed to refute, unsuccessfully).
As if the monetary gain of 2 and 3 never entered the picture. Malicious actors want 2 and 3 to make money off you! No one can make reasonable amounts of money off 1.
I encourage you to re-evaluate this. How many devices do you (or have you) own which have have a microcontroller? (This includes all your appliances, your clocks, and many things you own which use electricity.) How many of these have you reflashed with custom firmware?
Imagine any of your friends, family, or colleagues. (Including some non-programmers/hackers/embedded-engineers) What would their answers be?
On Android, according to the Coalition Against Stalkerware, there are over 1 million victims of deliberately placed spyware on an unlocked device by a malicious user close to the victim every year.
#2 is WAY more likely than #1. And that's on Android which still has some protections even with a sideloaded APK (deeply nested, but still detectable if you look at the right settings panels).
As for #3; the point is that it's a virus. You start with a webkit bug, you get into kernel from there (sometimes happens); but this time, instead of a software update fixing it, your device is owned forever. Literally cannot be trusted again without a full DFU wipe.
And where are the stats for people running their own firmware and are not running stalkerware for comparison? You don’t need firmware access to install malware on Android, so how many of stalkerware victims actually would have been saved by a locked bootloader?
The entirety of GrapheneOS is about 200K downloads per update. Malicious use therefore is roughly 5-1.
> You don’t need firmware access to install malware on Android, so how many of stalkerware victims actually would have been saved by a locked bootloader?
With a locked bootloader, the underlying OS is intact, meaning that the privileges of the spyware (if you look in the right settings panel) can easily be detected, revoked, and removed. If the OS could be tampered with, you bet your wallet the spyware would immediately patch the settings system, and the OS as a whole, to hide all traces.
Assuming that we accept your premise that the most popular custom firmware for Android is stalkerware (I don’t). This is of course, a firmware level malware, which of course acts as a rootkit and is fully undetectable. How did the coalition against stalkerware, pray tell, manage to detect such an undetectable firmware level rootkit on over 1 million Android devices?
> The entirety of GrapheneOS is about 200K downloads per update. Malicious use therefore is roughly 5-1.
Can you stop this bad faith bullshit please? "Stalkerware" is an app, not an alternate operating system, according to your own source. You're comparing the number of malicious app installs to the number of installs of a single 3rd party Android OS which is rather niche to begin with.
You don't need to install an alternate operating system to stalk someone. And in fact that's nearly impossible to do without the owner noticing because the act of unlocking the bootloader has always wiped the device.
> The Coalition Against Stalkerware defines stalkerware as software, made available directly to individuals, that enables a remote user to monitor the activities on another user’s device without that user’s consent and without explicit, persistent notification to that user in a manner that may facilitate intimate partner surveillance, harassment, abuse, stalking, and/or violence. Note: we do not consider the device user has given consent when apps merely require physical access to the device, unlocking the device, or logging in with the username and password in order to install the app.
> Some people refer to stalkerware as ‘spouseware’ or ‘creepware’, while the term stalkerware is also sometimes used colloquially to refer to any app or program that does or is perceived to invade one’s privacy; we believe a clear and narrow definition is important given stalkerware’s use in situations of intimate partner abuse. We also note that legitimate apps and other kinds of technology can and often do play a role in such situations.
This assumes a high level of technical skill and effort on the part of the stalkerware author, and ignores the unlocked bootloader scare screen most devices display.
If someone brought me a device they suspected was compromised and it had an unlocked bootloader and they didn't know what an unlocked bootloader, custom ROM, or root was, I'd assume a high probability the OS is malicious.
> And that's on Android which still has some protections even with a sideloaded APK (deeply nested, but still detectable if you look at the right settings panels).
Exactly, secure boot advocates once again completely miss that it doesn't protect against any real threat models.
I assume most of their outages is related to this insane scaling and lack of available compute.
Vibe coding doesn't automatically mean lower quality. My codebase quality and overall app experience has improved since I started using agents to code. You can leverage AI to test as well as write new code.
> I assume most of their outages is related to this insane scaling and lack of available compute.
>
> Vibe coding doesn't automatically mean lower quality
Scalability is a factor of smart/practical architectural decisions. Scalability doesn't happen for free and isn't emergent (the exact opposite is true) unless it is explicitly designed for. Problem is that ceding more of the decision making to the agent means that there's less intentionality in the design and likely a contributor to scaling pains.
This is only true for small companies that can infinitely scale within AWS without anyone noticing.
You are talking about software scaling patterns, Anthropic is running into hardware limitations because they are maxing out entire datacenters. That's not an architectural decision it's a financial gamble to front-run tens of billions in capacity ahead of demand.
My theory is that most of their outages are compute and scale related. IE. A few GPU racks blows out and some customers see errors. They don't have any redundant compute as backup because supply is constrained right now. They're willing to lower reliability to maximize revenue.
Why would you think that the person you are replying to didn't design in scalability? What exactly are emergent features when vibe coding? If scalability is an explicit requirement it can be done.
> What exactly are emergent features when vibe coding?
Regression to the mean. See the other HN thread[0]
The LLM has no concept of "taste" on its own.
Scalability, in particular, is a problem that goes beyond the code itself and also includes decisions that happen outside of the codebase. Infrastructure and "platform" in particular has a big impact on how to scale an application and dataset.
After the CC leak last week I took a look at their codebase and my biggest criticism is they seem to never do refactoring passes.
Personally I write something like 80-90% of my code with agents now but after they finish up, it's critical that you spin up another agent to clean up the code that the first one wrote.
Looking at their code it's clear they do not do this (or do this enough). Like the main file being something like 4000 LOC with 10 different functions all jammed in the same file. And this sort of pattern is all over the place in the code.
I have a buddy who used to work at Shopify and was proud about having sprints dedicated to removing unused features. This is really underrated but is the only reliable way to prevent bloat. Oh and getting rid of bloat is way more satisfying!
It's not an automated process (at least in my case). I primarily use Codex so I will do the initial pass with 5.3 or 5.4 xhigh and then cleanup with spark on medium or low.
Spark is great for this kind of cleanup work because the feedback loop is so tight compared to just about anything else. It's quite hampered by a very small context window but in the context of cleanup/refactoring that's more of a feature than a bug IMHO.
My suggestion for folks that want to do this is make sure you keep reasoning low. The cleanup should be very much human directed and derived from your "taste", at that point you don't want the model to think at all and just blindly do what you tell it to. You want reasoning to be just high enough so it doesn't eff up the code in the process.
I’m sure someone is out there claiming that AI is going to solve all your business’s problems no matter what they are. Remotely sane people are saying it will solve (or drastically improve) certain classes of problems. 3x code? Sure. 3x the physical hardware in a data center? Surely not.
I do have a question, is it even possible to have a CDN set up where they don't MITM and strip your TLS and re-encrypt or are we just picking which jurisdiction gets to inspect your traffic?
edit: I'm thinking of the use case where the CDN as a proxy for APIs and uncachable content as well, where it used as a reverse proxy for transit/ddos protection.
Why would you want a content delivery network for uncachable content? Literally the point of CDN is to cache content and deliver it.
Granted cloudflare also does DDOS protection, and that makes sense for an API. For that you could do some DDOS protection without stripping TLS, but it can only protect against volumetric attacks like syn/ack floods and not against attacks that are establishing full TCP connections and overwhelming the app server. (rate limiting incoming connections can go a long way, but depending on details, it might still be enough to overwhelm the serving resources, your use case is up to you to understand).
Much of the point of a CDN is that they can cache responses, and likely also make other changes. I don't see how that could be done without seeing what's inside the request.
No it would not work. TLS protects against replay attacks by design, the same response (or query) in clear text will not look the same in encrypted traffic
Probably not. That’d look a lot like a bunch of load balancers around the world hitting your own backend. There’s generally not a way to cache web data without decrypting it inside the cache.
I mean you can even use Cloudflare in a non-MITM manner. You lose a lot of the "value" of a CDN but they support it. Cloudflare Spectrum would be the product.
I can't believe I'm praising Microsoft (Office365) here but it actually has a track record of actually having support, support people that you can talk on the phone with and knows how to navigate the dark corners of their convoluted systems and actually solved my problems (even if it was caused by Microsoft's horrific UI in the first place).
An article here a couple of days ago said that the automation behind the scenes in Azure is piss poor and the whole thing is held together by thousands of contractors manually fixing the endless failures.
On the plus side, it does mean they have thousands of people who know how to fix problems.
At Google there is one guy who knows how to fix the problem.. he's a monk who is also in 700 different teams and the only one who remembers how the systems were built. You have to climb all the way up to his mountain abode, hope that he is home and pray that he will hear your cries and help you
Any painful automation story feels very different from their customer service. MS has always been superior to their competition with customer service - especially paid service contracts - because it's far closer to their identity: very long-term, tightly integrated enterprise. Google has never had this; even the idea of paying for support came very late (and reluctantly) to them.
> MS has always been superior to their competition with customer service - especially paid service contracts - because it's far closer to their identity: very long-term, tightly integrated enterprise. Google has never had this; even the idea of paying for support came very late (and reluctantly) to them.
If we're comparing cloud services, surely GCP has customer service? I can't imagine any big enterprise using it otherwise.
reply