[p2p-hackers] The next gen P2P secure email solution

[grarpamp]

On Mon, Dec 30, 2013 at 12:34 AM, ianG <iang at iang.org> wrote:
> On 28/12/13 09:24 AM, grarpamp wrote:
>>
>> On Wed, Dec 25, 2013 at 7:21 PM, Matthew Kaufman <matthew at matthew.at>
>> wrote:
>>>
>>> So there's already a system that until very recently did peer-to-peer
>>> delivery of messages over encrypted channels between hosts that
>>> participated
>>> in a peer-to-peer overlay. It was Skype.
>>
>>
>> Afaik, skype used a central lookup to get to unknown peers, not a DHT.
>> So they perhaps knew who wanted to talk to who. Of course now skype
>> is untrusted by anyone with a clue.
>
>
> So sad.  I have a clue and don't trust Skype.  But I can't for the life of
> me migrate my friends off of it.  It's as addictive as crack.  It's just
> better than the alternatives.
>
> As a serious business problem, if one wants to share documents on a frequent
> basis, which system would one choose for security?  Skype, google docs aka
> drive, or something else?
>
> I need something that ordinary people can use.  So no complicated "download
> this on 100 machines and ..."
>
> Also, should be free and can make a nice cup of coffee.

There is slick, and then there is utility. I'm seeing some good utility
in a few of the listings on https://www.prism-break.org/ . When it comes
getting utility done, it's not to hard to introduce (even firmly) people
into using utilities. Slick helps, but it's not required, and will come in
time. Everyone throws up BS about adoption and thus nothing ever
gets built, or even researched, screw that, I say build it and see.

I also question a few of those listings.

