bri3d

Is there any information about the touchscreen digitizer technology? My understanding is that there are a few different ways touchscreens are integrated into OLED panels (on-cell, in-cell, external grid). I have a Dell 16" laptop with a 4K OLED which happened to come with a touchscreen; I'm not mad about the touch features themselves (although I rarely if ever use them), except, the "on-cell" touchscreen digitizer is slightly visible under some conditions and because the display is otherwise so flawless and amazing, it's pretty annoying.

He also removed the people selling the ads and the people working on the ad targeting platform, mind you. I think that's what differentiates from a normal "PE gutting/squeeze" and what people should be analyzing, but everyone (from "both sides" of the Musk equation) gets caught up on the uptime number for some reason.

Which is where I was going with my (original) post - but the GP post seems to be using this as evidence to disagree, which is confusing.

I strongly disagree with this take; do you think all companies are 80% SREs? Did Twitter make money by serving pages to users?

The Twitter exodus does relate to this, kind of; it's an example of the "fall back on existing revenue streams" strategy (you could call it a private equity playbook, but it's more universal than that) exaggerated by the guy acquiring it not needing more revenue and clobbering the revenue part too.

Twitter pre-Musk had an _enormous_ amount of experiments going on. They were building streaming services, clones of every social network you can think of (Spaces etc.), an entire sports brand around MLB, and so on and so on.

They also had an army of sales people who sold ads and an army of engineers building and optimizing an ad platform, which is (or was?) their actual business.

The "platform going down" narrative from both sides was 100% irrelevant to what was actually going on. "We laid off PMs, salespeople, and engineers and the system didn't crash" is a complete non-sequitor that should be obvious to anyone who's involved in software engineering or maintenance. If anything, I'd expect laying off most of any company to make it much more stable; when you don't change things you introduce fewer bugs.

Before getting wrapped up in the usual LLM vs anti-LLM narratives, note that like many of these recent layoffs, this is essentially reversing 2020-2022 net headcount growth.

IMO a lot of these layoffs are companies going from an experimental fiscal mindset to a conservative fiscal mindset - ie, rather than acquiring companies and hiring to grow into new markets, a lot of organizations are falling back on what they know works, independent of any productivity impact of LLMs.

For what it's worth, TPM supports session encryption, but the compatibility is poor due to bad TPM implementations (which is a whole extra can of worms), so it isn't enabled by default in most configurations. If this threat model is meaningful to you (which it probably is if you're using TPM-backed FDE), it's worth looking into what it would take to set up (and switch to fTPM if possible).

Although, if anyone wants an RE project, I've always been interested in reversing the ME <-> CPU bus on Intel to see if the ME-embedded TPM is still vulnerable to snooping. And of course all of this is still highly vulnerable to any early-boot / root of trust exploit (ie against Boot Guard / PSB or horrible UEFI firmwares).

No, I think this is a valid threat model and a good rebuttal. The evil maid steals the original laptop, replaces it with a second laptop with a look-alike PIN entry screen without an attestation. You enter your PIN, it is transmitted to the evil maid with the first laptop, and your data is unlocked. You would notice, but your data would be exposed.

Now, to be clear, I don't think this negates TPM-sealed disk encryption or TPM-and-PIN sealed disk encryption; they're still meaningfully better than the alternatives (with a passphrase alone, your data is already compromised regardless in this invented scenario, and all scenarios are equally variable to the swiss-cheesiness of UEFI firmware unless it is replaced). But it is a valid model.

Sealing to a reasonable subset of PCRs (ie, not just 7 like the article) is reasonably strong against point-in-time evil maid, no?

Like, in Evil Maid Scenario 1, where the Evil Maid only has one-time access, if you've sealed to say 0,2,4,7,9 , or 7 and 15 with a reasonable setup for what gets extended into 15, the Evil Maid's Fake PIN Entry Software would _not_ validate in the secured boot configuration and couldn't actually unseal the TPM, only coerce you into entering your PIN. Then the Evil Maid would have to physically return to your "correct" boot state with the PIN to unseal the disk, no?

(this is all modulo firmware and early boot exploits, of course, since in that case the attestation could also be forged also)

AES-CBC is unbelievably popular and relies on the AES inverse block cipher?

> this is incredible stuff...

Is it? The theory and even the implementation is literally a gas station credit card skimmer for crypto. I do agree that anyone dismissing attacks on Ledger was foolish, but mostly because Ledger is an obviously low-quality product on even a cursory inspection, not because we need to become even more paranoid conspiracy theorists.

The hardware is much more sophisticated, miniaturized, and high-speed, and the supply chain is much more generic; a Ledger is a really primitive piece of hardware with a simple display interface and a ton of empty space inside it. An iPhone has no wasted space and extremely high-speed onboard buses that would be hard to sniff. Additionally, with Ledger, you know that every customer is going to be using the device to access crypto, so it's an easy target nearer the head of the supply chain. With an iPhone, you have no idea what end-user to target the implant against.

> So at some point the vendor will go through and patch the holes which the model had exploited and they will have to rewrite their admin architecture, and maybe be liable to some fines with the chip companies if "Intellectual Property" was improperly disclosed by their failure to write good software. And are we any closer to using the products as a general purpose SDR? No, we are not.

What? It tunes and it's streaming IQ over Ethernet. It is a general purpose SDR! You can use it as a general purpose SDR immediately.

I'd like a little more information from someone who actually knew what they were doing (or even just asked Claude to write it out in more detail) about the "real" nuts and bolts of the receiver, too (how's does IQ imbalance calibration work? How much dynamic range does it really have? How much can we configure the frontend, in detail?), but I don't think it's fair to claim this project is skiddie-level or not useful at this stage just because it was written by Claude.

