Discussion:
[whispersystems] Textsecure-Server
Ahmadova Matanat
2015-11-17 20:59:35 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hello,


I am trying to run my own textsecure-server. From

https://github.com/WhisperSystems/TextSecure-Server/issues/5

I understood that I must install postgresql, redis, memcached. After
it what should I do with these programs? how should I run a server?

Also, I don't have local.yml file that is written in web site.

Can you please explain me step-by-step what should I do?



Regards,

Matanat Ahmadova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWS5UtAAoJENn1YqUpKwXTfLgQALYsgp0H1R31CUQsb3BavrbO
S+ejmS5eOD6ErODMFgNX86cV+FP3m4KBb+SLF/t6613QOnVCSVxiP6Om7GMP30Q9
L7zaAxs4WEAsLB64EXNU9L29HHyijMMsUxZu2t0RCB9aTpmIVaWdQrCMBDhGtg0B
xjedcEwYVmNTHOh9js5wD1intuonwEuhVPgyBbW8DW2A/Mu7/8AeZeOt9HkJB4rj
LJnFTSm9pbtacxZnBzhGMIlj9Z8lOti+18dOyp3Qlc8/oqmlfaHQcLBc3Tx7jIOT
XmqciJ67WE70iaurNtXRnfQiBXMruyvk2J7F2llQEa+MsYhmsmI2lZHxclyd7YUY
Vw77dW7BJN/yR1RlY2LRCfE/cD1/0D77FoMEYYKEmxlyXS9Yo6Fdtxm8ulIvFA7T
TMPXmMNHoiq59s0Lrt3La6cFFHhONoKmvwvAzOlntXYJ+4YLW9E9d5Mw8KmAzqSD
qk0Kifuauq5EMDQsXeqsEpVnMzsRJv3v/O4+Ux+6cM2nxgup7BsHMzUWUkTzLh+T
ZeyqipwhiqfpLqYJjWN8fc6LjAuYrrRb9oi5yXCqVBimBmWFWdthuaqLfVyFL6oC
79d/jD/Kcm5liCiO4YxlYgJVzHpF8AQ6rgcwVdQivBhINIUc0BlVl6kJilzQU2xb
zBGhjhANvGP/wW8mttuG
=bpnD
-----END PGP SIGNATU
James Firth
2015-11-17 21:34:34 UTC
Permalink
Hey Matanat,

As far as I understand the mailing list isn't for supporting running ones
own server. Good luck though!
Post by Ahmadova Matanat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I am trying to run my own textsecure-server. From
https://github.com/WhisperSystems/TextSecure-Server/issues/5
I understood that I must install postgresql, redis, memcached. After
it what should I do with these programs? how should I run a server?
Also, I don't have local.yml file that is written in web site.
Can you please explain me step-by-step what should I do?
Regards,
Matanat Ahmadova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWS5UtAAoJENn1YqUpKwXTfLgQALYsgp0H1R31CUQsb3BavrbO
S+ejmS5eOD6ErODMFgNX86cV+FP3m4KBb+SLF/t6613QOnVCSVxiP6Om7GMP30Q9
L7zaAxs4WEAsLB64EXNU9L29HHyijMMsUxZu2t0RCB9aTpmIVaWdQrCMBDhGtg0B
xjedcEwYVmNTHOh9js5wD1intuonwEuhVPgyBbW8DW2A/Mu7/8AeZeOt9HkJB4rj
LJnFTSm9pbtacxZnBzhGMIlj9Z8lOti+18dOyp3Qlc8/oqmlfaHQcLBc3Tx7jIOT
XmqciJ67WE70iaurNtXRnfQiBXMruyvk2J7F2llQEa+MsYhmsmI2lZHxclyd7YUY
Vw77dW7BJN/yR1RlY2LRCfE/cD1/0D77FoMEYYKEmxlyXS9Yo6Fdtxm8ulIvFA7T
TMPXmMNHoiq59s0Lrt3La6cFFHhONoKmvwvAzOlntXYJ+4YLW9E9d5Mw8KmAzqSD
qk0Kifuauq5EMDQsXeqsEpVnMzsRJv3v/O4+Ux+6cM2nxgup7BsHMzUWUkTzLh+T
ZeyqipwhiqfpLqYJjWN8fc6LjAuYrrRb9oi5yXCqVBimBmWFWdthuaqLfVyFL6oC
79d/jD/Kcm5liCiO4YxlYgJVzHpF8AQ6rgcwVdQivBhINIUc0BlVl6kJilzQU2xb
zBGhjhANvGP/wW8mttuG
=bpnD
-----END PGP SIGNATURE-----
Isak Holmström
2015-11-18 12:33:23 UTC
Permalink
Hello,

I am completely new to this list so please be kind :-) I was wondering
if Whispersystems have a plan to implement a self destruct timer to the
conversations?

I couldn't find any info about this great feature. I know that the cloud
based messages app Telegram got support for this. But this might only
work when a service is cloud based?

Best regards,

Isak Holmstr�m ***@kajko.se +46(0)705323820
Sam Holton
2015-11-18 12:54:06 UTC
Permalink
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.

http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
Post by Ahmadova Matanat
Hello,
I am completely new to this list so please be kind :-)
I was wondering if Whispersystems have a plan to implement a self destruct
timer to the conversations?
I couldn't find any info about this great feature. I know that the cloud
based messages app Telegram got support for this. But this might only work
when a service is cloud based?
Best regards,
Isak Holmström
+46(0)705323820
Steffen Märcker
2015-11-18 12:57:18 UTC
Permalink
Additionally, I'd like to ask why some people want this? Do they bare in
mind that spoken words are like shot arrows: They never come back.
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
Post by Ahmadova Matanat
Hello,
I am completely new to this list so please be kind :-)
I was wondering if Whispersystems have a plan to implement a self destruct
timer to the conversations?
I couldn't find any info about this great feature. I know that the cloud
based messages app Telegram got support for this. But this might only work
when a service is cloud based?
Best regards,
Isak Holmström
+46(0)705323820
Tim Kuijsten
2015-11-18 13:12:47 UTC
Permalink
Post by Steffen Märcker
Additionally, I'd like to ask why some people want this? Do they bare in
mind that spoken words are like shot arrows: They never come back.
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
I agree it does not give any guarantee from a security point of view.

