Open Flowdalic opened 9 years ago
@rugk I'm very serious. When I tell Xabber developers what they should do today, I back my instructions with payment. I think it's fair that anyone who wants to give them instructions should too back it with payment. All by himself, owning responsibility for what he wants us to do. Why should someone on bountysource pay for what @ip4market wishes?
Why should someone on bountysource pay for what @ip4market wishes?
Bountysource does not work that way. Here is how it works:
So if you want to do that, just signup there, claim ownership over the account there and add a prominent link to the top of this issue.
@rugk why should I care how Bountysource works? The one who wants issue solved is not me, but @ip4market . So HE can negotiate the price with us, raise money with whatever means he has, pay us and get the job done.
Not payment. I must ask my daugther first, she has made my xabber account, because I'm ill.
Can you restore my account?
Do not understand your emails. Please wait one week till my daughter come back, she'll say me, what you write. You have no help in German?
@rugk see what you've done?
@heideline Dies ist nicht der richtige Ort für solche Supportanfragen :) This is not the right place for this kind of questions.
I speak about my xabber account, and you write about prices.I need xabber help to restore my account. I have cancel my xabber account by mistake.Thank you for your help, but you arenot right here.Heide Hemmelrath
Generally speaking, this is a place to discuss developer problems, specifically implementing a new feature in this case. You do have a user problem. Please seek help from the Xabber Support Team, not on Github. Unfortunately you are kind of making it hard to follow the original topic of this discussion with your request.
@andrewnenakhov Can you later delete this part of the discussion?
@heideline if you need our help with Xabber account, please email support@xabber.com This thread on Github is not for tech support. It's a place where crytonerds and cryptojerks try to coerce us to develop new functionality for our app so they could feel really safe from surveillance
@vanitasvitae don't wanna delete it, it's the most amusing part of this thread!
I'm waiting for my daughter, she say me, what I can doWhy I can't restore my xabber account and where? I don't find it, that is the question. I have cancel it by mistake.That's all.Heide Hemmelrath Xabber name ( heideline)
@heideline I'm sure your daughter can help you :) Please show her our discussion afterwards ;)
What a bunch of nonsense! Developers want money in advance for code they don't want to write, don't think it makes sense and aren't allowed to offer. Then they accuse their more interested customers for the mistakes of overtaxed noobs and find that funny. Why is this discussion not simply closed if you do not want to fulfil this desire for OMEMO? By the way, thanks to Liberapay I donate regularly for the further development of my xmpp client. However, this is another app that OMEMO already masters and does not abuse its users as junkies. So, what am I doing here? Waiting for Godot? Goodbye!
Don't know, how I come to your side, sorry. I want to restore my xmpp account in Xabber. I get no answer and must read and read and I do not understand.That's not my mistake, but a bad help menagement. Good by! Developer :-)
@Buntbart earlier we differentiated users interested in encryption in two groups: junkies and cryptonerds. However, recently we came to a conclusion that there is also a subset of users who should rather be called cryptojerks. Now, please leave our issue tracker. Forever.
Sorry where I an delete the part of discussion? Developer we need, they our future. ;-).
@heideline don't worry about that. Just send us email to support@xabber.com with details of your account.
Wtf happened here? @andrewnenakhov could not you please delete the comments added by @heideline, which have this huge bunch of email stuff there?
And yeah, I'd also suggest to close this issue here. (maybe even lock it – it may be better :wink:) You seem to not want to implement it, or better can't, because of the legal things discussed before, so leave it as it. Users wanting to use OMEMO should use a different client.
And I better unsubscribe this issue…
Users wanting to use OMEMO should use a different client.
All users should use other client, as thankfully E2E encryption is finally starting to be enabled by default, so this client is starting to be incompatible with modern clients such as Conversations.
@samphunter yeah, Conversations users were very happy when they were forced to have that e2e bullshit forced on them. Processone even changed default config in so OMEMO encryption in Conversations wouldn't work out of the box in ejabberd.
yeah, Conversations users were very happy when they were forced to have that e2e bullshit forced on them.
I was not Converastions user before OMEMO was turned on by default by I am one now and I am very happy that it is forced on users. Unfortunately not everyone cares about e2e and that is fine when two such people communicate. But it is a pain to explain to people how to configure and/or use it as a person who actually cares about privacy. So yeah, even companies like Whatsapp got the memo and enabled e2e by default. And XMPP, which should have been leading the charge is lacking behind, because all the developers can't agree about anything except basic message sending. Here it is OMEMO, Conversations don't want to implement eCards because I don't know... It is ridiculous. I am not surprised XMPP never caught on.
So yeah, you say it bullshit but you are exactly the kind of person who holds everyone back.
@samphunter if you care about privacy, run your own server and communicate within it. The only persons e2e helps against are admins of yours and your chat buddy's servers. But while encryption brings users a false sense of security it also breaks a lot of things that are really important in real life, like server-side history search and device convergence.
But while encryption brings users a false sense of security
First of all, e2e if done right is the only thing that can even start to provide some security without unreasonable amounts of effort.
if you care about privacy, run your own server and communicate within it.
What would be the point? I would not trust myself to run it properly. All my friends would have to use my server or their own, both of which is impractical. The server can't be at my home because village internet and having it at a datacenter ruins the point.
it also breaks a lot of things that are really important in real life, like server-side history search and device convergence.
I really don't understand how it breaks device convergence and modern devices are powerful enough to run client-side searches, so who cares.
So you want to keep all your very safely transmitted messages decrypted on your pocket device? Lol. So if it gets lost, stolen or taken from you, whoever gets access to device will have all your data. So by trying to eliminate one security risk you introduce many others much more severe.
What you don't get is that security and convenience don't fit together well. Encryption nerds lull themselves to be safe because they pressed some magic buttons in some app, only to get hacked via some security hole totally not related to message encryption protocol. Heard about that recent Signal code injection bug?
So you want to keep all your very safely transmitted messages decrypted on your pocket device?
First of all, if nothing else, FDE.
Second of all, what the hell is your point? Yes, if someone can walk up to me and get my device, they will get my messages, whether they are e2e encrypted or not as long as I store them. But for one, I can delete them and be reasonably sure they are deleted unlike with servers, which I can only hope they are doing something. And walking to me and taking my phone is a one time thing. They would probably need a probable cause and a warrant (law enforcement) or risk trying to robb me (other attackers). With unencrypted messages, they can monitor them long term and in bulk without any such extreme measures.
As for code injection bug, sure. How does not encrypting messages prevent that? Or should we just give up, because once in a while, there is a one time bug that almost no-one will be affected by?
E2E is not the final solution, it is a first step. I know that. But without the first step, all the other steps are pointless.
Also, just to illustrate I was thinking about the obtained/hacked device problem and how I think it can be mitigated to reasonable extent: https://github.com/siacs/Conversations/issues/557 Got shut-down as well though. But that is a problem for another day.
I don't get why you are still discussing. If you read the backlog, you can see that both sides already brought every point up against each other.
Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.
If you want OMEMO in Xabber, fork it and do it yourselves :) Xabber is based on Smack and Smack does have a module for that.
First of all, if nothing else, FDE.
That can be quite routinely unlocked by any party that is really interested in getting what's inside. Encrypting database is a bit better, we do it for one of our customers.
Second of all, what the hell is your point? Yes, if someone can walk up to me and get my device, they will get my messages, whether they are e2e encrypted or not as long as I store them.
Point is that crypto-fetishists like the feeling of being secure, but when talking about providing themselves real security, nope, that's too hard to keep own server and control all communications.
You introduce many more security risks to disclosure all your preciousss data to a potential attacker (or thief) by carrying it with you all the time, but you choose to be oblivious to those risks, pretending instead that e2e is the final solution to privacy (while running this perfectly secure messenger on an Android phone). And because real security is too damn hard and requires discipline and dedication, users don't really want that, opting for a cosy feeling of being safe.
Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.
@vanitasvitae money is good enough argument. I think we could do this for just 1₿ ;)
but you choose to be oblivious to those risks, pretending instead that e2e is the final solution to privacy
I specifically said the opposite, that it is just the first step. And once more, attacks on server are many many times easier than on your phone. Especially considering nothing is stopping them to attack your phone anyway.
You introduce many more security risks to disclosure all your preciousss data to a potential attacker (or thief) by carrying it with you all the time
Having them on the server does not protect them unless you log out every time you close the app. It is irrelevant to whether e2e should be used, as this can be solved by encrypting the database.
Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.
I honestly don't care much. I gave up on xabber as I wrote. I just thought I should reply here to prevent someone from buying the anti-encryption BS that is spreading around. E2E is not the whole solution, but it is certainly part of it. The most important first step, as while E2E does not provide perfect security by far, it decreases your attack surface massively.
And once more, attacks on server are many many times easier than on your phone.
Who told you that? Did you ever think that all your assumptions are based on wrong ideas?
Having them on the server does not protect them unless you log out every time you close the app.
It does if you care to do some things to prevent access to message history. We actually implemented it for one of our customers, who really cares about security, and does not only pretends to be caring like most folks here.
Speaking of spreading bullshit, that's exactly why I respond to all this massive outcry to encrypt everything instead of locking it down. Desire to encrypt everything is silly, and most sane developers know this, except those few who promote it as the main feature of their applications.
btw, I wonder if all emails on that Gmail mailbox of yours are encrypted too, or is your e2e crusade targeted only at chats?
btw, I wonder if all emails on that Gmail mailbox of yours are encrypted too, or is your e2e crusade targeted only at chats?
I have PGP set up for email, but I practically never use it, because it is more convenient to switch to a secure IM. Using PGP for mail is just unreasonably hard and there is no reason not to use IM (use best tool for the job).
Desire to encrypt everything is silly, and most sane developers know this
Maybe I am not a sane developer, but I don't believe this. Maybe my assumptions are wrong or maybe yours are.
Did you ever think that all your assumptions are based on wrong ideas?
Yes, but I never found a flaw in them. But considering you seem to be knowledgeable on the topic, you can point out my error if you see any. Here are my asumptions:
There is no practical way a server can improve security in case of device compromise beyond what encryption can do. Reasoning for that is: The only security feature reliant on server I ever heard of in connection with IM is protecting the chat history with additional passphrase. This can be done using encryption for example like this. Let Km be master key derived from sufficiently strong passphrase by sufficiently slow KDF. Let K0 be randomly generated key. Store K[0] in file encrypted by Km. Generate future keys as K[i] = H('1' + K[i-1]), where H is a one-way function (hash). Generate K[1] and destroy K[0] (form memory, not from encrypted file). Keep n starting from 1 as message counter. When a message is supposed to be protected by passphrase (is old enough), encrypt it with K[n], generate K[n+1] and store it. Throw away K[n]. Increment n. Your messages are encrypted and you need to enter the passphrase to decrypt them. To optimize this, after decrypting them for the first time, you can store them in the file encrypted by Km directly and replace K[0] with the current K[n] (+ increment the current n). This is just as resistant to device compromise as server side protection. If a malware is inserted, it can gain future messages in both cases and if passphrase is entered into infected device, it can be captured in both cases. Old messages can't be retrieved from stolen device without passphrase in both cases. Of course there may be other features I never heard of. If there are, please name at least one. But even then, they are not much use if they are not commonly implemented.
Trusting server in addition to the client (phone) creates new attack vectors and therefore increases the attack surface even with a well secured server (nothing is perfect). E2Ee mitigates this, as the server does not have to be trusted.
The assumptions 1 and 2 together mean E2Ee can only improve security, not weaken it.
Regular users who don't know a server provider can't verify providers trustworthines.
Only very few users (insignificant amount) have the skills, resources and time to run their own server. I don't believe I would be able to keep up with all the latest in security of servers let alone pay for all the equipment and SW such as firewalls, IDS... Even then, it is a lot of spent time and resources for something that can be better achieved by E2Ee. And running your own server insecurely would be the real false sense of security.
Assumptions 4 and 5 together mean, that most users can't fully trust the server they use. This is compounded by other factors, such as the inability to physically monitor (and restrict) access to the server room the way you can carry around and always see your phone. Or that you can't use encryption at rest efficiently for server as server needs constant access to the data.
Even users running their own server securely can't easily trust the server of the other communicating party.
If trust is ever eroded in the server for some reason or just plainly better option arisses, it is not trivial to move to a new server as all your contacts need the new ID and you need to changed it wherever it is shown (which if it is somewhere written down in physical format may be near impossible).
Having a secure server only adds security to E2E scheme, it is not mutually exclusive. You can for example store the encrypted chat history on a server to further secure yourself (both server authentication and encryption would have to be broken to obtain your message history).
Trusting a server is at the end of the day reliant on trust in the DNS (and PKI). More accurately trusting the domain name will never be obtained by the attackers. If for example your server closes down and an attacker buys the expired domain, they can get a valid certificate for it and impersonate an XMPP server. All the users trying to communicate with you using your old ID will inadvertently communicate with the attacker instead. This is mitigated by including your OMEMO fingerprint with your ID, for example on business cards.
I have PGP set up for email, but I practically never use it, because it is more convenient to switch to a secure IM. Using PGP for mail is just unreasonably hard and there is no reason not to use IM (use best tool for the job).
@samphunter thank you for proving my point with your own confession. Everything you write boils down to this: you yourself preach encryption everywhere, yet, you yourself use in only when it is convenient enough (or "not unreasonably hard").
And, since e2e is convenient enough for you, you want to force everyone to your level of convenience, and you don't really care if they want it or not. That, my friend, is hypocrisy.
You see, I don't totally oppose the idea of encryption. It should be used when it is appropriate. It is nicely done in best messaging service out there - Telegram. It uses 'super reliable encryption' as it's marketing gimmick, yet, users love Telegram, not for their encrypted chats (that don't even work across all platforms, by the way), but because it works seamlessly on all their desktops, tablets and browsers, because you can search history, because it has great group chat experience. All of this is possible only because Telegram does what WhatsApp and Viber do not try to do (for reasons beyond my understanding) - it stores all users archives on central servers. And encrypted secret chats are used very sparingly in it, only when specifically enabled.
That is a sane model that merges security and convenience in a good enough proportion, and users like it. That's what we're going to build too, one day. And you are pushing everyone to use e2e whether they like it or not.
yet, you yourself use in only when it is convenient enough (or "not unreasonably hard").
You misrepresent what I wrote. I have PGP set up and my PGP key published, ready to send or recieve encrypted mail. I just deem it "unreasonably hard" to ask other people to use it when there is a better solution (IM). I am certainly not ashamed to ask everyone to use IMs that are encrypted by default, as that is virtually ZERO effort on their side. There is no excuse not to use encrypted IM these days, it is that easy. But if they prefer to send me PGP mail, it is not a problem for me either. I just don't ask others to use PGP exactly because they don't have to share my priorities and asking them to use it would be bothersome (inconvenient?) for them.
All of this is possible only because Telegram does what WhatsApp and Viber do not try to do (for reasons beyond my understanding) - it stores all users archives on central servers.
Because that is a relic of an age when mobile devices were not fast enough to do all that locally. Thankfully most companies see that.
PS: And case in point, WhatsApp is vastly more popular than Telegram.
@samphunter no excuse, really? Just one thing, like the capability to have a nice history search in a web client, is a deal breaker for almost anyone who does some real work with XMPP.
@andrewnenakhov Great, so somehow we got from it being useless and bad for security all the way to, it disables one feature and only in webclients, who can't easily do OMEMO properly anyway... Are you trying to argue something or just throwing stuff around, hoping something will stick? Obviously webclients probably can't support this, but we are not on a github page of a webclient.
@samphunter I never told it's totally useless. But the desire to force everyone to press a magic button and pretend they are totally safe and secure is silly. It also breaks not 'one feature' but a number of killer features, like good device sync and server search, which are of paramount importance. And downloading all history from a server to client perform a search is not just stupid, but ultra-stupid.
Anyway, you are totally free to do whatever you like, use whatever products you like, create whatever software you like, just don't try to press me into buying this bullshit about e2e and infect me with this crypto-cancer. For any capable user who really cares about security absolutely same security level can be achieved by running own server without e2e, all without losing all the other features we're working on.
And I'll go on creating software as I like it and as my customers require it - and so far we didn't have any customers who would pay us for development of OMEMO in Xabber. You see, there is no real market demand for that, unlike, say, iOS version of Xabber, proper group chats or voice and video calls and fast device synchronization that we're working on now. Hope that makes my argument clear.
Official public offer: Anyone who wants us to add OMEMO functionality to Xabber for Android should pay us 1 bitcoin. Adding it to iOS and Web version would cost additional 0.5 bitcoin each. With this, I'm locking down this thread until further notice.
The offspring of this years GSOC XSF projects is OMEMO. An axolotl and PEP based open standard for end-to-end encryption. Would be great to see support for it in Xabber.
XEP: XEP-0384: OMEMO Related Smack issue: SMACK-743 ProtoXEP: http://conversations.im/xeps/multi-end.html More info: http://conversations.im/omemo/