Add SMSSecure #1267
Comments
|
And you can find it on F-Droid : They're planning on making F-Droid their main way of releasing the app |
|
I can give a +1 here. Been watching the development of this (was called SecuredText before), and it also recently hit f-droid. The only possible problem I think is that it's a young (as in recent) fork, but go ahead with pull request if you want of course. I don't think it would be a waste time. |
|
One issue I see with SMSSecure is that the SMS transport requires a key exchange. This is prone to user error and is also ugly from a UX perspective. Hence why TextSecure got rid of it. |
|
I see... And most likely they will have the same problems like TextSecure, that you can't export and revoke your keys and that you can't give your public key through another communication channel and that there will be no difference between writing with a person you validated and writing with a person of whom you have a invalid public key... But I think it is better to use this app than writing plain SMS... |
|
True but as sedrubal says I think that is supposed to be more of an intentional "feature", than a bug. |
(I assume you're replying to me?) The fact that key exchange is a feature instead of a bug doesn't mean that we can ignore the fact that it's unideal when considering it for inclusion on PRISM Break. |
Yes sorry. But how else can it be done? Is it possible? Because they can't remove support for SMS like textsecure because that's the whole point of the project. I get your point though, in that it isn't good enough prism break if it has that. But I think it's useful enough to include. While you're right that prism break is all about user friendliness, there's still a wide variety of applications that prism break suggests. And I wouldn't say key exchange is at the bottom of the list in terms of ease of use. Although maybe I could be wrong/biased. Thoughts? |
|
👍 I think SMS isn't dead yet and sending an encrypted SMS is better than sending a plain SMS. But prism break doesn't recommend any SMS app yet, even if you have to send a SMS sometimes... And BTW.: I currently don't get it, why key exchange is not ideal? What do you mean? |
|
👍 |
To be perfectly frank, I don't see this project ever being included on PRISM Break, because I think it's fundamentally flawed. I think the OpenWhisperSystems guys got rid of TextSecure's SMS transport for a reason, and I think that trying to preserve it in a fork is doomed to fail. My impression is that you seem to be approaching this issue (consciously or otherwise) in a way that assumes SMSSecure has a right to be on PRISM Break. I'm approaching it from the opposite: I think SMSSecure should have to prove its worth. I feel like you're simply explaining why SMSSecure has problems, instead of actually offering technical arguments explaining why I'm wrong. (Of course, this are just my personal feeling on the matter. Such are the limits of textual communication.) IMO, Key exchange should be an implementation detail. The protocol should handle it transparently, not the user. This is because a) the user won't be able to fully understand key exchanges and b) will inevitably just trust whatever key they get, or some other equally bad scenario.
Both parties still have to be on the same platform. At which point you might as well use TextSecure. I understand that's a very difficult position, because we don't currently list TextSecure, but I feel very strongly that SMSSecure is not the answer, and I would be uncomfortable recommending it.
Friendly reminder that PRISM Break emphasizes quality over quantity. |
OK, but thre is no SMS app on prism break. (It's like recommending to send plain SMS ;) )
Maybe you're right... We will see. For now It's working fine.
We primary don't list TextSecure because of Google dependency. SMSSecure is not an answer, it's a completely other thing. |
See my remarks below about protocol security vs. medium security.
I wasn't saying that it will fail on a technical level. I was saying that it will fail on a user experience level, and more importantly, I was saying that it already has failed on a user experience level.
But it is an answer. You're responding to the fact that we need something for the gap which TextSecure is supposed to fill. Yes, SMSSecure runs over a different protocol than TextSecure, but we shouldn't be securing protocols. We should be securing mediums. And SMSSecure and TextSecure are the same medium - instant messaging. |
Why? Because it's a fork?
Why not?
If you ask people, I don't think they will say, that SMS is instant messaging. It there are no technical reasons not to recommend SMSSecure I see no reason not to recommend SMSSecure... If there was less discussion about personal likes and dislikes in this repo there won't be more than 200 open issues (each more than 10 comments). And there would be more people contributing interesting stuff... And one app more is not as bad as having no secure SMS app in the list. |
|
Are there still any arguments against SMSSecure? BTW: Recently as TextSecure invented their new design, SMSSecure did this on the same day, so I think you can't say, they "failed on a user experience level"... |
I agree but smssecure does not require internet, which is probably why it's a special case/useful to list. |
|
I undersand strugee main argument not to list SMSSecure
Maybe there are more tech and IT people motivated enough to read prism-break website than general public. And those IT guys can advertise SMSSecure to there friends and family (at least I do). I guess it happens this way around, not the other one. And by doing this we can help understand the way key exchange work so friends and family can have little understanding about what to do to secure their SMS. And for a reason like this SMSSecure should be on the list. Many people have their android phone with GSM ON all day long. Not so true about wifi. |
|
Hey, sorry. I've been having a difficult time keeping up with GitHub for the last couple months. School, and all that.
No, because what they are trying to do is a bad idea.
Because people don't think in terms of protocols. Fundamentally, PRISM Break is about reaching people. So we have to present ideas in a form that make sense to people.
I do. They're profoundly similar. They're both short, person-to-person exchanges that happen largely in real time. Virtually the only difference is that custom IM protocols often support "bonus features" and often can be synced across devices. Look at iMessage. It runs over the data connection, so I assume you'd consider it an instant messaging protocol, right? So if SMS isn't an IM protocol, how was Apple able to transparently upgrade SMS conversations to iMessage, where both recipients used iOS? It's because they're the same medium.
I'm going to go ahead and assume that (while you didn't explicitly mention anyone) this comment was aimed at me. I see where you're coming from. But you have to trust me when I say that this isn't personal for me. I have no personal vendetta against SMSSecure. I care a lot about the mass adoption of secure communication, and I care a lot about the potency of PRISM Break, now and in the future. And that reflects in the language that I use. I've used stronger language against SMSSecure because I objectively think that it would be very bad to list it on PRISM Break, not because I e.g. hate the developers, or hate forking, or whatever. On a technical level, I don't really have a problem with SMSSecure. I think it's pretty sound. But on the UX level, I have issues. And that's what I've been arguing about.
Just because you make something pretty doesn't mean that the underlying concepts and designs aren't fundamentally flawed. User interface design and user experience design are very separate concepts. Sounds like SMSSecure improved their user interface design, which is awesome. I love seeing that in FLOSS. But that doesn't mean that their user experience is fixed. And IMHO, their user experience cannot be fixed, because of all the reasons I've listed in previous comments and above. |
Maybe. But this is not the ideal end goal. We want PRISM Break to reach everyone. |
|
I don't get it, why ux should be bad. It is working, it looks good it is easy to use and intuitive. BTW: if ux is a criteria, why is tox listed? Tox doesn't really work, it's unintuitive and difficult to use (but looks good ;) ) and it's beta (by design). I like tox, too and I'm glad that this is listed, but if tox is listed there is no argument against SMSsecure. |
|
@sedrubal yes very good point! +1 |
|
I'm the same opinion like @sedrubal |
|
Don't really agree that requiring key exchange should keep it off the list, if that's your main user experience argument. Especially when having SMS support makes it "special", not because it would simply be an unique protocol on the list, but because SMS does not require internet.
So it would be useful to such people because they would otherwise send unencrypted (because they have no internet to use any of other listed applications). |
I can't think of any situation where someone would have SMS but no data.
Tox has the "experimental" flag. Surely you are not trying to argue that UX isn't an important part of PRISM Break? See OpenWhisperSystems' blog post on why they dropped SMS support. tl;dr: key exchanges are ugly and SMS leaks tons and tons of metadata. |
Users shouldn't have to understand the concept of a key. Their apps should manage that for them. |
|
"I can't think of any situation where someone would have SMS but no data." |
Oh yes, there are situations. Think of rural areas and cheap mobile providers: there are many areas where mobile network doesn't work, even in Europe. And there are users without Google push on their Android... They are glad about old good SMS.
I think, tox will still be experimental in 5 years, but that's another discussion.
Thanks ;)
OK that's a strong argument. I don't know much about SMS beside the usability. Does it leak more metadata than mobile network? And does SMS only leak metadata on sending SMS? I know silent SMS and other mobile systems weaknesses, which you can't easily get rid of it, even if you don't use it.
I think, users should get a basic understanding of that concept and it mustn't be completely intransparent (WhatsApp). |
|
@dostoy 👍 |
|
@strugee i only have to travel in an other country. the costs for data connection is that damn high that i only would communicate via SMS (if no open WLAN is in range) |
What do you mean? SMS uses GSM, so it can be used without data. And having no data is still very common, just like not having wifi everywhere you go. And there's the case as @ximex mentioned about those with no data plan, like me right now. It's almost like saying "I can't think of any situation where someone would have SMS but no internet connection." Point is that even though you definitely don't want to be using SMS if you can otherwise, you also don't want to be sending unecrypted ones if you really need to. |
|
Can you directly message someone who has the app? |
|
@mastercoms Provided they have a number I believe. |
So would you suggest to remove the GNU Privacy Guard (GnuPG) from Prism-break? |
Eventually. Not in the near- or even medium-term future, because it's the best we can do right now and it has wide adoption. But yes, absolutely. |
|
Also, IMHO, users are willing to put up with a lot more stuff on a desktop. On their phones, users expect things to Just Work™. I don't have any data to back up that assertion, but that's my gut feeling. |
I understand but I don't think that's enough to dismiss the comparison to pgp. But what would you replace pgp with? |
Not according to the OpenWhisperSystems blog post I linked above. |
Nothing, yet. That's why I said long-term. But PGP has a long, long list of problems. When it's ready, Pond looks nice. |
They're talking about third world countires. Doesn't mean it still doesn't apply. |
Wow, stop! This was a rhethorical question, you can't answer "yes". - But that's an other thing. ;)
Ok, I understand that. But you have to try smssecure. It works as good as TextSecure (and Whatsapp, or however these apps are called, young people are used to use in this days ;) ) |
So you want to keep SMSSecure off the list because in the long-term future there will be better options? |
|
Thanks for mention of pond though. Link for readers (isn't exactly the easiest term to search for): https://pond.imperialviolet.org/ |
Why? You can't ask a rhetorical question and then get mad when someone calls you on it. (I realize the above is phrased somewhat confrontationally, which isn't what I mean, but it's very late here and I can't figure out how to phrase it better.) |
I'll try SMSSecure. It's the least I can do. But I'll warn you that it's very difficult to pitch something where you have to even think about keys to young people. And just so we're all on the same page, I'm 16, so when I talk about how to "pitch to young people", I know what I'm talking about. :) |
Imo, it's not that it has to be perfect for everyone. I agree with you in that having to key exchange is clunky. It's simply culture and the vast majority of people will not bother/care/want to understand. But it's that it might be useful for a 'significant' minority of visitors. The downside is that visitors might see SMS as a safer/better option compared to sending messages via the internet (using better protocols that don't leak as much metadata), but my opinion is that the positives are still worth it. |
|
@strugee I'm looking at pond (for the first time obviously, for like the past 5 minutes) and it looks real nice. But it seems to also require key exchanges before any communication can be done. That seems to be the way it's designed to work. In fact, it currently uses pgp for that. Am I missing something, because you can't really replace pgp with something that still uses pgp? You can though replace email + pgp with pond of course. But then your argument about requiring key exchanges with pgp (and hence removing it sometime in the future) doesn't seem to hold up? |
|
Off Topic |
|
Have switched from |
|
#1268 has been merged, so this is fixed... |
Are there any arguments, not to recommend
SMSSecure? Otherwise I'll create a pull request.SMSSecureis a forge ofTextSecure, withoutGoogle APIas dependency (this is why we not recommendTextSecure; see #1140 and #552). But withoutGoogle APIthere is not problem, isn't it?The text was updated successfully, but these errors were encountered: