Re: [vox-tech] any OTR preferences?

2016-12-07 Thread Bill Broadley 
On 12/06/2016 01:33 PM, Rick Moen wrote:
> As they point out, this results from the Signal people and the F-Droid
> people fighting over acceptance criteria.  You'll note that the author
> says in the notes 'Wow, the Signal vs F-Droid issue is a stupid hot
> mess. Can't we all just get along and share the software? Don't make me
> sing the RMS song, people... I'll do it...'  ;->

Heh, well the f-droid approach is *IMO* completely untenable.  Basically they
are saying to any software developers.  Send us your binary, we will do anything
we damn well want with it, change it if we want, publish it under our key, and
you have no power at all over the result.  Just "trust us".  The weird part is I
can find no reason, justification, etc.  I'm totally with signal, their entire
design is to prevent the local mafia, blackhats, government, whatever from
spying on you.  The entire idea behind e2e is to minimize trust of 3rd parties.

Google play uses the developers key, thus you don't have to trust google.
F-droid inserts themselves between the developer and the user.  Might as well
cc: every communication you make to the f-droid folks.  I'd hope that f-droid
would be more secure than google play, not laughably bad.

> Still 'n' all, yeah, Copperhead OS and drills like the one on the Tor
> blog post(s) are as good as we have, at the moment.  What boggled me 
> was what a near-total showstopper the baseband CPU/firmware problem
> continues to be.  The article's April iteration
> (https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy)
> goes through some elaborate steps to deal with this and related
> problems.  (At present, they recommend decoupling the phone or tablet
> from baseband problems by using a separate MiFi device.)

Indeed.  Unfortunately consumer devices are driven by decreasing costs,
decreasing thickness, increasing battery life, etc.  Used to be that often GSM
support would be off chip, with no access to system memory.  The OS could treat
it like a modem.  Sadly with everything integrated that barrier no longer
exists.  It's not likely to come back.

Sure tethering still helps, but you still have to trust the local firmware,
which is rarely open source and increasingly is network aware (like say 
intel's).

Seems like as people start internet enabling more decives that the tether thing
might take off.  After all why pay for internet for your watch, tablet, laptop,
phone, and car when you could just buy a WAN enabled widget smaller than a phone
and get live data wherever you are.

> Personally, the only Android-type device I have is a Nook Tablet running
> Cyangenmod, which at least sidesteps the baseband problem.  Copperhead
> OS would have been much better but, as the Tor blog notes, so far,
> Copperhead doesn't support any wifi-only devices, only certain
> smartphones.

Nexus 9 has a wifi only version I thought and has copperhead support.

So there are clearly threats that copperhead doesn't protect against, but there
certainly many threats that are.  Increasingly it seems like consumers are more
aware, and that OSX, Windows, Android, Linux Kernel, and IOS are upping their
security.  Those that lead like Signal, Copperhead, GR Security are working hard
on improvements that are definitely trickling down.  What's even more promising
is Google and Apple seem to be pushing things quite hard.

Here's a good PDF on the linux kernel security, seems like this one had a pretty
decent impact, and I'm glad to say that the updates in the last year are pretty
promising:
  http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf

> I have my doubts about progress.  The OEMs still are failing to support
> meaningful service lives for their hardware, and everyone's trying to 
> use tricks to control customers.

Nexus/Pixel and google in general do seem to be placing a relatively high
priority on security.  Not adding features for features sake.  Most of the evil,
sloppy code, and "lock in" I see if from the custom skins from Sony, Samsung,
HTC, and friends.  Code that's not open source, complex, written with minimal
regard for security.  What's worse is the skins slow down the important things
like security updates.  Estimates I've seen place around 85-90% of the security
problems with the android customizations/skins.

___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-06 Thread Rick Moen 
Quoting Bill Broadley (b...@broadley.org):

> Ha, looking at your link and found:
> Because the download integrity for all of these packages is abysmal 

Yes, I was intending to point out that bit to you in particular, but
couldn't find it on the November 16th blog post -- but I see it's on the
April 2nd original blog post of which the November one is a refresh.

I notice the refresh article is using keytool instead of sha256sum to
verify the Signal app key's fingerprint, FWIW, not that that does
anything for the basic, larger problem.

> Would be nice to have copperhead OS, then something automated like:
> * launch container/sandbox without rw to /system
> * use google play to download APKs and verify signatures.
> * save downloaded APK to /tmp
> * shutdown container
> * have copperhead install and verify the APKs (after checking they won't
> overwrite copperhead APKs)
> 
> That way no google play services, and no way for google to change any 
> copperhead
> files.

Yes, concur.  For _me_, I don't compelling need for anything from Google
Play, but I realise I'm a mutant.

> For most installing signal via:
> Download the apk.
> Unzip the apk with unzip org.thoughtcrime.securesms.apk
> Verify that the signing key is the official key with keytool -printcert -file
> META-INF/CERT.RSA
> You should see a line with SHA256:
> 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0
> EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
> Make sure that fingerprint matches (the space was added for formatting).
> Verify that the contents of that APK are properly signed by that cert with:
> jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified
> printed out.
> 
> Is *WAY* too complicated.

As they point out, this results from the Signal people and the F-Droid
people fighting over acceptance criteria.  You'll note that the author
says in the notes 'Wow, the Signal vs F-Droid issue is a stupid hot
mess. Can't we all just get along and share the software? Don't make me
sing the RMS song, people... I'll do it...'  ;->

Still 'n' all, yeah, Copperhead OS and drills like the one on the Tor
blog post(s) are as good as we have, at the moment.  What boggled me 
was what a near-total showstopper the baseband CPU/firmware problem
continues to be.  The article's April iteration
(https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy)
goes through some elaborate steps to deal with this and related
problems.  (At present, they recommend decoupling the phone or tablet
from baseband problems by using a separate MiFi device.)

Personally, the only Android-type device I have is a Nook Tablet running
Cyangenmod, which at least sidesteps the baseband problem.  Copperhead
OS would have been much better but, as the Tor blog notes, so far,
Copperhead doesn't support any wifi-only devices, only certain
smartphones.

I have my doubts about progress.  The OEMs still are failing to support
meaningful service lives for their hardware, and everyone's trying to 
use tricks to control customers.

___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-06 Thread Bill Broadley 
On 12/05/2016 11:44 PM, Rick Moen wrote:
> Hey, Bill (Broadley), I wonder if you've seen this useful page from the
> Tor folks about doing the best one can with Android security:
> https://blog.torproject.org/blog/mission-improbable-hardening-android-security-and-privacy
> 

Ha, looking at your link and found:
Because the download integrity for all of these packages is abysmal 

Couldn't agree more.  Looks pretty promising to me.  Hugely complicated, but
making progress.  Seems like f-droid is the wrong approach.

Would be nice to have copperhead OS, then something automated like:
* launch container/sandbox without rw to /system
* use google play to download APKs and verify signatures.
* save downloaded APK to /tmp
* shutdown container
* have copperhead install and verify the APKs (after checking they won't
overwrite copperhead APKs)

That way no google play services, and no way for google to change any copperhead
files.

For most installing signal via:
Download the apk.
Unzip the apk with unzip org.thoughtcrime.securesms.apk
Verify that the signing key is the official key with keytool -printcert -file
META-INF/CERT.RSA
You should see a line with SHA256:
29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0
EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
Make sure that fingerprint matches (the space was added for formatting).
Verify that the contents of that APK are properly signed by that cert with:
jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified
printed out.

Is *WAY* to complicated.

The updates process sound pretty painful as well.  Kinda surprised they are
trying to sign the entire /system, seems like they should just build a
dependency tree and check the signatures of the dependency tree.  RHEL does
similar, grub tests the kernel signature, kernel checks the module signatures,
and then hands control over to user space.

For similar reasons apple and google are moving from whole disk encryption to
per file encryption.  Entire immutable images are just too inflexible.  After
all what good is whole disk encryption if your device is booted and unlocked
close to 24/7 anyways?  Not to mention who wants their phone to reboot at night
to upgrade security and not be able to receive
calls/texts/email/notifications/podcast downloads etc until the user signs in?

With all the said, copperhead sounds awesome and a significant security upgrade.
 Good stuff.


___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-05 Thread Rick Moen 
Hey, Bill (Broadley), I wonder if you've seen this useful page from the
Tor folks about doing the best one can with Android security:
https://blog.torproject.org/blog/mission-improbable-hardening-android-security-and-privacy

-- 
Cheers,"It's easier to act your way into a new way of thinking
Rick Moen  than think your way into a new way of acting."
r...@linuxmafia.com-- Jerry Sternin 
McQ! (4x80)
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-05 Thread Bill Broadley 
On 12/05/2016 04:05 PM, T. Mark wrote:
> I continue to procrastinate in finding these posts by "Moxie" et al.. just
> haven't much spare time.  Hopefully that can change.

Moxie seems reasonable, generates plenty of attacks from the cryptonerds, which
generally haven't managed to improve security on 1% as many clients as Moxie 
has.

The basic problem is really good security is so painful to use that 0.01% of the
world will use it daily.  Like say PGP.  Signal seems to be focusing more on the
99.99% and protecting users from dragnet style bulk surveillance.

If the NSA is willing to intercept hardware before you get it, exploit it after
you get it, and customize attacks specifically against you signal isn't going to
save you.  However if you are just a civilian trying to avoid ransomware,
sniffing, monitoring, and whatever privacy invading technologies signal is a
great start.

> Sorry for presuming Hangouts.  I don't have service hooked up to my 
> Androids-- 
> no desire to enrich rip-off Wireless Companies nor be triangulated by 
> dirtboxes
> nor really a pressing need to be online or in-contact all the time.  I 
> suppose I
> could run Android on my laptop & goof around with apps when online, but 
> haven't
> got 'round to it.

Increasing chromeboxes (cheap laptops running ChromeOS) can run android as well,
and don't require a sim or a GPS.

> For sure--  I balk whenever someone directs me to The Play Store to get an
> app..  never felt comfortable Registering My Device with them which is 
> required
> to gain access.  F-Droid is nice, but not adopted widely enough as yet.  I

F-droid seems embarrassingly insecure.  Binaries aren't reproducible (you can't
be sure what you get is what was intended) *AND* they aren't signed with the
developer keys.  So 100% of the trust is with the f-droid folks, which of course
makes them a particularly juicy target.  Which is why Moxie doesn't want to A)
publish in f-droid or B) let others publish clients using their servers.

Imagine if someone said to you "Hey, upload your email to me, skip you PGP key,
just use mine.  Trust me... we do it well".  Hopefully you would laugh in their
face.

Googles play store on the other hand uses the developers key.  So you can be
sure that whatever you run is bit identical to what the developer published.
That's how keys are supposed to work.  So whisper systems can be very sure that
what people get is what they publish.

Sure, a google unencumbered store would be awesome.  But f-droid's security is
embarrassing.  Again Moxie went with the pragmatically more secure solution over
the philosophically more appealing one.

> eventually found  org.aclu.mobile.justice.ca* on one of the 3rd party sites 
> that
> hosts .apk's, though, so now I guess I can livestream questionable incidents 
> if

Random APK downloads or sideloads is another horrible practice that Moxie
doesn't want to get involved with.  Complex, error prone, insecure, and not end
user friendly.  Finding a random APK and a random post about how to install it
doesn't lead to good security practices by random users.  Last thing you should
be trying to train random users on is DNS (and DNSEC), http/https (when to trust
it and when to not), chain of trust, crypto checksums, etc.  Anything more than
download and install only software from https://play.google.com is likely to
significantly lessen your target audience.

> I happen to be in a free hotspot.  (Maybe someone going to the EFF event can 
> ask
> if they can ask ACLU to get hip to F-Droid?  But I wont get my hopes up-- just
> saw where ACLU did a live q&a on F*book Video.. (don't get me started!))

I recommend building from source or using https://play.google.com. Trusting
random 3rd parties to make and distribute APKs is just as bad as installing some
random screensaver.exe you found on the web and running it as root on a windows 
box.

___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-05 Thread T. Mark 



3. Dec 2016 15:06 by b...@broadley.org:


> On 12/02/2016 03:46 PM, T. Mark wrote:
>>   Thanks for your erudite observations, Bill.. I agree with almost all of 
>> them. 
>>   That is indeed a bit troubling that Keybase unnecessarily grabs your 
>> private
>> key.. I should've paid better attention & noticed that myself.  Looks like 
>> I'll
>> continue to not really use it (never connected any mobile devices like most
>> people do btw.. that thought creeped me out straight away.)  It's an 
>> interesting
>> idea though, & lots of cool nerds there, 
>
> Indeed, especially the FUSE based filesystem.
>
>>   I'll definitely take your enthusiasm for Signal into consideration along 
>> with
>> all the various opinions.
>
> It's a hard line.  Would federation be cool?  Definitely.  Do federated
> standards slow down innovation, definitely.  See SMTP, XMPP, or HTTP, all of
> which have been very slow to change.  None of which bake in e2e, and all of
> which have a huge variety of clients that will break if you tried to force 
> e2e.
> Not to mention large communities that will split into change nothing and 
> change
> everything communities and battle over changes, and ask for committees that 
> will
> decide anything at a glacial pace.  Even after the standards committe decides
> then software developers will implement suggested changes willy nilly... 
> leaving
> a bunch of half functional clients that you can't trust to do encryption 
> right.
>
> Thus the difference between signal and any of the old school federated 
> protocols.
>
>




I continue to procrastinate in finding these posts by "Moxie" et al.. just 
haven't much spare time.  Hopefully that can change. 


> See why Moxie isn't excited about Joe Randoms distributing hacked signal 
> clients
> and pointing at whisper systems servers?
>
>>   Where I think you're a bit mistaken is wrt Google Hangouts--  I recall 
>> reading
>
> I didn't the mention the word hangout.  I mentioned GCM (google cloud
> messaging).  It was a major complaint of the blog post, but seems to miss that
> it leaks no message, no meta data, can't tell who you are walking to etc.
>
>> a post by a developer on a Goog forum decrying the fact that Google Voice
>> traffic goes over unencrypted (even though the gmail connection spawning it 
>> is
>> https) ..  and sure enough, when I run Firefox from the command line & fire 
>> up
>> the Voice Plug-in, it's blurting out stuff all over the place, including my
>> gmail address as far as I can tell.  Haven't had the desire to do video (and
>> actually find the push to use Hangouts instead of the old Voice to be quite
>> annoying) so I have no observations about that.
>
>





