There are HSMs that are effectively immune to this attack by way of their construction and packaging. You need an optical path to the secure device. The only way to get at this is to tamper with the tamperproof part of the system.
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
It sounds like a more cleaner method to obtain the keys versus using solvents and a lot of trial and error hardware. As described by Chris Gerlinsky with "How Do I Crack Satellite and Cable Pay TV?" [0] [1]
Your phone isn't going to have a "very high end HSM" any time soon. n
Not until you're paying mid range car prices or more for your very specialised secure phone (and then that phone will probably be factory backdoored AN0M-style).
> Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
That's interesting. I suppose if that technology is in use, the attack would have to occur in a pressure-controlled chamber, so breaking the seal wouldn't cause a change in pressure.
A more likely measure, which I recall seeing years ago, is to measure the impedance of the enclosure of the thing you want to protect. If someone tampers with it, you would be alerted. It works at many scales, from a protective metal mesh over your IC to a PC case.
You can find the pressure through destructive trial-and-error if money is no object - which it isn't for governments when the target hardware is juicy.
Why would you make each device have the same pressure inside it? That's a bit like hardcoding the same password in each one. Any attacker is only going to have one shot on the actual device they care about no matter how much money they spend.
I expect typical smart cards like the one in your credit card are harder to crack than the raspberry pi was. Those cards are (or were) also used in TV set-top boxes and back in the day, there was a decades-long arms race between the chip makers and cable TV pirates. The TV pirates were also willing to make large expenditures to crack the chips so they could clone them and sell the clones. There's more about this in Ross Anderson's book "Security Engineering".
I've also heard that the Google Titan security enclave chip (used in Pixel phones) is very hard to crack. Apple has something similar for Iphones, I believe.
I sometimes have a hard time figuring out what shouldn't be built.
The next best thing is to rapidly build the crappiest thing that kind of works. Being a little bit bad on purpose usually helps. Getting trapped in clean code and test coverage ideological hell is precisely what we want to avoid.
I've found that the more aggressive you make your time constraint, the less likely you will wind up committing to some kind of engineering decision that ruins the whole pie.
If the 90 minute rapid prototype doesn't make sense, you didn't waste that much time. It's a lot easier to prove things to stakeholders this way too.
I've turned multi-month product roadmap expansion packs into single day tasks by building the right things at the right times in order to discover what not to build.
If you are using LLMs to interact with sites like GitLab and GitHub, and you have the option to use a GraphQL API, you should jump on it immediately.
GraphQL is absolutely terrible for human developers to interact with, but it's like Facebook could see into the future back in 2012. I cannot imagine a more perfect API surface for agents. With the REST API on GitHub, you can consume maybe 10 issue JSON blobs before your context window is blown out. With GraphQL constraining the results you can easily read hundreds in the same token budget.
Additionally, the # of requests your agents need to make can be reduced in many cases since GraphQL can join across types whereas REST APIs cannot. You essentially get savings in two dimensions here. Quota and raw token volume per logical response.
I work closely with the team responsible for a large, self-hosted GitHub Enterprise instance. This is good advice for clients/consumers of GH data, but it can very easily lead to a lot of strain on the server-side. It’s not obvious what fields that you request are simple reads from tables or actually end up invoking git under the hood.
You could argue the rate limit guards should better reflect that, but that’s just not the reality of the system. Likely speaks to a lot of stability issues GitHub has been facing lately.
All of the queries my agents use select fields like issue title, body, labels, createdAt, updatedAt, etc. That's about it. I would hope that stuff is cached and efficient to read. I do not think GraphQL is a good way to interact with git. Running git on the CLI is the best way to interact with git.
My over-simplified explanation: the graphql server will map a field on a request to a resolver. The resolver can execute whatever code it needs to return the value, up to and including calls into libgit.
So asking for the title of a PR might just be an extra column selected on a DB query. But calculating mergability status of that PR might be something else entirely.
That's why GitHub assigns "points" to each requests and deducts based on the data shape you request. For simple requests it's 1-to-1, but can quickly balloon
It's definitely one source of GitHub's issues. They never implemented limits properly and their codebase is likely decades of cruft and impossible to retrofit quickly (to say nothing of their horrific mysql clusters). If you want to scale and survive it, you have to build the thing right the first time.
You have to be so uptight about performance when you're small that people look at you funny, or your shit is going to fall right over under webscale (ai scale?) load.
Well 1. GitHub is the broken & bad one, and 2. isn't that kind of on them? If they're getting a ton of requests that read data awkwardly, the fix seems like the quintessential data engineering task.
You sound like someone who has not been informed about the problem GitHub is facing. No one else is facing anything close to it, so there is no meaning to "the bad one".
I put my ssh credential behind a tpm and now I notice that every time I switch a chat in ChatGPT it tries to see the current remote status of the branch.
That also doesn’t help with load. So besides what agents are doing themselves the AI companies also have a responsibility of being good citizens.
Although that may be true, the quota at least on GitHub depends on what you're quering. We worked directly with GitHub and a complex enough organisation hit with a GraphQL query can actually hit your hourly app limit before you even get a response.
As for GitLab, having hosted it for medium size organisations (~200 devs) and seeing how monorepo's work (they don't, we had GitLab's team show us that one page view made 50K db queries on our setup), please consult with your local admin team before firing GraphQL at it.
The quota consumption is based on the upfront possible number of connections given the query, not actual connections, so deeply nested queries can be very expensive if not aware and careful about it.
I digress, but GitHub's GraphQL API has been neglected for years. Or at the minimum, they have not maintained feature parity with their REST API, so there are a good number of cases where you simply cannot do what you need to do without using their REST API.
GraphQL is not terribly bad to interact with. The schema system and field selection is really powerful that you can pick partial results, and that you can use an object oriented way to represent your domain models. It is pretty neat for cross-team collaboration.
Replacing GraphQL and REST + OpenAPI OTOH I think is much more terrible. You have two API description language (one on the URL path, maybe the Zod schema, another one on the OpenAPI schema). Things like tRPC or magic functions are just using Typescript type system and comment to replace the schema that GraphQL already has.
The only thing I would bitch about GraphQL is it is quite hard to build an ad-hoc GraphQL server from the first principle, while REST is really KISS till the end. And GraphQL typically needs a lot more attention to N+1 problem.
It depends. There are hidden limits in GitHub’s gql. Some will time out above certain quantities and it’s not documented, which probably means it’s a significant server strain to serve the successful responses. I find I have to maintain a test suite to probe those limits. All this makes REST continue to be appealing if testing the gql load for a service hints at any uncertain limits/instability.
Now imagine an API that turns every prompt into a validated query within seconds, no prior schema knowledge required because we're building an index, so the model is not wasting tokens on that task even with multiple megabytes of SDL.
We're building such an API for some of the biggest enterprises in the world. Many of them have very large (federated) GraphQL APIs across tens and hundreds of teams. From an agent perspective it's a lot easier to consume a single unified graph where a single query can span 5 relationships vs making hundreds of N+1 rest API calls across many heterogenous APIs from different teams that all look slightly different.
All practical GraphQL interfaces constrain you to precisely the query formats that are used by the front end, to avoid queries accidentally reading private data or blowing up computation time.
CLI still has the possibility of being a little more token efficient, at worst it may use graphql behind the scenes.
For our company, we advertise the graphql schema to bots and they can one-shot whatever task they're trying to do. I've found that it's so good that I cancelled building an an MCP server and any skill. Just a well documented GQL schema. It's pretty remarkable.
I think you might also have a GQL schema that's particularly well suited to what those bots need. Either that or your backend schema is relatively simple and the GQL schema covers all its possible data compositions.
no the advantage of graphql is that the caller can limit the response to only the information that they need. in a REST API the caller has to filter out the extraneous information. using LLMs to do the filtering uses up context window
Yea- its just a matter of whether the work is delegated to the client or offered by the server. Making sure what is served is in a really quality schema is generally the most efficient path- ime
I think mDL is going to be a pretty big deal in some industries (e.g. banking). Apple announced an ecosystem around this at WWDC25. Very soon we are going to be in a world where you walk into a bank to open/maintain an account and the following occurs:
1. The bank emails/SMSes the customer a link
2. The customer takes out their iPhone, opens whatever email/messaging software & taps the link
3. The link takes the customer to a specially crafted page owned by the bank that triggers a native OS process for opening Apple Wallet and gathering requested ID details with consent.
This is potentially a superior arrangement because it could eventually establish a strong cryptographic chain of trust all the way to the issuer (e.g. the State of Alabama). Right now there are some gaps in that chain but I see no reason they couldn't be closed over time.
Walk into bank? The last time I opened a bank account (2023), I tapped my driver's license to my phone, it got my details+photo via NFC, I took a "liveness check" video and was onboarded. This has been the workflow for many years now for consumer account openings, or installing a banking app on a new phone. I think bunq did it first around 2017. As soon as (EUDI) wallets are more standardized, both neobanks and high streets banks will adopt that too.
The main idea in this that scares me is trusting the State of Alabama (e.g.) to protect their private keys. Humans tend to be the weak links in all of these chains.
> Very soon we are going to be in a world where you walk into a bank to open/maintain an account
I've never in my life walked into a bank to open a bank account. I've got accounts with many different banks these days. Real banks and credit unions, not fake neo banks.
The only times I've ever been in a bank was to get large denomination ($100s) currency, as most ATMs around me don't dispense those. And most of the time I didn't even bother going into a bank I had an account with, most will let you get cash for free with a debit card even if you don't normally do business with them.
Buildings games in Unity feels like magic with frontier reasoning models.
Assuming you are competent with scene work and the various art pipelines, the rest of the problem is significantly easier now.
I've been using the Unity CLI to run arbitrary C# code against Unity 6 scenes without requiring domain reloads. It uses Roslyn to compile the snippet in a special Unity editor component instead of running the normal compilation pipeline.
The implications for a reasoning model are significant. Domain reloads in my projects can take 10-20 seconds. Compound across 5-10 tool calls and the difference adds up very quickly.
This appears to be a security problem in some contexts. I've been able to see issue counts for repositories that I have not been granted access to yet (the view with the invite accept button). I can't actually get to the issues but I can see how many there are.
There is no way this could be reasonably framed as RSI.
This iterative, online optimization of an exploration policy is not recursively intelligent in any way. It simply reallocates the available computational resources to more promising (hopefully) parts of the search space as system conditions change over time.
The whole idea behind RL is that the agent improves over time by making actions in the environment and observing the next state and the reward then modifying its policy.
The exploration-exploitation dilemma still stands. "dreaming in the replay simulator" is jargon for the same replay ideas presented when Deep RL was first introduced (Q-learning with experience replay and all that).
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
reply