The issue becomes very difficult when you need to preserve message history reliably and allow account usage across devices. Because key management becomes tricky and clunky and there's no easy UX ways around it.
For ephemeral messaging like a SnapChat type use case, you can EASILY provide p2p encrypted. For services like Telegram and FacebookMessenger, their feature list requires cross device syncing, historical archiving, and those features don't play well with rotating keys, perfect forward secrecy, and other e2e encrypted messaging techniques.
I agree strongly with you that the direction to be taken is independent messaging clients for existing messaging channels as long as those channels allow third party API use.
What channel would you use to share the keys on FB? The Facebook API simply will not let you do that anymore. Direct messages have a character limit and you can't just post to someone's wall anymore.
I tried working on something like this for seecret.io but was confounded by the Facebook API's limitations.
Twitter is much better for that. Probably other network too.
This is why you should never trust proprietary secure messaging solutions that offer you both the client and the channel.
The future of trusted secure messaging will be open source, auditable, independent non-native clients that connect and send over third party message channels independently.
One option is to store the files in Amazon S3 and only serve them over cloudfront signed URLs. There's ways to lock down the S3 access so that only a few Very Important tech leadership folks can get to it.
From the article:"But take a closer look at that list and you can quickly see that all of these various behaviors could be described by one simple, everyday phrase: You're in trouble if your employee starts phoning it in."
This may be pretty obvious but it's not quite the terrible analysis of relying on just #4.
Are you perhaps thinking of JQuery UI? The core JQuery lib is still used. And for basic front end dev it really does offer most of the utility you'll look for in other libs.
1. Get and manipulate dom elements.
2. Register simple event handlers
3. Ajax calls that are simple (frankly all other ajax-ish APIs I've ever seen pretty much copy the design and approach of the JQuery one).
Also a pretty big ecosystem of simple highly focused add-ons. You (still) can get a long way with just JQuery
The App Store run by a central authority with complete control over what can even be available and the ability to modify the delivery at their own whim is certainly a big issue in terms of trusting the integrity of the apps running on a device.
Most interview processes are a real disservice to the interviewee AND the company.
Typically, the team manager will just have his team members all interview the candidate. They will have no prep, no guidance, nothing. Just "interview this person and tell me your decision".
No one asks the candidate any questions relevant to the actual work the candidate will be expected to do on the job. It's mostly sorting algorithms and trick questions about regex etc. All stuff they encountered in CS101 and in THEIR interview 2 months before....
A lot of these answers are pointing out the x-browser complexity which is true but that isn't what drives JS package mgmt. It's mostly Node stuff. The mature common JS libs for browser work are pretty robust when it comes to x-browser stuff now days.
For browser work, you can do almost everything you need with some jQuery, handlebars and moment if there are dates. A few other small libs here and there and you've got almost everything covered. Some edge cases may drive you to use some library that is heavily dependent on 32 different sub-libs but it's really not that often.
Server-side Node.js is the issue, not browser compatibility.
-- "Open source software and decentralization is nice and all but to become a mobile app it'll have to be compiled and run on a closed platform and will almost certainly use APIs of that platform." --
That's not necessarily true. End to end encryption doesn't need to be a compiled mobile app or send messages over a closed platform.
We built a decentralized, open source, freely distributable, browser-based Twitter client utilizing end-to-end encryption at www.seecret.io specifically to address that.
You can steal a JWT token the same way you can steal a session token.