Giorgio Maone:
>> The Goals section doesn't address interrupted / paused / retried
>> downloads. Is dealing with that a goal or a non-goal?
Thanks for joining this thread Giorgio!
> Considering the size of the ISO and the download speeds many Tor users
> may experience I'd consider it a goal (and a feasible one, too).
I tried to interrupt a download of the ISO with Tor Browser and, indeed,
it's not possible to continue it. So I might reconsider what I just said
in my answer to intrigeri :P
Still, I like the idea of having the verification experience for people
downloading through HTTP and through BitTorrent being the same. I also
like the idea of making an explicit and intentional move to verify the
ISO (instead of making it happen automatically).
I understand from your proposal Giorgio that the extension could be able
to resume an interrupted or paused download, right? Then I'll take good
note of this and will try to take a decision during our next UX sprint
(when we should be able to finalize all the UX side of things).
For example, maybe the download process can be done only if people
choose HTTP download, and then the verification process could still be
done in the same way for everybody.
But I'm more worried about the security discussion for the moment.
>>> Allow users who are downloading using BitTorrent to do the same
>>> level of verification as people downloading through their browser.
>>
>> IMO that could be demoted to a "bonus" goal, if time resources become
>> scarce along the way. But perhaps we can postpone this discussion, and
>> hopefully it won't be needed :)
>
> Providing a menu item or an option button somewhere to browse the
> filesystem and manually choose the file to be verified is simple enough.
> Am I missing some other requirement for this feature which would add
> complexity?
Not that I can think of. But you are answering here one of the questions
I had for you, since you are saying that the extension would be allowed
to browser or any file on the file system (for example from a BitTorrent
download) and verify that as well. That's good news.
Another question I had is whether the extension would be allowed to
rename it? In case we decide to use some trick in the filename (that's
not decided yet, see #7494).
>>> When the user clicks on the HTTP download button from the download
>>> page, we propose to install the extension.
>>
>> I guess this means that JavaScript will be needed on our download
>> page, so that we can detect if the extension is already installed
>
> No, it doesn't.
> If the extension is installed it can modify the download page on the fly
> by hiding the bits about installing the extension itself, or redirect to
> a different page, with no need for site JavaScript being enabled or any
> detection activity being operated by the page at all.
> The page should just statically default to "Please install the
> extension", but the extension would change this default appearance if
> already installed.
Yes, that's what I thought. Can you also confirm whether the extension
could change *any* page on the website for example? Even if it has not
been installed from this page (for example if it's shipped with the
browser or installed through APT).
And also, would all this be possible even in Tor Browser with JavaScript
completely disabled for example?
>>> we could [...] Not rely on the website to perform the ISO
>>> verification (use the add-ons menu for example). But the UX will
>>> suffer from this...
>
> I'm not sure it would. Could you please elaborate? If necessary, we
> could even statically package our web-pages inside the add-on and
> present them to the user as they were from the web-site (or as a native
> interface, it's up to you to decide).
> My point is, we could hard-code all the UI inside the add-on and move
> the a big chunk of the website security burden to addons.mozilla.org,
> which is probably in a fairly better position to defend itself
> effectively (see below).
Let's keep in mind that there are two discussions in parallel here. One
about UX and one about security. And maybe I have to make it clear to
you that we will integrate the extension in a bigger project, that we
call "web assistant" and that will be targeted at first time users and
that will lead them through the whole process from landing on our
website until having a Tails ready to boot.
So, from a security point of view, I think that pushing more content on
AMO doesn't solve the root of the problem: if someone is in control of
tails.boum.org (through MitM or exploit) then they can fool all those
newcomers with whatever rogue verification process even earlier in the
website. Even if I agree that AMO are in a better position to defend
themselves, visitors of tails.boum.org might be tricked not to install
the extension ever.
The only way we could mitigate such an attack (MitM or exploit on
tails.boum.org) is in the case of people following an external
documentation (for example from a book) that doesn't rely on
tails.boum.org at all. Then indeed it make sense, from a security point
of view, to do the verification in a native interface.
>From a UX point-of-view, I said that the "UX will suffer from this"
because at first sight having the verification process integrated on the
website seems to be less complicated than having to interact with menus
and a native interface. But on the other hand, I also like the idea of
having the user perform an explicit move to do the verification and as
you said a native interface might look more trustworthy.
So now, I'm more into the native interface. But I need to check with my
other fellow UX people.
> Consider also that in a near future Firefox add-ons will all be signed
> by Mozilla after editorial screening (which would be quite quick in case
> of updates) and users won't be able to install unsigned extensions anymore:
> https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
I read about that as well, it's interesting.
>> I understand that your current threat model doesn't include MitM with
>> valid certificates provided by a rogue CA, which anyway makes the CA
>> pinning kind of a bonus feature in this context. So I'll stick to the
>> technical aspect to start with:
>>
>> Can an extension really do X.509 CA pinning for TLS?
>> (Did Giorgio comment on this one yet?)
>
> It's not trivial, but feasible.
> On the other hand, Mozilla's efforts to protect addons.mozilla.org
> (whose is pinned by default in the browser, see the HPKP blog post
> linked above) may be regarded as an argument in favor of moving as much
> as possible of the (little) user interaction needed for the
> download+verification process into the add-on, rather than keeping it on
> the web page.
> Last but not least, the "native" look and feel which the extension could
> provide might increase the perceived trustworthiness of the download
> process, if compared with browsing a (possibly MITMed) website.
Yes, I like this idea too. And that's definitely worth begin considered.
