Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Wickr app aims to safeguard online privacy

Nadim Kobeissi nadim at nadim.cc
Tue Feb 5 13:19:25 PST 2013


On Tue, Feb 5, 2013 at 4:13 PM, Brian Conley <brianc at smallworldnews.tv>wrote:

> Just to clarify, are you suggesting such a feature would put the users at
> *greater* threat?
>

No: As mentioned in my previous email, I'm trying to point out that when
features like this are introduced, it's definitely true that they may have
positive benefits: But they also may shift the threat into a different
situation, and may even interfere with the process of classifying and
prioritizing threats.


>
> in my experience simply using CryptoTool™ puts you at risk of
> interrogation, torture, prison in certain countries. It seems that such a
> feature would mitigate. On the other hand, it seems like splitting hairs,
> until research is done, to suggest such a feature would be better than
> simply keeping all messages encrypted at rest.


Agreed, and research is the best way I can think of to get answers on this.
Until the research is done, by all means feel free to implement
self-destruct features. But don't let such features distract from threat
priorities and from the notion that they themselves may shift the threat
landscape.


>
>
Once we are talking about rubber hose decryption methods, I think we've
> kind of already lost, no?
>

See, that's kind of my point when I talk about how those features distract
from threat priorities. Shouldn't we be worrying about more low-level
things, such as code delivery, side-channel attacks and so on? (These are
just random examples.)


>
> B
>
>
> On Tue, Feb 5, 2013 at 12:46 PM, Nadim Kobeissi <nadim at nadim.cc> wrote:
>
>>
>>
>>
>> NK
>>
>>
>> On Tue, Feb 5, 2013 at 3:06 PM, Brian Conley <brianc at smallworldnews.tv>wrote:
>>
>>> In this case, self-destruct would potentially save Joe and Susan from
>>> the "fool" Billy's lazy security culture.
>>>
>>
>> In this kind of scenario, adding a self-destruct feature would definitely
>> be useful in preventing communications from leaking through certain vectors
>> after the messages have served their purpose.
>>
>> However, they also shift the threat. If Authoritarianstan police know
>> that CryptoToolX deletes messages after a while, they are likely to feel
>> more justified in further interrogating the suspect, knowing that if the
>> messages aren't there now, it's likely that they were there earlier.
>>
>> It's hard to discuss those features not because they aren't cool and
>> useful (they are!) but because they make it difficult to maintain a sense
>> of priority. Measuring how a feature will help, how it'll change the threat
>> and whether it will eclipse attention from greater threats and concerns is
>> kind of trick AFAICT.
>>
>>
>>>
>>> Certainly this is not a be all and and all, but does seem like a
>>> potentially valuable feature based on my own broad observation of "fools"
>>> amongst many activist and journalist groups.
>>>
>>> Brian
>>>
>>>
>>> On Tue, Feb 5, 2013 at 11:11 AM, Jacob Appelbaum <jacob at appelbaum.net>wrote:
>>>
>>>> Brian Conley:
>>>> > Apparently Silent Circle is also proposing such a feature now.
>>>>
>>>> Such a feature makes sense when we consider the pervasive world of
>>>> targeted attacks. If you compromise say, my email client today, you may
>>>> get years of email. If you compromise my Pond client today, you get a
>>>> weeks worth of messages. Such a feature is something I think is useful
>>>> and I agreed to it when I started using Pond. It is a kind of forward
>>>> secrecy that understands that attackers sometimes win but you'd like
>>>> them to not win everything for all time.
>>>>
>>>> Seems rather reasonable, really. Hardly malware but hardly perfect.
>>>>
>>>> All the best,
>>>> Jake
>>>>
>>>> --
>>>> Unsubscribe, change to digest, or change password at:
>>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> Brian Conley
>>>
>>> Director, Small World News
>>>
>>> http://smallworldnews.tv
>>>
>>> m: 646.285.2046
>>>
>>> Skype: brianjoelconley
>>>
>>>
>>>
>>> --
>>> Unsubscribe, change to digest, or change password at:
>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>>
>>
>>
>> --
>> Unsubscribe, change to digest, or change password at:
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>
>
>
>
> --
>
>
>
> Brian Conley
>
> Director, Small World News
>
> http://smallworldnews.tv
>
> m: 646.285.2046
>
> Skype: brianjoelconley
>
>
>
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130205/8bd007db/attachment.html>


More information about the liberationtech mailing list