On Tue, Feb 5, 2013 at 4:13 PM, Brian Conley <[email protected]>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 <[email protected]> wrote: > >> >> >> >> NK >> >> >> On Tue, Feb 5, 2013 at 3:06 PM, Brian Conley <[email protected]>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 <[email protected]>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 >
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
