Re: [Tails-dev] Testing the ISO Verification Extension

Delete this message

Reply to this message
Autor: sajolida
Data:  
Dla: The Tails public development discussion list
Temat: Re: [Tails-dev] Testing the ISO Verification Extension
I'll merge answering to both your emails.

Giorgio Maone:> On 12/11/2015 17:38, sajolida wrote:
> 1. From now on I'll strictly refer to the HTML at
> https://tails.boum.org/install/download/ and send tchou patches if and
> only if I actually need the markup to be modified


Great!

> 2. Latest iterations of the extension from git or from
> https://maone.net/dev/tails/dave.xpi automatically detect if they're
> used on an outdated page (by comaring with #extension-version) and if
> they're more up-to-date automatically replace the dave.css stylesheet
> with the one from https://maone.net, so while we're still in
> development. I don't need to actually push it on the site


Ok. I just updated dave.css, dave.js and #extension-version on the site.

> 3. If you want to use the .chrome-unsupported class on
> #download-and-verify, rather than on the <html> element, you just need
> to be sure dave.js is loaded after the element exists (e.g. by placing
> its <script> element as the bottomest child of <body>)


I'll let tchou deal with this.

> 4. The page acts as a view on the download manager: therefore it can
> "see" any download, no matter if added from a private window or not,
> just like the browser itself. However if the download was added in
> private mode, there will be no persistence in the extension-maintained
> state after you close the private window and reload the page (or
> restart the browser), as expected.


All of this makes sense to me then.

Giorgio Maone:
> On 12/11/2015 17:38, sajolida wrote:
>> 2. The extension is great because it preserves its state even if you
>> close the tab. You can open it again and the result of the verification
>> is still there. Still, I think we should reset its state in some cases:
>>
>>   - When the download is finished and the user clicks on the "next"
>>     button. :maone:

>
> Done: once you click "Next", the filesystem browser is shown with the
> file highlighted while in the background the page gets reloaded and goes
> in its initial state.


It works, thanks.

>> 4. We looked at the SSL information embedded in the code (conf.json) and
>> there's the fingerprint of the certificate for tails.boum.org. According
>> to the specification on
>> https://tails.boum.org/blueprint/bootstrapping/extension/#index5h2 it
>> should instead include "root certificate of the authority expected to
>> sign the certificate of https://tails.boum.org/". We don't want the
>> extension to break when boum.org renew their certificates. :maone:
>
> Done, maybe.
> Now you've got the flexibility of choosing to pin the domain cert, the
> issuer's (CA's) cert or both.


I've seen that in conf.json. Regarding the different kinds of pinning,
how do you switch from trusting the cert to trusting the issuer or both?
By adding and removing the corresponding information in the
configuration file? Is it that any pinning available in the
configuration file is trusted?

> I decided not to let you pin on the actual root, but on the nearest
> issuer in the chain (Gandi, in your case), because it seemed to me that
> pinning on a root CA which has many resellers (like "The UserTrust
> Network", in your case) would have sensibly reduced the security of this
> setup.


That was the idea. Sorry for the unclear specification. We want to ping
on Gandi, not on UserTrust.

> If you actually prefer the root to be tested, rather than the
> intermediate, I'm gonna implement it as a further option.


You interpreted the blurry specification right already :)

>> 5. In 2cf4737 you added a class to the <html> tag. We can't really do
>> that in ikiwiki. So is it possible to move this somewhere else in the
>> code? Maybe on #download-and-verify? :maone:
>
> Yes, just move the "dave.js" <script> element down in the page so that
> it runs after the element has been inserted in the DOM. :tchou: ?


We'll try this.

