Refilling the SPR would’ve required finding money to actually buy some oil. Put simply the SPR is broke/in debt.
Over the last few years congress passed pieces of legislation (infrastructure bills, healthcare changes, BBB) and used future SPR oil sales as an "offsetting receipt". Basically they say the’ll sell off millions of barrels of SPR holdings, count the future revenue as negative spending on paper, and use that money to pay for entirely unrelated legislative projects to make bills look deficit-neutral.
Yet another source for deficit spending (to the tune of $20bn) that doesn’t even show up in the headline numbers. Borrowing from future generations yet again.
(Sorry this is the kind of thing that grinds my gears - setting up some organization that is intended to be revenue neutral and self sufficient, then plundering it when politically useful. Same thing is happening to the Presidio park in SF right now)
As a tech literate customer, my willingness to entertain AI chatbot decision trees is rock bottom. I have no patience to try to find the correct incantation to actually fix something (or the, “before I transfer you to a person, let me try to help you first”).
For myself - and admittedly maybe I’m just far out on the long tail of customers - I think these need to be treated like self driving cars, where 98% of the way there just isn’t good enough to cut it for me.
I spent an entire month trying to build something with Reticulum, but there just isn’t great tooling for dealing with the protocol. Makes for a pretty infuriating devex if you’re just trying to build your app.
Neat concept but so many footguns that (imo) it’s not really sustainable to try bootstrapping.
Specifically, I had tried to port the stack to Rust no-std to use on nrf52 LoRA devices to use/abuse the existing MeshCore network to deliver reticulum packets. Turned out to be a nightmare just trying to figure out if my packets were even correctly formed.
I would absolutely love to read something about that - thanks for putting in the work and sharing it.
I have a buddy working on restoring a set of binoculars that were attached to the Target Bearing Transmitter system for a US sub from the 50s. Last I heard he was able to find someone that actually had parts of the original schematics for it so that he’s able to machine some new pieces.
I’ve heard rumors that DNS records are also sometimes used in some steganography-type communications. Great way of passing small messages in a ubiquitous and innocuous system, unlikely to be blocked or raise eyebrows by accessing.
Cloudflare has excellent (human) technical writers. I don’t see any indication this is “slop”, it’s the standard in-the-weeds but understandable blog post they’ve been doing for years.
I was using this as a demo project for playing around with code generation tools, so it’s really not in a great state and entirely AI written, but I can share a link here when I get a chance.
My initial stab was a rust port targeting esp32 Heltec V4 (since it has some niceties like tokio) with Reticulum communication over serial, BLE, WiFi and LoRA. The serial interface was sort of working, but frankly debugging using rnsd/nomadnet was infuriating (there’s no tools just to easily see messages over the wire!).
I’ve moved onto a build system that can also target the SEEED Wio Tracker using no_std, but it’s been… messier. AI tooling doesn’t quite have the context length for big migrations like that yet.
Reticulum is a full replacement networking stack for several layers of the OSI stack, so not directly comparable. The LXMF messaging protocol (built on top of reticulum) is nice as it’s encrypted-by-requirement, but doesn’t really have a ton of non-text messaging implementations.
Reticulum is not worth getting into, the utilities and general infrastructure just isn’t there yet.
The project was basically a one-man-show for a long time, and has a lot of odd, esoteric decisions that will drive you mad if you’re actually trying to build something with it (eg, configuration files with sparse documentation that are yaml-but-not-really). I don’t mean to belittle the loads of time the original maintainer put into this project, it’s just not really designed to be usable in the general case by other developers.
I spent some time porting the reference Python implementation to no_std rust, but basically had to roll all the basic debugging utilities myself.
It’s interesting that Apple is going down a similar path with hardware filtering location retrieval commands and neighborhood-level blurring on their C1 modems. Really awesome work from that team by making sure they’ve considered privacy as a first party feature for that chip.
How do you guys view the relative value of privacy/security at the network provider layer of the cell stack for the average user/citzen?
Even if Cape doesn’t retain metadata yourselves (eg LTE positioning info), is that data not still retained and repackaged by the tower owners themselves? Eg babel street, venntel, etc. A rotating IMEI every 24 hours might make it marginally more difficult for logical tracking, but there’s still only physically one location the phone can be in without fuzzing at the hardware level.
I should also say - I’ve been following y’all’s work for a while (and considered some of those early forward deployed engineer positions), but I’m struggling to see how this all works as a consumer product. Would be awesome to see an eventual partnership with Apple/Qualcomm to bring this to the hardware level since privacy is a tough nut to crack even at full MVNO.
The ATProto underlying BlueSky social network is similar. It uses a content-addressed DAG.
Each “post” has a CID, which is a cryptographic hash of the data. To “prove” ownership of the post, there’s a witness hash that is sent that can be proved all the way up the tree to the repo root hash, which is signed with the root key.
Neat way of having data say “here’s the data, and if you care to verify it, here’s an MST”.
The replies also make it clear the sycophancy of LLM chatbots is still alive and well.
All of the replies I saw were falling over themselves to praise OP. Not a single one gave an at all human chronically-online comment like “I can’t believe I spent 5 minutes of my life reading this disgusting slop”.
It’s like an echo chamber of the same mannerisms, which must be right in the center of the probability distribution for responses.
Would be interesting to see the first “non-standard” response to see how far out the tails go on the sycophancy-argumentative spectrum. Seems like a pretty narrow distribution rn
The plaintext TSS/ECID and the plaintext OCSP issues have been fixed, which IMO were the only meaningful security gripes of the article.
The iMessage/ADP/Metadata stuff I think is more of an implementation decision than a meaningful attempt at data collection. Using clear text file names and hashes for dealing with collisions and deduplicating is a reasonable first pass at something like this. Sure, they could probably roll some end-to-end obfuscation for this, but with how big their stack and cloud integrations are, I’m sure that’s non-trivial.
Just curious - how much of this was AI generated? The readme has crazy emojis & the code was all checked in at once, which is usually my telltale for these kinds of things. Didn't see anything crazy in the source files.
I think its polite to indicate AI agent usage in security related projects like this since they can have huge holes if they're just being vibe coded.
-- Edit: Intended to post this on the board root, sorry.