Personally I don't like the idea that my conversations with close
friends and family are stored on their, often insecure, devices
indefinitely. It's a hurdle to ask the other party to delete the message
history you share with them (and I do trust they do that when they
confirm, hence the security argument is not what it's about here). I
like to set an auto-expire period on a conversation so I don't have to
bother my friends with asking them to delete past conversations since
they don't really care.

-Tim
Isak Holmström
2015-11-18 14:03:30 UTC
Permalink
I want this feature as Tim explain it. Sometimes I want a message to be
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I like
Tims name for it auto-expire period.
--
Best regards,
Isak
Post by Tim Kuijsten
Post by Steffen Märcker
Additionally, I'd like to ask why some people want this? Do they bare in
mind that spoken words are like shot arrows: They never come back.
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
I agree it does not give any guarantee from a security point of view.
Personally I don't like the idea that my conversations with close
friends and family are stored on their, often insecure, devices
indefinitely. It's a hurdle to ask the other party to delete the message
history you share with them (and I do trust they do that when they
confirm, hence the security argument is not what it's about here). I
like to set an auto-expire period on a conversation so I don't have to
bother my friends with asking them to delete past conversations since
they don't really care.
-Tim
Tim Kuijsten
2015-11-18 14:14:16 UTC
Permalink
Post by Isak Holmström
I want this feature as Tim explain it. Sometimes I want a message to be
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I like
Tims name for it auto-expire period.
+1 for *not* naming it something completely misleading and
sensationalist like "self destruct". A default expiry period would be
way more subtle and mitigate security problems with modern day devices.
359
2015-11-18 14:18:11 UTC
Permalink
you forgot that many people, me included, would never install app where messages of our contacts would just disapear. no way! i'd call that an attack on my phone.
: P
--
359!
Post by Tim Kuijsten
Post by Isak Holmström
I want this feature as Tim explain it. Sometimes I want a message to
be
Post by Isak Holmström
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I
like
Post by Isak Holmström
Tims name for it auto-expire period.
+1 for *not* naming it something completely misleading and
sensationalist like "self destruct". A default expiry period would be
way more subtle and mitigate security problems with modern day devices.
Markux
2015-11-18 15:11:18 UTC
Permalink
There is a simpler way to achieve such illusion: tell your friend you
want him to shred your message... and trust him. If you can't trust him,
then such a feature wont help you. Change your friend, not your IM soft ;-)

Markus.
-------
Post by Isak Holmström
I want this feature as Tim explain it. Sometimes I want a message to be
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I like
Tims name for it auto-expire period.
Post by Steffen Märcker
Additionally, I'd like to ask why some people want this? Do they bare in
mind that spoken words are like shot arrows: They never come back.
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
Post by Isak Holmström
I agree it does not give any guarantee from a security point of view.
Personally I don't like the idea that my conversations with close
friends and family are stored on their, often insecure, devices
indefinitely. It's a hurdle to ask the other party to delete the message
history you share with them (and I do trust they do that when they
confirm, hence the security argument is not what it's about here). I
like to set an auto-expire period on a conversation so I don't have to
bother my friends with asking them to delete past conversations since
they don't really care.
-Tim
Tim Kuijsten
2015-11-18 15:22:27 UTC
Permalink
Post by Markux
There is a simpler way to achieve such illusion: tell your friend you
want him to shred your message... and trust him. If you can't trust him,
then such a feature wont help you. Change your friend, not your IM soft ;-)
Markus.
-------
The thing is I trust my contact, I just don't want to trust his device
indefinitely into the future. And I don't want to bother him, time and
time again to delete old messages. It's hard to ask friends to do
something for you over and over again if they don't really care.

The longer a phone is in use, the bigger the liability becomes as it
contains more and more data and history. I'm not sure we should accept
this as a sane default, especially given the current state of phone
security and lack of updates.
Olaf Leidinger
2015-11-18 15:32:42 UTC
Permalink
Hey,
Post by Tim Kuijsten
The thing is I trust my contact, I just don't want to trust his device
indefinitely into the future.
[...]
I'm not sure we should accept this as a sane default,
especially given the current state of phone security and lack of updates.
I'd rather tell your friends to set a password for TextSecure. That
way, the communication archive should be protected. And even if some
malicious app reads your friend's SD card, you're still safe.


Best,

Olaf
Tim Kuijsten
2015-11-18 15:42:19 UTC
Permalink
Post by Olaf Leidinger
Hey,
Post by Tim Kuijsten
The thing is I trust my contact, I just don't want to trust his device
indefinitely into the future.
[...]
I'm not sure we should accept this as a sane default,
especially given the current state of phone security and lack of updates.
I'd rather tell your friends to set a password for TextSecure. That
way, the communication archive should be protected. And even if some
malicious app reads your friend's SD card, you're still safe.
Best,
Olaf
This does sound like a solution for contacts you have a certain
influence on. I'm talking about minimizing the archive, i.e. a
mitigation for all those contacts where "tell your friend to" doesn't
work. It's orthogonal to your solution.
Markux
2015-11-18 16:07:05 UTC
Permalink
Post by Tim Kuijsten
This does sound like a solution for contacts you have a certain
influence on. I'm talking about minimizing the archive, i.e. a
mitigation for all those contacts where "tell your friend to" doesn't
work. It's orthogonal to your solution.
Hi Tim.

Trust a friend who is not going to erase your messages despite your
request is orthogonal to your interest too.

Anyway, it's not that easy. If your message deserves to be self-erased
because you don't trust your friend's smartphone, then you may consider
things can get complex: your not-absolutly-trusted friend can forward
your IM to a less-trusted friend. Keep moving along this proccess; a
couple of jumps away your IM will be in the wrong inbox.

I can't imagine such a feature: marking a message for self-destructing
should erase the full list of copies between you and the wrong inbox. I
will modify and a personal copy of Signal which wont do that.



Regards.
Markus.
Eric Hartsuyker
2015-11-18 15:45:35 UTC
Permalink
Telegram does this in a clear way. When you set the timer, it displays a
message like "the self destruct timer has been set for one week." Now both
users know. This could be done with a confirmation where both users have to
agree for it to be set so you will never have something deleted from your
device against your consent. Then, a logo saying "1W" appears on the
conversation so you know it's set. If Signal adds this, it should be done
more or less this way. On a "per message" basis is going to be confusing,
annoying, and people might forget to set it every time.

Whether or not the OWS guys want that added is a different topic.

-E
Post by Tim Kuijsten
Hey,
Post by Tim Kuijsten
The thing is I trust my contact, I just don't want to trust his device
indefinitely into the future.
[...]
I'm not sure we should accept this as a sane default,
especially given the current state of phone security and lack of
updates.
I'd rather tell your friends to set a password for TextSecure. That
way, the communication archive should be protected. And even if some
malicious app reads your friend's SD card, you're still safe.
Best,
Olaf
c***@mailbox.org
2015-11-18 16:54:57 UTC
Permalink
Post by Olaf Leidinger
Post by Benjamin Schäfer
I also think an auto-expire function would be an interesting
feature. I imagine it will be most commonly used by senders that
care a lot about privacy when contacting somebody who might not
care as much.
But when you care that much about privacy, why would you rely on a
feature that can't be implemented reliably? E.g. you could use an
encrypted Signal phone call instead.
Because this is not a guaranteed security improvement intented for
situations where maximum protection is needed.
Instead it is aimed at improving security in the much more common case
where the involved contacts prioritize privacy differently and
additional ephemerability of messages is nice to have.

Because the communicating partners give security different priorities,
your proposed solutions will never work.
Post by Olaf Leidinger
Post by Benjamin Schäfer
A global setting could be implemented in which the user could
decide whether expiration headers should be respected.
1. The phone gets stolen before the messages are expired and the
thieve disables auto-deletion.
Kind of like the difference between forward security and future security.
In this case the thief will never be able to get the older messages
(which are deleted), while he may get newer ones which weren't deleted
yet or by waiting or imitating the owner. This only works until the
contacts of the original owner are informed about the phone beeing
stolen tough.
This means a huge lot of information which was received earlier is safe
from the thiev tough.
Post by Olaf Leidinger
2. The user at the other end just disables this setting.
In this case the users trust model is broken, not the trust model of
Signal. You could as well ask "and what if the person you are
communicating with is a spy?". If you can't trust the people you are
communicating with, no technology can protect your communication.
And this is why disabling this has to either require patching and
compiling Signal OR the sender has to be constantly aware of the
non-ephemerability of their messages to this contact.
Because the latter would further clutter the UI I am against the option
to block automated deletion of old messages.

If you really need this information, you can take a screenshot or write
it down.
Post by Olaf Leidinger
IMHO it's better to rely on the messages being encrypted and the
device being locked in case the phone is stolen.
Yes, but you will never be able to force your non-security-aware friends
to use good passphrases with 128+ bits of entrophy.
Even if they wanted to, they'd probably fail like everybody else. But
most importantly they will instead tell you they've had enough and are
using whatsapp again.
Post by Olaf Leidinger
Post by Benjamin Schäfer
[...] Thus it might create an illusion of improved security (like
James said) just like self destruct messages.
ACK.
No. If the wording and UI is clear, this will not be a problem. While it
is true that the average user is not good at reading and understanding
technical details, they can be made to understand making a very clear
and straight forward UI.
Post by Olaf Leidinger
Post by Benjamin Schäfer
The thing is I trust my contact, I just don't want to trust his
device indefinitely into the future. [...] I'm not sure we should
accept this as a sane default, especially given the current state
of phone security and lack of updates.
I'd rather tell your friends to set a password for TextSecure. That
way, the communication archive should be protected. And even if some
malicious app reads your friend's SD card, you're still safe.
As I wrote before, the reaction will either be refusal or failure, none
of which reduce exposure. Ephemerality does.
TWfromSWD
2015-11-18 16:10:01 UTC
Permalink
If you have friends that don't care about your privacy, would such a
feature really help? They could take a screenshot of your message or
just create a backup. I would try to convince my friends rather than try
to force them into removing messages by using a possible insecure feature.

By the way: I wouldn't feel very safe if I knew that my messenger could
delete messages by itself. That kinda sounds like censoring for me. Also
it would be hard to reconstruct conversations that happened longer ago
when one person decided to delete their part of it. Also I sense some
potential for abuse.

And as a matter of fact: You wouldn't gain security. You could suggest
the other application to delete the message but would have no guarantee
that this would really happen. And if someone just doesn't want such a
feature, it would be fairly easy to remove it and use a Signal version
without it. Where is the security in that?
Post by Tim Kuijsten
Post by Markux
There is a simpler way to achieve such illusion: tell your friend you
want him to shred your message... and trust him. If you can't trust him,
then such a feature wont help you. Change your friend, not your IM soft ;-)
Markus.
-------
The thing is I trust my contact, I just don't want to trust his device
indefinitely into the future. And I don't want to bother him, time and
time again to delete old messages. It's hard to ask friends to do
something for you over and over again if they don't really care.
The longer a phone is in use, the bigger the liability becomes as it
contains more and more data and history. I'm not sure we should accept
this as a sane default, especially given the current state of phone
security and lack of updates.
Tim Kuijsten
2015-11-18 16:24:45 UTC
Permalink
Post by TWfromSWD
If you have friends that don't care about your privacy, would such a
feature really help? They could take a screenshot of your message or
just create a backup. I would try to convince my friends rather than try
to force them into removing messages by using a possible insecure feature.
By the way: I wouldn't feel very safe if I knew that my messenger could
delete messages by itself. That kinda sounds like censoring for me. Also
it would be hard to reconstruct conversations that happened longer ago
when one person decided to delete their part of it. Also I sense some
potential for abuse.
And as a matter of fact: You wouldn't gain security. You could suggest
the other application to delete the message but would have no guarantee
that this would really happen. And if someone just doesn't want such a
feature, it would be fairly easy to remove it and use a Signal version
without it. Where is the security in that?
This is not about individual cases or the fact that it's not a security
solution (I agree on that). It's about reducing the amount of sensitive
data for 99% of the eco system. If a default expiry date of a couple of
months is set on every new conversation and is adjustable by both
parties (without confirmation, only notification), this would have the
bigger effect of most Signal installations not having more than only a
couple of months of conversations carrying around. And still gives any
involved party a way to communicate and change this behavior if he or
she cares without the need for acknowledgment of all parties. Of course
a chosen expiry period can only apply on subsequent messages, not on
previously sent messages that might have had a different expiry period.
Shankar Kulumani
2015-11-18 16:27:34 UTC
Permalink
How about setting the trim messages default to something smaller?

