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. _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
