[Tails-dev] Tor Browser 13.0.13 (Windows, macOS, Linux)
Hello All, Unsigned Tor Browser 13.0.13 (desktop-only) release candidate builds are now available for testing: - https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.13-build1/ The full changelog can be found here: - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/tbb-13.0.13-build1/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt Best -- ma1 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tor Browser 13.0.6 (Windows, macOS, Linux)
Hello All, Unsigned Tor Browser 13.0.6 (desktop-only) release candidate builds are now available for testing: - https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.6-build1/ The full changelog can be found here: - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/tbb-13.0.6-build1/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt Best -- ma1 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tor Browser 13.0.4 (Android, Windows, macOS, Linux)
Hello All, Unsigned Tor Browser 13.0.4 release candidate builds are now available for testing: - https://tb-build-02.torproject.org/~ma1/builds/torbrowser/release/unsigned/13.0.4/ The full changelog can be found here: - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/tbb-13.0.4-build1/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt -- ma1 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tor Browser 12.5.3 (Android, Windows, macOS, Linux)
Hello All, Unsigned Tor Browser 12.5.3 release candidate builds are now available for testing: - https://tb-build-05.torproject.org/~ma1/builds/release/unsigned/12.5.3/ The full changelog can be found here: - https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/tbb-12.5.3-build1/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt Have a nice! -- ma1 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Server-side caching settings of IDF
Hi intrigeri, On 24/05/2016 16:56, intrigeri wrote: > > FWIW, the request headers always include: > > Pragma: no-cache > Cache-Control: no-cache Good catch! https://labs.riseup.net/code/issues/11304#change-58146 Sorry for not having noticed it earlier :( -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Server-side caching settings of IDF
On 25/04/2016 18:18, intrigeri wrote: >> Right. The server now sets both Cache-Control and Expires headers to >> "last access time + 2 hours", for IDFs. >> How can I verify, from the client side, that DAVE honors these? >> Using some Firefox developer tool, perhaps? > Yep, ctrl+k, "Net" tab. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Server-side caching settings of IDF
Hi, On 29/03/2016 20:23, intrigeri wrote: >> Should we add "Cache-Control" and "ETag", and remove "Expires"? > I don't know. I'll look into it later this week. > >> $ wget --server-response >> https://tails.boum.org/install/v1/Tails/i386/stable/latest.yml >> --2016-03-29 18:06:06-- >> https://tails.boum.org/install/v1/Tails/i386/stable/latest.yml >> Resolving tails.boum.org (tails.boum.org)... 204.13.164.188 >> Connecting to tails.boum.org (tails.boum.org)|204.13.164.188|:443... >> connected. >> HTTP request sent, awaiting response... >> HTTP/1.1 200 OK >> Date: Tue, 29 Mar 2016 18:06:08 GMT >> Server: Apache/2.2.22 (Debian) >> X-Frame-Options: SAMEORIGIN >> X-XSS-Protection: 1; mode=block >> X-Content-Type-Options: nosniff >> Strict-Transport-Security: max-age=15768000 >> Last-Modified: Fri, 18 Mar 2016 20:43:59 GMT >> Accept-Ranges: bytes >> Content-Length: 269 >> Cache-Control: max-age=0 >> Expires: Tue, 29 Mar 2016 18:06:08 GMT >> Keep-Alive: timeout=15, max=100 >> Connection: Keep-Alive >> Content-Type: text/plain >> Content-Language: en >> Length: 269 [text/plain] >> Saving to: ‘latest.yml’ I believe that Cache-control: max-age=0 header, which appears to be already there, actually causes the browser to revalidate every time, therefore producing an additional hit, even if the response for unchanged files is a body-empty "304 Not Modified". Both "max-age" and Expire should reflect your expectation of how long the IDF is likely to remain valid (1 day? 1 week? 1 month?). Using ETag is just an alternate way to reduce the network traffic, by giving the revalidating server another way to tell whether the IDF is stale other than If-Not-Modified-Since, i.e. If-None-Match, but won't reduce the validation hits: that's a job for Cache-Control and Expire. Disclaimer: I'm not a caching guru, but this resource may help https://www.mnot.net/cache_docs/ Cheers -- G -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Dynamically changing ISO URL in DAVE
On 13/02/2016 13:49, sajolida wrote: > intrigeri: >>> Beside that, I think the JSON should be fetched every time the UI page >>> is reloaded (of course obeying to server-side caching directives), just >>> like we currently do with the IDF. >> I'm afraid I don't know under which circumstances the UI page is >> reloaded, so I lack the background info to integrate this proposal >> into my mental representation of the problem. >> >> @sajolida + @Giorgio: is this done as part of the Installation >> Assistant or DAVE course of operation, or only due to external factors >> (e.g. the user manually reloading the page, or restarting their >> browser)? > I *think* that Giorgio is only referring to a possible manual refresh > from the user. Keep in mind that DAVE is supposed to follow up on > download in the background and a user coming back to the download page > after possibly closing the tab, or to survive a manual page refresh or > browser restart. > Whenever a page matching the pattern for a possible UI page (i.e. "https://tails.boum.org/*;), DAVE currently fetches the IDF. This is basically the only way to fix https://labs.riseup.net/code/issues/10685, as noted in https://labs.riseup.net/code/issues/10685#note-5 Of course you can and should limit the actual network activity by properly using Chache-Control and/or ETag headers. The same should apply to mirrors, if you want to keep them up-to-date. -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Dynamically changing ISO URL in DAVE
Works For Me™? Likely we will be working on it on April 6-8, and > ideally we would need the new feature to be on AMO by the end > of April. > > Also, it would be awesome if we could ask you one or three questions > when we hit technical difficulties along the way, but if you can't do > it, it's fine, I guess we can ask for help to other add-on developers > we know :) > > To end with, can you please give a quick look at our existing JS code, > and tell us if anything can't possibly work in a Firefox add-on such > as DAVE, or really, if anything raises a red light: > > https://git-tails.immerda.ch/mirror-pool-dispatcher/ > > This draft code implements something very similar to what I'm > describing here, except it's meant to be loaded and run from a web > page that has a download link, instead of from a Firefox extension > (which I think we will need for downloads that are not mediated by > DAVE). > > Cheers, -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Installation Assistant (+ ISO Verification Extension + Tails Install in Debian): release schedule
On 30/11/2015 20:32, sajolida wrote: > Giorgio Maone: >> thank you for your time filing those tickets :) >> >> Unfortunately I can't look at them closely until Monday because I'm >> traveling, so please forgive me if the answers to my questions below >> could be easily found by examining their details. > I don't think that there is any new information in these tickets, > outside from what we already discussed on the list. Now that I could read them no, indeed :) >>> - A beta release in time for 1.8 (December 15). The assistant would be >>> advertised in the release notes, maybe tweet about it and send a mail to >>> tails-testers. That's tracked by #8590 and subtasks. >> I will certainly try, but I'm not sure I can fix all those issues by >> then because I'm gonna attend Mozilla's December work-week in Orlando >> (AKA "Mozlando"), from 7 to 12, and I'm pretty sure I won't own the >> golden share on my time, there. > Ok, so we'll try to react quickly this week (before the 7) if you have > questions or are blocked. Then we'll leave you alone from the 7th to the > 12th. Perfect. >> However, if you set some kind of priority on them, I'll start from the >> highest attempting to fix as much as possible, always aiming for the >> full package of course. > Ok, so I set elevated prio on: > > - #10686: Network disconnection shouldn't make download fail in DAVE > - #10678: Prevent DAVE from reloading the page every 10s > > And lowered prio on: > > - #10685: Change in IDF should reset DAVE (← needs a confirmation) Confirmed, DAVE currently fetches the IDF (and therefore resets itself) every time either the browser starts, or the extension gets updated/installed/enabled after being disabled. Therefore this ticket is basically about forcing the IDF to be reloaded every time you load the UI page, or even more often (e.g. by setting a timer which reloads it every 3 minutes or so if the UI is currently shown), correct? > Just to clarify, my bullet point referred to the work on Tails > Installer done with intrigeri and u, so there's no implication for you > I think. But yes, once you committed a fix in your repo you should > mark your tickets as "Ready for QA" and assigned to me (or tchou). > Regarding the deadline, as none of our work goes into the actual ISO > image, our deadline is only to be ready when 1.5 is announced. That's > on Tuesday 15 late CET. I think that our work should be done on Monday > 14 so I can have some time on Tuesday to integrate everything on the > website, make sure everything works as expected, write the release > notes, etc. Roger > Regarding your schedule, when would you do the process to upload to AMO? > Before the 7? Between the 7 and the 12? Most likely between the 8 and the 11, when I'll be working shoulder-to-shoulder with the AMO admin themselves and help it to be approved immediately. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Installation Assistant (+ ISO Verification Extension + Tails Install in Debian): release schedule
Hi sajolida, thank you for your time filing those tickets :) Unfortunately I can't look at them closely until Monday because I'm traveling, so please forgive me if the answers to my questions below could be easily found by examining their details. > - A beta release in time for 1.8 (December 15). The assistant would be > advertised in the release notes, maybe tweet about it and send a mail to > tails-testers. That's tracked by #8590 and subtasks. I will certainly try, but I'm not sure I can fix all those issues by then because I'm gonna attend Mozilla's December work-week in Orlando (AKA "Mozlando"), from 7 to 12, and I'm pretty sure I won't own the golden share on my time, there. However, if you set some kind of priority on them, I'll start from the highest attempting to fix as much as possible, always aiming for the full package of course. > > - A final release in time for or before (January 26). The assistant > would then replace the current installation instructions and be linked > from the current "Download" button on the website (renamed "Install"). > That's tracked by #8592 and subtasks. That's definitely feasible. > So by December 15 we would need to have: > > - The Debian and Ubuntu packages ready in backports and PPA. So we can > do the beta with the final instructions for them. What does it mean from a logistics standpoint for me? Do I just need to commit my fixes to my repository and set the "Ready for QA" flag on the bugs, ir is there some further step I need to take for the things going in there place for your release, and what the actual deadlines? > - A version of the extension uploaded to addons.mozilla.org so we can > point to it instead of maone.net. That can be done, with the aforementioned caveat. -- G On 27/11/2015 16:37, sajolida wrote: > Hi, > > I'm putting tails-ux in copy but the implications of these mostly affect > development work so please answer on tails-dev. > > Last week-end we did intensive testing of the current prototype for the > Installation Assistant. We spent 18 hours testing the whole process with > 16 people and many findings came out of it. > > You can check the rainbow table [1] if you want to see our findings. > Today I'll also write a more specific email about the work left to be > done on the extension. > > [1]: > https://labs.riseup.net/code/attachments/download/1070/ux-testing-20151120.ods > > Then we decided on the release schedule for the whole thing. And I want > to check with Girgio and u whether that's fine with them. We thought > about doing: > > - A beta release in time for 1.8 (December 15). The assistant would be > advertised in the release notes, maybe tweet about it and send a mail to > tails-testers. That's tracked by #8590 and subtasks. > > - A final release in time for or before (January 26). The assistant > would then replace the current installation instructions and be linked > from the current "Download" button on the website (renamed "Install"). > That's tracked by #8592 and subtasks. > > So by December 15 we would need to have: > > - The Debian and Ubuntu packages ready in backports and PPA. So we can > do the beta with the final instructions for them. > - A version of the extension uploaded to addons.mozilla.org so we can > point to it instead of maone.net. > > Does that seems feasible to you? > _______ > Tails-dev mailing list > Tails-dev@boum.org > https://mailman.boum.org/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing the ISO Verification Extension
On 19/11/2015 13:17, sajolida wrote: >>> 2. #bittorrent-minor should also be visible when #use-button >>>and #install-button are visible. See slides 3 and 4. >> OK, done in latest commit. > I don't see this. I tested with 0.2.5 and it didn't work. I also don't > see any change while search on 'bittorrent' in the Git history as of > 1039f5f. Maybe you forgot to push? > >>> 3. Clicking #use-button or #install-button should #i_have_iso (when >>>the download starts). >> You mean *hide* #i_have_iso, correct? Tentatively done, then. > Sorry for the missing word. You understand correctly, I meant "Clicking > #use-button or #install-button should hide #i_have_iso". Still, I don't > see this in 0.2.5. See screenshot in attachment. Are you using latest dave.css? -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing the ISO Verification Extension
On 19/11/2015 17:46, Spencer wrote:
>
>> sajolida:
>> You can see it live on https://tails.boum.org/install/download.
>>
>
> Is there a way to verify the extension?
As soon as it's on AMO, it's gonna be signed by Mozilla.
Also, in a near future, installing extensions which have not been signed
by Mozilla will automatically fail.
Finally, if we want hash-based verification right now, rather than
providing a raw link we can use Firefox's proprietary
window.InstallTrigger method like this:
InstallTrigger.install(
"Download and Verify Extension 0.2.6": {
URL: "dave.xpi",
Hash:
"sha256:c750017b572ebc6417324196f216a13216e5f65de6abd8b1a5a1ce07618ccfdc"
}
);
--
Giorgio Maone
https://maone.net
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing the ISO Verification Extension
On 18/11/2015 19:54, sajolida wrote: > > I read this too fast. Actually, we don't want the extension to open the > file browser of the OS right now. After clicking on the "Next" button, > people will go through step-by-step instructions and we'll tell them > when to use the ISO image. So, when you click "Next" the extension should NOT open the file browser NOR reload the page to initial state, correct? What should happen exactly, instead? Should I just leave it up to you (i.e. the web page)? > > Here are the new issues: > > 1. Clicking the "Next" button should also bring back #use-button to >"show" and #use-text to "hide". So, if you click "Next", you get the "Use Firefox extension" button again visible, right? What is exactly supposed to happen when you click it, though? > 2. #bittorrent-minor should also be visible when #use-button >and #install-button are visible. See slides 3 and 4. OK, done in latest commit. > 3. Clicking #use-button or #install-button should #i_have_iso (when >the download starts). You mean *hide* #i_have_iso, correct? Tentatively done, then. > 4. The page reloads every 10s. Why? It makes it blink pretty badly on >Tor Browser and also sometimes loses state. Weird, can you consistently reproduce, and how? > 5. We tried in 26642eb to add a link below the "Next" button to reset >the page as well but it didn't work. Are you triggering the >cancelation only on the *first* "#verify-text-success .btn" in line >207-210? Yes I was. Fixed in latest commits. > 6. We tried in 7bcda1a to replace the URL in the download button with >the size in MiB but it failed. Maybe you should set iso-size-MiB in >updateBlobView around line 88. Fixed. > 7. We managed to get a negative ETA displayed :) See screenshot in >attachment. I couldn't find any screenshot, sorry. > 8. When doing "Resume", the progress bar goes to 100%, displays ???, >and then go back to where it was once the download really started >again. The progress bar should instead freeze where it is until the >download starts again for real. Tentatively fixed in 0.2.5 > 9. #verify-text-label should be visible once #download is visible. See >slide 11. We should be able to change its opacity until we get to >the verification state. And it shouldn't be clickable either, correct? So I suppose the extension should manage both the disabled state (maybe setting an attribute that you can use to style the button) and behavior, correct? -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing the ISO Verification Extension
On 17/11/2015 17:11, sajolida wrote:
> Giorgio Maone:
> 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?
>
In the "pins" section, you can add as many "certs" and "issuers" entries
as you want, listing identifiers for domain certificates and their
issuers, respectively.
Whether they're actually used to verify a certain domain or not is
determined by the content of "pins" > "domains", though.
This section currently looks like this:
"domains": {
"tails.boum.org": {
"cert": null,
"issuer": "Gandi"
},
"maone.net": {
"cert": "maone.net",
"issuer": "COMODO"
}
}
For any entry in "domains", you can specify a reference to a "certs"
entry ("cert"), to an "issuers" entry ("issuer") or both.
In the example above, "tails.boum.org" is pinned on its issuer ("Gandi")
only (because "cert" is null, rather than "*.boum.org"), while the
"maone.net" domain is pinned both on the certificated referenced by the
"maone.net" key and to the "COMODO" issuer.
If I've not been clear enough, feel free to ask.
Cheers
--
Giorgio Maone
https://maone.net
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing the ISO Verification Extension
Status update as of latest commit (extension version 0.2.1) follows. 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. > > 3. Regarding resetting the state of the extension, we were wondering how > this interacts with the Private Browsing of Firefox. Is is reseted when > going in and out of Private Browsing? The extension syncs with the download manager, hence if a download has been initiated from a private window it won't be available anymore once you close that window (even though if you already have the UI opened in another window it will still show its state until reloaded). Of course the state is not persisted across sessions if the download started from a private window. > > 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 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. If you actually prefer the root to be tested, rather than the intermediate, I'm gonna implement it as a further option. > > 5. In 2cf4737 you added a class to the 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"
Re: [Tails-dev] Testing the ISO Verification Extension
On 12/11/2015 17:38, sajolida wrote: > We also published an alpha version of that page on the website, for > testing purposes as well here: > > https://tails.boum.org/install/download/ > > But since the time we synced with Giorgio's code we did some changes, of > course :) They are visible in wiki/src/download.inline.mdwn in our main > repo (5c97222..926f355) but we'll comment on them here when relevant. > Giorgio, I wonder how we should do this syncing; as I understand that > you want to have some test HTML in your repo as well... Indeed, latest commit (minutes ago) addresses most of your feedback, but I cannot comment in deep right now. I will probably do it tomorrow, but in the meanwhile the most important points are: 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 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 3. If you want to use the .chrome-unsupported class on #download-and-verify, rather than on the element, you just need to be sure dave.js is loaded after the element exists (e.g. by placing its
Re: [Tails-dev] Update on Firefox extension
On 31/08/2015 20:55, sajolida wrote:
> Giorgio Maone:
>
>> The main roadblock was Mozilla finalizing its add-ons migration strategy
>> to the Electrolysis (e10s) multi-process & sandboxing architecture.
>> Without an ultimate public decision, which has been deemed "imminent"
>> for all the past month (see
>> https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even
>> decide which of the 4 different technical approaches to develop Firefox
>> add-ons was the best for this project:
>>
>> 1. XUL/XPCOM, like desktop NoScript;
>> 2. restartless, like Android NoScript;
>> 3. Add-on SDK;
First of all, let me clear what seems to be a qui pro quo I've
involuntarily induced: I wrote "restartless add-ons" because that's
their most commonly used name, but in this context I would better have
used the "bootstrapped add-ons" designation, in orde to prevent the
false impression that Add-on SDK extensions are not restartless themselves.
Please notice that *Add-on SDK extensions are restartless add-ons*: the
difference between #2 (bootstrapped) and #3 (SDK) is just the API
they've got available, i.e. just bare XPCOM for #2 and a pure-JS
sandboxed abstraction for #3.
Only #1 (XUL/XPCOM legacy add-ons) require a browser restart after
installation.
As far as I understand, this should already wipe off most of the worries
you expressed about the Add-on SDK :)
> If I understodd correctly, these were the three options that were
> already available previously.
Indeed. During the past few months I've been involved in Mozilla's
e10s/add-ons team, so I've been aware early that all these options were
going to be deprecated sooner or later, hence my decision to defer any
implementation commitment, but an actual schedule and details about the
ultimate replacement have been missing until mid-August, mostly because
a migration strategy for existing add-ons required careful planning and
long discussions, both technical and "political". Even now, the
situation is still in development.
>
> This move to WebExtensions indeed sounds interesting from a portability
> point of view.
Yes it does, even though there won't be a 1:1 mapping between the APIs,
but more like a "shared core" intersection plus browser-dependent
customizations reflecting the peculiarities of each browser and the
expectations of its own user base (e.g. Mozilla will neglect those APIs
whose main purpose is integrating with Google service, while is
committed to make the features needed by the most popular current
extensions available "natively" on the long run).
Also, different browsers are going to use different formats and signing
protocols, therefore cross-browser development will require at least
some repackaging step.
> So the dilemma we're facing here is to find the proper technology to
> use in order to be compatible with Electrolysis (FF43) while not being
> able to write it in WebExtensions (no ETA). Sounds like a pretty bad
> time to start writing new Firefox extensions :)
That's the biggest elephant in the room at this moment, indeed,
especially if you've got ESR compatibility as a requirement :(
Things should get more exciting (very exciting, I believe) as soon as
both the WebExtensions API and its native.js mechanism are supported in
all stable Firefox versions, which unfortunately seems to be about one
year away.
> I understand that Firefox wants to deprecate XUL/XPCOM, so we're left
> with option 2. restartless, and 3. Add-on SDK. But how do you choose
> Add-on SDK from these two:
Simple: non-SDK bootstrapped (restartless) add-ons can work without XUL,
but still depend on XPCOM heavily, therefore they're not gonna outlive
the XUL ones.
Add-on SDK extensions are basically restartless add-ons themselves, but
they run in a sandbox providing them with a rich high-level API
available as CommonJS modules, and under certain constraints (i.e. not
using XPCOM "super powers" which are currently available but are gonna
be deprecated as well) are automatically compatible with Electrolysis,
while bootstrapped ones require a considerable additional effort to
achieve the same compatibility.
In fact, the announcement states that Add-on SDK extensions will be
supported for the foreseeable future as long as they don't call
require('chrome'), i.e. as long as they don't touch XPCOM directly.
> - Do you need to restart the browser after installing a Add-on SDK
> extension? If so, then we probably need to rethink our wireframe,
> rethink what happens in browser with no history like Tor Browser, etc.
Fortunately that's not the case, since Add-on SDK extensions are
themselves restartless :)
>
> - What's the problem with restartless extensions? Will they become
> deprecated? Do they rely on XUL? Are they not e10s ready? Would they be
> much harder to port to WebE
Re: [Tails-dev] Update on Firefox extension
On 28/08/2015 17:37, sajolida wrote: In terms of extension code, Maone told us he would be busy with other extension work over the summer but maybe he's back on track now. Giorgio what's up? Do you have any ETA for a first prototype? Anything blocking you? The main roadblock was Mozilla finalizing its add-ons migration strategy to the Electrolysis (e10s) multi-process sandboxing architecture. Without an ultimate public decision, which has been deemed imminent for all the past month (see https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even decide which of the 4 different technical approaches to develop Firefox add-ons was the best for this project: 1. XUL/XPCOM, like desktop NoScript; 2. restartless, like Android NoScript; 3. Add-on SDK; 4. WebExtensions, the new, future proof, Chromium-like thing (not even disclosed yet until last week, but I was aware of it earlier because I've been working closely with the e10s/add-ons team) This finally happened last week, with this announcement: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ More about WebExtensions: https://wiki.mozilla.org/WebExtensions/ https://wiki.mozilla.org/WebExtensions/FAQ As I told intrigeri when we met, I had really hoped to develop our extension with the new API to improve its longevity and make a Chrome porting easy to do and maintain, but unfortunately, as you can also deduce from the links above, the decision have been dragged for so long that we wouldn't be able to support the Tor Browser (based on ESR) for about on year. Furthermore, until my own native.js proposal ( https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 ) gets implemented ( https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 -- filed just minutes ago), the WebExtensions API is not powerful enough to support our requirements. Therefore the only currently available option ensuring longevity is the Add-ons SDK (AKA Jetpack). I've just received guarantees from Mozilla (in a meeting held today) that they will give us any assistance for our extensions to be supported by any of the foreseeable future Firefox versions. I've already set up a development environment and started hacking. I'm gonna commit something to the git repository next week, and a working prototype most likely by the end of September. Just to let you know, we want to do extensive user testing sessions of the whole process (Installation Assistant + Verification Extension) in November. So we need all the pieces to be ready by then. I'm confident it's going to happen timely. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] ISO verification
Can a web page (and scripts it may be running) loaded in a given browser tab interfere in any way with the content of another tab? Only if it's same origin with that tab, or the content of the other tab opts-in for some form of cross-domain communication, or it's been opened with window.open() by a script in this tab or viceversa (in the latter cases it has an handle to the window of the other tab, either as the return value of window.open() or as the window.opener property, but it cannot actually touch the content unless it's same domain). Please notice that the Tor Browser provides even stronger guarantees of inter-tab insulation, but I'd dare say even those provided by vanilla Firefox are enough for our case. Of course, any tab can open an alert box saying Verification Successful, but it cannot overlay a different tab and, most important, cannot detect any hint that the verification is happening, since it happens in the extension, rather than in the content page (ideally, as soon as e10s is ready, it would even happen in a separate process). At any rate, since the extension would be allmighty, we can implement any UI-level strategy (e.g. going full screen or topmost on the windows stack) to ensure nothing else can tamper with user's perception. -- G On 08/07/2015 02:16, intrigeri wrote: Hi, Giorgio Maone wrote (07 Jul 2015 23:24:07 GMT) : So, just to be clear, *web pages cannot interfere in any way* with the result of the verification performed by the browser add-on, except if there are bugs in the add-on itself (very unlikely, since its code is gonna be relatively simple and high-level) or in the hosting browser (less unlikely, as we know that sh*t happens) . Thanks a lot for this clarification. Good to know! For completeness' sake, let me ask another one: Can a web page (and scripts it may be running) loaded in a given browser tab interfere in any way with the content of another tab? (Here, I'm defining content as whatever the user sees. E.g. detecting that the verification process is ongoing, and displaying a Verification successful overlay or dialog box counts as interfering in this context: most users won't know that such an overlay or dialog box has a different origin and shall not be trusted.) This said as an expert of browser technology and web security :) Yay :) Cheers, -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Test to see why my emails are held in moderation
Look at the subject :) -- Giorgio Maone https://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] extension specification
On 12/05/2015 18:54, sajolida wrote:
B. It's not the latest version of the extension. This version is
incompatible with the version of the page. We can't go forward or
otherwise stuff won't work:
- How can we detect that? Through a version number in the URL as you
are proposing? Wouldn't a version number in the code of the page be more
simple?
I vote for a version string at a fixed location (div
id=ui-version1.0/div) of the HTML.
Of course, we can keep it user-invisible via CSS (#ui-version { display:
none }).
- Then what do we do once we detected that incompatibility? Redirect
to a compatible version of the page that we're keeping on the website
for backward compatibility?
The extension can detect the incompatibility and ask the user that if
she wants to proceed by upgrading the downloader first ([Upgrade
Downloader] / [Abort]).
On [Upgrade Downloader], the extension forces its own upgrade to be
performed quietly (with no further prompts / warning unless something
goes wrong, e.g. if AMO's SSL certificate is bogus) and goes on with the
download+verify process.
C. It's not the latest version of the extension. This version is
compatible with the version of the page but we did a security upgrade of
the extension and we want to force people to update. In that case, we
need something on the page that says which version of the extension is
expected and asks for an upgrade if it doesn't match. That would be a
different version of slide 3 but to update instead of install.
Same as B above.
Of course all of this is particularly relevant for those who have
automatic add-ons updates disabled, such as Tor Browser users AFAIK.
Regular Firefox users would usually receive the most recent version of
the extension silently and timely through AMO.
--
Giorgio Maone
https://maone.net
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] extension specification
On 07/05/2015 18:12, sajolida wrote: Hi Giorgio, A few days ago we finished a wireframe of the extension that we believe is a good start for you to work on. It might still change slightly as we continue discussing small details of it. See https://labs.riseup.net/code/attachments/download/759/extension-20150430.fodg. Looks great, thank you! We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ See the sections: - Non goals - User scenario and wireframe - Integration in the web assistant - Initial browser detection - Checksum verification - Data source Regarding initial browser detection, I can also provide the JavaScript for browser sniffing and browser-specific web content provision if needed. Regarding the data source, we need to know whether YAML works for you as we already create very similar YAML files for the automatic upgrades. It works for me, no problem. May I just ask, though, why YAML and not, for instance, JSON? Does all this sounds reasonable to you? Yes it does. I think that what we need to work on together now is to specify which HTML tools (div, class, etc.) you will need in the code of those web pages to be able to do your stuff. Then tchou and I will start writing the HTML code for those pages. I'd actually feel more comfortable with you providing the HTML written the way you prefer best from a web authoring standpoint, and me developing my interaction code around the structure you come up with, bending it to my needs only if really necessary (e.g. by adding a missing id or class attribute) If that's relevant for you, note that we will most likely use bootstrap for the CSS of those pages. So for example the progress bar would have this markup: http://getbootstrap.com/components/#progress That's fine. Before you can start coding for real we'll also need a name for the extension. We'll try to sort this out quickly, see #9295. Feel free to comment on the latest proposals. I cast my vote for Download and Verify Tails: unambiguous and future-proof, in case should the verification process change. In all your work, it's also important to keep in mind that we'll try to have a similar extension for Chrome at least very soon. I don't know if you can make coding decisions that are more portable than others, but we should do that as much as possible. Yes I can and I had already planned to. We should also try to make the code as little Tails specific as possible. Of course it will be Tails specific as a first implementation, but we'd like to keep the Tails specific bits at least easy to factor out later on if other distros want to reuse our design and make it more generic. That was my idea too, I don't like to waste potentially reusable stuff. We also want to ask you whether you think we should have some written contract for your work with the specifications, deadlines, conditions, and so on. We don't usually do that when we work amongst ourselves but if you require one we can maybe get something. Informal email exchanges like this and the ones you initially contacted me with will work just fine, thank you. Otherwise, at least regarding the deadlines we'll have to deliver the web assistant to Hivos by the end of the year but we'll do several iterations before that and it would be great to have something on which we can do user testing let's say before July. Does that sound reasonable to you? I'm currently very busy with the Firefox transition to the Electrolysis multi-process architecture (enhancing security through low-privilege content sandboxing), and specifically with adapting NoScript to it and helping developers of other popular and complex add-ons who are facing the same challenges. Therefore, end of July or beginning of August is more realistic IMO, even though I'll do my best to prototype it ASAP. On the upside, you're guaranteed of being provided with an Electrolysis-ready add-on, rather than testing something earlier which only later is found to cause troubles in multi-process Firefox. Ah, and we took it for granted but your code will be public, GPL, and all from (almost) the beginning, right? Sure thing! Maybe we should create you a repo on git-tails.immerda.ch. Why not? -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/07/2014 23:35, sajol...@pimienta.org wrote: Still, I'd suggest not losing focus with that discussion now, and moving on to the initial implementation to verify SHA-256 and reconsider all that later on :) I agree and I'm almost done with that: I managed to make Firefox perform SHA-256 verification of the current ISO asynchronously, without blocking the browser GUI at all, in 7 seconds, which oddly seems significantly faster than the native GPG CLI (blocking), at least on my system. Now I just have to wrap this code in a nice UI and package ;) I created #7552 on our Redmine to track that project. Feel free to create yourself an account and assign that task to you. I registered an account, nickname ma1, but I didn't manage to assign the task to myself. Should anybody add me as a member to the project first? Thanks - -- G -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTytVyAAoJECMag6/anCQ013AH/jWv7MANQ3kW2WHAVYePYAjY UcsZaejvsnFGlM0MHZ7BSz292R+x0646SBue+sHo62fcqiGwNHAGR8O5B/yuq/Ln kmHZgEhUDfSjz3OynYH0DrCkK5BKlA49NDq/4efw154RIcM9fSq2X0yAEq6RJ0WH WTr/fbksXO/ZT9t1+2XFqhsGBqAxBAcXilr3O0EQwo9UeigkpR0AcwvnyHgoHTNp XrZF5UjuYnpvlbmP2mmDlWUAfGC2uWfVzv/SAbZEvjPwwH6IGKB4CZGx2nEmv/gl SqxSYCLZYEa/1zf6LxgYdgic5YHo+TUmrhCshdj9B7gIezvKG5OBfl1xYYhqn9E= =AK5o -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
On 09/07/2014 00:46, Griffin Boyce wrote: OpenPGP.js doesn't require the user to have GPG installed on their system. And keeps things cross-platform. Ideally, in this case, the pubkey would be already packaged within the extension, with only signed updates being able to overwrite it. Yes, that was the idea. However, I think to some extent this still relies on a user making an effort to verify the key's validity via its web of trust. It would be nice, but if the user cannot trust the extension he installed he pretty much lost anyway, so this setup would generally mitigate the risk of a MITM while grabbing the hash. However I agree, this is for a future version and shouldn't prevent us from shipping basic download+verification. -- G best, Griffin On July 8, 2014 6:19:07 PM EDT, sajol...@pimienta.org wrote: Giorgio Maone wrote: Hi everybody. The blueprint should be enough for me to start hacking a prototype together. If nobody has suggestions, I'd propose to call the extension with the catchy (!) name of Tails Catcher. I'd just add that a future version might embed tails developer's key and perform OpenPGP authentication itself. I didn't put that idea on the blueprint so far, for the following reasons: - OpenPGP for verifying our ISO image is only stronger than SHA256 if the WoT is used to build strong trust in the signing key. Otherwise, you might as well get an HTTPS MitM while receiving the key, as much as while receiving the hash. - Our past experience with Firegpg [1] taught us that doing GPG inside of a browser is usually a bad idea. The same might not apply to an ISO verification but I would check this very carefully before going this way. - I don't know how portable it would be to do such GPG operations from inside the browser. Would the user need to have GPG installed on their Windows or Mac OS X? Would we ship a GPG ourselves? All those options sounds scary to me :) Those are the reasons why I'm not convinced by that idea. We might also want to further discuss the role of the OpenPGP verification in the broad installation process with UX people. But anyway, that discussion shouldn't block in any way the first implementation... [1]: https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/index.en.html -- Sent from my tracking device. Please excuse brevity and cat photos. -- -- Giorgio Maone http://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
On 09/07/2014 01:41, Alasdair Young wrote: I'm not a fan of openpgp.js for a lot of reasons. http://tonyarcieri.com/whats-wrong-with-webcrypto explains why in a much better way than I ever could. I'm very new to this community and its mindset, so I know I've got a lot to learn and I'm certainly missing something essential, but I fail to understand how those (mostly valid) objections apply to our scenario, since they are directed either against the webcrypto standardization process or aganst cryptography performed in the context of a web page: 1. OpenPGP.js does not *depend* on webcrypto, even if it supports it 2. We wouldn't run as web content, but as privileged code, with the same powers and the same isolation as the browser itself (much like any platform-native program, even if written in cross-platform JavaScript). 3. We don't need to deal with private keys -- G On Jul 8, 2014 3:47 PM, Griffin Boyce grif...@cryptolab.net mailto:grif...@cryptolab.net wrote: OpenPGP.js doesn't require the user to have GPG installed on their system. Ideally, in this case, the pubkey would be already packaged within the extension, with only signed updates being able to overwrite it. However, I think to some extent this still relies on a user making an effort to verify the key's validity via its web of trust. best, Griffin On July 8, 2014 6:19:07 PM EDT, sajol...@pimienta.org mailto:sajol...@pimienta.org wrote: Giorgio Maone wrote: Hi everybody. The blueprint should be enough for me to start hacking a prototype together. If nobody has suggestions, I'd propose to call the extension with the catchy (!) name of Tails Catcher. I'd just add that a future version might embed tails developer's key and perform OpenPGP authentication itself. I didn't put that idea on the blueprint so far, for the following reasons: - OpenPGP for verifying our ISO image is only stronger than SHA256 if the WoT is used to build strong trust in the signing key. Otherwise, you might as well get an HTTPS MitM while receiving the key, as much as while receiving the hash. - Our past experience with Firegpg [1] taught us that doing GPG inside of a browser is usually a bad idea. The same might not apply to an ISO verification but I would check this very carefully before going this way. - I don't know how portable it would be to do such GPG operations from inside the browser. Would the user need to have GPG installed on their Windows or Mac OS X? Would we ship a GPG ourselves? All those options sounds scary to me :) Those are the reasons why I'm not convinced by that idea. We might also want to further discuss the role of the OpenPGP verification in the broad installation process with UX people. But anyway, that discussion shouldn't block in any way the first implementation... [1]: https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/index.en.html -- Sent from my tracking device. Please excuse brevity and cat photos. ___ Tails-dev mailing list Tails-dev@boum.org mailto:Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org mailto:tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. -- -- Giorgio Maone http://maone.net ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
On 06/07/2014 17:01, sajolida wrote: Ah, and tell us in case you subscribed to the mailing list, and we will stop putting you in copy. Just done. Also, I found Griffin's message in this thread from the public archive: I can confirm that an option to select an arbitrary file from the filesystem and automatically verify it as a known Tails ISO or for show its hash for manual verification is planned. Furthermore, if tails-dev has or can obtain a code signing certificate compatible with Mozilla XPIs ( https://developer.mozilla.org/en-US/docs/Signing_a_XPI ), we could ship a signed XPI as a mitigation against MITM concerns. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Firefox extension for downloading Tails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody. The blueprint should be enough for me to start hacking a prototype together. If nobody has suggestions, I'd propose to call the extension with the catchy (!) name of Tails Catcher. I'd just add that a future version might embed tails developer's key and perform OpenPGP authentication itself. - -- G On 06/07/2014 17:01, sajolida wrote: Together with Giorgio Maone from NoScript and tchou we designed a crazy new plan to solve a great deal of ISO verification for the masses. Here it is: https://tails.boum.org/blueprint/download_extension/ Please everybody, check the scenario that we are proposing there, so we all agree on the plan. Giorgio: tell me if you need any additional information to start with your work. At some point you will have to dig into our Git repositories, and ikiwiki setup, and etc. But I bet that you can start working on a prototype without doing so for the moment. But you can already add information to the blueprint which is world editable. Ah, and tell us in case you subscribed to the mailing list, and we will stop putting you in copy. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTucDuAAoJECMag6/anCQ0jiIH/jdEm9ctga+orh9Cfr5cQRkX fGofQvvXXDYF0U8nPhDiIl+mCTThxzLQ6GhPf6BrqnzStEzg64phSdssXGva1m0Z SIK7k1hHtnRh4BNcXL4Dp4Aq7mo8xx0m15saylaJcfz8K8KSxS22xH+b6n6SqY67 Ncy+oNWnvzsDQ5alK3RDq1UTBpqy6ZfFOwVTR6cTfaNSfwPbA+YxpP8W2RsTamU+ O1hudQQLs6BsQraoKGeBUFphyZtHFkAvywY3x0ErBLYdhqdAaPTLsq7mjyPcX+xd Gg93NWMD1rrwYdnaqg7pxTlZhu05hwKm8/oD8/gEW0ChPGO+smBh3+7kQsX7/wI= =90O3 -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
