nmgsd

You can't forge a JWT without stealing the private key of the valid JWT signer.

You can steal a JWT token the same way you can steal a session token.

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 highlights a major issue with ALL messaging apps, namely that the provider owns the clients AND the backend.

Distributed open-source clients that use end-2-end encryption over third party messaging channels is the future of secure messaging.

VPN people, VPN

It depends what the API is supposed to do of course.

A cool way to circumvent the keyword filtering: www.seecret.io

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.

See https://www.seecret.io

of course he does.

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.

You can always assume this.

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....

This is 100% false. Can confirm.

I have never once attended an all-hands meeting that couldn't have been an email instead.

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.

Let's hope they at least hashed their passwords correctly.

-- "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.

For high value targets yes, they can't really be safe but for avoiding mass surveillance it's good.

can anyone confirm this is legit?

Suprising to no one.

You had me at "planners"

To be fair this is a criticism of Javascript package and library tooling rather than Javascript itself.

No-password access can be pretty good for enterprise but just not realistic for consumers (yet). This humorous take on it actually does a pretty good job of explaining the user-experience reasons.

Accurate. Can confirm.