Re: The messenger service is ready to use

[TheJackiMonster]

On Sun, 2021-03-07 at 09:24 +0100, carlo von lynX wrote:
> Good morning!
> 
> > > Super inefficient for small pieces of data I would assume,
> > > and introducing so much latency that in the end it feels
> > > slower than using the web. When simple things arrive in-band
> > > you can display them immediately. I'd rather use FS for
> > > things >1M.
> 
> On Sat, Mar 06, 2021 at 09:47:48PM +0100, TheJackiMonster wrote:
> > The question is what kind of files to people actually share through
> > messengers. Uncompressed pictures, videos or other media should be
> 
> They throw gifs, songs, video clips at each other just to
> express a +1 or a lol.
> 
> > fine. If we want to have low latency, I would suggest to add a
> > message
> > type for binary data streaming directly since voice messages or
> > video
> > streams are also common messenger features which would have the
> > same
> > issue.
> 
> That means that *all* messages need to be binary data messages so
> that you can include gifs, jpegs, m4as, mp4s.. because pretty much
> any kind of message sent to the group could be illustrated with any
> of those things. If you start making exceptions people will start
> complaining why they can't put a gif into the group description
> or decorate a "/me is cleaning the house" message with an upload
> of queen's "i want to break free". So my recommendation here is
> to not raise artificial barriers and to not require every anigif
> to be stored in gnunet-fs. We can still find the optimal balance
> between immediacy and cachability later.
> 
> > > > So file formats and similar are not really an issue which needs
> > > > to
> > > > addressed via a text based format for messages.
> > > 
> > > It's one of the few things that is *still* annoying with
> > > modern messengers such as Telegram: you get to see a
> > > blurred preview that was somehow embedded into JSON
> > > and then depending on the condition of your network
> > > you may have to wait seconds or minutes until the
> > > actual content materialises on the screen. That's what
> > > you get when you introduce OOB-fetching transactions
> > > just because your message format can't handle data
> > > natively.
> > 
> > If we really want to have lowest latency as possible for pictures
> > and
> > previews, I know some formats we could look into (for example
> > streaming
> > pixels in a LOD like way increasing pixel density by every level of
> > transmission).
> 
> Those are techniques introduced to complement the architecture
> of the web, but we do not depend on that. The web artificially
> creates a realtimeness stress for users to interact with servers,
> but we can just display the complete message when it has fully
> arrived. No need to start showing previews and fill the user's
> screen with unfinished things.

Waiting for the completion of a message is far worse for most users
than looking at dynamic previews or states from my experience. Because
you can't expect the people to be physically separated while
sending/receiving a message. They will also send a message standing
next to eachother and check if the message was received. So the service
would wait for completion before showing anything at all, people would
more likely think the whole application is broken.

> 
> Should you consider going forther someday, think how websites in
> secushare are static views of the channel state of subscribed
> channels, thus when a person clicks on a menu item, it typically 
> refers to something which is already in the local memory. No
> latency, no tricks needed, no possibility to measure click patterns
> for purposes of surveillance capitalism. Oh, one more reason to
> use PSYC: the channel state it manages. It's a bit like git, PSYC
> as a series of messages executes modifications on a set of data
> elements, therefore as an application you can always look at the
> state for the current view of a chatroom's or a person's profile etc.

The problem is that while keeping different states of something is
great from the datas perspective, a user expects being able to delete
or edit something which they might have misspelled or similar. That was
also a reason for me to use some structure which allows this. I have
also seen decentral social media based on a blockchain for example with
every message and state stored locally but I don't think a general user
would ever use it if they understand or even just think they can't
delete anything.

Sure, you could argue that most centralized services probably just
visualize an option of deletion or modification while keeping the old
state stored anyway. But I would like to actually provide this
functionality.

> 
> > > > For example Telegram requires personal information to create an
> > > > account. The messenger service doesn't require anything (no
> > > > name,
> > > > no
> > > > mail address, no phone number) except that you have direct or
> > > > indirect
> > > > access to a peer running GNUnet. ^^'
> 
> We can make registration with regular Telegram optional
> for those who need it. I'm still talking about the advantage
> of using a powerful existing UI with generally accepted UX.
> Maybe the code already sports some levels of negotation, so
> if the server doesn't offer certain things, those options
> will not show up in the UI. In our case the server is a
> localhost gnunet service.