>> 7. We added an alternative display between outdated Firefox versions and
>> unsupported browser vendor in 67f4e01. Giorgio: do you think you can
>> adjust the sniffer accordingly?
>
> I don't believe it's a good idea, as users may be just faking their UAs
> and getting things even more confused.
> One change which I believe would be more useful would be adding direct
> links to the extension(s) packages with a "I'm actually using Firefox >=
> 38" and "I'm actually using Chrome >= 44" labels, so people can override
> our sniffing if misleaded by privacy countermeasures and install the
> extension right away (at least on Firefox, the browser add-on installing
> machinery will perform its own, much more reliable, version checking at
> that point).


That's right. I didn't think about faked user-agents, and this might be
an relevant share of our users. Still, it seems like your implemented
the code for this alternative already in d14d747 and this might be
relevant for people not using privacy tools. So I'd like to try to keep
both things, and added some clarification and an override as you
suggested. See af3570b6..fc20a99. I'd like to see how things go during
the user testing and maybe adjust based on that.

>> 8. We'd like to change the display of progress information:
>>
>>   - download speed from Kb/s to KB/s
>>   - downloaded size from MB to MiB
>>   - displayed ETA to adjust to "1 minute" and "seconds" (keeping in
>>     mind that all user-facing strings should be in our HTML so that
>>     people can translate them)

>>
>> Giorgio: is that possible? I guess we need to embed "minutes",
>> "minute", "seconds", and "second" in the HTML.
> Done. You can still the old measure units as well, they're both
> accounted for.
>
> In order to let you hide/show your measure unit fields automatically via
> CSS depending on the current count, DAVE is setting a
> 'data-value="${currentValue}"' attribute on the parent element, with the
> same value expressed in different measure units (properly floored) or
> "???" if floor(value_in_unit) gives 0.
> So,
>
>  <span data-value="1">
>   <span class="eta-mins">1</span>
>   <span class="plural">minutes</span>
>   <span class="singular">minute</span>
>  </span>
>  <span data-value="90">
>    <span class="eta-secs">90</span>
>    <span class="plural">seconds</span>
>    <span class="singular">second</span>
>  </span>

>
> Will just display
> 1 minute
>
> and
>
> <span data-value="???">
> <span class="eta-mins">???</span>
> <span class="plural">minutes</span>
> <span class="singular">minute</span>
> </span>
> <span data-value="20">
> <span class="eta-secs">20</span>
> <span class="plural">seconds</span>
> <span class="singular">second</span>
> </span>
>
> will give
> 20 seconds.
>
> Look at the current dave.css to see how the magic is done.


I think I got it. I tentatively added this to our HTML with 29c8feb.

>> 9. There's no way of going back to the previous steps using the "Back"
>> button of the browser. That was no specified in the wireframe and we're
>> wondering whether that's needed at all but apparently, in other such
>> scenarios of step-by-step processes inside a single page, sometime the
>> "Back" button of the browser is mapped to going back to the previous
>> step. For example, right now, as the extension remembers its state,
>> there's no way of canceling the download once it started (you can only
>> "pause" it). But this particular case can be solved differently maybe.
>
> You've got a "Cancel" button now.


It works!

>> 11. Once the download is over it should go from #download-button to
>> #download-text. :maone:
> Done


Ack.

>> 13. The #download-button-size is updated with the download URL once
>> clicked; but on the wireframe the ISO size remains displayed. Granted,
>> now that we have more complete progress indicators that would be a
>> duplicate information. Maybe we can empty this completely then? :maone:
>
> Unless I'm misunderstanding, it all depends on the classes set on the
> HTML elements, so you can decide at any time.


Tchou?

>> 14. When clicking the download button, we're proposed an alternative
>> between "Open with [Archive Manager (default)]" and "Save File". I
>> understand that this corresponds to the Content-Type sent by the HTTP
>> server. But in our scenario it doesn't make sense to open the ISO image
>> with any other application (as we want people to verify it before doing
>> anything, and then mostly likely to install it on a USB with special
>> instructions). So Giorgio, since you have very special powers on web
>> browers, could we do something to propose saving only? Maybe overriding
>> the MIME type or jumping straight to the saving dialog?
>
> I'm gonna try, not done yet.