This way only 500-1000 messages are kept by default?

This would not involve any new options/preferences but simply a change to
the current default?
Post by Tim Kuijsten
Post by TWfromSWD
If you have friends that don't care about your privacy, would such a
feature really help? They could take a screenshot of your message or
just create a backup. I would try to convince my friends rather than try
to force them into removing messages by using a possible insecure feature.
By the way: I wouldn't feel very safe if I knew that my messenger could
delete messages by itself. That kinda sounds like censoring for me. Also
it would be hard to reconstruct conversations that happened longer ago
when one person decided to delete their part of it. Also I sense some
potential for abuse.
And as a matter of fact: You wouldn't gain security. You could suggest
the other application to delete the message but would have no guarantee
that this would really happen. And if someone just doesn't want such a
feature, it would be fairly easy to remove it and use a Signal version
without it. Where is the security in that?
This is not about individual cases or the fact that it's not a security
solution (I agree on that). It's about reducing the amount of sensitive
data for 99% of the eco system. If a default expiry date of a couple of
months is set on every new conversation and is adjustable by both parties
(without confirmation, only notification), this would have the bigger
effect of most Signal installations not having more than only a couple of
months of conversations carrying around. And still gives any involved party
a way to communicate and change this behavior if he or she cares without
the need for acknowledgment of all parties. Of course a chosen expiry
period can only apply on subsequent messages, not on previously sent
messages that might have had a different expiry period.
Stephen Michel
2015-11-18 16:57:51 UTC
Permalink
Hi all,

Lurker here; I want to jump in here to propose a solution that I think
should be amicable to all.

1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a
message *would* be deleted, show the user a notification explaining
that by default Signal deletes messages older than XYZ and that
conversation Y is about to be deleted. The user can then choose to Keep
Defaults, Set a Custom Value, or Turn Trimming Off.

This accomplishes the following:

1. Users do not feel like the app has betrayed them by deleting
messages without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default
retention period is ("It's been this long since I installed Signal; I
really don't care about messages that old.").

Cheers.
Johan Wevers
2015-11-18 17:05:54 UTC
Permalink
Post by Stephen Michel
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
It currently defaults to 500 messages and the default setting is OFF. A
timer (delete after X time) is no option.

No way to default it to on! If I want a program to delete messages of
its own I want the one who makes that choice willingly, and I don't want
to loose messages due to forgetting that on a new install.
--
Met vriendelijke groet,

Johan Wevers
Stephen Michel
2015-11-18 17:07:54 UTC
Permalink
Post by Johan Wevers
Post by Stephen Michel
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
It currently defaults to 500 messages and the default setting is OFF. A
timer (delete after X time) is no option.
No way to default it to on! If I want a program to delete messages of
its own I want the one who makes that choice willingly, and I don't want
to loose messages due to forgetting that on a new install.
#3 addresses this point. The app will not delete anything without
consulting you first.
Johan Wevers
2015-11-18 17:39:25 UTC
Permalink
Post by Stephen Michel
#3 addresses this point. The app will not delete anything without
consulting you first.
I agree with #359 that this leads to bloatware. And for most people it
will probably be a reason to switch automatic deletion off.
--
Met vriendelijke groet,

Johan Wevers
Tim Kuijsten
2015-11-18 17:58:39 UTC
Permalink
Post by Johan Wevers
Post by Stephen Michel
#3 addresses this point. The app will not delete anything without
consulting you first.
I agree with #359 that this leads to bloatware. And for most people it
will probably be a reason to switch automatic deletion off.
I agree as well. I was thinking about one setting per conversation where
one can select different periods (week, month, three-months) and this
only applies to new messages sent after setting that particular period.
It's easy to print a "the other user has set the expiry date to 3
months" kind of message so that both parties know any message that is
sent after this line expires after 3 months. (Yes, this is a very simple
UI and how Telegram has implemented it, unfortunately they used the
sensationalist and misleading term "self-destruct" for it which makes
you look weird again with your non-technical friends ;-))

I think the debate should be about what the default should be for such a
per-message-expiry setting (off, 1 week, 1 month, 1 year). And again,
the goal is not to secure something, but to have *less to secure* (less
history in most phones).
Stephen Michel
2015-11-18 19:15:13 UTC
Permalink
I agree that we should seek to minimize settings. However, the
important part of my proposal is the method by which the user interacts
with message expiry settings. Whether message expiry is controlled by
message count, age, or both is largely irrelevant. Here's the logic
behind how I reach these conclusions (some rehash):

Premise: If the receiver wants to keep a copy, they will do that, even
if it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct"
is making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**

There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.

Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against
any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be
more valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages
on their own.*
Premise: Users will not change default settings unless prompted and
given incentive to do so.

Conclusion: Users are divided into three groups:
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security features
in favor of convenience.

Conclusion:
It is in group A's best interest for group B to use security features,
and for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the
defaults. Therefore, to support group A, we should make the security
feature be opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as
possible. The opt-out must be painless.

Conclusion: Message expiry should be turned on by default. This should
be a global setting that the user only must interact with once, at the
latest time at which there is still ample chance to disable it before
any messages are erased.

Either that, or accept that the convenience cost of message expiry is
too high, and abstain from implementing altogether.
Stephen Michel
2015-11-18 19:23:17 UTC
Permalink
Just realized that intro makes it seem like I'm explaining why number
of settings is irrelevant. It's not; number of settings is imortant,
just not what I'm discussing here.

On Wed, Nov 18, 2015 at 2:15 PM, Stephen Michel
Post by Stephen Michel
I agree that we should seek to minimize settings. However, the
important part of my proposal is the method by which the user
interacts with message expiry settings. Whether message expiry is
controlled by message count, age, or both is largely irrelevant.
Premise: If the receiver wants to keep a copy, they will do that,
even if it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct"
is making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed
"self-destruct" feature. Instead, we should think about Message
Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect
against any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be
more valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without
user knowledge and permission, many of those users will uninstall the
app.
Premise: Wide Adoption and friendliness to non-technical users are
key goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old
messages on their own.*
Premise: Users will not change default settings unless prompted and
given incentive to do so.
A: Security-minded individuals who would opt IN to security features
at the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security
features in favor of convenience.
It is in group A's best interest for group B to use security
features, and for as many users to switch from group C to group B as
possible.
Group B is the interesting group, because they will follow the
defaults. Therefore, to support group A, we should make the security
feature be opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as
possible. The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This
should be a global setting that the user only must interact with
once, at the latest time at which there is still ample chance to
disable it before any messages are erased.
Either that, or accept that the convenience cost of message expiry is
too high, and abstain from implementing altogether.
Emory Roane
2015-11-18 19:40:27 UTC
Permalink
Another Lurker Here,
There's not much I could add to Stephen's excellent breakdown, but I've
seen this paradigm play out countless times before. As it stands, we're
essentially held prisoner to the defaults.