Also, who's going to fine Mediatek for exposing Mediatek IP?

I think the idea here is cross-platform / runtime pluggability: an app can specify what policies it needs and this thing will map those policies onto the specific runtimes available (containers or VMs). It's basically a container security policy orchestration layer, I suppose.

I agree! Don't give it away!

Seriously, though, the popular Ghidra MCP is really badly architected; it's way better to rearchitect it or just script Ghidra directly. With that said, Opus 5.5 seems to have been trained on CoT from the popular Ghidra MCP. This makes it work better, but also makes it even more inefficient if you modify the MCP without changing its name and shape significantly (it will try to make tool calls using the "mainline" format, then have to retry them when they fail).

Even with Opus 5.5, IMO it's better to just ditch the MCP and let the LLMs eat with bintools and headless Ghidra; with both GLM and Opus this produces significantly more efficient results than the popular MCP. On the other hand the IDA Pro MCP is much better architected and seems to be pretty good.

The IDA Pro MCP is substantially better than the most popular Ghidra MCP, for what it's worth.

* Yes, TRACON have their own dedicated links. You can look into ASTERIX and STARS to learn some of the cursed ways the data processing and dataflow work.

* There is supposed to be a primary and a secondary link, in this case the primary failed and the fail-over also failed. It's unclear from the reporting if they were damaged in the same incident or if the failover was not tested or monitored adequately.

The Philadelphia TRACON site has been notoriously unreliable and was supposedly improved in 2025, it's also unclear if these issue actually could stem from that implementation.

I absolutely agree that engaging with these people beyond "we added checks to ensure your board has the RAM it came with, and this one failed" is a waste of time, but I think that at least providing that level of response would be much more aligned with the image they're still trying to project than just stonewalling entirely.

Really? I found that issue and all of the related ones really disingenuous from the Pi folks; they just stonewalled everyone with "contact your hardware seller" rather than explaining what was going on even at the glossed-over level they managed in the forum thread.

I do feel for them; they're between a rock and a hard place with mis-labeled clone boards. But their implementation seems to be the most hostile and opaque possible way to achieve these goals (which I also understand from an anti-cloning standpoint, but especially anymore, it's going to get reversed anyway).

I see that now… why did they check it in? One of the whole points of this approach is that that assembler should be trivial to re-derive by the end user since it’s just the original program listing. Some of the Xbox 360 recomp projects like https://github.com/mchughalex/skate3recomp offer a better example of how this pattern can be achieved without distributing the binary at any intermediate level.

This is a recomp project, not a decomp project; the original binary is supplied by the user, mechanically translated into source code at an architecture level (rather than a human-readable level), and patched. It’s AOT dynamic recompilation and the original IP isn’t distributed.

I do agree that decompilation projects are obviously not transformative (the only fair use feet they really have to stand on are purpose and market effect), but recomp projects are a little more interesting and might live on much less shaky footing.

