The core idea behind the “server-free” design is to keep users’ messages from ever touching the cloud

given that the messages are encrypted, what is the advantage that you perceive in using “the cloud” (servers) only for signaling rather than transmitting the actual ciphertext through them? Wouldn’t your “cloud” servers see “just the metadata” either way?

It saves some costs for you, but it comes at the cost of requiring users to be online at the same time to exchange messages… is there some other advantage that you see?

a server-side check on the Play purchase token

ah, so it will be the kind of “free open source software” which can only be used via Google Play 🙄

Separate forks aren’t interoperable

that’s another thing you should inform potential users of explicitly, if you want to be honest.

i won’t comment on your tor-to-cloudflare-to-google design because i haven’t looked at it and don’t expect i’ll make time to anytime soon.

I don’t think I can avoid cloud services entirely

Lots of similar things are able to avoid cloud services entirely; your perceived need to use them is driven by your so-called “server-free” design which isn’t really free of servers at all because, as the saying goes, “there is no cloud, just other people’s computers”.

You could also use Google’s push notifications but make them optional, btw. Making the protocol have a hard dependency on that is a choice you are making.

when the two peers are within Bluetooth range

having users’ devices transmit fixed identifiers while moving around is terrible for privacy / great for surveillance, and firmly in the category of things which i not only do not recommend but implore people to not build. please don’t.

I’m now focused on defining a solid architecture rather than working on my landing page

But your landing page is still up, and still making unsubstantiated claims and encouraging users to trust in (aka rely on) a thing which is totally half baked. You are still peddling snake oil. You should fix that.

The App is not for sale anyway at the moment, if and when I will eventually try to sell it, I was thinking about a monthly subscription, that would cover the cloud services costs plus some revenue.

I see, now we’re getting down to it :)

A few questions on that front:

1. Did you disclose to your beta users (and the general public you’re asking for help here from) that they/we are doing volunteer work for what you intend to be a for-profit endeavor?
2. How do you plan to limit access to your cloud services so only subscribers can use them?
3. If someone wants to fork the software (assuming you’re planning to keep it under a free software license) presumably users of the fork will not be able to communicate with the users who are paying you, since the whole thing fundamentally requires the cloud infra you’re paying for? Or, if you actually want forks to be interoperable, how do you expect that to work?

you say this is “now documented” but you actually also mean now implemented, don’t you?

I just looked at github and i see that until this commit one hour ago (four hours after i asked) you were actually calling db.collection(“users”).document(peer.userId).get() to read a publicKey from Firebase

Yep, true

thank you for your (belated) honesty on this :)

So genuinely, thank you for your time and feedback, of course I respect the decision, not going to re-post

thank you and you’re welcome

wait a minute… i asked this:

assuming a compromised/compelled google and/or cloudflare, is it possible to mitm people?

and you replied this:

About MITM under a compromised provider, both peers verify each other’s public key independently after one QR scan. The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified. A compromised directory cannot substitute either key without producing a fingerprint mismatch on one side or a failed decryption on the other, and it doesnt hold the private material to do either. The mechanism is now documented in “How MTC Connects You”.

in my first reply here i said that “that sounds reasonable” but now i looked a little closer. you say this is “now documented” but you actually also mean now implemented, don’t you?

I just looked at github and i see that until this commit one hour ago (four hours after i asked) you were actually calling db.collection("users").document(peer.userId).get() to read a publicKey from Firebase. This is my first and last glance at your github for the time being; I’m going to stop reviewing your project for now because the design is fundamentally changing while we’re talking, and not in a transparent way. i shouldn’t need to find out from git that your answer to my question is the result of a change you just made after i asked the question.

I’m also going to share here what i wrote to you privately about why i still don’t want you to post this to !cryptography@lemmy.ml, even now that you’ve removed the claim about not having single points of failure:

i [still] don’t want you to post it to /c/cryptography in its current state. the website is not saying “this is unreviewed cryptography, do not rely on it for anything serious” but on the contrary it says “Why Choose MindTheClub?”, “Uncompromised Security”, “Total Privacy”, “Unbreakable Encryption”, “Privacy Without Compromise”, etc. you’ve written the marketing copy to encourage regular users to rely on your software before having independent review of it; this is backwards.

