Re: The messenger service is ready to use

[carlo von lynX]

On Sun, Mar 07, 2021 at 12:23:31PM +0100, TheJackiMonster wrote:
> 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.

But it also generates a perception of lack of speed if people click
on a video and it takes a whole while before it can start… a simple
"incoming message" notification similar to today's typing notifications
could do…

> 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.

Didn't understand your argumentation since delete and edit operations
are syntactically integrated into PSYC rather than plastered on top
with custom message types, therefore any PSYC message can contain
modifications of the state including edits and deletions, however
suitable. It's one of the major differences to JSON and XML.

> > 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.

Which shouldn't be legal, and thus those services would no longer
be allowed to operate that way, and make space for a fair and humane
marketplace. Just like it is forbidden to use slavery in the creation
of T-Shirts… wait…

> 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

You only get to see as much of the social graph as your friendship
degree grants you, and in secushare you subscribe a channel of basic
information about each person in your social neighbourhood - even the
ones you haven't met yet - which may contain some basic clues about
that person like #catsitter, so if you look for a cat sitter, you might
find her with a local database search, or none if they so prefer.
Only as you interact with that person and she grants you permission
to subscribe further profile channels does the profile view provide
more and more information tailored to you. These decisions can be
automated and are always executed by open source software running on
your own device.

> decentralized I could query all friends of some contact without them
> knowing about it and track down when they meet anyone or befriend them.

No, you can't. Only the ones that were shown to you, and it would
be visible through whom you are contacting 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

The graph is also needed in order to be able to trust servers that
offer storage capacity and for them to trust you being a person worth
storing data for. And similar structural jobs. Sure, you would still
have encryption wrap around that data, but it's still uncool if all
the data resides on a company's cloud. Social graph offers an
additional way of measuring the trustworthiness of GNUnet nodes.

> 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.

> > 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.

Whereas with the social graph, searching for Michelle would return a
Michelle that is friends with Robert and a few other peeps, some
other Michelle that is friends with other folks, and a fake Michelle
who's only friend is the idiot who is desperately trying to fool you.
I think this is a lot safer than using a DHT w/o social graph.

> 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.

This is good for bootstrap, but you don't want to be vulnerable in
the long run as soon as millions of people have adopted your tool,
the abuse happens day-to-day like spam and phishing and you no longer
have any simple options to deal with it.

> > 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?

No, that's when you want to make a solid in-person exchange.
Frequently, as Facebook shows, you would then find out that you 
already have five or 23 friends in common, but that adds to the fun.

I don't think our tool should be suitable for spamming complete
strangers at the other end of the planet, but if you need to talk
to a professor in your line of business somewhere in Quebec, you
should have enough professional contacts to somehow build a few
social paths to this person.

> > 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.

That answer has some flaws: it's not good if the protection against
potential DoS works by avoiding to socialise with people, and it
also not good if it stops working as soon as your perpretator got
a hold on your public key and can thus attack its DHT nodes.

> > 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.

You haven't argumented why it wouldn't be possible to allocate
all the channels one might want to have. Picking up a pubkey from
a common channel to start a private conversation shouldn't put
anyone in the position of being able to DoS anyone else. The
private conversation may be rejected by default at first, if
there wasn't an invitation to start it - but I see no use in
embedding private conversations which could contain sexting or
a deejay mix for the party, into a channel which will distribute
it to all recipients, even if 99% cannot decrypt it. Either you
have a terrific waste of resources, or you have to introduce an
artificial limit to what message types you can "whisper".

Happy Tuesday!


-- 
  E-mail is public! Talk to me in private using encryption:
   //  http://loupsycedyglgamf.onion/LynX/
  //    irc://loupsycedyglgamf.onion:67/lynX
 //    https://psyced.org/LynX/