I don't see a problem in creating a powerful UI comparable to something
like Telegram. Also I already see a huge problem in using Telegrams UI
which is that you had three different kinds with different
functionality: App version, desktop version and web version.

So this would imply that the service has to be limited by Telegrams
feature set or we need to maintain three GUIs which get changes by
maintainers and other developers who don't even know about GNUnet. It
would be also pretty confusing for general users if you show them
Telegram and tell them how it is secure. They will mostly then just use
Telegram but not a GNUnet server interface, I assume.

> 
> > > Which brings about the disadvantage of having to "add" each
> > > person interactively before being able to even start. Would
> > > be ok if there was no unfair competition, but messengers
> > > are unfair competition.
> > 
> > The current state is far from being able to convince anyone
> > switching
> > from one existing messenger to this. But I can definitely say that
> > you
> > won't have to physically exchange peer identities or similar to add
> > a
> > contact. I can only provide cadet-gtk as example which allows every
> > user to opt-in to share their peer-identity linked to personal
> > information.
> > 
> > So when I say "the service doesn't require anything", I don't mean
> > you
> > can't use them. I just want to have a maximum of privacy by
> > ensuring
> > every piece of personal data is optional. So in the end it depends
> > on
> > each user if you can add them by a random number, a QR code, a tag-
> > name, a username or their email address.
> 
> As a general principle I don't believe in opt-in. I think it is the
> reason why GDPR is mostly a failure - assuming people have the
> ability
> to judge what long term implications it will have to give consent to
> data slavery. I was told there are psychological studies detailing
> how the human species is unable to make such decisions reasonably,
> they cannot even visualize the long term effects of smoking.

Opt-in is not really the issue but that most services and applications
are not designed to function without data collection. So they
manipulate or force a user to provide the requested data anyway.

> 
> So in the long run I would love people to use physical meetings
> (bluetooth, NFC, QR-code handshakes etc) combined with adoption
> from other people's social graph. But as long as it isn't illegal
> to use more invasive instruments, by not employing them we're just
> giving the unregulated offerings a strategic advantage. Even Telegram
> was created after Snowden's revelations with the intention of being a
> privacy-oriented alternative, but in order to compete with Whatsapp
> they had to put all the privacy second or third and make things as
> easy and comfortable for users as their spoiled expectation is.
> It's ugly, but it's the reason why they are still in the game.

We will only see physicial exchange of public keys if we design the UI
properly. Without any indication that this key exchange is required for
security, people won't know about it and automatically they won't
change behavior. Physical key exchange is not even inconvenient if the
UI is designed properly. Services like Telegram, WhatsApp or Signal are
not actually interested in providing a secure messenger. I mean they
have to pay server bills. We don't. We don't need any data from anyone.

> 
> > The practical problem with compatibility is just that you will have
> > more options with the planned client-side library in adding
> > contacts
> > practically than with any existing messenger I know.
> 
> Well, if you don't know by which method a person put herself into
> the DHT or GNS, then you end up inserting as much data as you have -
> so the data exposure is not happening through the person herself but
> through her contacts. Ironically, this behaviour is actually illegal
> by data protection regulation: you would have to ask for permission
> before you use *any* data of another person. And so the commercial
> social networks strive on the fact that, legally speaking, it's your
> own friends committing the crime, not the social network provider.
> Have you ever considered sueing a friend because they posted your
> photo on Facebook?
> 
> Therefore I expect it will be both much more comfortable and much
> safer if there are options for discovery within the social graph,
> so if I am Robert's good friend, I can add his friend Michelle that
> I met at his party last night, by searching his branch of the graph.

I have also looked at the concept of a social graph before developing
this and I didn't like the idea much. Searching a graph like this even
if I could only see friends of one of my contacts implies a huge data
exposure. Because the API would be open and the data would be
decentralized I could query all friends of some contact without them
knowing about it and track down when they meet anyone or befriend them.
So unless there is a protection to prevent such an attack, I would
prefer a social graph on application level rather than on service
level. So people could decide to use this feature. However in any case
this makes it inconvenient to use for adding contacts because you
couldn't find some people depending on restrictions or application
usage.

In many cases you don't need a social graph for getting a contact
anyway. You can just ask your friends to send you the contact which
would still be possible. However this would not allow tracking your
contacts without them knowing but it would be social interaction. If
that's still an issue we could exchange contacts on physical level
automatically via local networks. So that means, if you meet someone in
person, you can automatically exchange contacts via Bluetooth or Wifi
if enabled (I would also prefer opt-in because maybe the person doesn't
want to be contacted by anyone at all).