I felt compelled to reply to this because I agree with it so strongly (which is also why I phrased my initial post as "sort of odd" rather than "some evil anti-consumer monopoly volcano lair conspiracy"); so many corporate oddity theories are easily caused by dysfunction that I wonder how many of their proponents have ever really been exposed to a corporate job.

Patch embargoes are a debate as old as security.

I think the overall source embargo is rational _until_ fixes appear in a released binary build. Otherwise there's an integration/QA/rollout window where a source patch is public while the binary patch is unavailable to anyone, including attackers, which is undesirable. In "full" open source this has always been a time-suck mental gymnastics exercise around hidden mailing lists and obfuscated commit messages (which probably aren't useful in the LLM era anyway). It makes sense for Google to avoid engaging with that given they don't need to; I think it would be fully logical for them to perform source drops gated on the rollout cadence to the first available binary release channel.

I fully agree the slower-than-Pixel "vendor lead time" windows are really detrimental. Once the binary patch is out, the source patch and disclosure is effectively out too; those extra windows just let OEMs continue to be lazy as a matter of policy (which they love to do regardless) while exploits are already available.

Oh! I had thought they stopped at the same time they closed off AOSP commits - that makes this entire rabble-rousing effort _exceptionally_ silly, then; I can't see the angle GrapheneOS are trying to push at all in that case (like, I get their side of the _concern_, but "Google are shipping features to Pixels that you don't get" becomes... quite a poor argument indeed in that scenario).

So, the real thing that's happening here is:

* Google drop "real" Android source-code updates to OEMs _and_ the public every half.

* But they ship four Pixel updates, including documentation + SDKs.

* Now they added new APIs in a Pixel-only update.

* Google also drop security update backports to "trusted" OEMs monthly (which GrapheneOS have had access to for years).

So, there are now Pixel-exclusive app features on the Pixel SDK version which isn't available to OEMs - but, it's highly unlikely any app developer would actually depend on these new APIs, since Pixel marketshare is tiny to begin with. This in essence just makes Pixels a weird beta-testing device for what will come out a quarter later to "normal" devices, which is sort of an odd business decision, but also a weird thing to get really mad about, in my opinion (I do see what GrapheneOS are trying to do, with having OEMs saber-rattle about not getting features on the same cadence as Pixels, it just doesn't resonate very loudly for me).

However, the API headline seems to bury a deeper lede; in the thread, GrapheneOS also claim that the quarterly Pixel releases contain security content which is not appearing in the monthly backports. This is quite bad and very sloppy if true, since the Pixel releases can easily be patch-diffed and exploits backed out of them. I'd be interested in seeing this enumerated in more depth.

CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.

I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.

By not having void air space in between cylindrical cells like you'd get with two 18650s? It's mostly just a matter of packaging.

Pouches can be made to have better volumetric density than cylindrical cells quite easily, which is why laptops aren't generally full of cylinder cells anymore; the challenge is just providing them enough external support/compression and swelling allowance, which can be accomplished through chassis design.

I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.

Yeah, that’s a good way to summarize what people are mad about; they basically moved all of the calibration from onboard to offboard diagnostics, and then thwarted most efforts to access the offboard diagnostics.

Automotive is similar and I’m a bit worried for EVs; for ICE autos there’s enough emissions related regulation that some diagnostics and manuals are accessible, but for EVs there’s nothing much stopping a Deere style complete lockdown.

Newer Deere equipment has a lot of components that have to be adapted using DSA - turbo actuators, various hydraulic sensors, various suspension leveling sensors, fuel injectors, interior displays, and anything SCR related are the big ones. Basically, any sensor that needs a calibration step or triggers an emissions code, or a few intentionally vehicle locked modules (ECM).

Palantir sell consulting services ("forward deployed engineering") around graph and map database platforms, using data supplied by customers. Some of their customers ask them to make surveillance aggregation systems, others ask them to make totally banal and random enterprise software (this is why you commonly see freak-outs around hospitals buying "Palantir," for example; usually they are operating as consultants making some kind of medical records warehousing system owned by the customer).

Samdesk provide risk analytics using traditional risk analysis investigation and research, which they have now welded an "AI platform" to, like everyone does these days. They aggregate crime and protest data to make a map of "places your employees might be at risk" and sell it to companies.

Samdesk would be a Palantir _customer_ if they liked parting with their money, not a competitor; Palantir operate at a much "lower level" and don't do the data collection or research on their own.