Asking someone who is in Group B or (even worse) Group C to even *use* Signal
over the default messaging app on their phone is already a huge chore.
Going in and then politely asking them to set an additional password (which
is, really, a huge PITA for folks that already feel inundated with more
accounts and bad passwords than they can handle) has been next to
impossible for me. And I'm someone who evangelizes Signal literally to
anyone that sends me an unsecure text message. Setting the message trimming
feature to on by default with a confirmation or gui prompt that explains,
and offers to disable the feature before anything is actually deleted would
be a *huge* step in securing the vast majority of security unaware
adoptees.

I wholeheartedly support Stephen's proposal, which sounds like a very well
reasoned compromise.

Emory Roane
Juris Doctor Candidate
California Western School of Law
Just realized that intro makes it seem like I'm explaining why number of
settings is irrelevant. It's not; number of settings is imortant, just not
what I'm discussing here.
I agree that we should seek to minimize settings. However, the important
part of my proposal is the method by which the user interacts with message
expiry settings. Whether message expiry is controlled by message count,
age, or both is largely irrelevant. Here's the logic behind how I reach
Premise: If the receiver wants to keep a copy, they will do that, even if
it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct" is
making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against any
compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be more
valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages on
their own.*
Premise: Users will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security features
in favor of convenience.
C: Security-unaware individuals who would opt out of security features in
favor of convenience.
It is in group A's best interest for group B to use security features, and
for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the defaults.
Therefore, to support group A, we should make the security feature be
opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as possible.
The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should be
a global setting that the user only must interact with once, at the latest
time at which there is still ample chance to disable it before any messages
are erased.
Either that, or accept that the convenience cost of message expiry is too
high, and abstain from implementing altogether.
#359
2015-11-18 20:08:56 UTC
Permalink
it's a nice breakdown, but the second part is just - wrong. it's biased
by your wish to have a feature that you want. i think it's just paranoid
to look at Message Expiry as a security feature. it's not.

it's not for a mainstream user. with Device Encyiption for storage
and End to end encryption for transfer we have all we need for an
average user.

op.sec. is another story, where this feature is even more unneeded
because you need a trained user with the knowledge of her adversary. a
lawyer, journalist, activist, Ed Snowden or cheating husband would have
to send as few information by the phone as possible, delete every
message after reading or even not communicate via mobile phone at all.

i think the Message Expiry as a security feature would only benefit one
kind of user - a paranoic.


- jure

ps - i am very sorry for using some strong words but i think this idea
is ridiculous. ;)
Post by Stephen Michel
I agree that we should seek to minimize settings. However, the
important part of my proposal is the method by which the user
interacts with message expiry settings. Whether message expiry is
controlled by message count, age, or both is largely irrelevant.
Premise: If the receiver wants to keep a copy, they will do that, even
There is no way for a sender to enforce that the receiver keeps no
copy. Therefore, the recipient owns the message. Conclusion: Any
feature that claims to implement "true self-destruct" is making a
false promise. Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against
any compromising that may happen in the future. Premise: Many users
consider the ability to read old messages to be more valuable than the
security gained from minimal storage. Premise: If Signal implemented
forced expiry, particularly without user knowledge and permission,
many of those users will uninstall the app. Premise: Wide Adoption and
friendliness to non-technical users are key goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old
messages on their own.* Premise: Users will not change default
settings unless prompted and given incentive to do so.
A: Security-minded individuals who would opt IN to security features
at the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security features
in favor of convenience.
Conclusion: It is in group A's best interest for group B to use
security features, and for as many users to switch from group C to
group B as possible. Group B is the interesting group, because they
will follow the defaults. Therefore, to support group A, we should
make the security feature be opt-out rather than opt-in. It is in
group C's best interest to have the minimum interaction with settings.
Therefore, we should delay any opt-out for as long as possible. The
opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should
be a global setting that the user only must interact with once, at the
latest time at which there is still ample chance to disable it before
any messages are erased.
Either that, or accept that the convenience cost of message expiry is
too high, and abstain from implementing altogether.
Michael Herbig
2015-11-18 20:39:15 UTC
Permalink
I think this comment by Moxie (in relation to Signal requiring a phone
number) holds for this as well:

"If we were going to rank our priorities, they would be in this order:
1) Make mass surveillance impossible. 2) Stop targeted attacks against
crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1 takes
precedence when we're making decisions. It's totally possible for you to
install Signal on an iPod touch with a VoIP number, for instance, but that
takes more effort than the common case we're designing for."
it's a nice breakdown, but the second part is just - wrong. it's biased by
your wish to have a feature that you want. i think it's just paranoid to
look at Message Expiry as a security feature. it's not.
it's not for a mainstream user. with Device Encyiption for storage and End
to end encryption for transfer we have all we need for an average user.
op.sec. is another story, where this feature is even more unneeded because
you need a trained user with the knowledge of her adversary. a lawyer,
journalist, activist, Ed Snowden or cheating husband would have to send as
few information by the phone as possible, delete every message after
reading or even not communicate via mobile phone at all.
i think the Message Expiry as a security feature would only benefit one
kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think this idea is
ridiculous. ;)
I agree that we should seek to minimize settings. However, the important
part of my proposal is the method by which the user interacts with message
expiry settings. Whether message expiry is controlled by message count,
age, or both is largely irrelevant. Here's the logic behind how I reach
Premise: If the receiver wants to keep a copy, they will do that, even if
it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct" is
making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against any
compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be more
valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages on
their own.*
Premise: Users will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security features
in favor of convenience.
C: Security-unaware individuals who would opt out of security features in
favor of convenience.
It is in group A's best interest for group B to use security features, and
for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the defaults.
Therefore, to support group A, we should make the security feature be
opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as possible.
The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should be
a global setting that the user only must interact with once, at the latest
time at which there is still ample chance to disable it before any messages
are erased.
Either that, or accept that the convenience cost of message expiry is too
high, and abstain from implementing altogether.
Emory Roane
2015-11-18 20:46:10 UTC
Permalink
My problem with dismissing this issue, though, is that we don't have
encrypted local database by default, unless I'm misunderstanding the
default settings. Any user who downloads Signal has to go hunting in the
settings to enable a password, and I would bet that as a result the vast
majority of users don't.

You don't have to be a paranoic to recognize that devices that were once
secure can be compromised. If the phone is unlocked, or didn't have a
password (which is also likely if the person doesn't have a password on
Signal) then the user with default settings' entire history of
communication is compromised.

Obviously the password and encrypted local database is a huge security
boon, but unless it's enabled by default then it's not going to get used.
If the purpose of Signal is to bring the most security to the largest
number of people (recognizing the net benefit we all gain from implementing
secure standards, even and especially in the case of security unaware
users) I don't see why this option shouldn't be heavily encouraged whenever
possible.
Thoughts?
Cheers,

Emory Roane
Juris Doctor Candidate
California Western School of Law
Post by Michael Herbig
I think this comment by Moxie (in relation to Signal requiring a phone
1) Make mass surveillance impossible. 2) Stop targeted attacks against
crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1 takes
precedence when we're making decisions. It's totally possible for you to
install Signal on an iPod touch with a VoIP number, for instance, but that
takes more effort than the common case we're designing for."
Post by #359
it's a nice breakdown, but the second part is just - wrong. it's biased
by your wish to have a feature that you want. i think it's just paranoid to
look at Message Expiry as a security feature. it's not.
it's not for a mainstream user. with Device Encyiption for storage and
End to end encryption for transfer we have all we need for an average user.
op.sec. is another story, where this feature is even more unneeded
because you need a trained user with the knowledge of her adversary. a
lawyer, journalist, activist, Ed Snowden or cheating husband would have to
send as few information by the phone as possible, delete every message
after reading or even not communicate via mobile phone at all.
i think the Message Expiry as a security feature would only benefit one
kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think this idea is
ridiculous. ;)
I agree that we should seek to minimize settings. However, the important
part of my proposal is the method by which the user interacts with message
expiry settings. Whether message expiry is controlled by message count,
age, or both is largely irrelevant. Here's the logic behind how I reach
Premise: If the receiver wants to keep a copy, they will do that, even if
it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct" is
making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against
any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be more
valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages
on their own.*
Premise: Users will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security features in
favor of convenience.
It is in group A's best interest for group B to use security features,
and for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the defaults.
Therefore, to support group A, we should make the security feature be
opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as possible.
The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should be
a global setting that the user only must interact with once, at the latest
time at which there is still ample chance to disable it before any messages
are erased.
Either that, or accept that the convenience cost of message expiry is too
high, and abstain from implementing altogether.
Cl En
2015-11-18 21:02:13 UTC
Permalink
another scenario (of self deleting messages) = another app

Email for work; Signal for crypted; land line telephone for private; self
deleting messages for emotions.

