Re: [Tails-dev] HTML prototype for new download page

Delete this message

Reply to this message
Autor: sajolida
Data:  
Para: Uzair Farooq
CC: Muhammad Usman Subhani, The Tails public development discussion list
Assunto: Re: [Tails-dev] HTML prototype for new download page
Uzair Farooq:
> Hey,


Hey!

>> But then the extension doesn't work: it takes a full core starts eating
> as much RAM as it can. See this screencast:
>
> The SHA 256 takes time and CPU to compute for such large files. In the
> previous add-on we were using a native method (which is not supported in
> web extensions) which was probably fast because it was a native methods are
> native are not bound to Javascript while the SHA libs must javascript to
> compute hash.
>
> What we can do as a workaround is that we compute hash in a webworker. A
> web worker won't hang the page/browser but it'll still take CPU and RAM.


Regarding the RAM, today I see that the amount of RAM is topped at
~200MiB (fluctuating between 150MB and 200MB). Which is a whole lot but
at least not continuously increasing until it crashes, which is what I
thought at first.

Regarding the execution time, I tried again on my machine: it's been
running for 15 minutes and still eating a whole core.

How long does it take to get a successful result of the verification
extension on your machine?

Because maybe I'm facing a bug and not a normal run of the extension...

With the current extension, the checksum is calculated within seconds
(I didn't ever counted how many because it went so fast). On the
command line computing the checksum takes 11 seconds.

>> That you are embedding a crypto library to compute the SHA256
> (scripts/vendor/sha256.js) while the previous code didn't do that.
> In tails-download-and-verify/lib/hash.js he seems to use a build-in
> function from Firefox with:
>
> This is not possible in web extensions, that api only works Add-on SD.


Ok.

>> That you don't pin on the SSL certificate of our certificate authority
> (Let's Encrypt).
>
> This library is also addon SDK specific and is not supported in Web
> Extensions.


Did you check the portability of the pinning mechanism when we first
asked you about the feasibility of porting the extension to WebExtensions?

To be honest, I quite worried to learn only now that the two crypto
operations that are in the design of the extension (checksum and
certificate pining) are not available in Web Extension while I pointed
you to the code and the design back in May... while the deadline for the
new extension is November 16.

> There's this certificate pinning feature in HTML5
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning in
> which pinned certificates are returned in header of request when user
> visits the site first time.


We already have HSTS activated on our website and have plans to work on
having HPKP: https://labs.riseup.net/code/issues/9026 but as you can see
in #note-7 it's quite complex as it requires careful backups and
recovery plans. Definitely not something we can have before November 16.

So do you confirm that we won't be able to do certificate pining in the
new extension?

> It'd have been easier for us to reuse Giorgio's code instead of rewriting
> from scratch but because of the fact that a lot of API's being used in
> Giorgio's
> code are add-on SDK specific and aren't supported in WebExtensions, it was
> better to rewrite.


I can understand that, thanks for the clarification.