This is a very worthy article.
I have an impression that I've read it before 2024, but maybe that was a different article describing the same mess with how github exposes private repos.
If git in general would enforce pretending to not know about orphans, it would always need to know what you were meaning to consider the boundary, and/or you would end up waiting for useless duplicate network traffic. The fact that on GitHub, such references are visible irrespective of specified repo is not a bug, its a feature. Its the tools (including but not limited to: GitHub Actions) that cause dangerous misunderstanding in appearing to let you specify something they then never actually enforce.
intended meaning: use this hash if and only if it is accessible from the default branch of that repo
actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.
yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening
> github has a huge warning saying to never use pull_request_target to run user code
This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.
"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name so people know there's a dangerous quirk to it when reading their config.
I practiced the Buteyko method for many years when I was in states of high anxiety and frequent panic attacks, and it was incredibly helpful. I had a syndrome called new daily persistent headache, which means a sudden-onset headache that becomes constant from that instant forward, as in 24/7, for years. It's hard for people who haven't experienced that to understand I mean that literally. Buteyko breathing was the only thing that ever cut down on that headache, and a couple times I was able to suspend it for an hour or two, which when you have a literally constant headache for years, is a big deal.
My big takeaway from it was that breathing and neurological state are deeply connected and actually relaxed, natural, healthy breathing (and the corresponding state of the brain and nervous system) is something that most people have probably never even experienced unfortunately. We all think our state is normal, but I assure you, it is very far from the state where your control pause is 40s-60s or more, it's a radically different experience.
Also the nuance of what the control pause and how to measure it correctly is lost on I would say, even most people who attempt to learn Buteyko. The control pause is how long you can, under normal breathing, suspend breath with zero discomfort, and then prefectly resume normal breathing without any change from before. If you took a bigger breath to start, or when you start breathing again it's even slightly heavier, it's not a control pause measurement, it becomes an ego metric juiced to make you feel better about a number while avoiding the disappointing facts.
Buteyko claimed that healthy breathing had a 40+ second control pause. Which if you think about the real meaning and how to measure it, is a super long time. And I got there sometimes, it's a major learning experience about what deep alignment and relaxation of the brain/nerves can really feel like.
Buteyko practioners build up the ability to work very hard while only nasal breathing over the long term. The point is to learn to modulate breathing in a way that keeps a certain kind of blood chemistry (CO2 levels) and cellular oxygenation.
If you commit to nasal breathing for exercise as a constraint, it does force you to modulate your exertion while also increasing your CO2 and developing, according to the Buteyko folks, a new baseline for respiratory health and capability.
If you're running for your life from a tsunami, by all means mouth breathe. If your purpose is maximum exertion, of course mouth breathe. But that's not the only possible purpose of exercise. It can also be about respiratory training. Nasal breathing becomes a natural guideline/modulator for long term improvement in that regard.
I struggle to understand what this specifically has to do with rails or global IDs. In ANY framework or query system, if you are asking an LLM to produce IDs which you are then passing to a database for lookup, you need to understand those identifiers could be hallucinated or incorrect in surprising or malicious ways, and can lead to data leaks or exfiltration.
It's like writing an article about "the dangers of PostgreSQL" ... when generating SQL from an LLM. It has nothing to do with Postgres specifically, it's that you're generating queries to run in a trusted context from an untrustable origin.
I don't understand how code review would catch this. The extension advertises itself as an AI protection tool, that monitors your AI interactions. The code is basically consistent with the stated purpose. That it doesn't stop collecting data when you turn of the UI alerting is perhaps an inconsistency, but I think that's debatable (is there a rule in google's terms that says data collection is contingent on UI alerts being enabled?). I'm curious what workflow or decision tree you'd expect a code review process to follow here that results in this being rejected? The problem here doesn't seem like code related, it's policy related, as in, what are they doing with the information, not that the extension has code to collect it.
So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.
Yes "good" caching - a consistent storage interface - is an abstraction over "bad" caching - multiple different storage interfaces with different speeds. But caching overall is not an abstraction over not having caching.
When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.