*** Original post on bio 877 by Ludovic Hirlimann <ludovic AT hirlimann.net> at 2011-06-30 09:49:00 UTC *** Would be nice to be able to have conversations onver SSL and use OTR when possible.

*** Original post on bio 877 at 2011-06-30 10:37:22 UTC *** Adding the OTR link and confirming

*** Original post on bio 877 at 2011-11-16 23:26:01 UTC *** I've just found this while looking for something else: http://comments.gmane.org/gmane.comp.security.otr.devel/1161 http://gitorious.org/fireotr/fireotr/blobs/master/chrome/content/otr_wrapper.js may be reusable.

*** Original post on bio 877 by mozilla AT spacetrace.org at 2012-08-14 15:49:47 UTC *** i think this is really important! see https://bugzilla.mozilla.org/show_bug.cgi?id=779052

*** Original post on bio 877 at 2012-08-14 18:58:20 UTC *** We have an extension that demonstrates how to modify the message content before sending them (for outgoing messages) or displaying them (for incoming messages) by the way: http://hg.instantbird.org/addons/file/tip/rot13

*** Original post on bio 877 at 2012-09-04 21:38:09 UTC *** libotr http://www.cypherpunks.ca/otr/software.php

*** Original post on bio 877 by jacob AT appelbaum.net at 2012-09-05 03:50:37 UTC *** (In reply to comment #0) > Would be nice to be able to have conversations onver SSL and use OTR when > possible. SSL/TLS is already supported, right? OTR should be reasonably straight forward to add in terms of the actual crypto bits, though generation of keys requires a proper RNG - does instantbird have access to /dev/random properly? Would it be best to link against libotr and create bindings? Or would it make sense to try to use one of the javascript implementations of OTR?

*** Original post on bio 877 at 2012-09-05 04:21:06 UTC *** (In reply to comment #7) > (In reply to comment #0) > > Would be nice to be able to have conversations onver SSL and use OTR when > > possible. > > SSL/TLS is already supported, right? Of course. SSL is the default for every protocol that supports it (well). (It's not actually the default on IRC because of bug 954724 (bio 1292).) > OTR should be reasonably straight forward to add in terms of the actual crypto > bits, though generation of keys requires a proper RNG - does instantbird have > access to /dev/random properly? Certainly not on Windows. ;) It looks like there's a variety of ways in Gecko [1][2][3] to get random numbers, what's considered a "proper RNG" to you? > Would it be best to link against libotr and create bindings? This could be done with js-ctypes, the link in comment 2 points to a (partial?) js-ctypes binding to libotr. I haven't looked at this code in a while though, so I'm unsure how good it is or if it's updated and supports all the features necessary. > Or would it make > sense to try to use one of the javascript implementations of OTR? I only saw the one implementation on that site [4], I found it unacceptable: - LGPL is undesirable, but OK. - It uses CryptoJS, but we have access to native crypto routines via Gecko / NSS. - It's really grossly formatted. :P It makes me tend to wonder if it can be done more cleanly. This sounds a lot like when we were trying to find a blowfish JavaScript implementation for GSoC. wnayes ended up writing one from scratch because it was easier. It's possible it would be a good starting point, but I'm not convinced. I tend to think it might make more sense to link to the libotr library, although I'm unsure how complicated that really would be. [1] https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues [2] https://developer.mozilla.org/en-US/docs/JavaScript_crypto [3] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Math/random [4] https://github.com/arlolra/otr

*** Original post on bio 877 by jacob AT appelbaum.net at 2012-09-05 04:38:06 UTC *** (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #0) > > > Would be nice to be able to have conversations onver SSL and use OTR when > > > possible. > > > > SSL/TLS is already supported, right? > Of course. SSL is the default for every protocol that supports it (well). (It's > not actually the default on IRC because of bug 954724 (bio 1292).) SSL or TLS proper? :) > > > OTR should be reasonably straight forward to add in terms of the actual crypto > > bits, though generation of keys requires a proper RNG - does instantbird have > > access to /dev/random properly? > Certainly not on Windows. ;) It looks like there's a variety of ways in Gecko > [1][2][3] to get random numbers, what's considered a "proper RNG" to you? > Well, in an ideal world, /dev/random on say, Gnu/Linux or the CryptoAPI RNG on Win32. If possible, it would be nice to have say, OpenSSL or libnss bindings for hardware acceleration if possible. > > Would it be best to link against libotr and create bindings? > This could be done with js-ctypes, the link in comment 2 points to a (partial?) > js-ctypes binding to libotr. I haven't looked at this code in a while though, > so I'm unsure how good it is or if it's updated and supports all the features > necessary. > I don't know if anyone has audited any of this stuff, so I suspect if we linked against libotr, we'd be in reasonable shape. libotr is certainly a lot though - we link against libgcrypt as well as other libraries. > > Or would it make > > sense to try to use one of the javascript implementations of OTR? > I only saw the one implementation on that site [4], I found it unacceptable: > - LGPL is undesirable, but OK. arlolra made it LGPL, I think, to encourage more people to use it. I'll see him tomorrow, so I'll ask him about it. > - It uses CryptoJS, but we have access to native crypto routines via Gecko / > NSS. It might make sense to extend arlolra's JS OTR for exactly this environment. It seems to me that it's the one case where a JS OTR implementation might be reasonable sometime soon. > - It's really grossly formatted. :P It makes me tend to wonder if it can be > done more cleanly. Anything specifically? > > This sounds a lot like when we were trying to find a blowfish JavaScript > implementation for GSoC. wnayes ended up writing one from scratch because it > was easier. What did you need that for? :) > > It's possible it would be a good starting point, but I'm not convinced. I tend > to think it might make more sense to link to the libotr library, although I'm > unsure how complicated that really would be. Well, on Windows, we build libotr like so: http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/libotr;a=blob;f=INSTALL;h=9a7a433d6db194f0091370963048491a934f7941;hb=HEAD#l34 We build pidgin-otr like so: http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/pidgin-otr;a=blob_plain;f=Makefile.mingw;hb=HEAD In a perfect world, I'd like to help get OTR into instantbird by default. If it was possible to add deps on libotr and then just bind with ctypes, I guess that would be pretty nice. > > [1] https://developer.mozilla.org/en-US/docs/DOM/window.crypto.getRandomValues > [2] https://developer.mozilla.org/en-US/docs/JavaScript_crypto > [3] > https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Math/random > [4] https://github.com/arlolra/otr

*** Original post on bio 877 at 2012-09-05 10:45:28 UTC *** (In reply to comment #9) > Well, in an ideal world, /dev/random on say, Gnu/Linux or the CryptoAPI RNG on > Win32. If possible, it would be nice to have say, OpenSSL or libnss bindings > for hardware acceleration if possible. So we should (fairly easily) be able to get to (most of) the guts of libnss, it's build into the Mozilla platform. And we really do prefer to do things in cross platform ways whenever possible. > I don't know if anyone has audited any of this stuff, so I suspect if we linked > against libotr, we'd be in reasonable shape. libotr is certainly a lot though - > we link against libgcrypt as well as other libraries. Hmmm...sounds heavy. :) If we used js-ctypes we could just take the pre-built binaries and use those, I think. > > > Or would it make > > > sense to try to use one of the javascript implementations of OTR? > > I only saw the one implementation on that site [4], I found it unacceptable: > > - LGPL is undesirable, but OK. > arlolra made it LGPL, I think, to encourage more people to use it. I'll see him > tomorrow, so I'll ask him about it. Yes, well it's better than GPL! Since we include libpurple in Instantbird we could of course use this. But LGPL can't be used in Thunderbird (therefore not in the "chat core" of Instantbird). > > - It uses CryptoJS, but we have access to native crypto routines via Gecko / > > NSS. > It might make sense to extend arlolra's JS OTR for exactly this environment. It > seems to me that it's the one case where a JS OTR implementation might be > reasonable sometime soon. Possibly. I'd hope we could get rid of all dependencies on external JS libraries if we'd use it. > > - It's really grossly formatted. :P It makes me tend to wonder if it can be > > done more cleanly. > Anything specifically? I kind of get the feeling the person writing it isn't very familiar with JavaScript, it seems to use some confusing constructs. There's also few to no comments. :) I'd have to look at it again to know exactly what, however. I see there's a very brief test case, which is good -- does libotr have a test suite? > > This sounds a lot like when we were trying to find a blowfish JavaScript > > implementation for GSoC. wnayes ended up writing one from scratch because it > > was easier. > What did you need that for? :) Bug 954928 (bio 1495), specifically the AIM importer, I believe. > In a perfect world, I'd like to help get OTR into instantbird by default. If it > was possible to add deps on libotr and then just bind with ctypes, I guess that > would be pretty nice. FWIW libotr is also GPL (I think), which means it can't be included in the chat core by default, but could be included in Instantbird. Maybe you should come onto our IRC room and talk to us? It might facilitate conversation a bit: #instantbird on irc.mozilla.org Thanks for the information so far!

*** Original post on bio 877 by Karel Jára <jara.karel AT gmail.com> at 2013-07-15 07:55:24 UTC *** Has this moved any further, or are there not enough developer resources to implement this?

*** Original post on bio 877 at 2013-07-15 12:14:33 UTC *** (In reply to comment #11) > Has this moved any further, or are there not enough developer resources to > implement this? If this had moved any further there would be updates here. As far as I know, none of the developers are really interested in working on this, but we would gladly help someone who is.

*** Original post on bio 877 by Gervase Markham <gerv AT gerv.net> at 2013-09-16 20:39:46 UTC *** BTW, after a Mozilla policy change, LGPL is now fine for Thunderbird, as long as it's dynamically linked into a separate library. (Not sure what that would mean for a JS lib, but happy to explore it.) So that might make this bug easier to fix. Gerv

*** Original post on bio 877 by arlolra <arlolra AT gmail.com> at 2013-10-02 18:47:31 UTC *** For what it's worth, the OTR.js library switched to MPL v2.0 about 11 months ago and has had a modicum of auditing. It's being used in a few projects and hopefully isn't as gross as it was once purported to be :)

*** Original post on bio 877 at 2013-10-02 20:20:39 UTC *** (In reply to comment #14) > For what it's worth, the OTR.js library switched to MPL v2.0 about 11 months > ago I saw, that is great news for making it usable among a wide range of projects. > and has had a modicum of auditing. It's being used in a few projects and That's good and points in its favor. > hopefully isn't as gross as it was once purported to be :) This, unfortunately has not changed. I also dislike the number of external libraries used where we could use more "native" APIs. https://bugzilla.mozilla.org/show_bug.cgi?id=779052 has a lot of good information from jcranmer about ways forward.

*** Original post on bio 877 by arlolra <arlolra AT gmail.com> at 2013-10-03 00:03:32 UTC *** (In reply to comment #15) > > hopefully isn't as gross as it was once purported to be :) > This, unfortunately has not changed. I also dislike the number of external > libraries used where we could use more "native" APIs. In comment #10 you wrote, > > > - It's really grossly formatted. :P It makes me tend to wonder if it can be > > > done more cleanly. > Anything specifically? > I kind of get the feeling the person writing it isn't very familiar with > JavaScript, it seems to use some confusing constructs. There's also few to no > comments. :) I'd have to look at it again to know exactly what, however. I see > there's a very brief test case, which is good -- does libotr have a test suite? Which constructs are you referring to? I'm happy to make changes if it means you're more likely to use the library, or even if it just improves the codebase. Also, I should mention, I'm willing to help with this effort, overall.

*** Original post on bio 877 at 2013-10-05 14:45:45 UTC *** (In reply to comment #16) > Which constructs are you referring to? I'm happy to make changes if it means > you're more likely to use the library, or even if it just improves the > codebase. Honestly, I greatly dislike the code. I find it extremely hard to read and most likely not very maintainable. My biggest issues with it are: - There are very few comments. - There are a lot of style issues with it, that aren't really "issues", but I don't exactly know what our policy for style in third-party code is. - Lots of usage of var instead of let and const. - The node.js style of anonymous functions makes a lot of the code pretty confusing to follow. - It uses a lot of node libraries that we have "native" access to: - CryptoJS (we have WebCrypto + NSS) - BigInt, we'd probably still need this or used typed arrays or something. Pretty much...merging node.js style code into Mozilla via shims is EXTREMELY painful. I'd prefer not to do this. > Also, I should mention, I'm willing to help with this effort, overall. That's great! We've had a user being interested in #maildev on IRC about implementing this. You should try to coordinate efforts, most likely via IRC.

*** Original post on bio 877 by mozilla AT spacetrace.org at 2013-10-15 11:59:19 UTC *** Just for info: There is a patch suggestion in thunderbirds bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=779052

*** Original post on bio 877 by tststts <titusstahl+bugzilla AT gmail.com> at 2013-11-30 12:02:45 UTC *** Relevant bounty on bountysource: https://www.bountysource.com/issues/1012564-otr-encryption-in-thunderbird-chat

A backend based on the API from https://bugzilla.mozilla.org/show_bug.cgi?id=983347 is available at https://github.com/arlolra/ctypes-otr, with a minimal amount of UI. We need to discuss, * UI requirements and implementation * Path to upstream the code

Bounty on Bountysource: https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

Attaching the libotr wrapper for review. We can hopefully go through these modules independently.

Comment on attachment 8547924 [details] [diff] [review] libotr.patch Review of attachment 8547924 [details] [diff] [review]: ----------------------------------------------------------------- Sorry if some of my questions are naive, I don't fully understand ctypes. :) Overall I think this is a good start, but I dislike the design...that might just be because of ctypes. Can you point me to where this code is used though? I need to see some use cases to offer more feedback. ::: chat/modules/libotr.jsm @@ +2,5 @@ > + * License, v. 2.0. If a copy of the MPL was not distributed with this > + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ > + > +/* > + * js-ctypes wrapper for libotr I'm not sure if this comment needs to be expanded or not, but libOTR and libC are...what exactly? The libOTR/libC API done in ctypes? Do they wrap it to any greater degree than that? @@ +9,5 @@ > +const EXPORTED_SYMBOLS = ["libOTR", "libC"]; > + > +const {interfaces: Ci, utils: Cu, classes: Cc} = Components; > + > +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry); We only use this once, I think. So maybe put it near that. @@ +14,5 @@ > + > +Cu.import("resource://gre/modules/ctypes.jsm"); > +Cu.import("resource://gre/modules/Services.jsm"); > + > +let abi, libcPath; Add a comment above this saying what we're trying to do in this block. Also, please indent your case statements. @@ +26,5 @@ > + libcPath = ctypes.libraryName("c"); > + break; > +case "Linux": > + abi = ctypes.default_abi; > + libcPath = "libc.so.6"; Why is this not ctypes.libraryName("c") (i.e. the same as Darwin). @@ +29,5 @@ > + abi = ctypes.default_abi; > + libcPath = "libc.so.6"; > + break; > +default: > + throw new Error("Unknown OS"); Did you test this situation? What happens? Does the export even work? @@ +32,5 @@ > +default: > + throw new Error("Unknown OS"); > +} > + > +let libotr; Please add an explanatory comment saying what this is doing. @@ +37,5 @@ > +try { > + // try in chrome > + let uri = "chrome://otr/content/" + ctypes.libraryName("otr"); > + uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null)); > + libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path); Will OS.File simplify any of this path manipulations? @@ +40,5 @@ > + uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null)); > + libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path); > +} catch(e) { > + // look in standard locations > + libotr = ctypes.open(ctypes.libraryName("otr")); What if it isn't found here either? @@ +44,5 @@ > + libotr = ctypes.open(ctypes.libraryName("otr")); > +} > + > +// libotr API version > +const otrl_version = [4, 1, 0]; Does this represents the version we support? I have a feeling this should be named with our normal kConstantCamelcase constant formatting... @@ +741,5 @@ > + > +let libc = ctypes.open(libcPath); > + > +let libC = { > + close: () => libc.close(), I find it strange you have a close() function here, but that the open() seems to take place up above in the module. It might make sense to add an init function here which does the logic of finding where libc is, etc. and setting it as a property on this object. Who calls libc.close() anyway? What if there are multiple consumers? (Or maybe this can be done because of the libc.declares below?)

Comment on attachment 8547924 [details] [diff] [review] libotr.patch Review of attachment 8547924 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for the feedback. This library is loaded here: https://github.com/arlolra/ctypes-otr/blob/master/chrome/content/otr.js#L8 ::: chat/modules/libotr.jsm @@ +2,5 @@ > + * License, v. 2.0. If a copy of the MPL was not distributed with this > + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ > + > +/* > + * js-ctypes wrapper for libotr Just the parts of the libOTR / libC API necessary for the extension, done in ctypes. Nothing more than that in this file. @@ +9,5 @@ > +const EXPORTED_SYMBOLS = ["libOTR", "libC"]; > + > +const {interfaces: Ci, utils: Cu, classes: Cc} = Components; > + > +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry); Done @@ +14,5 @@ > + > +Cu.import("resource://gre/modules/ctypes.jsm"); > +Cu.import("resource://gre/modules/Services.jsm"); > + > +let abi, libcPath; Done @@ +26,5 @@ > + libcPath = ctypes.libraryName("c"); > + break; > +case "Linux": > + abi = ctypes.default_abi; > + libcPath = "libc.so.6"; I think `libraryName()` is pretty naive in that it just prepends "lib" and appends the platform specific extension (".so", ".dll"). And, because of multiarch support in Linux, libc.so isn't found in the standard library search paths. @@ +29,5 @@ > + abi = ctypes.default_abi; > + libcPath = "libc.so.6"; > + break; > +default: > + throw new Error("Unknown OS"); It throws an exception and the extension isn't loaded. 1423597990958 addons.xpi WARN Exception running bootstrap method startup on ctypes-otr@tormessenger: Error: Unknown OS (chrome://otr/content/libotr.js:24) JS Stack trace: @libotr.js:24:1 < @otr.js:8:1 < startup@bootstrap.js:308:3 < XPI_callBootstrapMethod@XPIProvider.jsm:4440:9 < XPI_startup@XPIProvider.jsm:2162:13 < callProvider@AddonManager.jsm:208:12 < _startProvider@AddonManager.jsm:669:5 < AMI_startup@AddonManager.jsm:837:9 < AMP_startup@AddonManager.jsm:2468:5 < AMC_observe@addonManager.js:55:7 @@ +32,5 @@ > +default: > + throw new Error("Unknown OS"); > +} > + > +let libotr; Done @@ +37,5 @@ > +try { > + // try in chrome > + let uri = "chrome://otr/content/" + ctypes.libraryName("otr"); > + uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null)); > + libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path); I don't think so ... but these steps are to determine the location of the extension directory. We'll need to change this to wherever you plan on bundling libotr, which for the other shared object files, seems to be the application directory. In which case, ctypes.open(ctypes.libraryName("otr")) should be sufficient. @@ +40,5 @@ > + uri = Cr.convertChromeURL(Services.io.newURI(uri, null, null)); > + libotr = ctypes.open(uri.QueryInterface(Ci.nsIFileURL).file.path); > +} catch(e) { > + // look in standard locations > + libotr = ctypes.open(ctypes.libraryName("otr")); It'll throw if it can't find the library. @@ +44,5 @@ > + libotr = ctypes.open(ctypes.libraryName("otr")); > +} > + > +// libotr API version > +const otrl_version = [4, 1, 0]; This is the libotr api version we are using, not the protocol versions we support. It needs to be set so that the right callbacks and whatnot are fired in libotr. @@ +741,5 @@ > + > +let libc = ctypes.open(libcPath); > + > +let libC = { > + close: () => libc.close(), Right, so you hinted at it in the "maybe this can't be done because of the libc.declares below". The library needs to be open before you can declare an api from it. But I agree that it's a little strange and am open to less cumbersome organization. Close is called at the extension unload time, which is kind of redundant in that it'll be closed automatically when the libc var is gc'd. Multiple consumers would be a problem but not a scenario that seemed to need support.

The bounty for this bug is now at $1K at https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

Please keep this bug to technical discussion. Thanks.

Comment on attachment 8547924 [details] [diff] [review] libotr.patch Review of attachment 8547924 [details] [diff] [review]: ----------------------------------------------------------------- I didn't expect to review this before it had been updated to address Patrick's comments, but I had a quick look and noticed some things to comment on. ::: chat/modules/libotr.jsm @@ +9,5 @@ > +const EXPORTED_SYMBOLS = ["libOTR", "libC"]; > + > +const {interfaces: Ci, utils: Cu, classes: Cc} = Components; > + > +let Cr = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(Ci.nsIXULChromeRegistry); "Cr" is always used for Components.results, so please use a different variable name. @@ +35,5 @@ > + > +let libotr; > +try { > + // try in chrome > + let uri = "chrome://otr/content/" + ctypes.libraryName("otr"); I don't think looking for a binary library in chrome:// is a good idea. Chrome files are usually stored in compressed jar files. If you want to preserve a way to make this work in an add-on, I think you would want to use a resource:// URI instead. @@ +51,5 @@ > + > +const time_t = ctypes.long; > +const gcry_error_t = ctypes.unsigned_int; > +const gcry_cipher_hd_t = ctypes.StructType("gcry_cipher_handle").ptr; > +const gcry_md_hd_t = ctypes.StructType("gcry_md_handle").ptr This part of the file looks like it has been somehow automatically generated, but given the missing ';' here, I guess it hasn't. I don't know how to usefully review this part of the file, as I don't know the libotr API, and am not really familiar with ctypes.

Hello, everybody I just saw two news this week about "Tor Messenger Beta" (https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily) that seems to be "based on Instantbird" with "OTR (Off-The-Record) Messaging in XMPP-based services are default enabled. " (https://tlhp.cf/tor-messenger-review/). How does this relates to this issue? Kind regards, Daniel

(In reply to daniel neis from comment #29) > Hello, everybody > > I just saw two news this week about "Tor Messenger Beta" > (https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily) > that seems to be "based on Instantbird" with "OTR (Off-The-Record) Messaging > in XMPP-based services are default enabled. " > (https://tlhp.cf/tor-messenger-review/). > > How does this relates to this issue? > > Kind regards, > Daniel Arlolra's OTR addon (that is shipped as part of Tor Messenger) can be found here https://github.com/arlolra/ctypes-otr. It works with Instantbird nightlies too (but not with IB 1.5).

There is still a bounty of 1020$ on this issue, and it seems like the bounty will be cut low during the next few months, since bountysource charges a fee each month if a project is inactive. So if someone has the time, now is the time to claim the bounty: https://www.bountysource.com/issues/5925617-add-support-for-otr-and-encrypted-chats

(In reply to github from comment #31) > There is still a bounty of 1020$ on this issue, and it seems like the bounty > will be cut low during the next few months, since bountysource charges a fee > each month if a project is inactive. So if someone has the time, now is the > time to claim the bounty: > https://www.bountysource.com/issues/5925617-add-support-for-otr-and- > encrypted-chats Maybe this money should simply be donated to the TB project, once it's implemented.

We're exploring the approach to port https://github.com/arlolra/ctypes-otr to Thunderbird, which would require to bundle libotr and its gnupg-project dependency libs. Bug 1518091 is about clarifying if bundling those libs is possible.

This feature will require several individual steps. I suggest to use this bug as the overall tracking bug, and use separate bugs for the individual tasks.