[cap-talk] Firefox breaks the principle of identifiability

[Ian G]

marcs wrote:

>>A much better approach is to work with small
>>changes in what we have available.  For example,
>>the simple change to Firefox 1.0 that makes the
>>URL bar yellow on SSL will (IMHO) do more to
>>defend against phishing than the more complete
>>approaches developed here - simply because it
>>is there, and in the hands of users.
>>    
>>
>
>A simple change that is easily adapted to by the aggressor might be useful
>enough to justify in terms of short-term improvement.
>

You seem to be implying that an aggressor
can adapt to this change?  And therefore ...
what?  it wasn't worth doing?

(Just to save you the trouble, it transpires that
I already broke the padlock before it was put
in place:  http://iang.org/ssl/  But that doesn't
reduce its value, which is something other
than the absolute effect of those changes.)

>Usually not, but one
>can do a cost/value comparison. Whatever the cost/value comparison delivers
>in the short term, however, is overwhelmed by which of three other
>categories the change falls into:
>
>-- It is a step towards a real, complete solution. We are trying to propose
>a system, based partly on pet names and partly on other machinery, that
>could be a complete solution. If we identify such a solution, and identify a
>part of that solution that is quickly deployable that has immediate benefit,
>that is a huge victory.
>
>-- It is a step away from a real, complete solution. If you come up with a
>plan that has short term benefit, but makes it even harder to get to any of
>the known real solutions, this is a disaster. Stop immediately :-)
>
>-- It is a step sideways compared to a real, complete solution. Do the cost
>benefit analysis to see if it's worth doing, but don't get confused and
>think you've done something important.
>  
>

All of your categories based framework assumes
that there is a known complete real solution,
there is a clear path to get to it, and someone
has the capability to walk that path.

I'd say all three are extremely ropey assumptions.

(What you seem to be saying is that in any cost/
benefit analysis you need to include a benefit / cost
related to some future expected target that you'd
like to achieve.  Seen in this way, you also have to
discount your target according to the perceived
value and the probability of ever getting the return.)

>"Progress is not so much a matter of improving what you have, as of taking a
>step towards what must be."
>  
>

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/