Sorry for presuming Hangouts.  I don't have service hooked up to my Androids--  
no desire to enrich rip-off Wireless Companies nor be triangulated by dirtboxes 
nor really a pressing need to be online or in-contact all the time.  I suppose 
I could run Android on my laptop & goof around with apps when online, but 
haven't got 'round to it.
 

> I didn't mention hangouts.  I mentioned GCM which is not hangouts.
>
>> But I've never trusted that
>> megacorporation much, for a variety of reasons, and I must admit I find
>> questionable your further assertion that "Google does NOT know who you are
>> talking to, or what you are saying .." I mean, if the rest of Hangouts is
>
> I was speaking specifically about signal's use of GCM, not some broad ranging
> comment about google.  I trust google to be relatively transparent.  They 
> admit
> to tracking your habits, showing you ads, reading your gmail, etc. etc.  It's
> what you "pay" for free services.  If you don't like it, don't use their 
> services.
>
> Android is pretty secure, and pretty good about being transparent.  But if you
> let it, it will track your position, your email, your commuting routes, your
> receipts, your contacts, your routes, etc.  However you can totally use 
> android,
> say no, use IMAP, XMPP, some google cal equivalent, and even install your own
> app store if you want.
>
>> anything like Voice, they absolutely try to know.  Voice automatically tries 
>> to
>> convert all your speech-recognize all your voicemails, presenting a 
>> usually-iffy
>> text of them (and there's no way to turn that off that I could find.)  This 
>> is
>> consistent with their "free" business model--  free doesnt mean Free As In
>> Freedom, to quote stallman.org..  our eyeballs (& vocal chords & probably
>> camera-gleaned biometrics) are absolutely The Product--  Goog is an advert
>> monster, after all.  If I had the patience to read legalese, I'm sure I could
>> provide passages from their ToS that'd leave no question about this.
>
> I don't deny that google collects tons of info if you let it.  If you don't 
> like
> it use something else.
>
>>   While I'm ragging on them, it might be worth noting that I heard some 
>> definite
>> discontent on one or more of the Linux podcasts I consume about Android 
>> tending

Re: [vox-tech] any OTR preferences?

2016-12-02 Thread Bill Broadley 
On 12/02/2016 03:46 PM, T. Mark wrote:
>   Thanks for your erudite observations, Bill.. I agree with almost all of 
> them. 
>   That is indeed a bit troubling that Keybase unnecessarily grabs your private
> key.. I should've paid better attention & noticed that myself.  Looks like 
> I'll
> continue to not really use it (never connected any mobile devices like most
> people do btw.. that thought creeped me out straight away.)  It's an 
> interesting
> idea though, & lots of cool nerds there, 

Indeed, especially the FUSE based filesystem.

>   I'll definitely take your enthusiasm for Signal into consideration along 
> with
> all the various opinions.

It's a hard line.  Would federation be cool?  Definitely.  Do federated
standards slow down innovation, definitely.  See SMTP, XMPP, or HTTP, all of
which have been very slow to change.  None of which bake in e2e, and all of
which have a huge variety of clients that will break if you tried to force e2e.
Not to mention large communities that will split into change nothing and change
everything communities and battle over changes, and ask for committees that will
decide anything at a glacial pace.  Even after the standards committe decides
then software developers will implement suggested changes willy nilly... leaving
a bunch of half functional clients that you can't trust to do encryption right.

Thus the difference between signal and any of the old school federated 
protocols.

See why Moxie isn't excited about Joe Randoms distributing hacked signal clients
and pointing at whisper systems servers?

>   Where I think you're a bit mistaken is wrt Google Hangouts--  I recall 
> reading

I didn't the mention the word hangout.  I mentioned GCM (google cloud
messaging).  It was a major complaint of the blog post, but seems to miss that
it leaks no message, no meta data, can't tell who you are walking to etc.