E.g. https://taptalk.me/faq
Photo messages with added text, and after you’ve seen a message it is
deleted. No Snapchat crap.

Sry, my 2¢
C
Post by Michael Herbig
I think this comment by Moxie (in relation to Signal requiring a phone
1) Make mass surveillance impossible. 2) Stop targeted attacks against
crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1 takes
precedence when we're making decisions. It's totally possible for you to
install Signal on an iPod touch with a VoIP number, for instance, but that
takes more effort than the common case we're designing for."
Post by #359
it's a nice breakdown, but the second part is just - wrong. it's biased
by your wish to have a feature that you want. i think it's just paranoid to
look at Message Expiry as a security feature. it's not.
it's not for a mainstream user. with Device Encyiption for storage and
End to end encryption for transfer we have all we need for an average user.
op.sec. is another story, where this feature is even more unneeded
because you need a trained user with the knowledge of her adversary. a
lawyer, journalist, activist, Ed Snowden or cheating husband would have to
send as few information by the phone as possible, delete every message
after reading or even not communicate via mobile phone at all.
i think the Message Expiry as a security feature would only benefit one
kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think this idea is
ridiculous. ;)
I agree that we should seek to minimize settings. However, the important
part of my proposal is the method by which the user interacts with message
expiry settings. Whether message expiry is controlled by message count,
age, or both is largely irrelevant. Here's the logic behind how I reach
Premise: If the receiver wants to keep a copy, they will do that, even if
it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct" is
making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against
any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be more
valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages
on their own.*
Premise: Users will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security features in
favor of convenience.
It is in group A's best interest for group B to use security features,
and for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the defaults.
Therefore, to support group A, we should make the security feature be
opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as possible.
The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should be
a global setting that the user only must interact with once, at the latest
time at which there is still ample chance to disable it before any messages
are erased.
Either that, or accept that the convenience cost of message expiry is too
high, and abstain from implementing altogether.
Isak Holmström
2015-11-19 07:54:07 UTC
Permalink
Hello, It's me again. So lots of people got different opinions about
what I first incorrectly called 'self-destructing messages' then later
renamed to 'expiring messages'. With some help from Tim.

The reason for this was not to remove messages with no consent from the
receiver. The idea was more having the option to start a new
thread/message thread for expiring messages. Like today, you got the
choice for a regular Message/SMS and a Signal Message. I would like to
see a third option called for example 'Expiring Message' or something
more clear to clarify. The option to remove already received messages
was never the intent.And never aimed for regular Messages/SMS not even
on Signal Messages.

I hope this makes it clearer and more sense. Please help me explain this
if you get me :-)

Best regards,

Isak Holmström ***@kajko.se +46(0)705323820


On Wed, Nov 18, 2015, at 22:02, Cl En wrote:
another scenario (of self deleting messages) = another app
Post by Cl En
Email for work; Signal for crypted; land line telephone for private;
self deleting messages for emotions.
E.g. https://taptalk.me/faq
Photo messages with added text, and after you’ve seen a message it is
deleted. No Snapchat crap.
Post by Cl En
Sry, my 2¢
C
Post by Cl En
Post by Michael Herbig
I think this comment by Moxie (in relation to Signal requiring a
"If we were going to rank our priorities, they would be in
1) Make mass surveillance impossible. 2) Stop targeted attacks
against crypto nerds. It's not that we don't find #2 laudable, but
optimizing for #1 takes precedence when we're making decisions.
It's totally possible for you to install Signal on an iPod touch
with a VoIP number, for instance, but that takes more effort than
the common case we're designing for."
Post by #359
__
it's a nice breakdown, but the second part is just - wrong. it's
biased by your wish to have a feature that you want. i think it's
just paranoid to look at Message Expiry as a security feature.
it's not.
it's not for a mainstream user. with Device Encyiption for storage
and End to end encryption for transfer we have all we need for an
average user.
op.sec. is another story, where this feature is even more unneeded
because you need a trained user with the knowledge of her adversary.
a lawyer, journalist, activist, Ed Snowden or cheating husband would
have to send as few information by the phone as possible, delete
every message after reading or even not communicate via mobile phone
at all.
i think the Message Expiry as a security feature would only benefit
one kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think this
idea is ridiculous. ;)
Post by Stephen Michel
I agree that we should seek to minimize settings. However, the
important part of my proposal is the method by which the user
interacts with message expiry settings. Whether message expiry is
controlled by message count, age, or both is largely irrelevant.
Here's the logic behind how I reach these conclusions (some
Premise: If the receiver wants to keep a copy, they will do that,
even if it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the
receiver keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-
destruct" is making a false promise. Premise: Signal should not
make false promises. **Conclusion: Signal should not implement any
supposed "self-destruct" feature. Instead, we should think about
Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect
Many users consider the ability to read old messages to be more
If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the
app. Premise: Wide Adoption and friendliness to non-technical
users are key goals of Signal. Conclusion: There must be a way to
disable any expiry feature. Premise: Users who are not security-
minded will not delete old messages on their own.* Premise: Users
will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security
features at the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security
features in favor of convenience.
Conclusion: It is in group A's best interest for group B to use
security features, and for as many users to switch from group C to
group B as possible. Group B is the interesting group, because they
will follow the defaults. Therefore, to support group A, we should
make the security feature be opt-out rather than opt-in. It is in
group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as
possible. The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This
should be a global setting that the user only must interact with
once, at the latest time at which there is still ample chance to
disable it before any messages are erased.
Either that, or accept that the convenience cost of message expiry
is too high, and abstain from implementing altogether.
Sadık Faruk Çetin
2015-11-19 08:23:30 UTC
Permalink
Hi everybody,I have a little question,
How can i run the textsecure-server on apache tomcat or any server?
please explain step by step,thank you
Hi everybody,I have a little question,
How can i run the textsecure-server on apache tomcat or any server?
Post by Ahmadova Matanat
Hello,
It's me again. So lots of people got different opinions about what I
first incorrectly called 'self-destructing messages' then later renamed to
'expiring messages'. With some help from Tim.
The reason for this was not to remove messages with no consent from the
receiver. The idea was more having the option to start a new thread/message
thread for expiring messages. Like today, you got the choice for a regular
Message/SMS and a Signal Message. I would like to see a third option called
for example 'Expiring Message' or something more clear to clarify. The
option to remove already received messages was never the intent.And never
aimed for regular Messages/SMS not even on Signal Messages.
I hope this makes it clearer and more sense. Please help me explain this
if you get me :-)
Best regards,
Isak Holmström
+46(0)705323820
another scenario (of self deleting messages) = another app
Email for work; Signal for crypted; land line telephone for private; self
deleting messages for emotions.
E.g. https://taptalk.me/faq
Photo messages with added text, and after you’ve seen a message it is
deleted. No Snapchat crap.
Sry, my 2¢
C
I think this comment by Moxie (in relation to Signal requiring a phone
1) Make mass surveillance impossible. 2) Stop targeted attacks against
crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1 takes
precedence when we're making decisions. It's totally possible for you to
install Signal on an iPod touch with a VoIP number, for instance, but that
takes more effort than the common case we're designing for."
it's a nice breakdown, but the second part is just - wrong. it's biased
by your wish to have a feature that you want. i think it's just paranoid to
look at Message Expiry as a security feature. it's not.
it's not for a mainstream user. with Device Encyiption for storage and
End to end encryption for transfer we have all we need for an average user.
op.sec. is another story, where this feature is even more unneeded
because you need a trained user with the knowledge of her adversary. a
lawyer, journalist, activist, Ed Snowden or cheating husband would have to
send as few information by the phone as possible, delete every message
after reading or even not communicate via mobile phone at all.
i think the Message Expiry as a security feature would only benefit one
kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think this idea is
ridiculous. ;)
I agree that we should seek to minimize settings. However, the important
part of my proposal is the method by which the user interacts with message
expiry settings. Whether message expiry is controlled by message count,
age, or both is largely irrelevant. Here's the logic behind how I reach
Premise: If the receiver wants to keep a copy, they will do that, even if
it requires manually transcribing it to another app.
Conclusion: There is no way for a sender to enforce that the receiver
keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true self-destruct" is
making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed "self-destruct"
feature. Instead, we should think about Message Expiry.**
There are two things which we value here: Security and Convenience.
Sometimes, though not always, these conflict. This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to protect against
any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages to be more
valuable than the security gained from minimal storage.
Premise: If Signal implemented forced expiry, particularly without user
knowledge and permission, many of those users will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical users are key
goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete old messages
on their own.*
Premise: Users will not change default settings unless prompted and given
incentive to do so.
A: Security-minded individuals who would opt IN to security features at
the cost of convenience.
B: Security-unaware individuals who would not opt out of security
features in favor of convenience.
C: Security-unaware individuals who would opt out of security features in
favor of convenience.
It is in group A's best interest for group B to use security features,
and for as many users to switch from group C to group B as possible.
Group B is the interesting group, because they will follow the defaults.
Therefore, to support group A, we should make the security feature be
opt-out rather than opt-in.
It is in group C's best interest to have the minimum interaction with
settings. Therefore, we should delay any opt-out for as long as possible.
The opt-out must be painless.
Conclusion: Message expiry should be turned on by default. This should be
a global setting that the user only must interact with once, at the latest
time at which there is still ample chance to disable it before any messages
are erased.
Either that, or accept that the convenience cost of message expiry is too
high, and abstain from implementing altogether.
Markux
2015-11-19 08:50:28 UTC
Permalink
Hi Isak.

