That’s the exact opposite impression of my recent user experiences of software: slower than ever.
Contrary to what initiatives like the tigerbeetle team is doing with tigerstyle, or the 10 nasa coding rules, code created by llms tends to be verbose and slow.
TBF the specific backdoor isn’t the point of the article. It’s a cautionary tale. The point is that practically all systems above the MCU level, and even some of those, have lower level systems that are often undocumented or not intended for use by the hardware designers, much less the end users. Those systems often have extremely low level access to system resources.
For example, I am building a device that records motion data, video, audio, and lidar imaging. Inside the 6 dollar IMU and the 12 dollar lidar sensor are powerful processors that load binary blobs provided by the manufacturer. The lidar could potentially gain access to any of the system data stored on the SPI bus, which includes the bulk storage and secondary RAM for the system. It could exfiltrate that data using its laser to anyone within a few hundred meters in the laser fov. It could also receive remote c&c over its optical sensor. The only thing that prevents that from being the case is that I trust the blob does not include the code to do those things, but it would be trivial to replace the blob with one that does.
Millions of devices are made that include basic wifi functionality. often, this comes in the form of a dedicated WiFi module. Those almost entirely consist of a powerful processor running a proprietary binary blobs, connected to some internal bus of the system that may give it access to some or all of the functions of the device, or at the very least could cause the device to malfunction. These WiFi phy modules are sub$1, pervasive, and often built in to devices that do not have any advertised connectivity features. A threat actor that has knowledge of an attack surface for that opaque blob can probably cause >50% of the connected devices built with that product to malfunction, in some cases in serious and dangerous ways, and sometimes to exfiltrate data that might be compromising or valuable.
I recently got an air purifier. The touch button controls for adjusting the fan speed didn't seem to be working, so I emailed support.
They had me download their app, link the air purifier, and give them its MAC address. Then they asked me to try pressing each of the buttons a few times and email them back. I did so, and they responded that they re-calibrated the buttons using my touch samples. It worked.
That’s insane. I actively avoid buying things that are pointlessly internet connected nowadays. An air purifier’s buttons should be simple electromechanical switches.
By "touch buttons" possibly he means that they are "buttons" on a touch screen. What's crazy to me is that this is now cheaper to put in a product than electromechanical switches.
It's a Mila, they're capacitive touch buttons but not a touchscreen. There's just a fan down, fan up, and mode button. Even still, I don't know how they got the calibration wrong enough at the factory that it can't detect a full-pressure thumb press.
I am amazed that by emailing support you were able to actually get in contact with someone technical who understood the product well enough to fix the problem.
I fancy myself as a decent writer, but I suck at writing documentation. People describe reading my notes frustrating and incomprehensible. I find it much better to use AI to untangle my, admittedly, convoluted reasoning
...which along with the already publicly-known microarchitecture of the C3 makes this statement sound like total nonsense:
The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU
I remember laughing at this with a few others knowledgeable in x86 when it first came out; a self-proclaimed "security researcher" who somehow failed to RTFM.
"It's documented in the datasheet" is such a weak excuse for a backdoor.
Documenting a backdoor doesn't make it not a backdoor, just means it's not a hidden backdoor.
The fact that a number of machines shipped with the backdoor accidentally enabled, and nobody noticed for over a decade shows just how dangerous even a documented backdoor can be. The oversight wasn't even detected by someone reading the manual, it was detected by a security researcher who wrote a generic tool to fuzz out such backdoors.
backdoor means a secondary access point that defeats the security features of the primary. In the door analogy, the home owner spends a ton on a lock and camera for the front door but doesn't even have a deadbolt on the back.
Every definition of a “backdoor” in computing implicitly or explicitly considers it hidden/covert.
In the house analogy you don’t see the backdoor when approaching the front. If it was just “an alternative everyone knows about and can be broken easier than the front door” then it probably would have been called “a window”.
Most login forms have a weaker option like a SMS 2FA or password reset fallback. Nobody calls it a backdoor. It’s just a crappy second front door, or window.
The Free Software Foundation (FSF) calls the update system used in Windows 10 a "back door" [1], I think because it installs updates automatically. This sounds like nonsense to me, because it implies that I installed a back door on my own machine by enabling automatic upgrades (on Trisquel).
It's meaningful that the Windows 10 install method has no (official) way to disable it, but I don't think making something optional could make it not a back door, if it was one before.
Even when automatic updates are disabled, I'm not going to be reading every update so the effect seems mostly the same, regardless of whether updates are automatic or not.
The FSF's definition of "back door" (at the bottom of the linked page) is "any feature of a program that enables someone who is not supposed to be in control of the computer where it is installed to send it commands" which leaves a lot of ambiguity with the words "supposed to be". I am not sure how to interpret this definition.
thats a tough decision
if something aint broke, dont fix it.
if there is a reason to upgrade, maybe wait until there are good reviews before actually applying it or make a safety backup first
The FSF definition can be interpreted in absurd ways; a very uncharitable interpretation would classify any network stack connected to the internet as backdoor because random, potentially misdirected packages trigger code exécution on the target machine, even if only to figure out that the packet must be ignored.
> Is there another term they could be classfied as?
As an advertised feature of the product.
Your personal definition doesn’t match the general understanding of the word and concept. By your definition every window on a house or car is a “backdoor”. Anything with an advertised fallback is a backdoor. And sometimes the “front door” is the back door: getting money from an ATM is less secure than with an ID at the bank teller.
Password resets aren't "backdoors" unless they contain a flaw the defeats any security protections. It's not just that the backdoor is less secure than the front, the backdoor has no security or is so easily defeated the security may as well not exist.
I'm surprised the hidden aspect of backdoor is so forward in folks minds. In my thinking nothing in cyber security is hidden, I drop the obviously present hidden part of backdoor definition when it's used in yhe cyber security context.
No offense but I don’t think you have a clear enough definition in your head and you’re making it up as we go along and you get challenged.
>> I'm probably mistaken, but I've always referred to password resets as backdoors
> Password resets aren't "backdoors" unless they contain a flaw the defeats any security protections.
You really have to make up your mind. It was “always” but then it wasn’t, and even as you put it you’d have been wrong almost every time to call a reset “a backdoor”.
> I'm surprised the hidden aspect of backdoor is so forward in folks minds.
Only because you misunderstand the meaning of the term, as made very clear above. Go through the wiki page for a “backdoor”.
> In my thinking nothing in cyber security is hidden
I wonder what all those security researchers do all day, with everything being so out in the open and known by everyone.
> I drop the obviously present hidden part of backdoor definition when it's used in yhe cyber security context.
You can drop it but then you’re just using the wrong definition and wrong understanding.
no offense taken. i shouldnt have included password resets in my def. it muddied the conversation. covert is part of a def, at least sometimes, but i think its still acurate to drop it. consider a machine with two copies of ssh running, one of 22 with authentication and another on 2222 with an automatic root login. the instance on 2222 would be considered a backdoor, even though its barely hidden. Swap the ports and it's an unauthenticated frontdoor, but i'd still call it a backdoor and expect everyone to know what i mean. the important part is its bypassing securit, not that its hidden.
Not really... backdoor just means something that can bypass the main security.
It's just that publicly known backdoors are of very limited usefulness, because people go out of their way to remove, disable, or avoid them. Or worse, use them for their own gains. There have been more than a few cases of governments trying to implement and enforce publicly known backdoors (with keys only the government knows), such as the Clipper cryptography chip in the 90s.
But... just because something is documented, doesn't mean it's publicly known. We have an example here of something obscure enough to be a useful backdoor (assuming someone knew about it).
And while the underlying feature might have been documented, the fact that many BIOSes enabled the feature was not documented anywhere. That does count as hidden.
It's not as clear cut as you describe it here. In the other old thread you linked there was no real consensus if this should be considered a backdoor or not.
I understand what they are trying to do, but to me it feels like the moment when MongoDB entered the database space, with semi-structured, "flexible" storage format. It has its uses, for prototyping mostly.
But in high-volume, production workloads, giving a structure to the data you extract (what Parseur does through defining the Fields in your Mailbox, basically giving your output data a schema) adds a ton of value, and the larger the dataset, the truer it is.
Usually, you start by defining where you want your data to go, and which structure it should have, before working backwards from here and starting to extract the data. This is the key to automating your document workflow.
Hey, good point about structure for integrated workflows:)
Fully agree, for enterprises we need to guarantee types, flag discrepancies and provide underlying sources so they can integrate it downstream (whether that's Databricks, n8n etc.)
There is no mention of the amount of fuel used to transport the fuel in the article. From what I know it’s a tiny fraction: boats are efficient at transporting stuff (slowly)
> Fossil fuels are roughly 40% of maritime tonnage, but in the model they represent about half of maritime freight energy because coal, oil, and gas are mostly long-haul bulk trades. Moving a ton of scrap metal a short distance and moving a ton of oil or LNG across oceans are not the same transport-energy problem, even if both show up as one ton in a cargo table.
as being exactly what was being talked about... more fuel is spent on transporting fuel due to distance it travels.
but your comment made me re-visit (i.e. more closely skim...) the article, and it's really about: "as the demand for fossil fuels is projected to decrease, (1) less long-haul shipping is needed and (2) a greater fraction of shipping will be short-haul, which will be practical for other types of freight fueling (i.e. what's shown in the figure at the top of the article)
I have no sense of how realistic the figure is. For example, I don't know the current projections for decline of fossil fuel demand over ?? year timeframe.
It happens for every single Anthropic release. Then I try it on real dev and the result is laughably bad. Except in design where it has been doing a decent job for a while. I am not a designer and my bar is pretty low.
I don't know; I am not sure I'm marketable in THIS particular market.
As for FastAPI bring a mistake - that's an overgeneralisation to be sure. It has it's uses.
My first issue is that it falls into the same kind of small footprint as Flask. Every Flask project I work on slowly reinvents Django via a combination of plugins of varied quality and custom code/plugins. Get some Auth plugins, build step for manifest static files, add in Jinja2, grab an ORM like SQLAlchemy (or hopefully PeeWee), a migration system, test runners with fixtures/dB integration and rollback and on and on and on.
FastAPI is operating more at that level but also adds the often unnecessary complexity of async. In Python this is a cooperative setup meaning you have to yield to the event loop yourself (otherwise despite being "async" it blocks). Plus with a webapp all async often does is let you hammer your services (i.e. dispatch more queries to your poor DB) harder. The actual performance improvements don't manifest so much at scale as people often think. Plus you end up with a whole second set of ways to call functions and... makes me pine for gevent.
There are absolutely cases for this kind of async, even in webapps, but it's often not actually that helpful in places that it's used (and doesn't actually need to be everywhere). Good development imo means picking the right tool for the job rather than jumping on hype trains.
Thank you for this answer, it saved me hours of experimenting.
And bonus points for bashing MongoDB, of course. Every single project that I worked on where MongoDB was used, also had MongoDB as the single largest constraint and operations time sink.
Are you building the site from the same json files that are used in the game?
AIs are still computer programs and are not given the resources to render javascript, so they cannot access the game data from the website. And they obviously don't have it in their parameters.
BTW Google Gemini Pro just told me that they know the game but did not know the value.
Actually, it points out that it is a known trap for AI to confidently give a wrong, hallucinated value. Maybe it had already seen this thread and integrated it in their parameters or fine tuning.
I don't know...
Gemini Fast confidently gives me a wrong value. But very quickly!
I'll attach the entire Gemini response as a sub-reply.
The json thing is what makes it particularly surprising.
It’s literally ’gameconstants.js’ with an item list that has a .name string and a .armor value that it could look up. But when I pointed it to the file and told it which row to read from, still chose to make something up instead of read the data designed to be read by computers.
I do like how your ai tries to cover for its buddies with lies about there not being any documentation online. Because pointing AIs to a specific page and asking them to read the numbers there is a known trap.
https://foaas.io/legend/foass.io/joss82
reply