> a post by a developer on a Goog forum decrying the fact that Google Voice
> traffic goes over unencrypted (even though the gmail connection spawning it is
> https) ..  and sure enough, when I run Firefox from the command line & fire up
> the Voice Plug-in, it's blurting out stuff all over the place, including my
> gmail address as far as I can tell.  Haven't had the desire to do video (and
> actually find the push to use Hangouts instead of the old Voice to be quite
> annoying) so I have no observations about that.

I didn't mention hangouts.  I mentioned GCM which is not hangouts.

> But I've never trusted that
> megacorporation much, for a variety of reasons, and I must admit I find
> questionable your further assertion that "Google does NOT know who you are
> talking to, or what you are saying .." I mean, if the rest of Hangouts is

I was speaking specifically about signal's use of GCM, not some broad ranging
comment about google.  I trust google to be relatively transparent.  They admit
to tracking your habits, showing you ads, reading your gmail, etc. etc.  It's
what you "pay" for free services.  If you don't like it, don't use their 
services.

Android is pretty secure, and pretty good about being transparent.  But if you
let it, it will track your position, your email, your commuting routes, your
receipts, your contacts, your routes, etc.  However you can totally use android,
say no, use IMAP, XMPP, some google cal equivalent, and even install your own
app store if you want.

> anything like Voice, they absolutely try to know.  Voice automatically tries 
> to
> convert all your speech-recognize all your voicemails, presenting a 
> usually-iffy
> text of them (and there's no way to turn that off that I could find.)  This is
> consistent with their "free" business model--  free doesnt mean Free As In
> Freedom, to quote stallman.org..  our eyeballs (& vocal chords & probably
> camera-gleaned biometrics) are absolutely The Product--  Goog is an advert
> monster, after all.  If I had the patience to read legalese, I'm sure I could
> provide passages from their ToS that'd leave no question about this.

I don't deny that google collects tons of info if you let it.  If you don't like
it use something else.

>   While I'm ragging on them, it might be worth noting that I heard some 
> definite
> discontent on one or more of the Linux podcasts I consume about Android 
> tending
> more & more toward pushing a proprietary silo sort of environment on
> hardwaremakers & consumers.  They basically bemoan the increasing 
> disappearance
> of AOSP options (
> https://en.wikipedia.org/wiki/Android_(operating_system)#Open-source_community
>  )..

Yeah, the #1 problem is google play services (GPS), which many apps depend on,
but isn't open source.  However the API to GPS is documented, but it would be
challenging to keep up with google.

___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-12-02 Thread T. Mark 
  Thanks for your erudite observations, Bill.. I agree with almost all of them. 
 
  That is indeed a bit troubling that Keybase unnecessarily grabs your private 
key.. I should've paid better attention & noticed that myself.  Looks like I'll 
continue to not really use it (never connected any mobile devices like most 
people do btw.. that thought creeped me out straight away.)  It's an 
interesting idea though, & lots of cool nerds there, like you say (albeit not 
the most astute about being wary vis-a-vis privacy, I'd reckon.)  And to update 
my ramblings:  I think their "invite" phase is overwith, and anyone can just 
freely grab an account/handle at this point (demand must've been underwhelming 
I suppose.)

  I'll definitely take your enthusiasm for Signal into consideration along with 
all the various opinions.

  Where I think you're a bit mistaken is wrt Google Hangouts--  I recall 
reading a post by a developer on a Goog forum decrying the fact that Google 
Voice traffic goes over unencrypted (even though the gmail connection spawning 
it is https) ..  and sure enough, when I run Firefox from the command line & 
fire up the Voice Plug-in, it's blurting out stuff all over the place, 
including my gmail address as far as I can tell.  Haven't had the desire to do 
video (and actually find the push to use Hangouts instead of the old Voice to 
be quite annoying) so I have no observations about that.  But I've never 
trusted that megacorporation much, for a variety of reasons, and I must admit I 
find questionable your further assertion that "Google does NOT know who you are 
talking to, or what you are saying .." I mean, if the rest of Hangouts is 
anything like Voice, they absolutely try to know.  Voice automatically tries to 
convert all your speech-recognize all your voicemails, presenting a 
usually-iffy text of them (and there's no way to turn that off that I could 
find.)  This is consistent with their "free" business model--  free doesnt mean 
Free As In Freedom, to quote stallman.org..  our eyeballs (& vocal chords & 
probably camera-gleaned biometrics) are absolutely The Product--  Goog is an 
advert monster, after all.  If I had the patience to read legalese, I'm sure I 
could provide passages from their ToS that'd leave no question about this.
  While I'm ragging on them, it might be worth noting that I heard some 
definite discontent on one or more of the Linux podcasts I consume about 
Android tending more & more toward pushing a proprietary silo sort of 
environment on hardwaremakers & consumers.  They basically bemoan the 
increasing disappearance of AOSP options ( 
https://en.wikipedia.org/wiki/Android_(operating_system)#Open-source_community 
)..

  But I don't want my points of disagreement to detract from my appreciation 
for your response--  it's a very much welcomed one.
  
  Mark
  
--
https://twitter.com/linuxusergroup


___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech

Re: [vox-tech] any OTR preferences?

2016-11-30 Thread Bill Broadley 
On 11/30/2016 05:33 PM, T. Mark wrote:
>   I've got a couple of Keybase.io "invites" laying around, & never got around 
> to
> offering them at a social gathering or such, so I'll offer them here.  This
> raises the technical question I have though, which I'm sure some of the many
> sharp people on this list might have thoughts about:
>   Does anyone have a take on trustworthiness of Keybase?  

I'd rate them pretty highly, except for one small detail.  Last I checked their
default was to suck your GPG private key into keybase.  Which is pretty evil.
They support not doing that, but it's not the default.

> Also would like
> analyses of Signal (which I just heard deemed inadvisable--  damned if I can
> remember where, all the sudden, but I found this
> https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore
> 

That's a pretty controversial post.  Heavily debated in various forums.  I
mostly disagree with it.  Additionally Moxie has come around on a few issues.

Maybe lugod should have a Crypto discussion as kind of a part #2 to the
EFF/Crypto talk.

But generally:
* Moxie is smart and very well respected
* signal is very well respected
* cryptonerds like to point fingers and lobby for their pet feature, often
ignoring why said feature damages the cause and results in approximately zero
users.  Just like PGP.
* Said cryptonerds often hem, and haw.  Bitch and complain.  Yet somehow have
nothing better to recommend.

Additionally that post wasn't particularly accurate, or at least they weren't
accurate when the read them.  He doesn't seem to really understand how signal
works, or how GCM is used.

> which
> among other things mentions that there's a non-OpenSource part to it, which 
> gets
> in the way of what else I want to ask everyone: "HAVE YOU perused the source
> code on these??"  And I could swear I used to see Signal recommended in the

Well the beauty of E2E encryption is you don't have to trust the server.  Of
course for this to be a big complaint you'd really want to offer something
better... like?

Some people discussed this and poked around in the github repo and foudn c++
code that looks quite a bit like the server code (for the java based client):

https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone

Not sure if that was added before or after the blog post.

> twitter bio-blurb of either @csoghoian (ACLU genius) or @ggreenwald  on 
> Twitter
> -- but now they're back to mentioning only PGP.  So much for that fad I 
> guess..
> what does appear new is wire.com -- now with in-browser functionality (but 
> only

wire is cool, up in coming, pretty recently I heard mention of the e2e
encryption being pretty mature.  People really seem to like it, because it
doesn't need GCM.  But GCM basically only says "wakeup", it's not a message
transport.  Google does NOT know who you are talking to, or what you are saying,
or even the length of your message.

The cryptonerd complaints about GCM have been amazing... all ignoring that the
signal folks said they would accept an alternative implementation with webhooks.
 Suddenly there's silence.

Additionally the power, and bandwidth needed for wire.com might well prevent you
from reaching the millions of users that you are trying to protect.

Generally people seem hopeful of tox and wire in the future.  But today it seems
like signal is much more trustworthy on the crypto front.

> the client sees my microphone in the Linux distro I'm running) ..  this is
> ballyhooed due to it being hosted in Switzerland which boasts the best privacy
> laws on-planet, they say.  What it is: the trustworthy alternative to Goo

Who needs privacy laws when nothing leaves your phone/desktop/laptop but
encrypted bits?  I'd say encryption over someone's promised privacy policy any 
day.

g
> Hangouts, I'm hoping!  Conferencing audio/video (not sure about max 
> participants
> on a call) over secure protocol.  So if anyone has auditing chops or knows of
> audits/viewpoints regarding any of these, do tell. 

Heh, video conf seems to barely work without encryption, I'd be surprised if
anything really secure worked great today.  Sure, keep it on the wish list.

> btw, I myself haven't been using Keybase much since signing up..  I was using
> its copy/paste-codeblobs-into-your-CLI option for awhile until trying its
> installable client..  the latter of which was even a bit scarier given that it

My favorite for that is termbin:
bill@home:~/imp$ echo "hello world" | tb
http://termbin.com/ewr94

bill@work:~/imp$ curl http://termbin.com/ewr94
hello world

Not for anything confidential of course.  For that I use scp/ssh, or signal.

> installed a line in .bashrc, thus firing it up on every boot-- & it's like its
> own fuse-fs which creates major load.  Did this without asking, so I commented
> out that line pretty quickly.

Yeah, keybase is well written by clued folks, but does play a bit f

[vox-tech] any OTR preferences?

2016-11-30 Thread T. Mark 
  I've got a couple of Keybase.io "invites" laying around, & never got around 
to offering them at a social gathering or such, so I'll offer them here.  This 
raises the technical question I have though, which I'm sure some of the many 
sharp people on this list might have thoughts about:
  Does anyone have a take on trustworthiness of Keybase?  Also would like 
analyses of Signal (which I just heard deemed inadvisable--  damned if I can 
remember where, all the sudden, but I found this 
https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore  which 
among other things mentions that there's a non-OpenSource part to it, which 
gets in the way of what else I want to ask everyone: "HAVE YOU perused the 
source code on these??"  And I could swear I used to see Signal recommended in 
the twitter bio-blurb of either @csoghoian (ACLU genius) or @ggreenwald  on 
Twitter  -- but now they're back to mentioning only PGP.  So much for that fad 
I guess.. what does appear new is wire.com -- now with in-browser functionality 
(but only the client sees my microphone in the Linux distro I'm running) ..  
this is ballyhooed due to it being hosted in Switzerland which boasts the best 
privacy laws on-planet, they say.  What it is: the trustworthy alternative to 
Goog Hangouts, I'm hoping!  Conferencing audio/video (not sure about max 
participants on a call) over secure protocol.  So if anyone has auditing chops 
or knows of audits/viewpoints regarding any of these, do tell.  
  

btw, I myself haven't been using Keybase much since signing up..  I was using 
its copy/paste-codeblobs-into-your-CLI option for awhile until trying its 
installable client..  the latter of which was even a bit scarier given that it 
installed a line in .bashrc, thus firing it up on every boot-- & it's like its 
own fuse-fs which creates major load.  Did this without asking, so I commented 
out that line pretty quickly.

--
https://twitter.com/linuxusergroup
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech