On Tue, Dec 1, 2015 at 2:47 PM, Andrew Sutherland <[email protected]> wrote: > 2) When you have addressed the technical debt, you potentially are left > with something that is not the same product that Thunderbird was to > begin with[1]. (:rkent's post at > https://mail.mozilla.org/pipermail/tb-planning/2015-September/004066.html > "Future Planning: Thunderbird as a Web App" could be interpreted as a > variation on this.)
Is that the plan of record that the Thunderbird devs agree on executing given resources? > An important question that falls out from all of this is and your > original question is: which is more important? Mail user agency or > Thunderbird the product, especially if there are serious opportunity > costs related to Thunderbird? In the tb-planning thread Mailpile was mentioned, but when looking at the archives, I failed to see the point addressed. How do Thunderbird devs see the benefits of Thunderbird rewritten as a local HTML + Web API JS app compared to Mailpile running locally with a general-purpose browser (or, hypothetically, Mailpile running locally with a special-purpose bundled browser engine or system WebView)? On Tue, Dec 1, 2015 at 5:01 AM, Robert Accettura <[email protected]> wrote: > It's not immediately clear (and maybe that's because it's truly undecided), > but is this an effort to separate Thunderbird from Mozilla entirely > (perhaps live on under Apache, someone else, or stand alone)? If you look at the contexts where Thunderbird has been recommended by someone over the last couple of years, the context often seems to have been privacy and end-to-end encryption in general and Enigmail+GPG in particular. Even though there is a lot to criticize about OpenPGP in general and GPG in particular, it seems to me that making OpenPGP a feature that is easy to use (to the extent the OpenPGP paradigm allows) and available by default is the angle that allows a locally-run MUA to make the most impact in a world where Gmail is otherwise winning on user experience. In that sense, I think Mozilla's GPL-avoiding license policy has hurt Thunderbird and it would have been better for Thunderbird to have bundled GPG and to have designed the UI for it right into the main product itself ages ago instead of leaving it to an extension. Mozilla's license policy seems to cater to the use case that a Netscape engine can be embedded into proprietary software such as an AOL client. Since Thunderbird doesn't exist in that context, I think the license policy hasn't been serving Thunderbird well. How has Thunderbird's mission benefited from Postbox being able to take the code with only a legal compliance dump coming back? If the choices are bundling GPG or enabling Postbox, I'd bundle GPG. When finding a new fiscal sponsor, I'd recommend finding one that doesn't impose a license policy that blocks Thunderbird from bundling GPG. Obviously, this means that I think that Apache's policies wouldn't be a good match for Thunderbird. (If Thunderbird developers are serious about eradicating non-JS code 100%, then bundling GPG will become moot eventually as OpenGPG functionality would have to be written in JS to comply with a "nothing but JS" stance. However, it's unlikely that Web Crypto will cater to the idiosyncrasies of OpenGPG and it's unlikely that you could implement the algorithms that OpenGPG requires but Web Crypto doesn't provide in JS without side channel problems. OTOH, compiling GPG to asm.js, ignoring the side-channel issues, would still be licensing-relevant.) -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
