The "recordings" are of a phisher attempting to get information from the author. It proves nothing about what Coinbase knew.
The author turned the information over to Coinbase, but that doesn't prove Coinbase knew about their breach. The customer could have leaked their account details in some other way.
I sent the phone recording and emails to coinbase, and they acknowledged them saying "This report is super robust and gives us a lot to look into. We are investigating this scammer now."
The recordings don't prove anything about what Coinbase knew.
I stand by my statement that the title is clickbait, as it's misleading on two fronts:
- It's the email, not the call recording that proves what Coinbase knew, but "recordings prove" sounds more sensational
- The email proves that Coinbase was aware of a sophisticated attack against a single user. You didn't have enough information to prove that there was a large scale leak of Coinbase customer data. There are sophisticated attacks against individual Coinbase users all the time due to the value of the accounts there.
It seems like you did a great job collecting info and reporting it. Still, how do you know that the info was obtained via Coinbase? Certainly they are a likely vector but you are too, and maybe there are others.
I listened to the first episode of the Telepathy Tapes, but then I read this article[0] and watched this video[1] of someone using a spellboard with their child and felt like Telepathy Tapes had deceived me.
I hope the people facilitating communication in the podcast aren't faking the communication as obviously as in that Instagram video, but the rest of the article showed specifics of the podcast where it feels like the host is using "sleight of hand" to present evidence in an overly strong way.
FC is always fake even thought the facilitator usually believes earnestly that it is real. It works partially through the ideomotor effect where the facilitator subconsciously makes physical queues to the letter they are thinking of next. There are plenty of tests where the facilitator is blind to a piece of information that the subject of facilitation can see and the FC always fails this test.
Are you serious? That video is nothing like the tests in the telepathy tapes, they have kids who don’t need to be touched at all and spell completely independently.
I hate this whole “skeptic” culture so much, it’s just as religious as the people who believe things without evidence. You have a preconceived agenda about things you were told are wacky and you don’t even bother to review the evidence before drawing a conclusion.
There is more rigorous peer-reviewed, published evidence for psychic abilities than most sociological and biological fields.
The Ganz experiment has been reproduced 78 times by 46 different researchers, but sure it’s all fake and a blogger and an one obviously fake strawman instagram video are suddenly enough evidence for the skeptics who constantly demand the highest standard of academic rigor from the other side.
First, the US and Russian governments did spend decades researching these abilities and in the US they CIA, DIA, Army, and other agencies all used psychics. Perhaps they are still using them, or maybe they found satellites and drones easier to work with.
The other issue is that psi seems to have strong statistical significance but low effect size. It’s not a crystal ball, the inconsistent results make it inconvenient for things like stock markets and espionage.
Finally, maybe people do use psychic abilities but they lack the introspection abilities to recognize it. Where do your thoughts really come from? If you’re a stock trader and you have a hunch or insight about an opportunity, where did it come from? Sure you likely gathered data and evidence to support your investment, but didn’t you first have a hunch or a fuzzy idea that seemingly came from nowhere?
We have much to learn about consciousness. I’m not asking anyone to accept psi on faith, but this culture of skepticism boils down to “psi isn’t real because psi can’t be real” and I believe it’s holding back our understanding of reality to be so close minded.
> First, the US and Russian governments did spend decades researching these abilities and in the US they CIA, DIA, Army, and other agencies all used psychics. Perhaps they are still using them, or maybe they found satellites and drones easier to work with.
Yeah, and they all stopped using "psychics" because, shockingly, they were worse than useless. (Please don't tell me the US military has somehow managed to keep actual psychics a secret for multiple decades despite people like trump being involved).
> but this culture of skepticism boils down to “psi isn’t real because psi can’t be real”
No, it boils down to asking for proof when people make claims. And extraordinary claims require extraordinary proofs.
Like, you can believe that stock brokers use psychic powers to get stock tips all you want, people believe in gods and demons and all sorts of things, but if you want this to actually be useful you need to find some way to demonstrate it in a repeatable way.
I provided evidence that demonstrates this phenomenon in a repeatable way, in peer reviewed research. 78 studies by 46 researchers. You just chose to ignore it because you have a dogma to push and don’t actually care about reviewing the evidence without bias
I was curious and read through the paper you linked. Here's my shot at rational thinking. A few things stood out:
1. Arbitrary prior
In the peer-review notes on p.26, a reviewer questions the basis of their bayesian prior: "they never clearly wrote down ... that the theoretical GZ effect size would be "Z/sqrt(N) = 0.1"
The authors reply: "The use of this prior in the Bayesian meta-analysis is an arbitrary choice based on the overall frequentist meta-analysis, and the previous meta-analyses e.g. Storm & Tressoldi, 2010."
That's a problem because a bayesian prior represents your initial belief about the true effect before looking at the current data. It's supposed to come from independent evidence or theoretical reasoning. Using the same dataset or past analyses of the same studies to set the prior is just circular reasoning. In other words, they assumed from the start that the true effect size was roughly 0.1, then unsurprisingly "found" an effect size around 0.08–0.1.
2. Publication bias
On p. 10, the authors admit that "for publication bias to attenuate (to "explain away") the observed overall effect size, affirmative results would need to be at least four-fold more likely to be published than non-affirmative results."
A modest 4x preference to publish positive results would erase the significance.
They do claim "the similarity of effect size between the two levels of peer-review add further support to the hypothesis that the 'file drawer' is empty"
But that's faulty reasoning. publication bias concerns which studies get published at all; comparing conferences vs. journals only looks at already published work.
Additionally, their own inclusion criteria are "peer reviewed and not peer-reviewed studies e.g., published in proceedings excluding dissertations." They explicitly removed dissertations and other gray literature, the most common source of null findings, further increasing the prior for the true publication bias in their dataset.
4. My analysis
With the already tiny effect size they report of Z/sqrt(N) = 0.08 (CI .04-.12) on p.1 and p.7, the above issues are significant. An arbitrary prior and a modest, unacknowledged publication bias could easily turn a negligible signal into an apparently "statistically significant" effect. And because the median statistical power of their dataset on p.10 is only 0.088, nearly all included studies were too weak to detect any real effect even if one existed. In that regime, small analytic or publication biases dominate the outcome.
Under more careful scrutiny, what looks like evidence for psi is just the echo of their own assumptions amplified by selective visibility.
I'm a casual fan of Zig for hobby development, so just as a data point:
I find Zig to be a pleasant option for code that requires high performance. I find it strictly dominates C as an option, as Zig outperforms C on every criteria I care about in a language's developer experience.
I often see people compare Zig to Rust and complain that Zig doesn't have Rust's safety guarantees. I don't know Rust, but looking at it casually, the language itself seems to have a lot of complexity that doesn't appeal to me, and I'd still prefer Zig to Rust. If I need memory safety, I'd rather write in Go or Python.
When I read articles like these, the gotchas they find don't seem that compelling to me. It's always like if you write your code in a deliberately confusing way to confuse the compiler, you can get incorrect results, but I don't care because I would never write code like that.
I recommend not using an LLM to write your posts for you. It makes your writing sound bland and similar to the infinite other LLM-generated posts polluting the web.
On tech-oriented sites like HN, Lobsters, and reddit, readers are going to notice the style, and it will turn them off. Generally, people on HN find it rude to share AI-generated blog posts here.[0]
You can use an LLM to get feedback on your writing, but you should be the one making decisions about the actual words you write, not just blindly delegating the whole job to an LLM.
I'm a software developer, but I took a brief career break in 2011 to try B2B sales for an ISP. I was the only sales rep with experience as a developer, so I was always looking for ways to use my software skills to get an edge as a sales rep.
The most valuable prospects were businesses in buildings where we had a direct fiber connection. There were sites online that purported to list the buildings and leads that the company bought from somewhere, but the sources were all really noisy. Like 98% of the time, the phone number was disconnected or didn't match the address the source said, so basically nobody used these sources.
I thought MTurk would be my secret weapon. If I could pay someone like $0.10/call to call business and confirm the business name and address, then I'd turn these garbage data sources into something where 100% of the prospects were valid, and none of the sales reps competing with me would have time to burn through these low-probability phone numbers.
The first day, I was so excited to call all the numbers that the MTurk workers had confirmed, and...
The work was all fake. They hadn't called anyone at all. And they were doing the jobs at like 4 AM local time when certainly nobody was answering phones at these businesses.
I tried a few times to increase the qualifications and increase pay, but everyone who took the job just blatantly lied about making the calls and gave me useless data.
Still, I thought MTurk was a neat idea and wish I'd found a better application for it.
Sorry for the offtopic comment, but it's bizarre to me that Google is hosting their book on Github with a github.io domain. Their previous two SRE books are hosted at https://sre.google on Google-owned IPs.[0]
What was that decision process? "We're Google, and we're literally writing a book about how good we are at hosting services. But hosting some static HTML files that are almost entirely text? That's a tough one. We'd better outsource that to one of our competitors."
I think one is a portal for GitHub developers, while the other is a public polished site. I reminisced the early Google forthright attitude that made life so simple and human.
sre.google links to this book, but it links to github.io. The other two books linked on sre.google point to within the sre.google domain, so this is the odd one out.
These criticisms all feel very nitpicky and subjective. So many of them seem to boil down to, "this is an opinionated configuration, but their opinions differ from my opinions."
This part was where I stopped taking the article seriously:
>Moreover, taking into account that the system relies heavily on sudo (instead of the more modern doas), and also considering that the default installation configures the maximum number of password retries to 10 (instead of the more cautious limit of three), it raises an important question: Does Omarchy care about security?
This is such a reflexive and petty critique. How many real world security breaches happened because a login prompt that requires physical access limited to 10 tries instead of the "more cautious" limit of 3? And do you even care about security at all unless you limit to the even more cautious limit of 2?
Moreover, the entire Omarchy ecosystem is held together by often poorly written Bash scripts that lack any structure, let alone properly defined interfaces. Software packages are being installed via curl | sh or similar mechanisms, rather than provided as properly packaged solutions via a package manager. Hansson is quick to label Omarchy a Linux distribution, yet he seems reluctant to engage with the foundational work that defines a true distribution: The development and proper packaging (“distribution”) of software.
Because it's opinionated? So maybe there are scripts that use sudo, and perhaps he needs more than 3 tries to fat-finger his password?
Personally, my opinion, I use sudo, and if I take more than 3 goes then I deserve a timeout to get my act together. Anyway, 10 attempts isn't enough to brute-force a decent password, and if bruteforcing is a concern then add 2FA codes or hardware.
There's more serious concerns in the article though - the part about the screensaver / hyprlock? That's just security theatre.
I’m all in for opinionated software, but not in the cases it is made by people… (if not vibe-coded, lol) by incompetent people. That’s what the article is about if you were to read it longer than you mentioned. Great that you are the top comment, summarises this community for me.
>This is such a reflexive and petty critique. How many real world security breaches happened because a login prompt that requires physical access limited to 10 tries instead of the "more cautious" limit of 3?
> Omarchy takes security extremely seriously. This is meant to be an operating system that you can use to do Real Work in the Real World. Where losing a laptop can’t lead to a security emergency.
lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password? Especially since it's not vetting that actual security of the password itself?
How many times does your bank allow you to type in the wrong password? Is it 10? Cmon.
>lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password? Especially since it's not vetting that actual security of the password itself?
It should, but anything below 100 guesses or so is kind of fine, unless the attacker knows you and has good guesses about your password.
Let's be generous and assume a six character password of all lowercase letters. That's 26^6 possible passwords. That's 3x10^8 possible passwords.
3 guesses means that you have a 0.000001% chance of guessing the password, whereas 10 guesses means your chances are 0.0000032%. Are you worried about a 0.0000022% difference?
The odds are slightly scarier if you limit it to English words, but I still doubt that 3 vs. 10 has any meaningful difference in practical terms.
I'm not seeing why 10 is so significantly worse than 3... How big of a difference is that, really? I believe it took something like 6 failed attempts for my bank to lock me out.
But why change the default? Is this in the top 10 things you would do after installing your distro of choice?
To me, this indicates a lack of judgement around what should be prioritised, which is reflected across the many issues the post raises. Naturally judgement is an acquired skill, which novices lack (and which they gain through experience and guidance), but given the big names associated with the project, that doesn't reflect well on their other projects.
> lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password?
I will absolutely say that a distro making that claim should not worry about the difference between 3 and 10 password attempts on sudo (i.e. when you're already logged in).
> Especially since it's not vetting that actual security of the password itself?
Yes, that should be fixed. But it's a separate matter.
At this scale? No, no they do not. Even if you know my password is a single dictionary word in lower case, the odds of you guessing it in 3 vs 10 guesses is negligible.
In fact, let's do this right now: I've just thought of a random english word and written it down. I'll give you 20 guesses. Guess it right and I'll agree with you.
"Hey guys, I'm going to prove that an OS that claims that you don't have to worry about security anymore is actually secure by asking a total stranger to guess my password"
Since it's so flimsy and insecure, you should guess so you can prove how insecure it is. Alternatively, you could fail to do that, because 10 guesses is safe even against an awful password.
lol But what if, and I know this sounds absolutely insane, the person who stole your laptop knows you and isn't a total stranger on the internet? In your security guru mind, would that effect the probability of them guessing right? Or are you of the opinion that you don't need to worry about people close to you breaking into your stuff?
If someone steals your laptop, then sudo limiting guesses is completely irrelevant. Note that I started with
> I will absolutely say that a distro making that claim should not worry about the difference between 3 and 10 password attempts on sudo (i.e. when you're already logged in).
If you'd like to point out that it's really important to require a high-entropy password for the lockscreen or disk encryption, then I'll agree, but that isn't the argument we're in right now.
Agree with this 100%. The article reads as a super gatekeepy “he made different choices than me so I’m going to trash it and him” piece. The author’s perspective seems to be “how dare he use bash scripts! REAL programmers use system level languages”. Come on buddy.
Author claims there is no structure to the project but one look in the GitHub repo says there clearly is. Also, how many users will now try Arch (or Ubuntu via Omakub) as a result of this? If the answer is a positive number and DHH wants to put his time and weight behind it, that’s a good thing.
I'll admit I read only the summary linked at the beginning, so I surely skipped over minutae that might have lost me. That said, I disagree with this and gp: the conclusion strikes me not as gatekeepy but reasonable and humane to inexperienced users:
> In fact, it is Omarchy that complicates things further down the line, by including a number of unnecessary components and workarounds, especially when it comes to its chosen desktop environment. The moment an inexperienced user wants or needs to change anything, they’ll be confronted with a jumbled mess that’s difficult to understand and even harder to manage.
> If you want Arch but are too lazy to read through its fantastic Wiki, then look at Manjaro, it’ll take care of you. [...]
> On the other hand, if you’re just looking to tweak your existing desktop, check out other people’s dotfiles and dive into the unixporn communities for inspiration.
That strikes me as very fair. I don't think it's gatekeeping to say that setting users up with a "distro" that eschews package management for a pile of curl|sh invocations is a bad idea for which there are much better approaches.
That commentary proves that the guy doesn't get it or is being a willfully obtuse hater. One of the big reasons people have been gravitating toward Omarchy is because they don't want to spend hours ricing or tweaking their desktop, they want to be getting shit done after a sub-15 minute install. And Omarchy does that very well. That's what omakase and "opinionated" mean.
That sounds fine for those first 15 minutes and maybe first weeks though. What if a certain `curl | sh` fails after a month? What if I need some other stuff down the road? If anything the article's criticism makes sense from the perspective of needing to get work done, and omarchy seems to be focused more on the aesthetics. A package manager is exactly what is needed to get shit done instead of tweaking and troubleshooting stuff.
Omarchy is fine as an (opinionated) collection of dotfiles and configurations, but there are reasons proper distros are useful aside from wanting to spend time tweaking stuff or whatever. I don't see how the article talks about anything else than practical issues with it.
Omarchy is a very fast moving target at this point. I have every expectation that in the near future, they'll develop a package manager. I agree that Omarchy is not yet a "real distribution", but it's undeniable that it's rapidly heading in that direction.
No one should use this script, EVER. It's a disaster waiting to happen. DHH is a fucking liar, it's not even a distro and he's ripping off the hard work of Arch and several other open source projects and using it as his own creation
No, I saw that bug in the issue log, but I never hit that personally.
If you're running into it, I'd test again with the latest release (0.5.1) and see if it's still present. If so, I suspect it would get more traction from the dev team if the report was complete, as it's currently missing repro steps and the litestream.yml is not compatible with 0.5.0 (it still has "replicas" plural).
Oh, thanks for the correction! I can't believe I never noticed that. I've updated the post.
After your comment, I thought, "Oh, I should contribute a PR to the repo to add the Docker badge so the Docker image is obvious to everyone," but it turns out the badge has been right there for four years.[0]
What I suspect happened is that I tried to use the Litestream Docker image once, discovered that image was amd64-only (until 0.3.9), so I didn't use it because I needed ARM, and then I just kept copy/pasting my workaround from project to project.
The "recordings" are of a phisher attempting to get information from the author. It proves nothing about what Coinbase knew.
The author turned the information over to Coinbase, but that doesn't prove Coinbase knew about their breach. The customer could have leaked their account details in some other way.