Re: The messenger service is ready to use

[TheJackiMonster]

On Tue, 2021-03-09 at 12:28 +0100, carlo von lynX wrote:
> 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…

The problem with streaming every piece of data directly still has a
second problem: Everyone will keep the data. Some people may not want
to download a shared video, picture or similar. Some may have
restrictions in the amount of download.

So no matter of the implementation details. A user interface should
definitely allow both options: Download such content automatically for
convenience and download on request.

If I would include the whole files in the send messages everyone
receives and stores, the second option wouldn't be possible. Also
having a preview makes sense if you download on request because it
helps on making a decision.

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

I'm not talking about partitial removal or correction. I mean fully
deletion. At least I didn't find any about this in the paper about Psyc
from 2013.

The deletion message as implemented will remove any evidince from the
stores of all peers. The permission for such deletions is the ownership
of the selected message verified by its encryptic signature. The
deletion message can operate with a custom delay as well.

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

I didn't imply to contact them. Just being able to the get contacts as
results in a search allows drawing conclusions from that if they come
from a social graph.

Many people I know would strongly restrict such a publication of
contacts which would end up in making them very difficult to contact at
all. It's a good structure for social networking but there are people
which tend to dislike social networking these days. Still they need an
application to message someone.

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

Would it be possible to generate trust? In other words does the amount
of others trusting a specific peer makes it trustworthy or does every
user have to rate others with a selected trust-rate?

Because first option would still make the big companies the ones being
trustworthy.

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

I wouldn't say it's unlikely "the idiot" and Robert could be the same
person. Because even trust is not equal to integrity.

Assuming the only option in the current messenger service would be
searching in the DHT for "Michelle", you would probably get a result
like 10 to 1000 different entries... all called "Michelle". So people
clicking on the first entry assuming they can't be fooled are quite
enthusiastic, I guess.

So the first option to add a contact is the physicial exchange (key
pairs get exchanged). The second option is adding a contact which is
already member of a common groupchat (the same key pairs will be used
as in the groupchat). The third option is asking a contact/friend to
establish contact. Then the last option is using a search via DHT for
example.

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

The thing is not everyone likes social networking. So some people won't
share contacts with anyone. However that does not imply they are
strangers, far distanced or unsocial.

Also some people only know others from communication via the internet.
They don't have any common friends making a connection with each other.
So those people could not interact at all?

If yes, I really think social media and messaging should be separate
applications with potential embedding or integration from one to
another. But they should still be usable self-standing.

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

Restricting certain people from contacting you is not equal to avoiding
to socialize. You just select or filter the people you socialize with.
I know several people which completely avoid social media because
everyone can contact them, spam messages and annoy them. So that's an
issue without including any potential DoS attacks.

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

New channels for private conversations would use a random port. So
unless people can brute-force a 512bit hash, I would think it's
unlikely that other people besides the ones invited show up in your
chat.

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

There are certain restrictions what private messages allow but besides
that I think it would be extremely inconvenient to use them instead of
opening a new chat if you just want to have a private conversation. For
example latency would be higher. The messages wouldn't be separate from
other public messages and other people could still see that you are
whispering.

> 
> Happy Tuesday!
> 
>

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