if your website didn’t say all of those things and you were asking for review of your design and/or source code without simultaneously telling the general public that your “very new” software already provides “Total Privacy”, it would be a good post for /c/cryptography and other places.

HTH.

The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified

that sounds reasonable

The “no single point of failure” sentence conflated three different things (availability, compromise, compelled disclosure) and treated them as one. I’ve rewritten the relevant section.

I wouldn’t say your previous text conflated these things per se; it said all three aren’t possible failure modes when all three in fact are.

And unless I’m mistaken, you didn’t rewrite it but rather simply removed that bullet point altogether? I think it would be more honest for the ‘white paper’ to explicitly acknowledge that Google and Cloudflare are both single points of failure for availability, and also enumerate what an adversary gains by compelling or otherwise compromising them. Assuming your qrcode key verificaion works as described, it sounds like it’s “just” metadata (who talks to who, and when, who is in what groups with who, users’ online/offline and location history, etc) and also the ability to do targeted denial-of-service. Right?

Also it would be nice to disclose what your business model is; presumably you’re paying for these cloud services, but how much? and how long and to what scale can you afford to do so?

I hope you’ll forgive my bluntness; to be clear I appreciate you building something with cryptographic identifiers and not requiring phone numbers, but it isn’t something i would use or recommend as long as it relies on companies like google or cloudflare.

i don’t see any advantage over SimpleX except for that it “doesn’t require a server” (and btw SimpleX’s default preset servers also don’t have a very confidence-inspiring answer to the business model question i asked you here - it’s we’ll do some freemium thing later), but, since you still require cloud services, sacrificing the ability to store-and-forward a message to someone who is offline doesn’t seem like a very good tradeoff 🤔

among the high-level problems which prevent me from taking a closer look at how this works at a lower level:

• it depends on both cloudflare and google. it claims “Groups don’t have a single point of failure. No central server means no central point to fail, be compromised, or be compelled to hand over data.” but it sounds like both cloudflare and google (both companies in the business of surveillance capitalism, as well as other kinds of capitalism, and also longstanding government surveillance partners) are each a “single point of failure”: if either goes down, the system stops working, and if either is compelled to hand over data, they DO have (at the least) useful metadata they can hand over. (i didn’t bother to review it closer so i have no idea if compromising/compelling google and/or cloudflare could ALSO allow key replacement (and mitm) to circumvent the message confidentiality.)
• messages cannot be (re)-delivered until both parties are online simultaneously
• it’s mobile only for some reason, despite not being phone number-based
• i don’t actually think it’s a good idea to reveal one’s IP address (from which location can be inferred) to chat contacts all the time
• it gives strong slop vibes

these attributes prevent me from wanting to look any closer at it.

@GradleSurvivor@lemmy.ml i recommend that you ask your LLM to write a threat model document (first based on the current design you are distributing today, in the interest of honesty, and then a new one for your updated design as it continues to evolve) which explicitly describes which attacker capabilities are needed to perform which attacks. eg, assuming a compromised/compelled google and/or cloudflare, is it possible to mitm people? or collect metadata about people and groups? or selectively denial-of-service targeted users? can a user’s contact silently record their online presence and IP address on an ongoing basis?

in the interest of transparency, after asking your LLM these questions you should publish an updated threat model document which is far more sober and emphasizes what kind of attacks you acknowledge the software cannot prevent before talking about the specific attacks which you believe it can prevent.

One shot rewriting the whole test suite

tridge’s blog post makes it clear that this was not “one-shotted” at all.

You should read the whole thread

I regret reading it; I’ll assume in good faith that it wasn’t LLM generated but it is ironically as confidently wrong as if it were.

It almost (and should have) lost me when it started by quote-agreeing with someone else saying “rsync was basically done until the maintainer discovered vibecoding” - no, pay attention, it was not “basically done”, there were/are a mountain of CVEs!

But then this got my interest:

This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function.

tridge says he has used pytest on other projects and had good reasons not to use it here; I’m inclined to believe him.

