Earlier quoted context omitted.
Cool, anyone got a referral?
sure: refer.beeper.com/descsi
Thank you!
New Beeper Android app – Open beta test
81–90 of 93 posts
Re: New Beeper Android app – Open beta test
#82I try to register, i receive code, I apply it then unable to register, tried twice, uninstalled this app..
Re: New Beeper Android app – Open beta test
#83Earlier quoted context omitted.
That's exactly what our bridge-manager repo allows you to do. Self-host the bridges yourself, use the Beeper client app.
What I'd really like to do (and the poster you responded to) is to connect your app to my own self-hosted matrix-server.
I'm confused about the downvoting. This is absolutely what a lot of tech people want to do, use the nice client and self-host.
Re: New Beeper Android app – Open beta test
#84So all of the messaging apps I use are just damn protocols?
Re: New Beeper Android app – Open beta test
#85Earlier quoted context omitted.
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 n…
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 (f…
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.
Re: New Beeper Android app – Open beta test
#86So all of the messaging apps I use are just damn protocols?
Always have been
Re: New Beeper Android app – Open beta test
#87Earlier quoted context omitted.
[flagged]
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…
Not all open software is secure, but all secure software is open.
Re: New Beeper Android app – Open beta test
#88Anyone have a referral code? TIA
Re: New Beeper Android app – Open beta test
#89Earlier quoted context omitted.
This works?
Does for me, although I do self-host their stack. It's been surprisingly stable, given what's actually happening behind the scenes.
Replaced Signal and Whatsapp on my Android today, got a lot if faith in these guys. But if there's a breach I'm f'ed.
Re: New Beeper Android app – Open beta test
#90Earlier quoted context omitted.
Does for me, although I do self-host their stack. It's been surprisingly stable, given what's actually happening behind the scenes.
Replaced Signal and Whatsapp on my Android today, got a lot if faith in these guys. But if there's a breach I'm f'ed.
If you're that concerned, self-host. It's not too bad with the Ansible script.