Proposal to start a new implementation of Thunderbird based on web technologies - <AUTHOR> https://mail.mozilla.org/pipermail/tb-planning/2017-March/005298.html <comment><USER2> Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

<comment><USER3> The search is unusable -- wedding finds 'weds'. There is no way to do exact searching. I reported this 5 years ago, lots of other people have complained about the stemming, there has been no fix.

There is no support for outlook/exchange. Not saying it's trivial, but it's useful in the modern era.

IMAP folder support is very flakey, I reported some bugs but nothing got fixed.

<comment><USER4> It sounds like search needs a patch bounty, but it would be ridiculous to rewrite Thunderbird because search is naively implemented.

I've never had problems with IMAP, nor do I use Exchange, so I can't speak to those...

<comment><USER5> And thankfully, there's a Lucene-in-C (which I haven't personally had a need to use, but Lucene as a project is __awesome __), so the patch might not even be terribly large unless their current search implementation is splattered all over the app

[https://lucy.apache.org](https://lucy.apache.org)

</comment></comment></comment></comment><comment><USER6> "JavaScript is the best choice."

(Citation Needed).

This proposal identifies serious legitimate concerns with Thunderbird development going forward, but the proposed solution looks more like a hammer seeking a nail than a thoughtful approach to addressing the concerns.

<comment><USER7> Yeah, I cringed at the JS thing. Why not do it in Rust and start with some of the Servo code as a base? That would give the developers an intermediate application to work with that doesn't require the full capability of a web browser.

<comment><USER8> The whole tirade read like a thinly veiled "building an Electron-based MUA is just easier by now", which is a thing I've been contemplating toying with because, to paraphrase another well-known MUA, all those desktop email clients† flat out suck and the best ones are barely above the tolerable threshold.

> Why not do it in Rust and start with some of the Servo code as a base?

Thought about it, but I think Servo might just not be _that_ ready yet given the expected timeframe. Could be of a great synergy and a nice real-life testbed for Servo though.

† I've extensively used a lot on various OSes, from Claws to Gmail (web) to mutt to Mail.app to Eudora to Fastmail (web) to Outlook to AirMail. For _none_ of them could I ever say "nailed it" and while some do have their pluses they're all broken one way or another which brings the whole package down.

<comment><USER9> You say that desktop email clients all suck. Is there a web-based client that, in your opinion, doesn't?

</comment></comment></comment></comment><comment><USER10> Hmm, I thought Mozilla had pulled financial support from Thunderbird? This would be an exciting new chapter for the product, but the article doesn't address whether it makes financial sense for Mozilla to invest this much in Thunderbird's future.

For most of the last three years I've worked on Nylas Mail ([https://github.com/Nylas/Nylas-mail](https://github.com/Nylas/Nylas-mail)), and it hit 2.0 yesterday with Mac/Win/Linux support. It's entirely open source (GPL), written in JavaScript, syncs mail locally, etc. It essentially -is- what the author of the post is looking to build, except it doesn't look like Thunderbird. Nylas put at least $2M+ worth of engineering time into it, and I imagine ThunderbirdJS would take at least a similar commitment of time and effort. Heck, maybe they could just skin Nylas Mail and call it Thunderbird ;-)

<comment><USER11> Is the "open source" label still comically misleading? [0]

I tried it out, didn't read the fine print, filed an issue, never looked at it again.

Because "It keeps user data local and private." is kind of one of the main benefits.

[0]: [https://github.com/nylas/nylas- mail/issues/860](https://github.com/nylas/nylas-mail/issues/860)

<comment><USER10> Ahh thanks I need to update that!

Originally Nylas Mail was OSS, but tied to the Nylas Cloud APIs (which did the actual mail processing.)

The cloud strategy was too expensive, and in version 2.0 the entire mail-sync system was moved into the client and open sourced. ([https://github.com/nylas/nylas- mail/tree/master/packages/cli...](https://github.com/nylas/nylas- mail/tree/master/packages/client-sync)). It's now much more like Thunderbird. There's a bit of cloud processing for snoozing / send later, etc., but it no longer syncs all your email through the cloud.

<comment><USER12> Is there a way to configure it so it makes _zero_ requests to your servers?

If not (yet), would it at least be technically feasible, and would supporting this be an option for you?

<comment><USER13> Definitely feasible but it's not our product focus right now. Most of the features that help differentiate Nylas Mail require some cloud component. (snoozing, send later, reminders, open tracking, etc.)

We totally encourage folks to fork the project and take it in whatever direction they want. If you want to chat with other devs in the community, you should join our Slack room: [http://slack-invite.nylas.com/](http://slack- invite.nylas.com/)

(I work at Nylas)

<comment><USER14> > (snoozing, send later, reminders, open tracking, etc.)

None of that has any appeal to me, I'd much rather a mail system which doesn't require using someone else's server.

Maybe this isn't a priority for other people, but just putting it out there. This is what's making me not use Nylas today.

<comment><USER15> He's already given you a good alternative – fork and collaborate with other devs on a version that doesn't touch their server.

Seems sufficient.

<comment><USER16> I would consider forking a last option, instead of "a good alternative".

A good alternative in my opinion would be just to make some parts optional. Does not sound too hard, to implement (if the codebase is well done)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> If it becomes yet another Electron package it is time to look elsewhere.

<comment><USER18> Perhaps the idea to implement it as web technology is to leverage NPM so that millions of plugins can be made available to an email client.

<comment><USER19> Now you have 100,000 problems.

</comment></comment></comment><comment><USER20> I wonder, if they want to use JS, why not QtQuick? I'm a heavy Thunderbird user but I would move to pretty much anything else if it were to switch to Electron.

<comment> irq-1 I think the reason QtQuick hasn't taken over this space, is that you still need to deal with C++ and cross-compiling. If QT had an option that made it clear you could develop and distribute in JavaScript only, that would be a hit.

<comment><USER21> You can write QML apps in like every popular language, there are well supported bindings everywhere.

I dont get the C++ hate though. C++11 and up is a totally new language and much more productive than its reputation gives it.

</comment></comment></comment><comment><USER22> It would be neat if TB would be rebased on top of Servo (and Rust) as a flagship application for using Servo as an GUI foundation, the same way as TB previously was for Gecko/XUL.

Sadly I doubt TB has the resources to make that happen, but still, it would be neat...

<comment><USER23> I wonder if basing a desktop application on top of Servo would be any more painful than on any of the existing self contained HTML/JS delivery mechanism. It probably would be annoying until Servo reaches parity not to be able to use the web technologies to their fullest extent, but at least you have one (admittedly moving) target.

<comment><USER24> People have done this, not just for desktop applications but also for Android apps, using Servo to display a web UI on mobile.

And there's some work in progress to put a WebView-compatible API on top of Servo, making it trivial to substitute it in an arbitrary application.

</comment></comment></comment><comment><USER25> "JavaScript, if used diligently and with good design, is a very efficient language. Both in execution time, but more importantly for developers. Personally, I wrote apps in many languages, including C++, Java and JavaScript. Of those, JavaScript is by far the most productive - I am personally 4-10 times as productive as with C++."

Not trying to start a this language is better flame war, but is this true? I still find JS to be a strange and incomplete feeling language, but I've not really done much outside of front end work with it. Is it really that productive?

Also I've disliked every interaction with NPM. You end up with a huge chain of decencies for even simple applications. Is this something that's workable with production software?

<comment><USER26> I suspect it is true that among Java, C++ and JavaScript, disciplined well designed JavaScript is easier for developers, and reasonably efficient in execution (given e.g. v8). Especially compared to C++, the memory safety and speed of the compile->run->debug cycle tend to give JavaScript an edge for more programmers (x4 to x10 is of course subjective).

But that doesn't mean JavaScript is a good language. e.g., you have to be extremely careful to not get bitten by the floating point-only math. It was the source of catastrophic bugs for many Twitter clients (in the sense that they stopped working) -- I would hate to find such a bug ate my local mail store.

Not sure what I'd recommend, though - JavaScript is technically bad, but socially excellent for such a project. Python is not fast enough for it (PyPy not withstanding), D/Rust/Nim/Ocaml/Scala are not mainstream enough.

</comment></comment><comment> Ono-Sendai Sounds like a terrible idea, please no. I for one probably will stop using thunderbird if it gets rewritten in JS.

<comment><USER27> What is it written in now? If I remember correctly it's mostly JS with a few native extensions in the chrome.

<comment><USER28> The backend is mostly in pure C++ (~500KLOC or so). The frontend is in JS (~200KLOC or so).

</comment></comment></comment><comment><USER29> I'd rather see projects like Cyberfox, Thunderbird, Palemoon and Evolus Pencil (which, sadly, has been rewritten by now) taking up xulrunner, fork it and continue developing it.

I have yet to find a better system for rapid application development. XUL is wonderful, extentable, everybody know CSS and Javascript these days, XML is very well suited for such tasks. It's one of the best technologies for power- users I ever came around!

All that was ever needed would habe been a Mozilla, that creates an XUL IDE, rather than taking up on a lot of stupid projects (Persona Light Themes, Hello Chat, FirefoxOS, removing XPFE (how coding with XUL is actually called) and whatever (the only real good thing to mention would be Ubiquity, but they killed that off as well), oh, and let's not start talking about Firefoxy mugs, t-shirts, community barbecues, community videos... But hey, that's what happened.

Now, if some people would just fork xulrunner and mirrror the addons.mozilla.org stuff...

As for Thunderbird, I am also pretty satisfied as it is. It may be nice, if one could set certain To: email-addresses per folder (mailing-list folders would greatly benefit from that, along with subscribe/unsubscribe configured per such folder), alternate views onto mails and have, maybe, a modernized foldering-system.

<comment><USER30> > I have yet to find a better system for rapid application development. XUL is > wonderful, extentable, everybody know CSS and Javascript these days, XML is > very well suited for such tasks. It's one of the best technologies for > power-users I ever came around!

It also looks awful and ignores desktop themeing. Or is that just firefox?

</comment></comment><comment> norea-armozel I'm just gonna say I oppose this proposal because I'm really tired of seeing developers shy away from utilizing or learning C/C++ only to admit much later in a project's life cycle that those languages and their associated libraries are the best for the job. I'm all ears on utilizing JS for front end to even a desktop application but if the entire thing gets written to be ran on Servo or whatever browser engine they choose then I oppose it categorically. JS might be fine for some things but as a general programming language on a substandard runtime is just asking for trouble. Learn to write in C/C++ for native applications or go home.

<comment><USER31> Why do you oppose things being run on something like Servo categorically?

<comment> norea-armozel Because there's existing libraries which solve many of the same problems which they inevitably run into and then re-implement them in JS. The "not invented here" mentality has to stop. Unless there's a significant reason to not utilize a library then it shouldn't be avoided. There's no good reason to replicate that functionality.

<comment><USER32> _The "not invented here" mentality has to stop._

This is true, but the track record of bugs and poor security inherent in using relatively low-level languages like C and C++ for everyday Internet-connected applications also has to stop.

<comment> norea-armozel That doesn't really help you when the platform you run on be it a browser or a virtual machine is written in C/C++ which by implication can be exposed to the same security flaws if/when they utilize unsafe design patterns or idioms. So, all you've done is pass the buck onto Servo/Gecko/Safari. The reality is that you can't make an argument that's ironclad in favor of forcing JS to become the new C. Let JS do it's wonders for the web and let C/C++ and other languages that have great native application tools do their wonders for the desktop?

<comment><USER32> I didn't say anything about using JS as the alternative. I happen to think it's a rather poor language and that using it for anything other than running front-end code on a web site until we have better alternatives is usually a mistake. But there are a lot more languages out there than C, C++ and JS, and I don't think any of those is a particularly good choice for this sort of task.

<comment> norea-armozel Oh no doubt there's better languages in terms of general purpose programming. I'm biased towards OCaml myself since it has nice syntax but there's plenty of options to choose from. I'm just pointing to C/C++ languages since they're the most mature and widely available in terms of documentation, IDEs, etc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Note that this is from the end of March, and the thread continues at [https://mail.mozilla.org/pipermail/tb- planning/2017-April/th...](https://mail.mozilla.org/pipermail/tb- planning/2017-April/thread.html)

</comment><comment><USER34> > We need 2 persons for the framework, 3 for backend modules, 4 for frontend > UI, and 1 for theming.

Doesn't 4 people dedicated to front-end UI seem excessive/unnecessary? At least, at the beginning? I would dedicate almost all work to the framework and backend modules; UI with web technologies is far from complicated compared to everything else the client would require.

</comment><comment><USER35> The mockups look very promising. I was never a TB user because it never looked the part in Gnome, but it's something I've kept an eye on and recommended to other people.

[https://dribbble.com/shots/2917534-Thunderbird- Redesign](https://dribbble.com/shots/2917534-Thunderbird-Redesign)

</comment><comment><USER36> I skimmed through this and saw no management of PGP, encryption, key storage, or key exhange. Is that not going to be one of the main focuses of this? I wish that PGP/encrypted mail would be a main feature post Snowden.

<comment><USER37> The one thing i'd like to see is some kind of integration of the Signal protocol-- preferably in a way that supports federation as (1) having OpenWhisper Systems as a single point of failure for all email is not a good idea and (2) having to tie one's email to a phone number is sheer insanity. It's bad enough with messaging.

</comment></comment><comment><USER38> Why not rewrite it in Graphene, which is the Servo's foundation for browser.html?

[https://github.com/browserhtml/browserhtml](https://github.com/browserhtml/browserhtml)

</comment><comment><USER39> title should be the one of the submitted e-mail: "Proposal to start a new implementation of Thunderbird based on web technologies", especially since "is in the works" doesn't seem to be the case yet. (Lots of discussion, continuing into April, but unless I missed it no actual decision made and work begun yet.)

The thread is worth a read, interesting arguments regarding rewrite/refactor/approaches to transition.

<comment><AUTHOR> According to Cambridge Dictionary "in the works" has the following meaning:

      in the process of being planned or done

Thunderbird replacement is currently being planned, so I think it's correct.

<comment><USER40> I think it's that "in the works" seems to imply an agreement/commitment, but this appears to be a proposal.

<comment><AUTHOR> This is a post[0] from one of the project leaders:

 _However, I think we all agree we want the Thunderbird replacement to be a desktop client (plus other platforms like mobile), and based on web technologies, most importantly written in JavaScript._

But the title has now been changed and that is fine with me.

[0][https://mail.mozilla.org/pipermail/tb- planning/2017-April/00...](https://mail.mozilla.org/pipermail/tb- planning/2017-April/005394.html)

</comment></comment></comment></comment><comment><USER41> The only point I could argue with is the choice of JavaScript, all the others seem inevitable. As a Thunderbird user I'm happy to know that I might be using it for another 20 years.

Even JavaScript is not that bad. I not familiar with Electron: do those apps run from a directory with the source code or are a binary file? Running from source code would make it easy to hack with the code, which is good.

<comment><USER10> Yep! Electron essentially just launches a web app from a directory on disk in an included copy of Chromium, with NodeJS's JavaScript bindings as well as the usual ones. The web app has an index.html, CSS, all the standard stuff. It's usually packaged into a .asar file so things can be loaded faster, but it's great for hackability.

</comment></comment><comment><USER42> > We must pay attention to also keep technical qualities that many of our > users rely on. An obvious one is that the new implementation must be able to > quickly scroll through a list of up to 100000 messages.

Does any cross-platform GUI toolkit have a widget that can handle this with sane defaults?

<comment><USER43> Qt, as long as you back the view with a model with O(1) lookup, can handle up to INT_MAX rows perfectly fast. I expect other cross-platform GUI toolkits work similarly. Most native table/list views work on an assumption of uniform row height and thus handle huge lists with no trouble.

The problem browser based apps run into is rendering the entire list into the DOM and thus the browser has to lay out the whole thing in order to compute scroll bars and scroll positions.

You can work around this using requestAnimationFrame, large empty padding divs, and inspecting the scroll position to create DOM elements for only things that you compute are visible. At my last job I implemented a web based table that could do 60fps scrolling on 100,000 items that were all dynamically updating using js_of_ocaml and [https://github.com/janestreet/incr_dom](https://github.com/janestreet/incr_dom).

<comment><USER44> There's also toolkits like React-Virtualized: [https://github.com/bvaughn/react- virtualized](https://github.com/bvaughn/react-virtualized) .

</comment></comment></comment><comment><USER45> That is awesome! I actually toyed with the same idea a couple of months ago and started a prototype, but in the end it was too much work for a single developer (having to implement IMAP/POP backends, etc. in addition to the UI).

Using web technologies for desktop apps is not ideal, but at the same time it's probably the easiest way these days to build cross-platform apps because of the lack of a good cross-platform UI toolkit.

A big benefit I see is that it will make it very hackable as a lot of developers are familiar with web technologies. That should be a good way to get a lot of contributors to implement features and innovate (See for example the community / contributions around Visual Studio Code).

</comment><comment><USER46> Mozilla already has a mail client written in Javascript and HTML 5 - the one shipping in Firefox OS.

And it worked decently.

Start by tidying it up for Android and then port it to desktop. One code base - for mobile, tablet _and_ desktop.

</comment><comment><USER47> I am a bit extreme here as I think Mozilla shall reduce efforts on firefox and make thunderbird a great product instead, one reason is that chrome is too powerful to beat already, and thunderbird could become the universal email client for all, not much contender there yet.

after using slack for a while i feel we can use one slack-channel for each email contact, a bit like google wave probably, and thunderbird can merge email+slack experience into one.

<comment><USER48> If Mozilla manages to build a product based on Servo that kicks Electron's ass (safer, faster, cheaper to distribute, etc.), then I am not sure that Chrome cannot be beat (or be seriously challenged).

This Electron competitor would become very popular, and it could become the "entry drug" into Rust development (you would be able to do everything in HTML/CSS/JS but you would also have the option to code some parts in Rust, for more power), which would also grow the number of Servo contributors. With a large enough community, Servo-based Firefox could fight for a place at being the best browser (safest, fastest, full-featured).

</comment></comment><comment><USER49> Whatever you do, make it render emails in a sane way. I still prefer mutt text-only rendering of emails (content) than any email rendering software, but if you're going to render and digest html, actually do it. The total time involved in and barbarity with which web atrocities have been committed to make emails render correctly in Outlook or even Gmail cannot be understated.

</comment><comment><USER50> Before we start thinking about working on Thunderbird or its replacement there is a fundamental question that needs answering. Is there a future for email? Email is/was a function of the personal computer era. But as PC sales decline and smart phone sales grow do people still use email to the same extent? Is its place in field of personal communications being replaced by SMS, etc. In the business arena I am seeing some companies where internal email is not allowed. The reasoning is that email has become a way of procrastinating (send and forget). On the customer facing side of things email is being replaced by web based customer service apps that use AI (or similar) to answer the customers query ASAP, and if that is not possible get the info and pass on to a human if and only if needed (people cost money). So back to the question is email and by extension Thunderbird obsolescent. Would effort in redeveloping TB be futile as it would wind up give us wonderful app just as email disappears.

</comment><comment><USER51> I like the idea of using web technologies for desktop application. The only major problem right now is that each application uses at least 1.5-2g of RAM each since it basically launches a full web browser under it (and chromium loves ram). We will need enormous amount of RAM soon if all applications starts to go that way...

<comment><USER52> Thunderbird has browser engine to display html emails anyway. And probably most of Thunderbird's code is already in javascript, but using XUL instead of HTML DOM.

</comment></comment><comment><USER53> So it'll be a self-hosted webmail service with a custom web server that runs locally?

<comment><USER32> That doesn't seem to be what they're aiming for here. The goal is supposed to be a new UI that looks and functions very similar to today's.

That's too bad, in a way. One thing I'd really like that Thunderbird doesn't offer today is to separate the mail receive/store/send functionality from the reading/writing UI, so I could run the former on my own server and access it from any device on my network.

Obviously there are some relevant standards here and you could set something like this up with enough technical knowledge using other tools that already exist. However, that reduces the potential market by a few orders of magnitude to those who are sufficiently expert with those tools, and then probably by a few orders more for those who have the time to actually do it.

<comment><USER30> > That's too bad, in a way. One thing I'd really like that Thunderbird doesn't > offer today is to separate the mail receive/store/send functionality from > the reading/writing UI, so I could run the former on my own server and > access it from any device on my network.

Uh, that's exactly what an email server does. Thunderbird is just the client used to access it from any device.

<comment><USER32> Assuming by "email server" you mean an SMTP server, that's not quite what I'm talking about. What I'm looking for is more akin to a mail store, an IMAP server, and functionality for sending and receiving via actual SMTP server(s). That's a separate set of responsibilities to reading or composing messages, which would just need something like an IMAP-compatible client. And all of those are separate responsibilities to a full SMTP server with all the administrative overheads that comes with.

You could do the back office part of what I'm talking about with tools like Dovecot and fetchmail today, running on a Linux server with a standard Maildir backing store, and then you could run Thunderbird purely for its IMAP client capabilities as a front-end, but setting it all up and maintaining it is a horrendous hassle and it's far too technically demanding for most users anyway.

However, separating the receive/store/send responsibilities from the read/write responsibilities would mean you could have a single store on any server with relatively straightforward set-up to actually send and receive mail, which you could then access from any device on your network (or over a VPN or the Internet if it's running on a remotely accessible box), _without_ the risks and overheads of both running your own SMTP server and trying to get mail from it actually accepted anywhere else these days.

Now that everyone's got PCs, laptops, tablets, phones, and who knows what else, I think this is probably the single most limiting problem with traditional offline email clients compared to all the hosted webmail services, but it shouldn't be necessary to incur all the downsides of those hosted webmail services just to access your mail from different devices.

<comment><USER30> IMAP is that single store. Setting up a server just for that would be just as impossible for most users as settings up a mail server would be.

<comment><USER32> An IMAP server alone typically doesn't include the equivalents of fetchmail and the like. It just provides a protocol for remotely accessing the mail store.

However, I don't see why you think it would be impossible for most users to set up what I'm describing. If they can install Thunderbird and configure it to retrieve mail from their ISP or GMail or whatever, they could install a two-part system and configure the store part to do the same using exactly the same information.

In particular, just installing both parts on a single PC would work fine and provide equivalent functionality to current standalone mail clients like Thunderbird. You just have the flexibility to connect other devices to the same store and safely access your mail from those as well, or to install the store part on some other place on the network like an office server or maybe a NAS at home if you want to.

<comment><USER30> > However, I don't see why you think it would be impossible for most users to > set up what I'm describing. If they can install Thunderbird and configure it > to retrieve mail from their ISP or GMail or whatever, they could install a > two-part system and configure the store part to do the same using exactly > the same information.

Then to connect from their mobile they have to open ports on their home networks, get a static IP, know what their IP is to enter it on their phone, worry about a whole host of new security issues.

At that point you may as well run a full mail server.

<comment><USER32> Many ISPs offer a static IP. This is applicable for small businesses as well, and they almost certainly have one. Anyone with VPN on their router to access anything remotely has a way in.

There are difficulties in running a full mail server far beyond this. For example, many ISPs won't let you run one on anything below a high-level business plan without just blocking port 25 and friends at a firewall. Even if you can, many other mail servers will flag anything you send as likely junk mail if you're not running a well-known mail server yourself. For incoming mail, you need something that's going to be up 24/7/365 if you're going to give it as the MX for your domain, and you need to be constantly monitoring for security issues in real time, because if you're even a few hours late with the patch then you're probably running an open relay already and you just made every blacklist on the Internet.

Basically, if you're not big enough to have your own full time IT department, there are huge practical advantages to sending and receiving your mail via a dedicated SMTP server run by someone who does. These are completely unrelated to the usefulness of having a centralised mail store that can be used from anywhere on your network, or beyond if you provide a way in for remote access.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER54> If it's scoped for 3 years, does that mean it'll take 9? =P

</comment><comment><USER55> The backstory here is that Thunderbird devs would like to be faster but have a _hard_ time working against the Gecko changes that breaks their build.

Sure Thunderbird kind-of works, as in it's "done", but people find Security bugs in the Firefox base and it's not sure how they apply to Thunderbird to Thunderbird has to take the update and then they have to deal with the breakage and the incompatibility. You can't just stop and be on Firefox 45 forever. That's just asking for trouble.

</comment><comment><USER56> I really like my hosted email because it's not on my computer. I love offline software, but it all sucks for security. Dropbox, Evernote, Outlook, etc. They all just dump my data in a folder anyone with physical access to my very stealable laptop can get at. Email is especially terrifying because there's just so much personal info in there. I have evernote and dropbox sitting in a bitlocker, so that's okay-ish, but the email thing is just too much.

<comment><USER16> You have heard of this awesome new thing called "Complete System encription"?

</comment></comment><comment><USER57> A couple of days ago I reached out to users to give a morale booster to the devs as they try to figure this rewrite business out: [https://www.reddit.com/r/linux/comments/65upot/show_some_lov...](https://www.reddit.com/r/linux/comments/65upot/show_some_love_for_thunderbird_by_testing_bugs/)

</comment><comment><USER58> I like the gpg integration using enigmail in Thunderbird. So I can send encrypted messages to my friends and people I write code with.

<comment><USER59> You'll be happy to learn that the P=P folks are most likely going to be handling full end to end encryption integration for Thunderbird, for the current version, and the new one (if it happens):

[https://pep-project.org/](https://pep-project.org/)

</comment></comment><comment><USER60> > JavaScript

Nylas all over again... Why complicate and bloat things as if it's the obvious sensible choice?

The time to finally learn how to configure mutt is that much close...

</comment><comment><USER61> The sieve plugin is still broken :-( What's the alternative when using Thunderbird?

</comment><comment><USER62> After many years waiting, maybe we will have a compose new email on a tab.

<comment><USER59> God no, unless there is a way to disable it. I hate tabs in Thunderbird.

</comment></comment><comment><USER63> Interesting that mithril.js gets a mention. I really like it.

<comment><USER44> Was that mentioned in one of the replies? I don't see any specific libraries mentioned in the linked message, or the other replies I searched through.

 _edit_ : Scratch that, it was in this reply: [https://mail.mozilla.org/pipermail/tb- planning/2017-March/00...](https://mail.mozilla.org/pipermail/tb- planning/2017-March/005328.html) . "I'd suggest using TypeScript, Mithril.js, Tachyons, and Node.js for the base technologies -- probably with Mocha/Chai for testing. Later we can make a more stand-alone desktop version with Electron or such. We could use socket.io to push notifications for changes in real or virtual folders and then use Mithril.js (a vdom library) to quickly rerender changed data the client UI requests (or is pushed)."

Worth noting that reply looks more like a wishlist of stuff than a meaningful viable proposal.

<comment><USER64> FWIW that reply appears to be someone who's serious about this proposal: [https://github.com/pdfernhout/Twirlip2](https://github.com/pdfernhout/Twirlip2)

</comment></comment></comment><comment><USER65> Please no. Im very happy with current state of Thunderbird.

</comment><comment><USER66> They've already neglected Thunderbird for years, and now they want to start from scratch? Doesn't sound like a good idea. Sounds more like another project they will shut down after a while.

I used to use both Thunderbird and Firefox a few years ago as my main mail client and browser. Since then, Mozilla started spreading between too many projects, chasing the failed phone thing, and both Firefox and even worse Thunderbird are nowhere near where their competitors are.

I now use Google Chrome and Google Inbox (via Electron app Wavebox, formerly WMail), and they actually look from this century. I downloaded Thunderbird a few months ago out of nostalgia, and everything looks the same as 5 years ago. Pretty sad.

<comment><USER67> I think Thunderbird is fine how it is. I think a lot of the projects Mozilla takes on are stupid (Rust being a giant exception, I love Rust).

You know what I want? NWJS/Electron but using Firefox/Spidermonkey. I want to package desktop apps with Firefox. They almost had this with xulrunner but killed it for some reason. And I want them to build crosswalk ([https://crosswalk-project.org/](https://crosswalk-project.org/)) for mobile, but with Firefox. The only real reason is that I don't trust Google or anything they touch, and I've never actually been able to build Chromium/NWJS from source (such a complicated build), which worries me.

Call me paranoid, but the monoculture around Chromium creeps me out and I'd really like a viable alternative from Mozilla. Seems like they jumped ship from the packaged HTML5 desktop/mobile app paradigm _right_ when it started getting popular.

<comment><USER28> There actually was a fork of node.js that used SpiderMonkey.

IMHO, one of Mozilla's greatest failures was its decision to more or less give up on embedding (for both SpiderMonkey and Gecko). They effectively killed off embedding in the process of moving to the train model back in 2011, 2012, but back then, the expectation was that they would have their 2 years of "let's kill our broken architecture." Instead, it sort of ended up dragging on how long it would take them to stabilize some APIs for embedding, and they certainly never bothered to try to maintain any documentation (I briefly attempted to maintain some client application that used SpiderMonkey in 2011, and it was a headache trying to find any sort of documentation on how to fix each incremental bustage, since everything that was found on MDN was woefully out of date).

First, there was to be some sort of IPC-based embedding mechanism in Gecko. Then that idea was nixed in favor of just XULRunner. Then Mozilla decided it didn't want to maintain XULRunner anymore. For a period of time, they had a XULRunner-like setup called something like webapprt (which was basically a Firefox sans normal Firefox UI), but that too was killed off within a few years.

</comment></comment></comment><comment><USER68> I wish I could freeze the program Thunderbird in time to keep it precisely how it is right now for the next couple of decades. I literally want not change. I know, I know. It's a pipe dream, the surrounding environment changes, breaking the program as the OS and libraries evolve. But this constant resolving of perfectly solved problems annoys me.

<comment><USER69>
      git clone <thunderbird-url>
      <build from source and sudo make install>

^ there you go. A stable thunderbird branch that will work mostly forever. Every time an API changes just shove it in another iteration of a virtual machine :P

<comment><USER68> Thank you, I know all of that. I like native though. So, both VM and HTML5+JS are things I try to avoid for convenience messaging tools I use many times every day.

</comment></comment></comment><comment><USER70> Mozilla just doesn't get the message.... We don't want your features, fixes, refreshes, rebranding, or re-imagining. We want a browser that is fast, stable, secure, minimal, and that DOES NOT FIGHT US. Let me load my old SSL certs (a warning is fine). Let me keep my preferences (why does [https://](https://) disappear from my address bar every update, and my search bar keep switching back to case sensitive).

Stop making your problems worse and get your $#!% together! I'm a sysadmin, dangit, I need this tool to work!

<comment><USER71> So Thunderbird is moving away from legacy technology that was built to make Mozilla/Firefox more than just a browser. They are doing this to be free to improve Firefox to make it more stable, fast, secure and minimal.

This leads to a completely independent Mozilla project, Thunderbird, that relied on this technology to get the axe.

That project thus is discussing taking the difficult technical step to start from scratch while keeping the user experience the same its been for 10 years.

This, in turn, leads to you criticising Mozilla for not focusing on making their browser fast, stable and secure. Because you are hitting some configuration/update/UI bugs that seem entirely unrelated to the core browsing experience. Thunderbird, BTW, has 25 million users. So even if you don't need it, some people do.

<comment><USER70> The resource allocation decisions mozilla has been making is driving me away from their products. Throwing resources at recreating thunderbird with a new framework is a poor use of their time.

<comment><USER71> You are still not paying attention. Mozilla has decided to _not_ throw resources at Thunderbird anymore. The outcome of that is that the _community_ is debating to move away from the to be deprecated XUL platform.</comment></comment></comment></comment>


Stress-testing airplane wings - <AUTHOR> http://www.popularmechanics.com/flight/g2428/7-airplane-wing-stress-tests/ <comment><USER2> I was talking to someone in this industry, and he was lamenting the fact that there is revolving door between Boeing and the FAA, who runs these tests.

He said the consequence is that the testing is less stringent for Boeing planes than for Airbus planes, since it is often their friends (and sometimes their own design!) being tested.

You would think these tests have a fixed set of outcomes, but it turns out there is a lot of flexibility allowed by the testers. Which makes sense since they make the rules and want to make sure those Boeing planes are passing.

They justify it by saying that it's only fair since Airbus is funded by the government (not realizing how much Boeing is subsidized by the government too).

It's made me wary of flying on Boeing equipment.

<comment><USER3> Same coziness goes on with EASA certifying Airbus aircraft. And then EASA gives Boeing a harder time with this understanding. This is why countries/regions have their own aviation regulators that perform their own independent evaluations of new aircraft headed for their country. FAA certification is good within the US only. It took us six years to get EASA cert after FAA; it took our euro competitor the same time for the opposite.

</comment></comment><comment><USER4> I remember watching the documentary series on the design and making of the Boeing 777. I remember seeing this segment on how far the wings actually flexed upwards. But most of all, I remember the genius of dampening the toilet seats so they don't bang when let down. They did it because bangs and loud noises scare passengers.

If you're interested in the documentary, it's a 5 part PBS series from the 90's. You can find it on Youtube.

<comment><USER5> Another interesting thing: that documentary was part of Alan Mulally's plan to make Boeing play nice internally. [1]You can't be as nasty if there's a film crew watching.

1\. [https://books.google.com/books?id=18idhw_C4xgC&pg=PA61&lpg=P...](https://books.google.com/books?id=18idhw_C4xgC&pg=PA61&lpg=PA61&dq=mulalley+overcame+it+by+inviting+a+documentary+film+crew&source=bl&ots=cdak8gLVeJ&sig=j9HUwEi_xAzFdPYCPpdwhkQVwEA&hl=en&sa=X&ved=0ahUKEwjH_dCMlMbKAhUCKCYKHc84ByAQ6AEIHTAA#v=onepage&q=mulalley%20overcame%20it%20by%20inviting%20a%20documentary%20film%20crew&f=false) American Icon, page 61,62

</comment></comment><comment><USER6> I'm surprised at how old the footage appears to be. Goes to show that commercial flight hardware remains largely similar in the past decade or two.

<comment><USER7> New airliner _types_ are actually pretty uncommon. New _models_ of existing types happen more often, and are typically incremental improvements on the basic design, and usually do not rebuild/redesign the wings or other major flight-oriented components of the airframe.

Consider that in the past 15 years only three new types (Airbus A380 and A350, and Boeing 787) have entered service from the two major manufacturers, while the same time period has seen nine new models of pre-existing types from those manufacturers (the A320neo, the high-takeoff-weight variant of the A330, the 737-900, 747-8, 777-200LR, 777-300ER and the 787-9).

</comment></comment><comment><USER8> Being serious about reliability is not cheap.</comment>


What if I designed Windows 8 - <AUTHOR> http://zohaibsh.tumblr.com/post/60339655325/i-always-asked-myself-the-question-if-i-was-the

<comment><USER2> Actually, this is really nice work and has a better ux experience.

Would you keep the sidebars of win 8?

<comment><USER3> How can you determine that it has better UX from a screenshot?</comment></comment>


Hijacking Open ID-Enabled Accounts - <AUTHOR> http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts/

<comment><USER2> This isn't a flaw in the protocol, but rather the user management features of one particular implementation.</comment>


Trump's campaign's marketing team manipulated Reddit  to get front page - <AUTHOR> http://www.huffingtonpost.com/entry/593469a8e4b062a6ac0ad0fc <comment><USER3> > This post from The Huffington Post Contributor Platform is no longer > available on our site.

<comment><USER4> [https://archive.fo/pZ9zb](https://archive.fo/pZ9zb)

</comment></comment><comment><USER5> How is this news? It's just marketing.

I agree that the organizations doing these sorts of things should be brought to light, but it's not like this isn't business as usual for all sides - <USER2> for that matter, not limited to politics.

</comment><comment><USER6> Turned out to be fake news. I found the debunking of the story to be more relevant to HN than the story itself. Details: [http://i.magaimg.net/img/pao.png](http://i.magaimg.net/img/pao.png)</comment>


What Places Have the Worst Commutes? - <AUTHOR> http://www.slate.com/articles/news_and_politics/map_of_the_week/2013/03/longest_commutes_drive_times_by_zip_code_map.html

<comment><AUTHOR> Immediate interesting conclusion is that traffic conditions often aren't as important as average distance from workplace.</comment>


Wonderful Wikis… they are Free and they are Hosted! - <AUTHOR> http://tpgblog.com/2008/05/05/wonderful-wikis-they-are-free-and-they-are-hosted/ <comment><USER2> I use Wikispaces. They were early openid supporters and have good support for scientific content and default Creative Commons licensing, all things that are important to me. I use the regular editor since I am pretty sure the wysiwyg is not too bad.

</comment><comment><USER3> i use pbwiki. i have not found something else that has easy interface and wysiwyg editing.</comment>


"AngelList is the real deal" - <AUTHOR> http://venturehacks.com/articles/angellist-real-deal <comment><USER2> Would you use this? Could doing something like this be a turn off to other angels in the future?

<comment><USER3> Why would it be a turn off?</comment></comment>


The Steve Jobs Market Research Quote Should Rest in Peace - <AUTHOR> http://mvctest.com/the-steve-jobs-research-quote-should-rest-in-peace/ <comment><USER2> I think the "Jobs path to success" is largely misunderstood in that there is an assumption that anyone can mimic Jobs and achieve success. The problem with this line of thinking is that while it is true Job didn't rely on market research, the reason why he was able to do that he had an innate understanding of what people will like. You can't unfortunately teach that and without it, the "Jobs path" is a recipe for disaster.</comment>


Sunshine makes weather on your smartphone simple, personal and more accurate - <AUTHOR> https://thesunshine.co <comment><USER2> Seems interesting. Apple only Unfourtanetly.</comment>


Unintended Affordances (or why I believe encrypting everything is a bad idea) - <AUTHOR> http://lucumr.pocoo.org/2015/4/28/unintended-affordances/ <comment><USER2> >There is the idea that "there is no such thing as insensitive web traffic" and that the privacy of communication is absolute.

The essay seems to center on "privacy" and "hiding".

The other use for encryption is "authenticity". We want to have trust that the pixels on the desktop monitor or iPhone are actually correct. Whether a user is a city administrator looking at weather.com pixels to decide whether to shutdown schools for the day, or a grandmother looking at NYT or Yahoo pixels to check a stock price before selling, encryption helps ensure the veracity of what their eyeballs see.

Grandma doesn't care if the government or Facebook knows she read the New York Times. Someone on the subway can look over her shoulder to discover that same datapoint. On the other hand, she does need to have confidence that what she reads has not been tampered with.

One could attempt to write "data protection" protocols that send multiple hashes to verify the payload. However, if the hashes are cleartext, you're back to where you started with broken trust because the hashes can be spoofed. The necessity of encryption (without regard for hiding or privacy) appears again.

<comment><USER3> You can verify authenticity through signatures -- no need to encrypt the full body for that. The fact that there's no (widespread) general-purpose solution to sign arbitrary traffic is IMO problematic, people apparently are fine with just paying the cost of encryption.

<comment><USER2> _> You can verify authenticity through signatures -- no need to encrypt the full body for that._

If NYT or Yahoo Finance has a javascript widget to let a reader pick a stock symbol, and dynamically choose start and end points of stock performance, what "body of text" is relevant to compute a "signature"? What if the NYT has an option to dynamically translate their stories into other languages, or rotate different related stories on a sidebar? Are servers constantly regenerating thousands of signatures for all unforseen combinations of dynamic text? And how do these multiple signatures continuously travel from the server to the browser? Presumably it would be an encrypted channel because cleartext signatures would be vulnerable to tampering. Would a browser then have twin- channels (2 ports) open for the NYT page? One channel is encrypted for the signatures and the other channel is the cleartext? Why would this scheme be "better"? You still have encryption _somewhere_.

<comment><USER3> I suppose you have some encryption in this (I'm no expert), I'm only arguing against encrypting the full body, because for larger downloads, full-body encryption might cause extreme overhead (think Netflix or Steam)

<comment><USER4> Except even Netflix has recently announced they are going to be performing "Full Body" encryption on their video streams and that it was financially worth it for them to do so.

You can make value based arguments for/against pervasive encryption, but technical arguments against it continue to be debunked.

<comment><USER3> Not sure where you get the idea that anecdotes count as "technical arguments", but let's stay with the Netflix example: According to another comment in this thread, Netflix measured severe performance drops with SSL: [https://news.ycombinator.com/item?id=9465553](https://news.ycombinator.com/item?id=9465553)

<comment><USER4> Not sure how one of the largest sites on the internet with intensive bandwidth successfully implementing encryption is anecdotal. Performance drop or not, they implemented it because they find the benefits to outweigh the costs.

Netflix, and many others before them, have demonstrated it is possible to do so. Obviously there is an impact.

But many people like to immediately say, "its too resource intensive! it cant be done! its not practical". Those people are wrong. It's expensive. It may take engineers. But it can be done.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Having read the entire article, I'd say that while it's good to _consider_ the implications of encrypting all traffic (including those mentioned in the article), it's perfectly reasonable to have done so and still come to the conclusion that every single one of those implications are _entirely by design_ features, rather than bugs.

"Lawful intercept": sure, you have the right, good luck with that. We're not going to make the Internet less secure for the benefit of government interception; if anything, we're making it more secure _because_ of the possibility of government interception. This one is a very old argument, and easily debunked: assuming you allow any encryption at all, just having _less_ of it doesn't make lawful interception any easier, because of course all the illicit traffic will be encrypted. The only thing it does is make encrypted traffic seem more suspicious, which isn't good for _anyone_.

SNI works just about everywhere these days, and it's quite safe for most services to just turn it on and write off the few systems (IE on XP, and truly ancient mobile devices) that can't cope.

People don't get used to clicking certificate warnings away because browsers have gone out of their way to make that painful, and it _should_ be.

If you don't understand TLS, learn, or count on other people to have learned. That's no excuse for not using it.

There are many folks working on fixing the CA problem, but even without that completely fixed, SSL is still better than cleartext.

All that said, I do think the first section of the article, about unintended affordances (such as emergencies) is worth considering in _other_ technological contexts. That point was made years ago: [http://code-is- law.org/](http://code-is-law.org/)

<comment><USER6> > "Lawful intercept": sure, you have the right, good luck with that. We're not > going to make the Internet less secure for the benefit of government > interception; if anything, we're making it more secure because of the > possibility of government interception.

Government censorship is happening if you want it or not. The main difference is now that there is a lot more collateral damage with SSL deployed.

> If you don't understand TLS, learn, or count on other people to have > learned. That's no excuse for not using it.

I agree in the sense that anyone who runs a security critical website should deploy SSL and there is no excuse for not doing it. However what triggered the whole article was that more and more websites become completely impossible to use in the absence of SSL even for anonymous data access.

<comment><USER5> > Government censorship is happening if you want it or not. The main > difference is now that there is a lot more collateral damage with SSL > deployed.

Good. Censorship and other _attacks_ should be as noisy, obtrusive, and damaging as possible, so that we have more incentive to stop it (by both legal and technical means). Such attacks should not pass silently.

> However what triggered the whole article was that more and more websites > become completely impossible to use in the absence of SSL even for anonymous > data access.

Why do you need to use them in the absence of SSL?

Many ridiculously tiny devices still have enough power to run a simple TLS stack. And if you're really trying to access web services from some potato- powered device that can't run a TLS stack, you have much the same problems as a device that can't run a fully capable network stack at all. In either case, speak a simpler encrypted protocol (e.g. Bluetooth Low Energy, 6LoWPAN) to a local device, that can either provide the services you need or access them on your behalf.

<comment><USER7> > Good. Censorship and other _attacks_ should be as noisy, obtrusive, and > damaging as possible

Agreed. It's human nature to not bother to speak up when a group you're not a part of is attacked. If widespread encryption means that more people will be affected when governments try to censor traffic, then I'd say we have one more argument for widespread encryption. [http://hmd.org.uk/resources/poetry/first- they-came-pastor-ma...](http://hmd.org.uk/resources/poetry/first-they-came- pastor-martin-niemoller)

</comment></comment></comment></comment><comment><USER8> The author seems to be calling a lot of things effectively bugs of encryption that I see as features.

>Unfortunately, SSL prevents this. Unfortunately because it means that if a website hosts partially illegal shared content, then the whole website is down and not just the subsets of it which are legally problematic.

>But not everybody is entitled to privacy in all situations. For instance convicted criminals are not. Likewise many lawful professions need to be heavily surveyed for security.

>a pilot hid his psychological problems from his employer and intentionally caused a plane to crash.

In my view this is all valid reasons to encrypt everything. When prisoners are made such based on unjust laws, I say that anything that gives them their rights is good. Forcing a government to be very overt about its censorship of websites is good. Allowing people to hide their mental disorders in a world where a mental disorder is still seen as a moral failing is good.

Encrypting everything enforces a positive change on society. Governments have to be more open about their censorship, allowing for greater discussion. Dissidents can communicate in secret, allowing for greater freedom. Critical systems have to be built so that a single individual cannot cause a large loss of life. Groups that are required to be surveyed must directly incorporate it into their systems

As for the cost of using SSL, my understanding is that they are much overstated.

</comment><comment><USER9> I take issue with these arguments.

I respect the author but this doesn't read well reasoned.

Firstly CAs not being equipped to scale and the inevitable mistakes that will happen in a highly manual process. Thankfully this has already been resolved, we have DNS - if you are in control of DNS you are authenticated. This is is the system to be used in the EFF automated certificate issuing protocol.

As for CPU cycles we have Moore's law (which is still in full effect for things like SSL decryption). That and many many motivated engineers.

The next bit is where things get sour.

It seems the argument is because law enforcement has the "right" to read your traffic that anything you do to dissuade them will only result in further systematic destruction of privacy, i.e MITM attacks on SSL.

The final points around complexity do make some sense but those are against SSL, not against encryption IMO. SSL and TLS are both hugely complicated but this need not be the case.

As for my point of view.

We need encryption. Why? Because communication has changed.

Communication used to be manual and as such the attacks against it were manual and unable to be orchestrated at scale. Government surveillance was better understood because communication was simpler so lawmakers couldn't destroy all privacy accidentally.

Now almost all communication is digital, it's become economical to simply subvert -everyones- privacy. Lawmakers are at a loss to understand even basic computer science let alone what motivated and technically sophisticated "law enforcement" agencies can do with such massive amounts of information.

We need encryption to save privacy before it's lost forever.

<comment><USER6> > We need encryption. Why? Because communication has changed.

I never said that we don't need encryption, far form it. I said we do not need to encrypt _everything_ and I firmly stand by that. If we do want to encrypt the entirety of the internet traffic then I believe we need to consider all the consequences this causes. That was my point, not more, not less.

<comment><USER10> "I said we do not need to encrypt everything"

... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.

<comment><USER6> > ... as justified by many arguments from ignorance, like "I don't think > everyone ...", and "There is no technical reason..." over and over. Even one > counterexample for those (some helpfully supplied in comments hereabouts) > makes the arguments invalid.

I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.

<comment><USER11> Authentication and Integrity are just as much part of SSL/TLS as secrecy is. For code I'm going to run on my system, I quite like the idea that I can tell where it comes from and if it's correct.

When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.

<comment><USER6> > When it comes down to it, it's nobody else's business what python code- > modules I'm downloading, it might give them enough information to attack my > servers, so secrecy isn't a bad thing either.

There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases.

Or I'm just a bad person and would ship you bad code.

SSL does not solve that problem.

<comment><USER11> >> There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones.

This is bad practice, and is not solved by _less_ integrity and authenticity checking!

>> Or I'm just a bad person and would ship you bad code.

Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.

<comment><USER12> I'll just leave this here: [https://pypi.python.org/pypi/peep/](https://pypi.python.org/pypi/peep/). (It verifies Python package downloads against local hashes.)

<comment><USER11> That certainly helps repeatability of install, but it doesn't (so far as I can tell) help if you've been MITM'd on first download. So it's a bit like a self- signed certificate at that point.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > There is no technical reason for this unless you want to hide from someone > that you are downloading a specific Python package which seems pointless.

"Oh, I see you're downloading this package in a slightly old version that is still vulnerable. I guess you're going to install it, which means you'll be vulnerable in the next 10 mins"

This is one of the main obstacles of things like apt-p2p or debtorrent (i.e downloading your system packages in a p2p fashion): you don't wan't to tell the whole world what are the packages on your machine.

<comment><USER14> Agreed. There is a very technical reason for wanting to encrypt downloads.

There's a political reason as well: "I see you just downloaded pycrypto - we're going to throw you on a watchlist since you obviously want to hide something". This speculation is based on past actions doing this very thing with Tor.

</comment></comment><comment><USER15> > The greatest impact on user's safety would have been the development of per > user encryption for public Wifi access points. Instead what happened is that > now every larger website has to implement SSL

Assuming that, once it's off the wifi, it's _utterly unrealistic_ that an attacker could be anywhere else in the packet path? That -- even outside of ecommerce -- there's no way any icky ISP could be doing deep packet inspection to sell your data out for ads, or any virus on a cheap consumer-grade router interested in hijacking your profile to turn into a spambot? And assuming, moreover, that this New Technological Capability would be deployed in a consistent and timely fashion? Sure, I agree it'd be an excellent deterrent to many attacks on its own, but end-to-end encryption easily wins. (And if you're really an interesting "larger website" then you have the resources to make SSL happen.)

<comment><USER6> Of course the ISP could fiddle with your data. But likewise a post man could open your mail. That fiddling with data is not a crime is first and foremost a policy and law problem.

<comment><USER16> Given that encryption also solves the problem, and solves it much more reliably than policy and law ever could, how do you justify the statement that it's first and foremost a policy and law problem?

</comment></comment></comment><comment><USER11> This article takes the position the government has the right to shut down communication it dislikes and spy on communication as it sees fit, as this is legal in some places and the author does not want to get into whether or not it should be legal.

This is a fundamental disconnect with how many people on the pro-encryption side think - the government has no right to do this, regardless of the law, and therefore we will do all we can to get in the way.

>> Cryptography is black magic.

It's maths.

>> As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide

There are multiple reasons.

One might be to ensure integrity of the file, and authenticity of the source. TLS gives you this, plaintext not so much.

Another is that the more uninteresting stuff there is getting encrypted, the better, as it means it's less noteworthy.

<comment><USER17> I think you are misrepresenting the position opposed to you. My position is like this: pro-encryption people distrust government, which is fundametally mistaken position. Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption. Such policy-change-by- technology bypasses democratic process and is dangerous. Trust is human construct, so "trust math, not government" is position that is not only wrong, but also is confused.

<comment><USER11> >> Government has rightful authority justified by democratic process. Policy change should be done by democratic process, not by decree from elites using technology such as encryption.

This is demonstrably false in light of releases like Snowden's stuff. There is little to no democratic oversight, and at every turn the people are denied the knowledge of what their government is doing and are therefore denied the ability to voice any opposition.

How can you democratically oppose something if nobody will even tell you it's going on?

>> Such policy-change-by-technology bypasses democratic process and is dangerous.

Democracy is being bypassed everywhere here.

</comment></comment></comment><comment><USER18> Not a fan of this argument. It applies the small economic negatives w/o counting the value of the positives.

Pro: Democracy is more stable and more guaranteed Pro: Lower level criminals are thwarted and the cost of attacks prohibit profitability of small attacks. Pro: Increasing value of transactions are becoming possible online. No one in their right (or educated) mind would sign into a $10k+ account if their password/traffic wasnt protected.

</comment><comment><USER19> >From an economical perspective a few years ago nobody would have thought about building a SSL MITM proxy for these purposes.

sslsniff was released over a decade ago.

<comment><USER6> From my limited testing Anti-virus solutions did not start to scan SSL connections by default until last year.

<comment><USER19> There have been security appliances that have had the ability to MITM and scan SSL traffic since at least 2010.

</comment></comment></comment><comment><USER20> I like this essay, not because I agree with most of its arguments, but because it raises interesting ones. What's frustrating about it, to me, is that the main thrust seems to be "There are problems with TLS, and especially using it everywhere", which is very valid.

But then the message / proposed solution is "let's just give up on TLS except for what I arbitrarily define as important". What I would have hoped for is "let's try to make it better".

</comment><comment><USER21> Encrypting everything promotes individual agency, the freedom of an individual to communicate solely (encryption) and certainly (MAC) with whomever that individual chooses. Cryptographic protocols do not inherently cause performance or logistics complications (Resource usage, content isolation) as these are side effects of other underlying issues with the technology upon which we implement cryptography and can be fixed without compromising the security of cryptography.

The only argument against pervasive solid encryption with potential validity is external-party bypassing; where the external-party is outside the intended group of involved parties (Bob & Alice) and wishes to access or manipulate the secured communications. The most obvious situation being some external authority wishing to prevent or prosecute a crime.

Traditionally, in the US, you (and your property) have agency until a warrant, subpena, or probable cause arises. At this point, and no sooner, the acting authority suspends some part of that agency for the assumed greater good of the society and begins collecting evidence through an established process. Without this suspension of agency the authority, traditionally, cannot and should not be treating you or your property with reduced agency; the authority should not be preemptively diminishing your agency by starting that evidence collection process (compromising protections) with zero probably cause.

It is the problem and responsibility of that authority, as set out by the social contract of free agents comprising our society, to reduce agency and collect evidence AFTER probably cause arises and NOT as the default against every citizen.

</comment><comment><USER22> This article ignores the complexity of not encrypting everything.

What is the recourse for the average Joe when his social network doesn't encrypt logins? Facebook did this for years, the average user just ignored it and logged in, no amount of training or convincing could dissuade many.

What will the user interface look like for a site that is not encrypted but verified secure? It is hard enough to get people verify the lock icon is green or gold. Many ignore and just assume that online shopping is so fraught with hackers that it cannot be done safely. This will not help that situation.

Why do we care about the cost of CPU cycles? No matter how good the encryption is a human still needs to make a decision. Settling on a simple one helps the human make it faster. CPU cycles get cheaper every year but the brain hasn't improved in thousands.

Encrypting everything is simple and can be made to work even for less technical people.

<comment><USER22> As a secondary point even if don't get simplicity isn't incorrectly setup encryption, better than none? For one example: Self signed certificates don't protect you from a man in the middle perpetrated by the government or ISP, but they will stop neighbors with packet sniffers.

If we forgo simplicity I will still encrypt what I can. Having only some protection is not the same as my protection being an illusion.

</comment></comment><comment><USER23> I agree with the point about CDN's. Cloudflare is a single point of failure, that could tamper with connections to a large part of the web.

</comment><comment><USER6> In case someone reads the cached version, I added a note about my point about Wifi after it was brought up that the attacker could be the Wifi provider itself so refresh the page.

</comment><comment><USER24> An interesting read.

Perhaps he should have said "Using SSL is like using antibiotics. If everyone is using it all the time, the attackers just find ways around it that are impossible to defend against and you're screwed."

Not sure I get the analogy about having gates on the subway are bad when people need to use the subway in an emergency. Like, if you have a stab wound and are taking the subway to the hospital, its better not to have to fumble around for change in your pocket and line up for a ticket? Seems like there are actually very few or no emergencies where someone needs to ride the subway for free.

Also, I'm no SSL expert, but even if the certificate is expired and the user acknowledges the error, isn't the communication still encrypted? They don't lose the encryption just because of an expired certificate do they? I honestly don't know, but I just assumed that's how it worked.

The one thing I agree with is that the trust model for SSL is opaque to most users. I have no idea who my browsers trust by default, and I have no idea who those guys trust, and even if there is a 3rd degree of trust beyond that, and so ultimately there are thousands of people around the world who could spin up an SSL certificate that my browser would trust without question. Strange system.

<comment><USER16> > Perhaps he should have said "Using SSL is like using antibiotics. If > everyone is using it all the time, the attackers just find ways around it > that are impossible to defend against and you're screwed."

Except no such mechanism exists. If you build proper crypto, it's secure, attackers can not simply make it insecure by wishing it were.

> Also, I'm no SSL expert, but even if the certificate is expired and the user > acknowledges the error, isn't the communication still encrypted?

But it might be using a compromised key, for example. Also, one problem is people getting used to clicking "OK" on SSL warnings, which might backfire when confronted with an actual attack.

<comment><USER24> > Except no such mechanism exists. If you build proper crypto, it's secure, > attackers can not simply make it insecure by wishing it were.

It's like the XKCD cartoon.[1] The best crypto can be defeated by a wrench and a guy willing to hit you with it. Or more likely, by passing laws requiring all the major companies of the world to give the government access to the servers whenever they wish. Or by building backdoors into routers that allow them into networks.

The way to defeat good crypto is to go around it.

[1] [https://xkcd.com/538/](https://xkcd.com/538/)

</comment></comment></comment><comment><USER25> I want to point another thing: more and more ISPs are moving away network neutrality. Latest example: Verizon is injecting cookies into users request to be able track their activities and then sell gathered info to advertisers [1] I don't have problems with 3-letter agencies doing what they have to do (though, I would prefer to have proper governance over data access procedures and SSL might help there too), but ISPs should not be altering your traffic. Especially if you pay for the service. SSL prevents cookies injection.

[1] [https://www.eff.org/deeplinks/2014/11/verizon-x- uidh](https://www.eff.org/deeplinks/2014/11/verizon-x-uidh)

<comment><USER6> ISPs should most likely not be allowed by law to intercept traffic for such purposes.

</comment></comment><comment><USER26> As I understand it, your argument on a technical level is basically that SSL and the CA system as-is sucks, and I think most people would agree with that. That's something that can be fixed (at least according to djb).

On a social level, I don't find any of the arguments convincing. The positives of ensuring private communication far outweigh the negatives.

</comment><comment><USER27> So, I've upvoted the article because these are things that need to be discussed. And I don't have good answers necessarily, all I really have is a sort of counterpoint to add to the pile of confusing issues.

Consider the two-dimensional graph of difficulty of hostile interception of traffic vs. the value of hostile interception of traffic to the intercepting entity. ("Interception" including both attacking authenticity and privacy of the connection.) In the low/low side, you have, say, my blog posts. Deliberately public, of interest to pretty much nobody "official", unencrypted, unauthenticated HTTP. On the high/high side, well-encrypted inter-colo traffic between two computers owned by a bank, or perhaps an arms manufacturer.

10 years ago, this was a rich graph with lots of interesting nuances. Who even cares about the easy/easy cases? Of course the hard/hard cases justify encryption. And there's a lot of in between and useful cost/benefit analysis that could be done. I think the original article is written based on this mental conception of the landscape.

However, recently between technological advances and increased discovery about what is being done by governments (and remember, _not just_ the US government, _many_ have been caught doing things and many more are presumably getting away with things we still have not heard about) and a variety of corporations (and remember all this Superfish stuff and such _predates_ the mandatory encryption!) has revealed that the previously-rich 2D landscape really isn't 2D after. It turns out that there is no "difficulty" dimension. It's all very easy to intercept, at scale, if not downright trivial. Governments hoover (both the vacuum and as in J. Edgar) up entire fiber optic trunks. Companies and spyware get a footprint on a machine and basically nuke all SSL flat for thousands of machines or entire major corporations at a time.

In the other dimension, it has become pretty clear that even "trivial metadata" allows far more information to be exposed about someone than any but a handful of computer scientists would have believed 10 years ago [1]. Everything has a great deal more value than we thought.

The net effect of all of this is that it collapses the entire previously-two- dimensional landscape to a nearly a single point. Everything is trivial to collect, and everything leaks a shocking amount of information, and information is power.

Consequently, regardless of the fact that both answers suck in their own way, we really only have one choice: Require encryption, or not. There's no middle ground anymore. We used to have one, but it's collapsed away.

And, frankly, acknowledging everything in the original article and with the amplification that there's probably even some stuff missing that could be added, I'm pretty sure that in the end, there's still only one reasonable choice, which is the direction we're currently headed in. Yeah, it sucks. But a root cause analysis of the problem isn't that it's the encryption's fault... it's the companies, spyware, and government that have put in so very, very much effort into collapsing this landscape. Blame _them_ for the measures we have to take to protect everybody.

Though, even as you do so, bear in mind that in the rich, complex ecosystem of the Internet, parasites are ultimately inevitable, so it's also no use pretending that if we just fix the current companies and governments we could somehow change the problems. The only answer is that, yeah, we have to rewrite how the "laws of physics" of this ecosystem work. The only other alternative is the overproliferation of parasites and a resulting value collapse of the ecosystem to humanity as it becomes too untrustworthy to use for a variety of things we'd really like to use it for. (That is, I'm not claiming that the Internet would become entirely useless, but we'd really _like_ to be able to use it for important things, not just Buzzfeed and cat videos.)

[1]: [http://33bits.org/about/](http://33bits.org/about/)

<comment><USER28> This is a really interesting argument you've advanced. The chart you describe is illustrative and the changes wrought on it certainly disturbing.

Unfortunately, I think you have over-simplified a complex issue to a dichotomy (encrypt everything or nothing) that is perhaps more confusing than helpful.

Encryption is a broad and diverse subject, as well as a field of expertise (not mine). I doubt parties in the debate have axioms that align here as there are so many interpretations and levels of detail to disagree about. Put more clearly I don't think any three people reading this would agree on what you mean by encryption in your post.

If you instead said "protect" "everything" / all traffic / all data/ all browsing /... , and gave some details as to the threats you are concerned about, it might strengthen the argument you are making.

EG : "protect" the "names of sites I visit" from sousveillance ... "protect" the "integrity of software packages I download" from "evilgrade" attacks ... protect "the pseudo-anonymity" of "journalists posting to social networks" from "state sponsored malware injection" ... and so on. Encryption techniques could be (are) used against all of these problems, but in different ways.

There is a lot to discuss and try to understand in these issues. Thank you for contributing positively to the discussion ( and I hope I am as well).

</comment></comment><comment><USER29> Tell this to Github. They are being Javascript DDoSed thanks to non-encrypted connections.

And no, it's not "the same thing" if China forced baidu to do it directly, or if they made CNNIC forge an SSL cert.

</comment><comment><USER30> Nice bit of assuming the government's self-granted permissions are "rights" and then hand wringing they can't access them, there. I find myself unconvinced.

</comment><comment><USER28> Thank you for posting and discussing on HN. More discussion and more viewpoints can only help as we all struggle with these political and technical issues.

</comment><comment><USER31> > But not everybody is entitled to privacy in all situations.

Most people are entitled to privacy on the machines that they own. Having to log or monitor internet traffic is the special case, and should not be the default.

> That privacy and safety stand in a big conflict was recently quite > dramatically demonstrated when a pilot hid his psychological problems from > his employer and intentionally caused a plane to crash.

You claim a background in psychology, you should be able to recognise this as fear mongering.

> The trust there is acquired by giving someone at a specific (private!) > institution money and a copy of a passport. This system does not scale, and > the number of SSL hosts is exploding.

A technological limitation in the current state of internet crypto is not a reason to abandon the concept. Everyone agrees that the concept of a CA isn't great. Someone will solve the problem eventually.

> SSL is bloody expensive compared to not doing it.

SSL is largely implemented in hardware these days. This is no longer true.

> SSL scales really badly intentionally.

I find it hard to accept that someone sat down and designed a system to not scale intentionally. Especially hard to believe when you look at the scale of SSL deployment today.

> A big cost of encryption however is lawful interception. This is not the > place to discuss if governments should have the ability to intercept your > internet traffic or not but in many cases they have that right.

A big cost of any societal construct is law enforcement. You can make the same argument about cars, or wigs, or plastic surgery. Most of the world strives to not limit personal freedoms out of fear.

> Unfortunately because it means that if a website hosts partially illegal > shared content, then the whole website is down and not just the subsets of > it which are legally problematic.

It is up to the website owners to manage this risk, with or without encryption.

> A shocking amount of Windows users run software that MITMs SSL connections > to scan for viruses, malware etc. Even Ad providers (Superfish cough) > started to destroy SSL traffic because it became so widespread that it was > necessary. I'm firmly of the opinion that none of that would have happened > if SSL traffic was less common.

MITM is the default with unsecured traffic. Again, TLS isn't perfect, but why give up?

> To give you an example of how ridiculous our love for SSL has become: PyPI. > It's the Python package service. As of recently the Python package installer > downloads every package via SSL. Why? There is no technical reason for this > unless you want to hide from someone that you are downloading a specific > Python package which seems pointless.

NO!!!!! Package managers are a huge target! What better way to sneak malicious code into someone work than through package management traffic? TLS mitigates this! This is a situation in which a trusted connection is a must.

<comment><USER32> You need to edit this comment to add additional newlines after the quotes - your responses are otherwise merged with them.

<comment><USER31> Thanks. Updated.

</comment></comment></comment><comment><USER33> >"this system is even larger than in the past and as such slip-ups are only going to increase."

Yes, the system is certainly larger (as is the internet as a whole) and slip- ups are natural. Luckily these 'slip ups' are typically simple things like certs expiring or supporting outdated cipher suites. These are just minor configuration fixes that things like Lets Encrypt aim to fix (both distribution and configuration of TLS). The thing is, even the worst 'slip ups' don't make you any more insecure than only supporting HTTP. _Any_ amount of TLS is better than none. That is a weak argument to start with.

>"SSL is bloody expensive compared to not doing it."

No it's not. Certs are not expensive (another thing improved by Let's Encrypt). This opinion exists from people spreading these kinds of rumors. It's 2015 and the minor difference in processing power is negligible. If your web hosting can't handle the difference in processing costs, you need to look for a better hosting platform.

>"Not only does that mean that you are downloading a really big certificate, but also that the SSL encryption is a bit of a lie for you as a user."

'Really big certificate' when has this been an issue for anyone ever? A CDN providing SSL is still better than no SSL. That "lie" _still_ protects the user at their host->Local Router->ISP->CDN. This is massive value not offered via just HTTP.

>"The cost of deploying SSL should not be underestimated, and forcing SSL on people out of principle should consider that."

The cost raised by implementing SSL vs the cost of hosting a web application is negligible. It's pennies on the dollar to ensure your users can have a safer experience using your site. Security comes at a cost, this is part of life.

>"The second method is to go to the local ISP and tell them to disable access to it. The rather is the better option in the sense that it only affects the citizens of that country and it isolates the problem. Unfortunately, SSL prevents this."

Yep it's a real shame that it's harder to censor websites. Joe Shmoe the intended reader shouldn't use SSL just in case the government wants to blacklist his domain.

>"Even Ad providers (Superfish cough) started to destroy SSL traffic because it became so widespread that it was necessary. I'm firmly of the opinion that none of that would have happened if SSL traffic was less common. "

THE WHOLE REASON THESE AD PROVIDERS ARE BREAKING SSL IS BECAUSE THEY CAN NO LONGER WILLY NILLY READ/INJECT YOUR TRAFFIC. This exactly what Version + AT&T's "super cookie" was doing to HTTP traffic. SSL _prevents_ shit like this from happening. SSL being less common in no way equals less ads reading/injecting your content.

>"The greatest impact on user's safety would have been the development of per user encryption for public Wifi access points."

This exists. It's called IPSec and it's a way bigger hassle than SSL, so we all agreed in the 90's that it made more sense to prioritize SSL over IPSec.

>"Instead what happened is that now every larger website has to implement SSL to protect against the only realistic attack vector which is someone surfing at Starbucks."

This is absolutely false. I would argue the _most_ users are at risk further down the pipeline, not at Starbucks. We know for a fact that ISP's like Verizon have injected cookies into HTTP traffic leaving their networks and we know for a fact that Governments have done dragnet collections of HTTP traffic. SSL protects users at every step of their internet journey, suggesting half ass encryption is bullshit.

>"I now no longer claim I have any understanding of SSL at all."

This is the most accurate statement he makes in the entire article.

>"Cryptography is black magic."

Here in lies the problem. It's not. It's actually the opposite, it's open source and it's inner workings can be explained by a multitude of resources. The various features you call 'bugs' in SSL/TLS are things the security community has refined over many years. Crypto is hard, and a lot of things that seem intuitive are not. TLS exists in it's current state because it accomplishes what we want crypto to do. Saying "everyone fuck this thing I'm frustrated with" is counter productive to the whole process. ANY amount of SSL is better for the user than none.

>"but the truth is that the most popular cryptography library (OpenSSL) is an old and complex mess. Even if the library itself would be okay, there are so many ways to misuse it and it's really badly documented."

Oh boi let's jump on the OpenSSL hate wagon. We know OpenSSL has had it's issues and there are lots of people helping to make it better ([https://cryptoservices.github.io/…/2015/03/09/openssl- audit…](https://cryptoservices.github.io/…/2015/03/09/openssl-audit…)). The fact that OpenSSL has the occasional implementation error doesn't make the SSL/TLS protocol any worse.

>"Gone are the days where you could fully understand how a web application works."

This has gone from trying to make some kind of point to full whine fest. Yes, web applications have become complicated. So have all parts of technology. As things grow their internals become more intricate and complicated. Also gone are the days where you can fully understand the inner workings of your car engine. Doesn't mean we shouldn't use airbags.

>"As of recently the Python package installer downloads every package via SSL. Why? There is no technical reason for this unless you want to hide from someone that you are downloading a specific Python package which seems pointless."

Or you know, you don't want packages injected/swapped out with malware when you download them. If I'm downloading code I'm about to run on my system, you better be sure as hell I'm going to want to want integrity and confidentiality of said code. TLS is a standardized way of ensuring both of those things.

>"It's plenty to download the package over an untrusted connection and to then verify the checksum with one you downloaded from a secure place."

WHERE IS THIS MAGICALLY SECURE PLACE? HOW DOES ONE COMMUNICATE WITH THIS SECURE PLACE? For a guy who considers SSL to be too much effort, I'm to believe that everything he downloads is checked against checksums received via his 'secure place'</comment>


Show HN: Ultralink, the Hyperlink 2.0 - <AUTHOR> https://ultralink.me <comment><AUTHOR> Hey All,

Ultralink is a project I've been working on that aims to improve and move forward the most basic of internet grammars: the link. I have tried to figure out solutions to all the problems that hyperlinks have like staleness/broken links, overlinking, authoring/maintenance labor intensity, single resource restriction, etc. In attacking those problems, I also stumbled across a lot of other really neat features and value additions that you get when you add an abstraction layer to links.

I have made some products that are aimed at consumers, like the browser extensions and WordPress plugin that anybody can just use to kick the tires. These hook into something I call the Mainline Database which is a gigantic repository of Ultralinks meant for use in general contexts. I think of it as a kind of long-term, Wikipediaesque public service that anybody can use for free to do content analysis, public sentiment analytics or other interesting stuff.

I have also tried to make the platform as open and extensible as possible so that developers can build on top of the technology and use it in solving their own problems. I have documented many aspects of how the technology works and made some tools you can play around with on the developer site: [https://developer.ultralink.me](https://developer.ultralink.me). Feedback here would be especially useful from the Hacker News community.

I'm happy to answer any questions you might have or discuss ideas for where to take Ultralink going forward :)

</comment><comment><USER2> great work!

<comment><AUTHOR> Thanks :)</comment></comment>


Distributing a Fully Connected Neural Network Across a Cluster - <AUTHOR> http://iamtrask.github.io/2014/11/24/distributing-network/

<comment><USER2> How is this on the front page? This is a completely incoherent.

For anyone actually interested in some interesting techniques for multi-GPU DNN training, [http://arxiv.org/pdf/1404.5997v2.pdf](http://arxiv.org/pdf/1404.5997v2.pdf) and references therein are probably a good start.

<comment><AUTHOR> This also might help... here are some slides graphically showing how the distribution works. [http://prezi.com/hdctecihctdr/?utm_campaign=share&utm_medium...](http://prezi.com/hdctecihctdr/?utm_campaign=share&utm_medium=copy&rc=ex0share)

</comment></comment><comment><USER3> The exposition is not very clear. What exactly do you mean when you say "No edges will be communicated over the network, only half of the nodes."? I'm puzzled, because a few sentences later, you claim "The only network IO that would be required would be sending each edge value to its respective node in Q."; so the edge values are actually communicated?

From what I've understood, what you're suggesting is that for every node in a layer, you colocate the edge on the same machine?

<comment><AUTHOR> Precisely! I highly encourage checking out the slide-deck for a graphical representation.

For every node in every other layer, I colocate the edge on the same machine. In this way, when a group of, say, 10 nodes in layer 1 are each sending a weighted message to a single node in layer 2... they can pre-combine their messages (weighted sum) and send only that value over the network. This happens for every node in the second layer, reducing network i/o (this is the first optimization).</comment></comment>


Coolors – The super fast color schemes generator - <AUTHOR> http://coolors.co/intro/

<comment><USER2> I like color scheme generators in general because I have trouble finding novel colors that go with each other. But it's not clear to me that these are actually good combinations, or if they are, how they might be used?

Maybe you could mock up a small iconic site in css that has a nav set to one of the colors, bits of text set to others, a sidebar set to another, etc. so people can actually envision them. Just a thought.

</comment><comment><USER3> I wish that it showed the previous color scheme if I go back. As it stands I have to go back and then refresh with that URL. (firefox)

</comment><comment><USER4> It's just looping the tutorial for me, clicking 'skip tutorial' just goes back to the beginning.

(Safari on Yosemite)

<comment><USER4> FWIW: Closing and re-visiting fixed it.</comment></comment>