But the notion of every test defining its own way to invoke rsync sounded like a valid criticism, and an easy one to verify, so I checked: It turns out that there is in fact a common run_rsync function which is used by the majority of the tests. One test defines its own _run_and_capture function (which differs in that it writes the output to a file, for reasons I didn’t investigate), and it looks like a few others invoke rsync other ways, but the majority of them use the common function.

So, that rambling thread’s sole concrete criticism of rsync’s new python tests turns out to be false.

efforts to intervene, which range from removing perches to hormone treatment and surgery

wtf :(

The 2021 paper OSRM-CCTV: Open-source CCTV-aware routing and navigation system for privacy, anonymity and safety says they published source code at https://github.com/Fuziih but I don’t see it there now (though there is a related project called cctv-exposure).

The final published version of the paper seems to be paywalled; it’s probably on scihub but there is also a preprint of it here on arxiv.

https://github.com/FNBIP/ghost-route (just 3 commits, from February this year) says it is inspired by the paper and “extended to a production-grade multi-mode threat routing system”. It’s a node app you run locally (there doesn’t appear to be a public instance currently) which would be nice if it could work offline but unfortunately “Offline mode with pre-downloaded OSM tiles” is still on the roadmap and it currently lists “A Mapbox GL JS token (free tier works)” as a requirement (which is probably why there isn’t a public instance - someone would need to pay mapbox if they wanted to run it for other people).

I have not tried it; if anyone reading this has or does please post here about how it works!

🎶 it gives you that fuzzy feeling 🎶

“lmao”?

they obviously didn’t RTFM, specifically section 6.4. Loading Missing Firmware

but actually I’m not sure where to find the TNT drivers for Linux anymore… https://www.nvidia.com/en-us/drivers/riva-drivers/ has them for OS/2 and BeOS but no Linux 🤔

edit: ok so https://www.nvidia.com/en-us/drivers/details/21931/ has it for i386 Linux, OP can probably just ask their ethernet LLM to port it to rv128

https://en.wikipedia.org/wiki/Nimrod_Workman

here he sings “Black Lung Blues” and is interviewed by the BBC in 1984

here he is doing the crab walk:

https://en.wiktionary.org/wiki/nimrod has several plausible explanations which predate Bugs Bunny’s use of it

moderator reports still don’t federate to other instances

you are mistaken. reports are federated from the reporter’s instance to the community’s instance, as well as to the instances of all moderators of the community, and to the instance of the user who posted the comment or post being reported.

The visual option is the normal reCAPTCHA (eg) and the audio option is the (quite difficult) thing they’ve been subjecting blind people to for years. Presumably they will keep offering desktop users these options (at least in many/most cases) for a long time still; this new phone-required extra-invasive CAPTCHA is just a hint of where they’re heading. (But already it is apparently actually required for Android users in some cases: https://reclaimthenet.org/google-broke-recaptcha-for-de-googled-android-users …)

Is this something that websites opt into and add to their own site?

Yes.

reCAPTCHA is google’s “anti-abuse” service which many websites use to prevent slightly increase the cost of operating automated crawlers (which somewhat ironically google operates one of the largest of itself, for their search engine).

Before neural networks could solve CAPTCHAs reliably, spammers were solving them with human labor; solving services like anti-captcha.com (intentionally not a clickable link…) today use a mixture of automated and human solvers.

In the future google is apparently building, solving services will need farms of able-to-run-a-recent-android-release mobile devices with some kind of trusted computing hardware, each one of which they’ll have to use sparingly enough to keep usage of its unique ID under some plausibly-human threshold.

And even if you do have a phone and are willing to identify yourself with it, if it is too old to run a recent enough Android you also will sometimes be denied services for being unable to pass a robots’ “human” test.

🤮

Any website using this will simply cease to exist in my eyes.

as i wrote in another recent thread on this topic:

for some reCaptcha-using websites there actually aren’t alternatives. eg many governments, healthcare providers, public utilities, etc are using it :(

I would guess not, given the other recent news about degoogled Android devices also being unable to pass reCAPTCHA.