Your're describing a kind of new message with vanishing capabilities.
That's right, but keep in mind that despite the objective, you're
dealing with the old concept of "good neighbourg policy". Do you
actually believe your contacts are "good neighbourgs"?. Briefly: don't
trust me, 'cause I'm going to make my own client. Your "self-vanishing"
messages wont vanish from my inbox.

You'll finally lay your secrets in a client you wont control. Zero
security is better than untrusted security. Remember Maria Estuardo.

Markus.


------------
Post by Ahmadova Matanat
Hello,
It's me again. So lots of people got different opinions about what I
first incorrectly called 'self-destructing messages' then later renamed
to 'expiring messages'. With some help from Tim.
The reason for this was not to remove messages with no consent from the
receiver. The idea was more having the option to start a new
thread/message thread for expiring messages. Like today, you got the
choice for a regular Message/SMS and a Signal Message. I would like to
see a third option called for example 'Expiring Message' or something
more clear to clarify. The option to remove already received messages
was never the intent.And never aimed for regular Messages/SMS not even
on Signal Messages.
I hope this makes it clearer and more sense. Please help me explain this
if you get me :-)
Best regards,
Isak Holmström
+46(0)705323820
Post by Cl En
another scenario (of self deleting messages) = another app
Email for work; Signal for crypted; land line telephone for private;
self deleting messages for emotions.
E.g. https://taptalk.me/faq
Photo messages with added text, and after you’ve seen a message it is
deleted. No Snapchat crap.
Sry, my 2¢
C
I think this comment by Moxie (in relation to Signal requiring a
1) Make mass surveillance impossible. 2) Stop targeted attacks
against crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1
takes precedence when we're making decisions. It's totally
possible for you to install Signal on an iPod touch with a VoIP
number, for instance, but that takes more effort than the common
case we're designing for."
__
it's a nice breakdown, but the second part is just - wrong.
it's biased by your wish to have a feature that you want. i
think it's just paranoid to look at Message Expiry as a
security feature. it's not.
it's not for a mainstream user. with Device Encyiption for
storage and End to end encryption for transfer we have all we
need for an average user.
op.sec. is another story, where this feature is even more
unneeded because you need a trained user with the knowledge of
her adversary. a lawyer, journalist, activist, Ed Snowden or
cheating husband would have to send as few information by the
phone as possible, delete every message after reading or even
not communicate via mobile phone at all.
i think the Message Expiry as a security feature would only
benefit one kind of user - a paranoic.
- jure
ps - i am very sorry for using some strong words but i think
this idea is ridiculous. ;)
Post by Stephen Michel
I agree that we should seek to minimize settings. However,
the important part of my proposal is the method by which the
user interacts with message expiry settings. Whether message
expiry is controlled by message count, age, or both is
largely irrelevant. Here's the logic behind how I reach these
Premise: If the receiver wants to keep a copy, they will do
that, even if it requires manually transcribing it to another
app.
Conclusion: There is no way for a sender to enforce that the
receiver keeps no copy. Therefore, the recipient owns the message.
Conclusion: Any feature that claims to implement "true
self-destruct" is making a false promise.
Premise: Signal should not make false promises.
**Conclusion: Signal should not implement any supposed
"self-destruct" feature. Instead, we should think about
Message Expiry.**
There are two things which we value here: Security and
Convenience. Sometimes, though not always, these conflict.
This is one such time.
Premise: There is no way to protect against a compromised device.
Conclusion: This feature is about minimal retention to
protect against any compromising that may happen in the future.
Premise: Many users consider the ability to read old messages
to be more valuable than the security gained from minimal
storage.
Premise: If Signal implemented forced expiry, particularly
without user knowledge and permission, many of those users
will uninstall the app.
Premise: Wide Adoption and friendliness to non-technical
users are key goals of Signal.
Conclusion: There must be a way to disable any expiry feature.
Premise: Users who are not security-minded will not delete
old messages on their own.*
Premise: Users will not change default settings unless
prompted and given incentive to do so.
A: Security-minded individuals who would opt IN to security
features at the cost of convenience.
B: Security-unaware individuals who would not opt out of
security features in favor of convenience.
C: Security-unaware individuals who would opt out of security
features in favor of convenience.
It is in group A's best interest for group B to use security
features, and for as many users to switch from group C to
group B as possible.
Group B is the interesting group, because they will follow
the defaults. Therefore, to support group A, we should make
the security feature be opt-out rather than opt-in.
It is in group C's best interest to have the minimum
interaction with settings. Therefore, we should delay any
opt-out for as long as possible. The opt-out must be painless.
Conclusion: Message expiry should be turned on by default.
This should be a global setting that the user only must
interact with once, at the latest time at which there is
still ample chance to disable it before any messages are erased.
Either that, or accept that the convenience cost of message
expiry is too high, and abstain from implementing altogether.
#359
2015-11-18 17:21:19 UTC
Permalink
that's how you start to make bloatware.

but, luckily... the mantra goes: "the answer is never more options"