> 
> Also, I'm not sure how well the use of DHT and GNS is protected
> from systematic attacks. Can I, by knowing someone's email address,
> publish a wrong pubkey in her name? Can I DoS a person out of
> existence?

Yes, you could probably publish a wrong connection if you know the
exact credentials, I assume. However this is possible in every other
messenger as well since most of them rely on server trust which
basically means there's nothing preventing the server to perform a PITM
attack on its users. The only way to prevent this is physical key
exchange.

However this service is mostly designed to add contacts you already
know from another platform which implies the possibility to ensure you
add the correct person or to add a contact from the same platform which
is possible by E2E invitation. So with that in mind: If the UI is
misleading (for example if we would just use UI from any other
messenger) and/or a user decides to go for the worst way possible to
add a contact... and the user does not make use of any from of
verification... then yes, a user could be deceived.

> The social graph doesn't have these problems.. luckily GNS mostly
> promotes social graph style modeling, but not enough to build
> secushare
> upon, AFAIR. In particular the frequent traversal that an app like
> secushare needs would be a stress on the DHT rather than on a locally
> managed database.

If a social graph would not have these problems: Is there actually a
convenient way to add a contact via social graph which you haven't met
in person, haven't chatted with before and is not a contact of any of
your friends?

> 
> > > > Also you can't mix end-to-end encrypted messages with
> > > > transport-
> > > > only-
> > > > encrypted messages in Telegram (or at least the interface would
> > > > require
> > > > major changes to handle that).
> > > 
> > > But in our case it would simply be an extra E2E on top of
> > > CADET's Axolotl… pretty unnecessary.
> > 
> > Yes, the E2E is on top of CADET which seems to be unnecessary but
> > it is
> > also optional. The most communication will only use CADETs
> > encryption
> > if the user does not explicitly request otherwise.
> > 
> > The whole design is based on the concept that a direct chat between
> > two
> > people is basically just a group of two. So all chats (huge or
> > small
> 
> Same with secushare. Every conversation is a group, not a 1:1.
> 
> > groups) get treated as the same. The user can still decide to use
> > E2E
> > for every message they send which is as inefficient as Signal,
> > Threema
> > and multiple other messengers out there. ^^'
> > 
> > However the E2E ensures that you can privately send a message to
> > only
> > one or multiple selected members of a chatroom. So you are able to
> > invite them to private chatrooms which can be opened dynamically or
> > to
> > just send other sensible information which is not intended for
> > everyone
> > in the chatroom.
> 
> That has the disadvantage that a client which is honest to their
> users could indicate to their users that there is some "whispering"
> going on in the chatroom. In secushare we've been hoping/planning/
> postulating that channel creation must be rather cheap, therefore
> for any new subgroup of recipients you would create a dedicated
> multicast group, irrespective of whether that subgroup happens to
> be in one or several chatrooms together, and/or just happen to
> share a certain view of somebody's social profile as that person
> has categorized them as friends of a special kind. Say you have 50
> people that were at your wedding - they have access to your wedding
> videos on your secushare profile and sit in two chatrooms related
> to the event - distributionwise it all goes through the same
> multicast
> as long as the recipient group is identical.

Yes, there will be something as whispering in a chatroom. But I don't
think this is actually a bad thing. It's just a transparent way of
visualizing that the messenger is actually private and secure. The
moment you see others using that feature, you are convinced it works as
promised.

In comparison in other messengers the user just has to believe that the
application they use encrypts a message and sends it to selected
contacts only. Because visually it doesn't differentiate in any way
from messengers or chats which do not encrypt anything at all. This is
one of many reasons why existing messenger UI is quite confusing for
its users.

Also one reason for these private messages is that the service does not
require you knowing of the peer identity of the selected contact. Peer
identities will only be shared if requested by the user. Otherwise
people can only contact you indirectly via common groups.

In other words if a person does not want you to send messages to them,
they can completely prevent that. I think that should also answer your
question about the potential DoS attack.

> 
> Should that assumption prove wrong, then we need approximizations
> such as "whispering" over existing channels, sending irrelevant
> data and notifications to smartphones that can't even decipher them.
> 
>

signature.asc
Description: This is a digitally signed message part