[liberationtech] Wickr app aims to safeguard online privacy

[Rich Kulawiec]

I'm finding this discussion highly illuminating -- as I find many here.
So before I make my comments, I want to says thanks to everyone for the
education.  You've given me *a lot* to think about while running.

My concerns re these sorts of "self-destructing" documents revolve (first)
around the general notion that the application software which manages them
has to have a timer -- so that it knows when it's time to delete them/expire
their key/whatever.

What if the timer never ticks?  Or doesn't tick as expected?

I'll freely admit that I'm not at all a phone software guy, but on
the systems I'm most familiar with (Unix, Linux) it's not that hard to
rewrite the system call time(2), relink the shared C library, and then
cause dynamically linked applications to use this new one.  It's somewhat
harder to perform the equivalent manipulation with statically linked
binaries (presuming one doesn't have the source code) but it can be done.
And of course just changing the behavior in the OS would suffice.
("Who's asking?"  "Oh...then *this* is the answer.")

I have to guess that these applications may rely on a similar underlying
system service (which may in turn rely on NTP or some other off-system
time source) to find out what time it is.  Am I way wrong here?

My (second) set of concerns is that displaying a message to a
user requires using utilizing underlying system services as well.
For example, when I read an email message with mutt, of course mutt
itself is in play, as are some underlying screen manipulation libraries
("curses" and "termlib", if memory serves) as is the OS tty driver.
Any of those could be modified to capture, store, copy, etc. the
stream of bytes as it goes by.  (For that matter, script(1) will
do a first-order job of doing that.)  None of these are particularly
elegant, and it would take some post-processing to reassemble the
pieces into a complete and accurate message, but "Natasha! Tonight we
get moose and squirrel!" could certainly be plucked out of that.

I suppose what I'm saying is that I don't think the set of {all
recipients' phones} can be or should be trusted to actually delete
messages when senders intend them to be because there's no way to
know -- on the sender's side -- that this has actually happened AND
that no copies of the plaintext were made anywhere along the way.

I think that what these projects are trying to do is impose DRM on
content...and so far, every attempt to do DRM has failed.  (That's a good
thing.)  Some of them have failed badly.  (That's a very good thing.)
As Schneier has said, "trying to make bits not copyable is like trying
to make water not wet".  So I'm very skeptical that this can be made to
work in the presence of attacks on the recipient side.

---rsk