- jure
Post by Stephen Michel
Hi all,
Lurker here; I want to jump in here to propose a solution that I think
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a
message *would* be deleted, show the user a notification explaining
that by default Signal deletes messages older than XYZ and that
conversation Y is about to be deleted. The user can then choose to
Keep Defaults, Set a Custom Value, or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting
messages without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default
retention period is ("It's been this long since I installed Signal;
I really don't care about messages that old.").
Cheers.
Shankar Kulumani
2015-11-18 17:28:29 UTC
Permalink
Hello lind,

Thank you for your reply.
Post by #359
Therefore there is no method of time/delivery count etc that can ensure
your messages expire.
I misspoke here and actually meant that there is no method that would
ensure that your messages are ephemeral or time limited.

Once sent (to a trusted or otherwise contact) there's no guarantee that the
message will be removed (screen capture, writing the message down,
memorization to name a few)

I'm still not convinced of the utility or even feasibility of "message
expiration."

Once a message is sent and decrypted on the receiving side, all bets are
off.
Post by #359
that's how you start to make bloatware.
but, luckily... the mantra goes: "the answer is never more options"
- jure
Hi all,
Lurker here; I want to jump in here to propose a solution that I think
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a message
*would* be deleted, show the user a notification explaining that by default
Signal deletes messages older than XYZ and that conversation Y is about to
be deleted. The user can then choose to Keep Defaults, Set a Custom Value,
or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting messages
without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default retention
period is ("It's been this long since I installed Signal; I really don't
care about messages that old.").
Cheers.
c***@mailbox.org
2015-11-18 17:49:37 UTC
Permalink
Post by Shankar Kulumani
Therefore there is no method of time/delivery count etc that can ensure
your messages expire.
I misspoke here and actually meant that there is no method that would
ensure that your messages are ephemeral or time limited.
Once sent (to a trusted or otherwise contact) there's no guarantee that
the message will be removed (screen capture, writing the message down,
memorization to name a few)
Yes there is, until your friend turns evil or their phone is corrupted.
I'll focus on the part where their device becomes untrustworthy, because
the solution to untrustworthy friends is not to have them in the first
place.
All sent messages are deleted and thus protected according to the
senders settings UNTIL the receiving device is breached. In most of the
real world scenarios like stealing, the owner will notice and notify
their contacts about the untrustworthiness of their device. This means
the timeframe in which sent messages can be abused is limited to the
time until deletion plus the time the attacker has access to the phone
while the owners contacts still trust the device.

The case where the phone is corrupted in a way unnoticed by the user
represents a targeted attack and can not possibly be part of the trust
model of an app.
Post by Shankar Kulumani
Once a message is sent and decrypted on the receiving side, all bets are
off.
As I stated before, this is irrelevant, because the difference this
setting makes is that you only have to trust your friends to not reveal
your messages to other parties while you currently also have to trust
them to properly encrypt their phone, choose a good passphrase (which is
currently only possible on rooted android devices, because unrooted ones
use the same passphrase/pin for unlocking and encrypting) and not
leaving their phone unlocked for a second.

This is not about an absolute security feature with guarantees like
"nobody will ever read any of your messages". It is about guaranteeing
that old messages can not be read even if the people you wrote them to
don't protect them in the same way you would and get breached.
c***@mailbox.org
2015-11-18 17:56:10 UTC
Permalink
That idea is actually quiet good as a new default for the automatic
deletion of old messages.
But it doesn't cover the case where the proposed setting excels at:
Protecting old messages I SENT to somebody even if this person is worse
than me at protecting them and his devices becomes untrustworthy. If my
friends don't care about security, they will probably turn your proposed
setting off of choose a higher time until deletion than I would.

What this comes down to is "who owns the messages I send to someone".
If your answer is "me", the proposal to allow the sender to
automatically remove old messages is great.
If your answer is "the receiver", deleting those messages will be a
breach of trust.
Post by Stephen Michel
Hi all,
Lurker here; I want to jump in here to propose a solution that I think
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a message
*would* be deleted, show the user a notification explaining that by
default Signal deletes messages older than XYZ and that conversation Y
is about to be deleted. The user can then choose to Keep Defaults, Set a
Custom Value, or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting messages
without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default retention
period is ("It's been this long since I installed Signal; I really don't
care about messages that old.").
Cheers.
359
2015-11-18 18:29:31 UTC
Permalink
why would anyone want to give control to his inbox to others? this is ridiculous! when you say/send something it's gone. don't say/send it or live with it!

--
jure
Post by c***@mailbox.org
That idea is actually quiet good as a new default for the automatic
deletion of old messages.
Protecting old messages I SENT to somebody even if this person is worse
than me at protecting them and his devices becomes untrustworthy. If my
friends don't care about security, they will probably turn your
proposed
setting off of choose a higher time until deletion than I would.
What this comes down to is "who owns the messages I send to someone".
If your answer is "me", the proposal to allow the sender to
automatically remove old messages is great.
If your answer is "the receiver", deleting those messages will be a
breach of trust.
Post by Stephen Michel
Hi all,
Lurker here; I want to jump in here to propose a solution that I
think
Post by Stephen Michel
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with
sensible
Post by Stephen Michel
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a
message
Post by Stephen Michel
*would* be deleted, show the user a notification explaining that by
default Signal deletes messages older than XYZ and that conversation
Y
Post by Stephen Michel
is about to be deleted. The user can then choose to Keep Defaults,
Set a
Post by Stephen Michel
Custom Value, or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting
messages
Post by Stephen Michel
without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default
retention
Post by Stephen Michel
period is ("It's been this long since I installed Signal; I really
don't
Post by Stephen Michel
care about messages that old.").
Cheers.
TWfromSWD
2015-11-18 19:59:52 UTC
Permalink
I totally agree. I don't want the conversations on my phone to self
delete per default. I want to keep them to read them later. And I
believe most of the people would simply turn this "feature" off because
they think so too.

By the way: If someone cannot be trusted to keep private messages on his
own phone safe, even in an encrypted database within a secure messenger,
the why send this person such messages?
Post by 359
why would anyone want to give control to his inbox to others? this is ridiculous! when you say/send something it's gone. don't say/send it or live with it!
--
jure
Post by c***@mailbox.org
That idea is actually quiet good as a new default for the automatic
deletion of old messages.
Protecting old messages I SENT to somebody even if this person is worse
than me at protecting them and his devices becomes untrustworthy. If my
friends don't care about security, they will probably turn your proposed
setting off of choose a higher time until deletion than I would.
What this comes down to is "who owns the messages I send to someone".
If your answer is "me", the proposal to allow the sender to
automatically remove old messages is great.
If your answer is "the receiver", deleting those messages will be a
breach of trust.
Post by Stephen Michel
Hi all,
Lurker here; I want to jump in here to propose a solution that I
think
Post by Stephen Michel
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with
sensible
Post by Stephen Michel
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a
message
Post by Stephen Michel
*would* be deleted, show the user a notification explaining that by
default Signal deletes messages older than XYZ and that conversation
Y
Post by Stephen Michel
is about to be deleted. The user can then choose to Keep Defaults,
Set a
Post by Stephen Michel
Custom Value, or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting
messages
Post by Stephen Michel
without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default
retention
Post by Stephen Michel
period is ("It's been this long since I installed Signal; I really
don't
Post by Stephen Michel
care about messages that old.").
Cheers.
Bryan Phelps
2015-11-18 17:45:45 UTC
Permalink
Yep, I agree with this. After this chain and back and forth I can see the concerns of a false security feature like expiring messages. However, enabling a default delete after X messages or Y months is a good start. I also think this would improve user experience. If messages are never deleted then a user may start running out of space on their phone without knowing why (even though they have 20,000 messages from 2 years ago in signal).

I like Lurker's solution because it'll address the majority of users and the easy option will be more secure than the current setup.
Post by Stephen Michel
Hi all,
Lurker here; I want to jump in here to propose a solution that I think
should be amicable to all.
1. Add one additional setting to Signal. "Message Trimming -> Message
Expiry".
2. By default, "Delete Old Messages" should be turned ON with sensible
defaults (500 messages / 2 months? I have no experience here).
3. However, messages are not deleted by default. Instead, when a
message *would* be deleted, show the user a notification explaining
that by default Signal deletes messages older than XYZ and that
conversation Y is about to be deleted. The user can then choose to Keep
Defaults, Set a Custom Value, or Turn Trimming Off.
1. Users do not feel like the app has betrayed them by deleting
messages without their permission.
2. Signal still works with no initial config.
3. Users are informed that the "more secure" default setting is no
retention.
4. Users have some frame of reference for how long the default
retention period is ("It's been this long since I installed Signal; I
really don't care about messages that old.").
Cheers.
--Bryan
c***@mailbox.org
2015-11-18 17:35:14 UTC
Permalink
Post by Shankar Kulumani
How about setting the trim messages default to something smaller?
This way only 500-1000 messages are kept by default?
This would not involve any new options/preferences but simply a change
to the current default?
This doesn't work for three reasons:
1. Because it's not turned on by default. 99% of all users never change
the defaults.

2. It's the wrong approach, because you can not control this setting on
your contacts phones. The proposed solution is meant to protect the
messages you sent to your contacts, even tough they are not as security
aware as you are. If you ask them to constantly delete messages
manually, use good passphrases etc they will react with rejection or
switching to a less "complicated" app.

3. It's not time based, so the oldest of 100 messages with someone you
barely talk to can be many many years old. Or maybe you stopped talking
to them because they abused your trust at some point. A time based
setting helps in those cases and also makes it easier for the user to
understand. That's because humans are a lot better at keeping track of
"how much time has passed since X" than at keeping track of "how many
individual messages have I sent and received since X".
c***@mailbox.org
2015-11-18 16:56:41 UTC
Permalink
Post by TWfromSWD
If you have friends that don't care about your privacy, would such a
feature really help? They could take a screenshot of your message or
just create a backup. I would try to convince my friends rather than
try to force them into removing messages by using a possible insecure
feature.
Yes it would help because this feature is not supposed to be used as a
security feature you apply to certain messages you want special
protection for.
If that were the case, you can ask your friend to delete it and they'll
probably do so.

This feature is useful where security is a priority for one partner in
the conversation (you) but not the other (your friend).
This feature can only be useful if applied to all messages, maybe
allowing exepting contacts who also prioritize security.
This way old conversations lose their content just as in face to face
conversations, where people forget the unimportant details first, then
the exact conversation they talked about the topic and at some point
they will forget they ever talked about it.

If you ask your friends to remove all of your messages after XX new
messages or a certain time, they will tell you to go to hell.
Post by TWfromSWD
By the way: I wouldn't feel very safe if I knew that my messenger
could delete messages by itself. That kinda sounds like censoring for
me.
The messenger can do whatever it wants to your messages, that's not the
point. This can be a kind of historical self-censorship at best, because
the person sending you the auto-deleting messages chose to do so. And
people self-censor in basically every conversation they have.
It may feel weird to you, but those messages belong to the sender, not
the receiver.
Post by TWfromSWD
Also it would be hard to reconstruct conversations that happened
longer ago when one person decided to delete their part of it.
That's the whole reason to implement this feature in the first place.
Removing possibly incriminating content before they can be disconvered
by your adversary.
Post by TWfromSWD
Also I sense some potential for abuse.
Can you clarify?
Post by TWfromSWD
And as a matter of fact: You wouldn't gain security. You could
suggest the other application to delete the message but would have no
guarantee that this would really happen. And if someone just doesn't
want such a feature, it would be fairly easy to remove it and use a
Signal version without it. Where is the security in that?
Yes you would gain security. If you talk to someone who undermines your
trust by using a fork without this feature, your trust model is broken,
because your contact deserves no trust. This has nothing to do with
Signals trust model.
Isak Holmström
2015-11-18 14:07:49 UTC
Permalink
But sure I read what Sam posted. And its true its not a guarantee that
the message sent is secure.
--
Best regards,
Isak
Post by Isak Holmström
I want this feature as Tim explain it. Sometimes I want a message to be
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I like
Tims name for it auto-expire period.
--
Best regards,
Isak
Post by Tim Kuijsten
Post by Steffen Märcker
Additionally, I'd like to ask why some people want this? Do they bare in
mind that spoken words are like shot arrows: They never come back.
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure way to
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
I agree it does not give any guarantee from a security point of view.
Personally I don't like the idea that my conversations with close
friends and family are stored on their, often insecure, devices
indefinitely. It's a hurdle to ask the other party to delete the message
history you share with them (and I do trust they do that when they
confirm, hence the security argument is not what it's about here). I
like to set an auto-expire period on a conversation so I don't have to
bother my friends with asking them to delete past conversations since
they don't really care.
-Tim
Bryan Phelps
2015-11-18 14:18:31 UTC
Permalink
As far as I'm concerned I guess I wouldn't mind a feature like this. Knowing that there isn't a perfect way to do it securely. Obviously it would have to be for signal messages only. Maybe include an extra field of expiration on the message that can be left blank or null. It would be blank or null by default. Then have an option for the sender to set an expiration. The receiver's phone would be responsible for deleting the message after it expires.
Post by Isak Holmström
But sure I read what Sam posted. And its true its not a guarantee that
the message sent is secure.
--
Best regards,
Isak
Post by Isak Holmström
I want this feature as Tim explain it. Sometimes I want a message to
be
Post by Isak Holmström
read by a friend and later to expire in case that phone happens to be
left unlocked anywhere. Maybe self destruct is wrong term here, I
like
Post by Isak Holmström
Tims name for it auto-expire period.
--
Best regards,
Isak
Post by Tim Kuijsten
Post by Steffen Märcker
Additionally, I'd like to ask why some people want this? Do they
bare in
Post by Isak Holmström
Post by Tim Kuijsten
Post by Steffen Märcker
mind that spoken words are like shot arrows: They never come
back.
Post by Isak Holmström
Post by Tim Kuijsten
Post by Steffen Märcker
Post by Sam Holton
No, there are no plans as its an illusion and there is no secure
way to
Post by Isak Holmström
Post by Tim Kuijsten
Post by Steffen Märcker
Post by Sam Holton
enforce it. See this link for more details.
http://support.whispersystems.org/hc/en-us/articles/213134237-Why-doesn-t-Signal-have-self-destructing-messages-or-remote-deletion-functionality-
Post by Isak Holmström
Post by Tim Kuijsten
I agree it does not give any guarantee from a security point of
view.
Post by Isak Holmström
Post by Tim Kuijsten
Personally I don't like the idea that my conversations with close
friends and family are stored on their, often insecure, devices
indefinitely. It's a hurdle to ask the other party to delete the
message
Post by Isak Holmström
Post by Tim Kuijsten
history you share with them (and I do trust they do that when they
confirm, hence the security argument is not what it's about here).
I
Post by Isak Holmström
Post by Tim Kuijsten
like to set an auto-expire period on a conversation so I don't have
to
Post by Isak Holmström
Post by Tim Kuijsten
bother my friends with asking them to delete past conversations
since
Post by Isak Holmström
Post by Tim Kuijsten
they don't really care.
-Tim
--Bryan
Noir
2015-11-18 14:28:44 UTC
Permalink
I don't think that there's an easy way to communicate that messages with
expiration date maybe or maybe not expire on the other side except by
displaying a big fat warning. And then most users will not use this
feature after reading this warning since I don't think that they have
this
"it-would-be-nice-if-the-message-expires-but-if-not-its-also-ok"-use-case.
Post by Bryan Phelps
As far as I'm concerned I guess I wouldn't mind a feature like this.
Knowing that there isn't a perfect way to do it securely. Obviously it
would have to be for signal messages only. Maybe include an extra
field of expiration on the message that can be left blank or null. It
would be blank or null by default. Then have an option for the sender
to set an expiration. The receiver's phone would be responsible for
deleting the message after it expires.
But sure I read what Sam posted. And its true its not a guarantee that
the message sent is secure.
--Bryan
Tim Kuijsten
2015-11-18 14:52:25 UTC
Permalink
Post by Noir
I don't think that there's an easy way to communicate that messages with
expiration date maybe or maybe not expire on the other side except by
displaying a big fat warning. And then most users will not use this
feature after reading this warning since I don't think that they have
this
"it-would-be-nice-if-the-message-expires-but-if-not-its-also-ok"-use-case.
This might have it's use in situations where you do trust the other
person (friends, relatives), but not their technical skills or will to
maintain their phone security. A default expiry policy will limit the
damage that is done if a phone of your contact you trust is compromised
somewhere in the future.
James Budarz
2015-11-18 15:10:11 UTC
Permalink
The danger of implementing an imperfect security feature is that some users
may mistakenly rely on it.
It's better to leave a feature out than to put it in, potentially
undermining the trust OWS has earned.
Post by Noir
Post by Noir
I don't think that there's an easy way to communicate that messages with
expiration date maybe or maybe not expire on the other side except by
displaying a big fat warning. And then most users will not use this
feature after reading this warning since I don't think that they have
this
"it-would-be-nice-if-the-message-expires-but-if-not-its-also-ok"-use-case.
This might have it's use in situations where you do trust the other
person (friends, relatives), but not their technical skills or will to
maintain their phone security. A default expiry policy will limit the
damage that is done if a phone of your contact you trust is compromised
somewhere in the future.
Benjamin Schäfer
2015-11-18 15:12:14 UTC
Permalink
I also think an auto-expire function would be an interesting feature. I
imagine it will be most commonly used by senders that care a lot about
privacy when contacting somebody who might not care as much.
As 359 pointed out just deleting messages without consent of the
recipient is not a nice way to handle this.
I could imagine a header-field like Bryan proposed that is set by the
sender. (I don't know the details of the implementation since I'm just
an interested user.) A global setting could be implemented in which the
user could decide whether expiration headers should be respected.
When a recipient first receives a message with this header he'd be
prompted to choose a value for that setting.

The downside of this approach would be that more complexity would be
dropped on the user. The protocol would need to be expanded? And the
benefit is not very substantial in my opinion, since the sender doesn't
know if the recipient accepts his header. Thus it might create an
illusion of improved security (like James said) just like self destruct
messages.
Post by James Budarz
The danger of implementing an imperfect security feature is that some
users may mistakenly rely on it.
It's better to leave a feature out than to put it in, potentially
undermining the trust OWS has earned.
Post by Noir
I don't think that there's an easy way to communicate that
messages with
Post by Noir
expiration date maybe or maybe not expire on the other side except by
displaying a big fat warning. And then most users will not use this
feature after reading this warning since I don't think that they have
this
"it-would-be-nice-if-the-message-expires-but-if-not-its-also-ok"-use-case.
This might have it's use in situations where you do trust the other
person (friends, relatives), but not their technical skills or will to
maintain their phone security. A default expiry policy will limit the
damage that is done if a phone of your contact you trust is compromised
somewhere in the future.
Olaf Leidinger
2015-11-18 15:27:34 UTC
Permalink
Hey,
Post by Benjamin Schäfer
I also think an auto-expire function would be an interesting feature. I
imagine it will be most commonly used by senders that care a lot about
privacy when contacting somebody who might not care as much.
But when you care that much about privacy, why would you rely on a
feature that can't be implemented reliably? E.g. you could use an
encrypted Signal phone call instead.
Post by Benjamin Schäfer
A global setting could be implemented in which the
user could decide whether expiration headers should be respected.
Two scenarios:

1. The phone gets stolen before the messages are expired and the thieve
disables auto-deletion.

2. The user at the other end just disables this setting.

IMHO it's better to rely on the messages being encrypted and the device
being locked in case the phone is stolen.
Post by Benjamin Schäfer
[...] Thus it might create an illusion of improved security
(like James said) just like self destruct messages.
ACK.

Best,

Olaf
Continue reading on narkive:
Loading...