Yes. Honestly it’s way too stimulating — I read way faster than I listen, so when I scroll quickly it just feels super off. Also, the content is just tech people talking — it’s cool how it’s like an sf house party but 24/7 but there’s a reason I only go to those 3 hours a week at maximum. Will like to see how it evolves though, always love to see new social media projects.
Ah, I get it! The playback speed options can be a bit off-putting when you're quite used to reading fast. So far, yes it's a lot more tech people but that seems to be changing slowly.
I like the newness in terms of just voice (the experience), and feeling it a lot more personal while hearing all these usually distant and far-fetched people!
Beeper at least has source code for the bridges, which you can have some hope is the same code that they run and that they don't get court orders to look at the messages.
If they ever chose to implement remote attestation for bridges, and you chose to use an open source matrix client to control your local keys, there is at least a potential path for you to prove they can't look at messages so you don't have to trust them.
You also have the option to self host bridges and take your ball and go home at any time, given that Matrix is an open protocol. Minimal lock-in.
Texts.com by contrast is completely proprietary as far as I can tell, with no path to self host, so it is strictly worse than Beeper in every way in terms of transparency.
So you tell user devices to run any code of your choosing, and no one but you is allowed to look at that code. Presumably you do not use reproducible builds, because almost no one does, so the choice of which code runs on user devices likely comes down to a single system administrator or release engineer.
A court order or someone holding a rubber hose could instruct that release engineer to ship tweaked code to any number of devices that sets "42" as the random seed for private keys, allowing anyone with that knowledge to decrypt all messages in transit covertly.
It would be in the best interest of your shareholders to lie if this was ever to happen.
Without the code being open source, everyone should assume this is the case.
Messengers are a massive target, and a target of that size on one person is certain to be exploited.
One of core areas of my research is supply chain attacks, and you have no hope of providing strong defense against them without open source reproducible builds.
I agree that open source is very important — it’s one of the core values here at Automattic, where we have a long track record of open sourcing our products and vast majority of what we make is already open source.
Texts connects directly to the platform, from your device, without using any Texts servers having any access to your messages (even in encrypted form) and without breaking the E2EE the platform provides (for platforms that support that), similar to Beeper’s new Signal integration.
A major benefit of this is you can verify what requests are made and what responses are received. You can also use Texts, not upgrade, and would run the same WhatsApp code for example until you upgrade. Same can’t be said for WhatsApp Web for example. It might also be easier to compromise the platform themselves for a government entity, if that’s our threat factor.
It should go without saying we take user privacy and security very seriously, and have restrictions around who can build, sign and distribute our binaries.
I do hope to see something like Texts fully open source, as then it becomes instantly a Beeper killer.
Until then at least hearing if you are willing to to be transparent about your supply chain security strategy would be a great start.
Some of the supply chain integrity tactics I find most companies skip:
1. Are all commits signed with personal engineer HSMs (yubikey, nitrokeys etc)?
2. Are all reviews similarly signed by someone other the author?
3. Does tamper-evident CI/CD (that no single engineer can manipulate) verify these signatures?
4. Is the code for release binaries reproducible?
5. Does more than one system controlled by different employees (or ideally a third party audit firm) build the code at least a second time and get the same hash?
6. Are the app signing keys managed with multi-party custody? (Threshold signing, multiple-in-person witnesses to airgapped signing, or managed in a remotely attestable secure enclave running reproducible firmware?)
7. Does the signing system verify multiple reproducible build signatures before issuing app-store signing keys?
8. Do you provide standalone signed binaries for users to side-load on de-googled devices so users can remove google (and their many partners) from their supply chain attack surface?
9. Do you review any/all of your third party dependencies, and every update to them?
10. Do you build exclusively with multi-signed reproducible OS and system packages?
11. Do you have published audits from reputable third party security firms attesting all your security claims, and all of the above? (Ideally with the exact hashes of the binaries whose sources they audited)
My team and I help companies with most of the above regularly for highly targeted orgs, but it takes a lot of engineering hours to get this stuff right. Failing to do any of the above would put a massive target on a single human or system, and in my experience this always results in a compromise one way or the other for a highly targeted service such as yours.
It is honestly much cheaper to just open source reproducible code, and let the community help check some of supply chain security and accountability boxes for you.
I highly doubt Beeper gets much of the above right either, but by allowing you to self host open source bridges, they grant users with higher risk profiles the option to not trust them a bit less. Granted, if you are self hosting bridges with an open source client, then there is no reason to pay Beeper.
IMO the only reasonable move in this space is to provide turn-key remotely attestable open source bridges paired with an open client to save users work without asking for trust.
Full disclosure, I did do some security and infrastructure consulting work for Beeper a few years ago.
most software available is not open source. Any app you download from the iOS App Store might not even match what an entity claims to be its open source repository. Any app or service with a backend of any sort that you don’t host is not auditable by you.
Self hosting is fantastic, but it is 100% not common and especially not something most people are interested in setting up. So your framing that this is objectively terrible either applies to nearly the entire software industry or isn’t a fair framing.
> and you realize you've become a perpetual debt slave to the corporation that inflicted this upon you
By the look of it, he's an adult who made a conscious decision. I'd like it to change, but we all know what the risks are of going against megacorps and the system that protects them. He inflicted this on himself...
Slightly tangent, I vividly remember how a bit more than 15 years ago the ruling class would compare streaming services to paying a fixed fee for anything you want in a shop. Likely repeating what was on the leaflet of the lobby of the editors. At the time it was mainly Deezer here, now that it's an industry worth a few hundred billion dollars across all kind of medium, it's all fine and needs protecting.
> we all know what the risks are of going against megacorps and the system that protects them. He inflicted this on himself...
This is textbook victim blaming. I imagine you don’t think he really filed a lawsuit against himself. Someone else made the decision to throw this guy in prison and garnish his income, probably until he passes.
Not that I disagree with it per se, just this language reads as a sort of “culpability laundering”. Another way to say practically the same thing: “He got what was coming.” Even if it’s literally true, “what was coming” isn’t necessarily deserved.
I feel like with this kind of reasoning, everyone is always a victim regardless of their actions. This man intentionally played a game that is known to be rigged and lost...
> “what was coming” isn’t necessarily deserved
For sure, and I agreed with that at the beginning of my previous comment
> Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for the law.
> Martin Luther King Jr.
My conscience is thoroughly aroused. I see the absurdity of the laws they used to punish him. Others will see it too.
(author here) How do you know what's a prompt injection vs actual content? If you train another LLM to tell you what's a prompt injection, how do you know it has 100% coverage of all possible injections? OpenAI has been battling people trying to bypass their prompt re-write filter, and as far as I can see, not really winning, just constantly adding stuff to their blocklist until the next thing gets discovered.
Logged in to say exactly this. I thought I understand computation after my degree, and this book, while far from perfect, did an incredible job of bringing fundamental computation to life in the readers mind.
I'm looking forward to diving into the second edition and hoping the second half is better than the first edition.
I feel like computer science degrees rarely get into much of the hardware beyond some basic assembly. You might have benefitted from taking some computer engineering courses which cover the topics in this book in much greater detail.
Even some people actually working on compilers still talk about pipeline stalls in a ye olde pentium/RISC sense rather than the out of order monsters we have today.
Interesting my CS degree had a required introductory Computer Engineering course which itself had a pre-req first year course where we learned digital logic (among other stuff).
We didn't go quite as far as this book seems to but definitly got a decent grounding in how computers actually do their thing before it was back to theory.
