What are you on about?

When legislation aiming to restrict people’s rights fails to pass, it is very common for legislators/governments to try again shortly thereafter, and then again, and again, until some version of it eventually does pass. With each revision, some wording might be replaced, or weak assurances added, or the most obvious targets changed to placate the loudest critics. It might be broken up in to several parts, to be proposed separately over time. But the overall goal remains the same. This practice is (part of) why vigilance and voting are so important in democracies.

There’s nothing “deep state” about it. It’s plainly visible, on the record, and easily verifiable.

As someone who knows two people that worked for the Swiss government closely

This is an appeal to authority (please look it up) and a laughably weak one at that.

There is no big plan to weaken encryption or anything.

You obviously have not been keeping up with events surrounding this topic over the past 30 years.

Not against a government that can compel the organizations who issue the https certificates and run the https servers. And not against leaks that occur outside of https.

The Tor network cannot protect against that, because the attack circumvents it. Certain tools, like the Tor browser, do have protection against it (as much as they can) when you use them correctly, but they cannot keep users from inadvertently opening a link in some other tool. Nor can they protect against other software on a user’s device, like a spyware keyboard or the OS provider working with law enforcement.

It would be easy to dismiss the headline’s claim because Telegram’s design makes it arguably not a privacy tool in the first place.

However, it is possible that this arrest was chosen in part for that reason, with the knowledge that privacy and cryptography advocates wouldn’t be so upset by the targeting of a tool that is already weak in those areas. This could be an early step in a plan to gradually normalize outlawing cryptographic tools, piece by piece. (Legislators and spy agencies have demonstrated that they want to do this, after all.) With such an approach, the people affected might not resist much until it’s too late, like boiling the proverbial frog.

Watching from the sidelines, it’s impossible to see the underlying motivations or where this is going. I just hope this doesn’t become case law for eventual use in criminalizing solid cryptography.

It is very important to mention that you mean end-to-end encryption. The data is stored encrypted when using cloud chat.

In response, it is very important to mention that point-to-point encryption and encryption at rest are next to meaningless with respect to the chat participants’ privacy. They might be relevant to the case against Durov, but they don’t protect against leaks or compromised servers. Please don’t rely on them for your safety.

It has been a while since I looked at Wire, and I didn’t look very deep, but here’s what I noted:

Self-hosting was unavailable at the time.

I believe they violated their privacy policy a while back, by accepting new owners/investors without notifying their users. That kind of behavior is telling of what to expect from an organization, and potentially dangerous (depending on your threat model) if you’re trusting them with anything, such as…

I have read complaints that they stored cleartext contact lists on the server, but I haven’t verified this myself. (The first two points were already deal-breakers for me, so I didn’t bother.)

New?

That does seem like a decent workaround for the multi-device problem, if you only communicate in small groups and each member only has a couple of devices. Directly addressing each other could get unwieldy fast as a group (or the number of devices) grows, but I’m guessing you’re not in that situation. Nice work.

I feel like this is being unnecessarily harsh to the majority of potential users.

I don’t know why you would think it harsh to point out shortcomings in software. It’s not a matter of opinion. These limitations exist, plain and simple, and some of them are not easily discovered from a quick visit to the SimpleX home page.

By listing them here, it saves everyone else the time and trouble of having to investigate on their own. (Unless they assume I’m lying or don’t know what I’m talking about, but I can’t help them with that.) It might also save some people from starting to build their network of contacts on a particular messenger, only to later discover a deal-breaking problem and have to start all over, asking all their contacts to switch again.

What would you consider ready for general use?

I can’t make a single suggestion to fit everyone else’s needs, because there is no messenger that addresses everyone’s needs. All of them have different tradeoffs, so we have to prioritize the things we want.

For myself and my contacts, Matirx does all the things we must have: Free, anonymous, good crypto, audited, multi-platform, multi-device, not centralized, self-hostable, reasonably easy to use, and delivers messages (without time limits) even when we’re offline. It even supports some nice extras, like screen sharing and voice calls.

Matrix detractors generally complain about certain metadata not being encrypted, which is technically true: A few things like the usernames that have joined a room, and avatars (if you set one), have not yet been moved to the encrypted channel and can therefore be seen by your homeserver admin. Frankly, it’s not a high enough priority for us to be driven away from a tool that meets our needs. Protecting the content is our priority. We could self-host a server to protect the metadata, but we don’t bother, because it’s not part of our threat model.

Would I recommend Matrix for high-risk work, where state authorities finding out who you’re talking to could threaten your safety? No, at least not in its current state. Communications like that demand very specific protections, and those protections don’t exist in any messenger that has the conveniences and features that I expect from a modern chat service. That’s (one of the reasons) why whistleblowers and targeted journalists turn to special tools. Having a separate tool/platform for high-risk work is fine; giving up features to meet those needs is a perfectly appropriate tradeoff.

