Why 2.1 is delayed for so long

[Ximin Luo]

On 23/09/14 15:12, Robert J. Hansen wrote:
>> However, if you keep making arguments like this, the overall effect
>> is that a typical user has to tweak a lot of things to get a maximal
>> level of security
> 
> I've got two problems with this:
> 
> First, "security" is a vague and pretty much meaningless word.  It must
> be contextualized to have any usefulness.  Security against which
> threats?  Is it likely is the normal user will encounter these threats,
> or are these threats unlikely?
> 
> Second, "maximal level of security" is ... it leads to some extreme and
> not very helpful 'solutions'.  For instance, if you want a maximal level
> of security against the risk of auto accident, your only choice is to
> never go within several hundred meters of an automobile.  That's why we
> talk about mitigating risks rather than providing maximal security.  You
> can't get a maximal level of security against auto accidents and still
> be able to drive to work, but you *can* wear a seat belt, never drive
> impaired, and have your car regularly checked for safety issues.
> 
> Risks are to be mitigated to a reasonable degree -- not to a maximal degree.
> 

We all know this, yes my words could have been more precise. But you're generalising to a degree outside of the original context. 

As security software developers, we should aim to automate as much as possible that increases a user's security. This means it's cheaper *on the user side* to get the same level of security, than if there was no automation. This is based on the premise that everyone is OK with getting extra security "for free", which I think is a reasonable premise. (Of course everyone has different security levels.)

Where there is a trade-off in security, then certain automation shouldn't be done. I don't think that's the case here with 2 subkeys, though.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140923/95936ed8/attachment.sig>