>>> battery life... and when they're on 3G/4G, the bandwidth isn't as good
>>> and
>>> it can be very expensive, and it burns the battery up even faster.
>>
>>
>> Sure, there's a class of users that want this, a big class. They can
>> have and use their modified legacy centralized email as they wish.
>> There's another big class that want's something more than that.
>>
>> We're also going to see faster hardware, lighter code, and maybe
>> even wearable battery packs... because as you say, these users
>> want it all and are willing to go to almost any means to get it.
>
>
> I'm going to make a call here.  I reckon that future phone bandwidth and
> batterywidth will be sufficient to close the gap, to the point that this
> problem goes away.
>
> So, moving away from p2p notions that are popular with the
> one-laptop-per-everyone western world would be the wrong strategy.
>
> Although it seems that the phone market is 'different' it is catching up
> fast in the things that matter.  Right now, the only thing where they are
> arguably short is VoIP.  Hell, they're happy watching utube on phones...
>
> But that's no problem because in today's world, what dominates is chat &
> apps.  Lack of good VoIP over phones is just a short term issue.
>
> (It's a prediction, not a claim!)

I agree with this hardware path, especially for the subject of p2p
secure messaging.

I think voip is currently not a user priority on devices with a cell
stack because that
stack is already activated and paid for. With good apps and wider access to free
wifi in particular, encrypted voip should take off. Or we will see
more use of cell
based IP plans. Another twist is going out of voiceband to get the key material
of your peer, then with the more open phones out there, grab the cell
mic/vocoder/modem
on them and stuff your encrypted voice over that if voip doesn't work
at that moment.
But that's way off topic to p2p secure messaging... at least until
that hardware path
allows for p2p secure <everything>.


>>> These users want to be able to send and receive messages when their
>>> device
>>> is on, but the recipient's device isn't. Because most of the time, the
>>> recipient's device, even if they put it in their pocket 10 seconds ago,
>>> is
>>> already asleep, trying to preserve as much battery as possible.
>>>
>>> That pretty much eliminates all designs that do direct transfer from
>>> sender
>>> to receiver, irrespective of the traffic analysis risks of doing so.
>>>
>>> Additionally, it also means that nearly all the participant nodes are
>>> also
>>> unable to participate in a peer-to-peer overlay network, because they
>>> can't
>>> afford the network uptime (and consequent battery drain) necessary.
>>
>>
>> We're exploring ideas. What is to say we are able to develop into it some
>> kind of automaton taho-lafs delivery storage nodes. Storing messages in
>> transit under some expiry policy is not a huge space concern. So who
>> knows.
>>
>> Maybe everyone with their uber important phones will end
>> up VPN to their home/colo servers where the horsepower is.
>>
>> Predicting mobile is hard. Throw more apps out there and your
>> $30-50/mo unlimited data plans go away. Now is everyone going
>> to pay $150+/mo for that? Where is free open wifi going to end up
>> spanning? And so many other things.
>
>
> In the market I'm in, people are very used to switching off Apps when they
> see the bandwidth being sucked.  Just an observation...  I think it's a
> problem that solves itself, a warning to developers that they have to think
> outside their tech box.

Right... I think not everything has to run in RAM... we have a few GiB
to store the network state in, as a sliding tradeoff for reconnection speed
when switching them back on. CPU is another available slider. So is
network rate/transfer limits.


>> What I think is clear is that there will for the far to indefinite
>> forseeable
>> future be some form of real workstation/laptop in the home and office.
>> Phones just can't replace that. Maybe we're seeing something in how
>> you see larger tablet/netbooks/laptops with headsets being carried about
>> now as if it is natural. And lots of those people will want a highly
>> secure system to communicate over with their peers in this new
>> world of disgustingly gratuitous surveillance and databasing.
>> I would not underestimate the demand for that sort of a comms system.
>
>
>
> I see this as rather a rich western world observation.  It probably works
> for Apple.  It doesn't so much work in the non-rich world, where things are
> much more widely driven by Android, etc.

I gather Africa does a lot of things with simple text messaging on
simple non-I/Android/MS/Unix phones. What is their path for phone tech
advancement, and when?

Is it reasonable to expect to truly need to develop for more than the
'West' as a userbase? Keep in mind the West now probably includes
China and many other places, so we're looking at more than 1B nodes
anyways. We probably mean 'Western class' of phones. And by the
time a p2p secure messaging platform the subject of this thread is
deployed in a handful of years, that class will be much more widespread.
So perhaps natural convergence of this software and hardware will occur.

Yes there are West/first vs. second/third disparities, if everyone
waited we wouldn't have what 'western' tools we have today.
There are folks in the west that need them too, even to work on
solving those disparities, so it is not much of an argument to expect
to limit develop only for western class HW.

See what you can build for intel/amd CPU's.
See what you can fit in ARM, snapdragon, android, etc.



>>> ps. And then there's the other unsolved problem: If you do actually build
>>> a
>>> popular service that lets people securely exchange messages, the
>>> government
>>> comes with an order to reveal the content of the messages, and threats to
>>> lock up the principals if those demands aren't met. I wish I could tell
>>> you
>>> more stories about this, but of course I'm subject to the same sorts of
>>> non-disclosure that everyone else who's ever gotten one of those is.
>>
>>
>> That's why you should be doing the development of these new
>> protocols entirely within existing secure networks such as Tor
>> and I2P. And why you should bootstrap via peers instead of
>> clearnet authorities like Tor that can be shutdown... it's a little
>> less secure, but you can have in network authorities wrapped
>> in web of trust and then rejoin listening only to them later. And
>> if clearnet get''s that bad, it becomes a freedom of speech issue
>> which is well, SHTF time.
>
>
>
> Easy to say :)  And then you meet your users, and they don't want that, they
> want something different.

ie: I2P has it's main repo in .i2p and some anon developers.

I don't see bootstrapping into the net via peers as 'unwanted',
they are your trusted real world friends for the most part. What
your app does after that with the network db it learns from that
doesn't necessarily need to involve your friend anymore.

What don't they want? A little less initial security for a day while
the app crunches and sorts things out? Possibly selecting a trust chain
other than that introduced to them by their friend? Reading the
public consensus on that?
It sounds like the BS adoption issue people like to claim in
order to not build anything.
Granny learned to surf the net, so Johnny can learn to encrypt.
And both of them know how to read the manual. Seriously.