But again, that metadata issue is not a risk factor for us. We’re certainly not going to reject a uniquely useful chat platform because of it.

Back to your question:

I don’t post on social media telling everyone to use the same tool I do, because I don’t know everyone’s needs, and I do know that a few people have very specific needs that don’t match mine.

However, it turns out that the vast majority of the people I’ve talked to about this stuff have needs similar to mine, so Matrix (the protocol) often ends up at the top of the list of things to consider.

My main reservation in suggesting Matrix for general use right now is that the official reference clients (they’re called Element on every platform) still have some rough edges. For example, occasionally sending messages that cannot be immediately decrypted by the recipient unless they jump through some troubleshooting hoops, and a search feature that isn’t implemented in all clients yet. The underlying bugs have been steadily disappearing, so these issues are becoming less and less common, but since they’re not entirely solved yet, I use an alternative client and avoid suggesting Matrix to mom and dad for now.

I already use it daily with friends (who I can help if a problem comes up) and people who are comfortable with troubleshooting on their own. It’s visibly moving in the right direction.

Their queue IDs are user IDs. Each one points to a specific user. You can call it a queue ID, or an account ID, or a user ID, or an elephant, but that doesn’t change what it is.

They crate a different ID to share with each contact in 1:1 chats, but that doesn’t make them anything less than user IDs. You can do the same thing on any other chat service by creating a different account to reveal to each contact. (This is obviously easier to manage on clients that support multiple accounts, but again, that doesn’t change what the IDs do.)

And in group chats, they don’t even do that; they reveal the same ID to all group members.

On SimpleX? No, there is not. LAN tethering is not multi-device support.

That assumes the community can maintain enough public queue servers to deliver on its privacy promises and provide a good level of service.

Things I didn’t like about Session when I looked at it:

• Small group size limit
• Forward secrecy has been removed
• Isolated, app-specific onion network seems destined to forever be inferior to something like Tor, at least where privacy is concerned
• Immature codebase (time and dedication could solve this, of course)

From two days ago:

https://lemmy.ml/comment/13108576

A few SimpleX shortcomings beyond what you noted, in no particular order:

• No multi-device support.
• Adding contacts requires sharing somewhat large links (as either text or QR code) which can be inconvenient.
• Messages are lost if not retrieved soon after they’re sent. (I think it’s 21 days by default. I’ve had vacations longer than that.)
• No group calls.
• Group messaging is full-mesh, meaning that as a group grows, the network traffic will balloon faster than it would with any other topology. This is generally bad for high-traffic groups, but it might be okay if they stay small or everyone always has great unmetered connectivity.
• The claim to not have user IDs is misleading at best, and outright false in group chats.
• The desktop app uses Java, which will be unappealing to more than a few people. (To be fair, several other messengers use Electron, which is also unappealing to more than a few.)

It does have some neat design ideas. I don’t consider it ready for general use, but I look forward to seeing how it develops.

You’ll probably get more help here: https://xdaforums.com/

Nobody owes you their time or their patience. If you want help understanding something, I suggest you tone down the fearmongering, manipulative, adversarial comments. If you’re just looking for a fight, kindly go elsewhere.

I think SimpleX is better in everyway.

A few SimpleX shortcomings beyond what you noted, in no particular order:

• No multi-device support.
• Adding contacts requires sharing somewhat large links (as either text or QR code) which can be inconvenient.
• Messages are lost if not retrieved soon after they’re sent. (I think it’s 21 days by default. I’ve had vacations longer than that.)
• No group calls.
• Group messaging is full-mesh, meaning that as a group grows, the network traffic will balloon faster than it would with any other topology. This is generally bad for high-traffic groups, but it might be okay if they stay small or everyone always has great unmetered connectivity.
• The claim to not have user IDs is misleading at best, and outright false in group chats.
• The desktop app uses Java, which will be unappealing to more than a few people. (To be fair, several other messengers use Electron, which is also unappealing to more than a few.)

It does have some neat design ideas. I don’t consider it ready for general use, but I look forward to seeing how it develops.

People need to get this through their heads, XMPP is the only solution for their problems.

On the contrary, you need to understand that your own needs and priorities do not match everyone else’s, and that XMPP is not a good fit for every use case.

(Your rant was amusing, though. I hadn’t seen one like that in a couple weeks.)

deleted by creator

Robots.txt: Do not index this particular area.

Problem is that you’re also blocking search engines to index your site, no?

No. That’s why they wrote “this particular area”.

The point is to have an area of the site that serves no purpose other than to catch bots that ignore the rules in robots.txt. Legit search engine indexers will respect directives in robots.txt to avoid that area; they will still index everything else. Bad bots will ignore the directives, index the forbidden area anyway, and by doing so, reveal themselves in the server logs.

That’s the trap, aka honeypot.