Snowden triggers flood of Crapware [was: Gruveo, more secure skype?]
On Wed, Jul 23, 2014 at 2:29 PM, Cypher <cypher@cpunk.us> wrote:
On 2014-07-22 23:24, unixninja92 wrote:
Recently found Gruveo[1]. Allows easy video and audio calls similar to cryptocat. Unfortunately not open source and makes no mention of being audited. Otherwise looks very interesting and promising. It tries to use P2P to make calls, and if it fails, then it will go through their servers. Uses WebRTC for end to end encrypted audio and video chat. They claim they don't keep any logs that could identify users.
So the question is, is this an NSA honey pot or something that might actually be trustworthy? It seems at least a bit more secure/trustworthy than skype to me.
Why even consider closed alternatives when you have things like Jitsi[1] available? It's open source, does secure voice, video, and text, and runs on just about any platform (including Android).
[1] www.jitsi.org
Eugen says... RetroShare has quite good P2P audio. It's not properly audited though, caveat emptor.
Ditto. Though it will take some time not just for the open source community to pick which projects to audit under limited resources, but to even develop a real auditing framework within itself to do that under. It's a huge undertaking and responsibility in its own right. Further, what's with crap like gruveo.com, goldbug.sf.net [1], protonmail.ch, and so many more (especially the 'Look, we just solved Email encryption' crowd)? And of the partly open hw/sw stack vendor types like BlackPhone? What are we, some free debunkment service for shills, charlatans, closed source, browser/app/phone loaded crypto/exec environments provided by the service provider instead of reasonably disinterested third parties, keys disclosed, Web3.0, looks like a phone, junk? Sure, ok, it's good that we are, but the dearth of CrapWare and ProCrap analysts and marketers popping up out there lately is ridiculous. And I'm not laying down a universal CrapWare blanket, some of the stuff we see is pretty good, but simply fails to clearly, publicly, and obviously state to its users what risks their model does not cover. That's lack of care, obliviousness, lying, or profiteering... so it lands itself back in Crap territory. To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while. Though the makeup of their lists is perhaps not yet complete/ideal, you'd be better off picking anything from prism-break.org, yes say Jitsi, than this type of Crapware. We should make prism-locked.org just to list all the junk out there. It's good to have more crypto used in the world, but let's at least try to make and promote strong and open solutions. [1] I and others have been displeased with their, shall we say, 'community involvement'. As with the attempts at parallel compilation and auditing of Truecrypt, has anyone attempted that with their code? Tried to contact them? Seen any presentations? Know who they are? Open development? Etc? People say OpenPGP and crypto is hard for user adoption, no gui's for grandma, etc. So when potentially interesting gui tools appear, it's a shame many of them choose to draw these questions and thus seriously limit and tarnish their forward prospectus. At least Gruveo appears to have already answered those questions.
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil: not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On Wed, Jul 23, 2014, at 05:59 PM, stef wrote:
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
I like the idea of this. Are there any check lists out there that can be used to qualify if software is safe? Flipping what Stef wrote, so far we have: - Must be open source - Must be run on the client's machine - Must use non-shared, private key Alfie -- Alfie John alfiej@fastmail.fm
Dnia środa, 23 lipca 2014 23:59:25 stef pisze:
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
So very true. Can we have it named as "stef's six rules of snakeoilness" and spread around? I'm serious, this is important. -- Pozdr rysiek
On Thu, Jul 24, 2014 at 12:34:24AM +0200, rysiek wrote:
Dnia środa, 23 lipca 2014 23:59:25 stef pisze:
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
So very true. Can we have it named as "stef's six rules of snakeoilness" and spread around? I'm serious, this is important.
"7 rules of thumb against snakeoil" is good enough. pls note it's really 7 rules. ;) -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On Wed, Jul 23, 2014, at 06:34 PM, rysiek wrote:
Dnia środa, 23 lipca 2014 23:59:25 stef pisze:
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
So very true. Can we have it named as "stef's six rules of snakeoilness" and spread around? I'm serious, this is important.
I've always been a fan of the Spam Solution checklist: https://craphound.com/spamsolutions.txt Maybe Stef's six rules can be expanded into something like this. Alfie -- Alfie John alfiej@fastmail.fm
neglects general sad state of host security
You mean user host (client endpoint security, for most people nonexistent) or server host? Because at least with the latter, a clever design or threat-model can make server-client pretty secure by simply making the server zero-knowledge. I used to be a total P2P hippie, and P2P is still my preference aesthetically and for reasons of simple resilience, but I no longer regard server-client as an automatic fail, provided the server is zero-knowledge. So, encrypted XMPP/Jingle (Jitsi) is good, whereas lol-not-really-encrypted-server-sees-all Mumble is not. On 23/07/14 22:59, stef wrote:
On Wed, Jul 23, 2014 at 05:24:22PM -0400, grarpamp wrote:
To quote OP... not open source.. not audited.. central servers.. webrtc.. 'no' logs.. and a shiny link for grins... and then claims it 'looks very interesting and promising'. WTF, really? I appreciate innocent questions, but the answer (or at least our response) should be obvious, from those parameters alone, to someone who's been around for a while.
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
-- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com
On Wed, Jul 23, 2014 at 11:40:39PM +0100, Cathal Garvey wrote:
neglects general sad state of host security
You mean user host (client endpoint security, for most people nonexistent)
+ -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On 2014-07-23, 23:59, stef wrote:
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
In order to qualify as snake oil according to this definition, do all of these have to be true, or is any criterion sufficient? Because if it's "any", then this https://www.cylab.cmu.edu/safeslinger/ is snakeoil, which I think is unfair. (Note that I'm not saying that this is a secure app; I haven't looked at the code. But you can't fault the authors on threat modelling etc. Its only "fault" is that it runs on a smart phone.) Fun, Stephan --
On Thu, Jul 24, 2014 at 08:39:35AM +0200, Stephan Neuhaus wrote:
On 2014-07-23, 23:59, stef wrote:
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
In order to qualify as snake oil according to this definition, do all of these have to be true, or is any criterion sufficient?
any is enough, but combo-bonuses are combo-bonuses.
Because if it's "any", then this https://www.cylab.cmu.edu/safeslinger/ is snakeoil, which I think is unfair. (Note that I'm not saying that this is a secure app; I haven't looked at the code. But you can't fault the authors on threat modelling etc. Its only "fault" is that it runs on a smart phone.)
well, you have a baseband stack behind it, and a vendor/provider delivering stuff without your consent, etc... -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
That is a problem with most desktop or laptop computers, too. I don't think "runs on a smartphone" is practically different from "neglects client endpoint security". A properly built and programmed smartphone is indistinguishable from a regular computer. On 24 July 2014 09:29:11 GMT+01:00, stef <s@ctrlc.hu> wrote:
On Thu, Jul 24, 2014 at 08:39:35AM +0200, Stephan Neuhaus wrote:
On 2014-07-23, 23:59, stef wrote:
exactly this prompted me to come up with the seven rules of thumb to detect snakeoil:
not free software runs in a browser runs on a smartphone the user doesn't generate, or exclusively own the private encryption keys there is no threat model uses marketing-terminology like "cyber", "military-grade" neglects general sad state of host security
In order to qualify as snake oil according to this definition, do all of these have to be true, or is any criterion sufficient?
any is enough, but combo-bonuses are combo-bonuses.
Because if it's "any", then this https://www.cylab.cmu.edu/safeslinger/ is snakeoil, which I think is unfair. (Note that I'm not saying that this is a secure app; I haven't looked at the code. But you can't fault the authors on threat modelling etc. Its only "fault" is that it runs on a smart phone.)
well, you have a baseband stack behind it, and a vendor/provider delivering stuff without your consent, etc...
-- otr fp: https://www.ctrlc.hu/~stef/otr.txt
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thu, Jul 24, 2014 at 09:46:35AM +0100, Cathal (Phone) wrote:
That is a problem with most desktop or laptop computers, too. I don't think "runs on a smartphone" is practically different from "neglects client endpoint security". A properly built and programmed smartphone is indistinguishable from a regular computer.
indeed the hostsec rule is a generalization of the "browser/smartphone" rules, however this is meant for avg people, so i spelled it out explicitly, otherwise it gets misunderstood. -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
Why nott "Windows or MacOS" while we're being explicit? On 24 July 2014 09:52:09 GMT+01:00, stef <s@ctrlc.hu> wrote:
That is a problem with most desktop or laptop computers, too. I don't
On Thu, Jul 24, 2014 at 09:46:35AM +0100, Cathal (Phone) wrote: think "runs on a smartphone" is practically different from "neglects client endpoint security". A properly built and programmed smartphone is indistinguishable from a regular computer.
indeed the hostsec rule is a generalization of the "browser/smartphone" rules, however this is meant for avg people, so i spelled it out explicitly, otherwise it gets misunderstood.
-- otr fp: https://www.ctrlc.hu/~stef/otr.txt
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Dnia czwartek, 24 lipca 2014 13:01:57 Cathal pisze:
Why nott "Windows or MacOS" while we're being explicit?
I think stef's rules are really quite good as rules of thumb. I don't think putting "Windows or MacOS" rule there would improve them in any way. At the same time I find that the "runs on smartphones" rule actually does improve them, simply because "runs on smartphone" is a buzzword. It's oft-used today as a marketing ploy, and when I see it my "snakeoil sense" is actually tingling. I don't get that tingling sensation with "runs on Windows and MacOS" usually, because that's usually just a statement of fact, not a marketing bulletpoint that can be used as a leverage with masses today. -- Pozdr rysiek
Very fair point; accepted! On 24 July 2014 13:55:18 GMT+01:00, rysiek <rysiek@hackerspace.pl> wrote:
Dnia czwartek, 24 lipca 2014 13:01:57 Cathal pisze:
Why nott "Windows or MacOS" while we're being explicit?
I think stef's rules are really quite good as rules of thumb. I don't think putting "Windows or MacOS" rule there would improve them in any way.
At the same time I find that the "runs on smartphones" rule actually does improve them, simply because "runs on smartphone" is a buzzword. It's oft-used today as a marketing ploy, and when I see it my "snakeoil sense" is actually tingling.
I don't get that tingling sensation with "runs on Windows and MacOS" usually, because that's usually just a statement of fact, not a marketing bulletpoint that can be used as a leverage with masses today.
-- Pozdr rysiek
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2014-07-24, 14:55, rysiek wrote:
At the same time I find that the "runs on smartphones" rule actually does improve them, simply because "runs on smartphone" is a buzzword. It's oft-used today as a marketing ploy, and when I see it my "snakeoil sense" is actually tingling.
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc? Stephan --
On Thu, Jul 24, 2014 at 04:06:03PM +0200, Stephan Neuhaus wrote:
On 2014-07-24, 14:55, rysiek wrote:
At the same time I find that the "runs on smartphones" rule actually does improve them, simply because "runs on smartphone" is a buzzword. It's oft-used today as a marketing ploy, and when I see it my "snakeoil sense" is actually tingling.
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc?
it's rule of thumb. right? there might be exceptions (i know of exactly one), which strengthen the rule ;) -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On 2014-07-24, 18:16, stef wrote:
On Thu, Jul 24, 2014 at 04:06:03PM +0200, Stephan Neuhaus wrote:
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc?
it's rule of thumb. right? there might be exceptions (i know of exactly one), which strengthen the rule ;)
Sorry to insist, but I gave you a concrete app, namely safeslinger: https://www.cylab.cmu.edu/safeslinger/ Do you think that it is snake oil? Fun, Stephan PS: The original version is "the exception proves the rule", where "prove" is used in its old meaning of "test".
On Thu, Jul 24, 2014 at 10:41:35PM +0200, Stephan Neuhaus wrote:
On 2014-07-24, 18:16, stef wrote:
On Thu, Jul 24, 2014 at 04:06:03PM +0200, Stephan Neuhaus wrote:
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc?
it's rule of thumb. right? there might be exceptions (i know of exactly one), which strengthen the rule ;)
Sorry to insist, but I gave you a concrete app, namely safeslinger: https://www.cylab.cmu.edu/safeslinger/ Do you think that it is snake oil?
unless it is being deployed for confidentiality defending against only low level adversaries (but by stating this i already narrowed down the threat-model significantly). i believe so. it is an app, nothing more. -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On Thu, Jul 24, 2014 at 10:54:16PM +0200, stef wrote:
On Thu, Jul 24, 2014 at 10:41:35PM +0200, Stephan Neuhaus wrote:
On 2014-07-24, 18:16, stef wrote:
On Thu, Jul 24, 2014 at 04:06:03PM +0200, Stephan Neuhaus wrote:
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc?
it's rule of thumb. right? there might be exceptions (i know of exactly one), which strengthen the rule ;)
Sorry to insist, but I gave you a concrete app, namely safeslinger: https://www.cylab.cmu.edu/safeslinger/ Do you think that it is snake oil?
unless it is being deployed for confidentiality defending against only low level adversaries (but by stating this i already narrowed down the threat-model significantly). i believe so. it is an app, nothing more.
not saying that the research and the protocols might be sound. but even much more mature algos that are yet unbroken on a scientific level do not pass the rule of thumb when they're implemented on smartphones. all of matejs concerns apply. the phone is basically a huge side channel. not saying you can't build castles on sand, but their threat model is quite limited. just a few days ago i believe eugen posted a nice list of ios bugdoors. no insult to the product in question, its the underlying platform that's broken. -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On Thu, Jul 24, 2014 at 10:06 AM, Stephan Neuhaus < stephan.neuhaus@tik.ee.ethz.ch> wrote:
So if I mention to you that a certain app just happens to run on a smartphone, your Spidey-sense would be tingling, no matter if the app has had excellent threat modelling, code audit etc?
I'd treat it as an indicator, not a certainty. All of stef's rules are indicators, where any one could be raised without the application being a problem. The more that get raised, the more likely the app is snake oil. It's like personnel security -- an employee gambling is not necessarily a problem, but it can indicate a potential security risk. And it's like diagnosing medical or psychiatric conditions -- a lack of empathy for other humans might not mean anything, but it's an indicator for psychopathy. Regarding the security app indicators, good job, stef. And I'll add one: "10000000000-bit encryption!!!!" -- Neca eos omnes. Deus suos agnoscet. -- Arnaud-Amaury, 1209
Smartphones have so many problems with them, I really wouldn't feel 'secure' using anything built on top of a smartphone. From the baseband to the OS, there's been a lot of yellow and red flags raised around smartphones. Even a well-audited app I would still be cautious around. There may be nothing wrong with the app itself but I simply don't trust the platform. Smartphones are many steps at multiple layers from being secure.
Dnia środa, 23 lipca 2014 17:24:22 grarpamp pisze:
On Wed, Jul 23, 2014 at 2:29 PM, Cypher <cypher@cpunk.us> wrote:
On 2014-07-22 23:24, unixninja92 wrote:
Recently found Gruveo[1]. Allows easy video and audio calls similar to cryptocat. Unfortunately not open source and makes no mention of being audited. Otherwise looks very interesting and promising. It tries to use P2P to make calls, and if it fails, then it will go through their servers. Uses WebRTC for end to end encrypted audio and video chat. They claim they don't keep any logs that could identify users.
So the question is, is this an NSA honey pot or something that might actually be trustworthy? It seems at least a bit more secure/trustworthy than skype to me.
Why even consider closed alternatives when you have things like Jitsi[1] available? It's open source, does secure voice, video, and text, and runs on just about any platform (including Android).
[1] www.jitsi.org
Eugen says... RetroShare has quite good P2P audio. It's not properly audited though, caveat emptor.
Ditto. Though it will take some time not just for the open source community to pick which projects to audit under limited resources, but to even develop a real auditing framework within itself to do that under. It's a huge undertaking and responsibility in its own right.
Further, what's with crap like gruveo.com, goldbug.sf.net [1], protonmail.ch, and so many more (especially the 'Look, we just solved Email encryption' crowd)? And of the partly open hw/sw stack vendor types like BlackPhone?
Here, have a chuckle: https://www.kickstarter.com/projects/icloak/icloak-tm-stik-easy-powerful-onl... Hat-tip to all the TAILS/Tor people here. -- Pozdr rysiek
participants (9)
-
Alfie John -
Cathal (Phone) -
Cathal Garvey
-
David Vorick -
grarpamp -
rysiek -
stef -
Stephan Neuhaus -
Steve Furlong