intrigeri:
> Hi,
>
> sajolida wrote (03 Jul 2015 08:38:25 GMT) :
>> intrigeri:
>>> sajolida wrote (04 Mar 2015 17:43:01 GMT) :
>> You're answering here a quite old message of mine
>
> Yep, sorry about that. Your reply makes it clear that I should have
> re-read the blueprint and relevant threads more carefully before
> bothering to reply to this old email.
That's ok :)
You're bringing in important points anyway.
>>> Thanks. (Food for thought: this seems to assume that an ISO
>>> voluntarily corrupted by an attacker will generally not be smaller
>>> than the genuine one. Not sure how good an assumption this is.)
>
>> Not relevant anymore for the same reason.
>
> The goals section still reads "In case of a bad ISO image, help the
> user diagnose whether the download has been interrupted or the ISO has
> been corrupted", so I don't understand why my side comment isn't
> relevant anymore: how can we make the difference between an
> interrupted download, and a malicious ISO that's smaller than the
> genuine one? In other words:
>
> * if the ISO is too big, then by definition it's been corrupted
> (potentially maliciously);
> * if the ISO has the right size but not the correct checksum, then by
> definition it's been corrupted (potentially maliciously);
> * if the ISO is too small, then it's highly probable that the
> download was simply interrupted, but we can't guarantee that to the
> user. I've no idea what to do with this, and I totally trust you to
> take it into account when helping the user make a sensible decision
> based on this fact, in case the current wireframes don't (sorry, no
> time to check the details right now).
I updated the blueprint with 0d3780e. If you look at the latest
wireframe, the idea now is to force people to download the ISO image
through the extension (or BitT, so the extension should enforce
finishing the download before starting the verification. See
https://labs.riseup.net/code/attachments/download/764/extension-20150505.fodg.
But the important point that you are raising here is that we didn't
clarify what happens from a user point of view if the download gets
interrupted (lost connection). I created #9717 to tackle this.
>>>> Are you saying that any other website that's been loaded in the
>>>> current session could alter the result of this verification?
>>>> That sounds very bad...
>>>
>>> That is what I would assume until some experts in this field tell me
>>> that browsers are safe about this. I guess this has been done
>>> elsewhere in this thread (still not finished reading it), otherwise
>>> you would have switched strategies since then.
>
>> Yes, that's
>> https://mailman.boum.org/pipermail/tails-dev/2015-April/008648.html I think.
>
> In that thread, the only answers that are potentially relevant to the
> question at hand are:
>
> * a message by Giorgio, who addresses mostly off-topic concerns
> someone else posted, but doesn't answer your questions;
> * a message by Kathleen, who wrote "absent a bug in Firefox or Tor
> Browser, other web pages should not be able to interfere"... after
> stating that "Mark and I do not have a lot of expertise in threat
> modeling"
>
> JFTR, assuming that you're basing your assessment on that second
> reply, I personally find it half-convincing, but giving the timing of
> my feedback here, I will cross fingers instead of insisting (I already
> feel half pissed off and half guilty wrt. how pushy I've been on this
> topic, so it's time for me to stop).
Sorry for being unclear, but my link was mainly to tell you that this
discussion was happening in another thread (though it was not really
finished there).
--
sajolida
