MEGAChat now includes end-to-end encryption
mega.nz
mega.nz
> Then we plan to launch a 'Whisper Mode' for additional protection when in instant messaging sessions (e.g. message transcript/order consistency, delivery assurance, forward secrecy, and some others).
This is what I was working on at MEGA, but recently they decided to stop funding me, and I'm under the strong impression that nobody else there is working on this. So it's unclear that they have a concrete time frame for it.
The source code and docs are here though:
https://github.com/meganz/mpenc_js https://github.com/meganz/mpenc_doc https://docs.mega.nz/chat/mpenc/
If anyone wants to continue funding this work, feel free to drop me a line.
If you're looking for actually secure communication that runs as a Web app, my startup Cyph (cyph.com) is the only option that exists. This is because we put in the time to build it correctly; the root page of our application is a permanently pinned (TOFU) bootstrap that validates/executes signed application packages, and the scheme to accomplish this was rigorously vetted in a 12-day audit.
Edits:
* Here's how it works: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...
* Here's Cure53's audit report: http://cyph.team/cure53report
Vetted by whom? It would help build trust if there was a public report on the strength of your implementation available somewhere.
(That link contains a page of additional context to explain the findings, e.g. some were pre-production.)
If you could post a link explaining how this tech works, I would be very interested in reading about it...
That having been said, my cofounder and I are the only two people with the keys to sign releases (and as long Cyph exists they'll only ever be held by either ourselves or an equally small set of individuals deemed worthy to trust with our lives) — so you shouldn't ever expect that kind of deliberate backdoor, even if I end up in prison for refusing. We're also maintaining a strong focus on OpSec of these keys, e.g. we're about to migrate the release signing off of our (full disk encrypted) personal laptops to a dedicated air gapped environment.
As far as how the tech works, we don't have a great explanation on the website yet, so this reddit comment will have to do for now: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp.... There's also a visualisation in http://cyph.team/producthandout, if that's helpful.
As for opsec on keys... the only thing making key extraction remotely difficult by a state actor is probably some form of hsm - but recalling the xbox 1 crack, I don't know how well even those stand up in practice. For everything else, I assume you're just a sneak-and-peak warrant and some cameras/listening-devices away from sharing your passphrase.
Don't get me wrong, I think it's great that people are working on secure chat applications. I just think one needs to be very careful making claims that end up on the side of being secure against state actors.
Also agreed on all other counts; if all else failed, I have no doubt that a state actor could certainly extract our keys through targeted physical surveillance and/or force, which I don't think there's really a good workaround for short of raising our own army to protect a private bunker for air gapped release signing.
What this first iteration of the air gapped environment is meant to accomplish is to simply make it that much harder. Sure, the CIA can still probably break into my home and set up a surveillance camera to steal the encryption passwords of my keys without my noticing, but what they will no longer be able to do is steal them by tampering with my laptop while my head's turned in broad daylight.
As Cyph continues to grow as a company, we expect to have the resources to implement increasingly sophisticated OpSec measures.
From the actual conclusion: "Cyph claims to provide security from a broad range of cryptographic attacks"
Whats the deal here?
The thinking there was that there wasn't a good way to quote any single part of the report without introducing unnecessary and/or fishy ellipses, because although the point of the rest of the conclusion is that it confirms the claim made by Cyph, there wasn't a readily available standalone sentence in there which could go on the front page.
Background: I advised Cyph on AppSec topics on behalf of Mach37 as a mentor, and I helped coordinate the Cure53 pentest. I'm the one who sourced the quote.
Give me a few moments (or days; we'll see) for me to find a good way to publicly and non-repudiably present the exact source of the quote.
Edit:
Signed statement: http://pastebin.com/HcL5bneg
Key: https://keybase.io/cure53
Hat tip to Mario (https://twitter.com/0x6d6172696f)
This stuff has to work. The adversary for secure messaging is world governments. If all you're worried about is criminals, Gchat will do a fine job of protecting you. For a vivid example of what I'm talking about, see the Telegram/Iran fiasco.
It's hard enough building secure messaging in a native application; there are lots of details that are not easy to get right (as Cure53 demonstrated to your team).
Bluntly: I feel that it's irresponsible to add to that portfolio of difficulties the added attack surface of content-controlled Javascript.
The reason people build services like this is that users will prefer them to (more secure) native app alternatives. It's easy to see why. The common response to this observation is: "but users won't install an app". They won't install an app because people keep luring the away with insecure web-page based secure messengers.
I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually makes a web application safer for this use compared to creating a native application on the basis that if the native application is exploited, all user-mode data is now at risk. At least with the containment of the browser, the only things at risk are (potentially) your messages assuming successful XSS.
So long as the proper mitigations are in place, it really makes no difference. The largest future improvement for Cyph in the future would be to incorporate one of the CSP2 changes for more safely allowing inlining, notably hash-src. However, since CSP2 adoption isn't all that widespread quite yet, it's better to hold off until the implementation details between the largest browsers are equalized.
Edit to address your last paragraph: "[Users] won't install an app because people keep luring the away with insecure web-page based secure messengers."
Native encrypted messaging apps have been around for a while and haven't really caught on unless integrated into existing apps a la iMessage. That's where the need for in-browser apps is coming from.
My 2 cents. I'm likely entirely wrong; you've got more experience in general AppSec than I do, so my assumption of risks here might be off-base.
If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page.
For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.
All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics.
I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said...
> and today, they need to install software to do [address serious adversaries].
I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration.
Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.
Not interested in this argument, sorry.
> Not interested in this argument, sorry.
You shouldn't have started it then.
So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app?
The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way.
Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).
Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint:
b2b90c80626b1ba036bd87abc0741e1c69d2f6da398018de00b52a3cb9fe2121
Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail.
This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.
As for the rest of it: I'm sorry you feel that way, but I've reached a point in my message-boarding career where, after many, many years of fighting the good (then marginal then tedious then bad) fight, I'm just not going to litigate this issue anymore. What you're doing is now is a bad idea, and for the sake of your users I think you should port to a browser extension (and, eventually, to a native mobile app) as soon as you possibly can. Maybe you can improve your security before your popularity gets out of hand and avoid the fate Telegram seems to be falling into.
When new web standards make browser crypto viable, I'll acknowledge them. Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
Chrome extensions are HTML5/JS... which wouldn't stand to your own argument.
> Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
You're saying IE6 and Firefox 1.0 were better for cryptography than our environment today? We've got effective standards like CSP and CSP2 for restricting code execution client side, SRI for validating resources hosted beyond trust boundaries, HPKP and HSTS for ensuring trust on TLS connections, and we have cooperation between major browser vendors to implement patterns like HSTS preloading and even certificate preloading for certain sites such as Twitter, environment sandboxing introduced as early as 2007, and your assertion is that the browser environment now is less hospitable to cryptography than in 2005?
You were right a few comments ago; there's no point debating this any further. I have to do some shoveling anyway.
The mic drop at the end of your comment would have been more dramatic had you been replying to a comment addressed to you.
As far as Mario's statement, while you're correct that it doesn't explicitly compare WebSign with installing a native app, it was made in the context of a threat model that assumed that level of security. This is why the one WebSign bypass exploit they found[1] was flagged as High — in any other Web app it would simply be a given that the server can serve new code.
re: browser extensions, what WebSign provides is comparable, except without sacrificing the security benefits of the restricted privilege set of a standard Web context. (i.e. A vuln in Cyph wouldn't put more than just your browser tab at risk.)
---
1: This was immediately fixed, and then the HPKP rotation scheme Cure53 came up with was soon added on top of that fix.
I'm asking explicitly because, since you still maintain that the extension model is objectively more secure, at least one of us is clearly missing something very important.
While our audit demonstrates that this scheme shouldn't be expected to be cracked without a critical vulnerability making its way into your browser, it does introduce some odd dependency relationships that certainly introduce new attack vectors not seen in the TOFU property of regular standalone apps.
For example, given that the NSA can be assumed to be indiscriminately passively logging all HTTPS traffic, imagine that one day they gain the capability to break 4096-bit RSA: in a targeted attack scenario, suddenly they can now go back through their traffic logs, find whichever public key is pinned in a particular Cyph user's browser, compute the associated private key, and undo method #2 as descried in the linked reddit comment (the "permanent offline" trick), which gets them half of the way toward completely breaking that user's TOFU.
That having been said, I consider it a perfectly acceptable and pretty neat solution to the problem. Is there something else you're seeing that makes you object to it?
Edit: If your objection isn't to WebSign but to the Web / JS as an execution environment in general, I'll throw in a link to this note on how we're mitigating those traditional risks while also benefitting from the sophisticated sandboxing of modern browsers: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...
Breaking WebSign would require defeating TLS public key pinning (which is a security feature), thanks to the technique that an email I just received so perfectly referred to as "HPKP suicide".
Again: I just think this is a bad idea. I'm sure you're great people, but cryptographic security is hard enough for native apps, without trying to deploy it in the jungle gym of some random browser runtime.
You should stop deploying this app from a web page. Altogether. And soon. Port it instead to be a Chrome extension that users install.
I'm sure you're not hurting anyone right now. But you've built the kind of application that will, if it ever gets to be very successful, probably get people hurt. Better instead to work on something that will help people more as it gets more popular.
No, you aren't; the example was to illustrate an entirely different point.
Again: I just think this is a bad idea. I'm sure you're great people, but cryptographic security is hard enough for native apps, without trying to deploy it in the jungle gym of some random browser runtime.
Do you have a specific criticism, or is your argument more of a general point that solving multiple hard problems is more difficult to do correctly?
If that is what you're getting at, it seems like it would be effectively addressed by frequent audits of the Cyph source code.
But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!".
It's great that you paid for an audit, but audits aren't magic feathers. If you got audited again by a strong team, they'd find other things you missed. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! Crypto is hard even on the "easy" setting. You've got the difficulty setting dialed all the way to "nightmare".
Dial it back down.
What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript?
I'm aware that asm.js isn't literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is vastly different from a project like Cryptocat.
As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces!
It was an accident, in pre-production code. (And hardly "nightmare"-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn't obviously exploitable.) That was also the only bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not.
The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod.
This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we'd been using if Castle turned out to be unfit for production.
---
1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated/no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.
I agree with you about web crypto, but I disagree with this point. A point that Roger Dingledine (of Tor fame) made a few years ago was that people who are going to say something which their government doesn't want them to say are going to say it anyway. If they can't communicate using the internet, they are willing to make protests in the streets, to shout and scream to try to improve their world. The job of people making cryptosystems to try to keep such activists safe is to minimise risk and do the best they can. You shouldn't think that you're responsible for what happens to those people, you're doing the best you can for them. But at the end of the day, they are willing to die for their goals and it is disrespectful to ignore that fact.
But yes, I agree that the service in question probably needs much more work. And it should probably say "this is still Alpha".
I'm also not sure where you get the impression that Cyph is currently at an "alpha" stage, but I'm going to have to disagree with you there too. Do you have more specific feedback, and/or did you run into a bug while using it?
Cyph of course runs in a mobile browser but unless I missed something, it doesn't support notifications, which are important. Is there any chance of Cyph supporting push notifications on mobile devices in the future?
However, native mobile apps are definitely on the roadmap.
I'm sure that these solutions are a lot more secure than completely unprotected alternatives, but am I wrong in assuming that if you want secure and private communications, the following principles must be met at the least?
* The protocol used must be open, standardized and implementable by others
* Widely endorsed by cryptography experts
* An implementation must be available and developed as free and open source software
* End-to-end encryption is used for the contents of the conversations, private keys do not leave the user's computing device
* The protocol must not have any technological barriers that prevent an implementation from working on any modern operating system (i.e., a phone number is not required)
* The protocol must allow for a complete communications network (clients and servers) to be implemented without the need for centralised third-party services
(The last point probably implies federation.)
For e-mail, OpenPGP meets these requirements. For chat, XMPP has Off-The-Record messaging.
Some of the above points are hostile towards any party that creates secure communications tools with the intent of growing a large user base for economic purposes. Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principles — for anyone betting on creating the next WhatsApp in one of the mobile walled gardens embracing the whole list means risking losing your potential advertising eyeballs to alternatives.
Of course, there is also the matter of infrastructure. A lot of people expect to be able to use these tools for free, but that implies that someone is paying for the hosting of (relay) servers.
OpenPGP is impossible for most email users to get working correctly.
Remember that most people don't even know the difference between CC and BCC.
Here's an example of de-anonymising anonymous messages, supossedly from clueful users: https://ritter.vg/blog-deanonymizing_amm.html
Difficult perhaps, certainly not impossible, and quite feasible if someone helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for everyone; only for those who understand how to use the technology properly.
I mention OpenPGP and XMPP OTR because they are examples of open standards that do fulfil the principles outlined above. That is, to illustrate that it is certainly not impossible or infeasible to create such a technology. What is missing is a technology that does that, and allows anyone (regardless of technological prowess) to use them safely. It is a tough problem though.
In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity -> Modify -> Cryptography, change my signing and encryption keys (and it supports PGP or MIME) and then, since I don't already have keys, need to open Kleopatra, the KDE GPG client.
Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file -> new certificate to make one. Its a wizard, so you go step by step, setting up a password for the cert along the way. You also make a revoke cert you save somewhere.
Once you made the key, you need to export it to the server. And you probably want to make a signing and encryption key, since if you got this far you are already a super techy nerd and that is what makes my point right there.
If you want normal people to be able to use gpg in kmail, there needs to be a wizard just like the "add account wizard" called "Setup GPG" that searches for keys that match your email address first in case you already have them and if there are none generates you new ones and just asks you for the password. It handles the propagation and importing of keys itself because thats not something a user should be dealing with unless they need to.
And even that is unlikely to happen - you want the GPG setup to really be a part of the first-start of Kmail process. Like the first time you open the program and get the "add account" button you should also get "setup security".
But even if you can get people making keys, the UX sucks because it makes them enter a password every time you send an email. You should be able to do what kwallet recently did, and bind the unlock key to your GPG keys to your user session so that when you enter the desktop via SDDM it unlocks your GPG keys just like it unlocks your wallet. Then people can use secure email whenever they want without any bullshit.
There are even more UX nightmares - getting your keys across different computers, easily revoking them if they get compromised, even knowing what that means.
By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use OTR" button and if your chat partner does the same it automagically generates and shares the keys, no user interaction required. The only downside is that you don't get local logging of your OTR conversations - that should definitely be an option, maybe even encrypt them with your kwallet keys! Eh, eh?
But these kind of UX nightmares keep secure communications from being a thing. Mumble is literally the best security solution I have, because I can get a letsencrypt cert, run my own server, put on a password, and anyone chatting on it has perfect security in voice and text - the whole thing is encrypted, I can do my own trust network based off my x509 cert, and it even supports pinned users so nobody can impersonate anyone else.
But I say that its the best because for anyone I invite, they literally just need to enter the password I give them to my server. Sure, its problematic to give them the password if you don't have a secure communication link beforehand, but I guess thats what OTR is for! Oh drat...
The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and encryption key based off your password, backs it up on their server (remember, its password protected, they cannot access it despite backing it up) and then whenever you sign in on other device your keys are downloaded and just work.
This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
And I worry even that is too complicated for my grandmother to be willing to put up with to stop the NSA from reading her emails.
> This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
Or you could carry your keys around with you on a physical smart device that communicates over usb or nfc. This ux already seems to work well in corporate environments, it's just a matter of convincing consumers it's worthwhile and vendors to bake support into their products.
However Mumble is not a valid comparison, because Mumble is not End-to-End encrypted. The security of Mumble amounts to an encrypted connection to the server, protected by a password; from this POV Mumble is no more secure than Facebook or Hacker News.
"You're browsing without Javascript! If you have no idea what that means, you should ask your technical friend about it. Otherwise - kudos."
No, kudos to you. I could count on one hand the number of times I have been congratulated by one of these capability detection messages for browsing without Javascript.
Perhaps the combination of federation and OTA can be given an impressive sounding name, a nice logo and a foundation (everything needs a foundation). Then the name/logo can show up on feature lists. People love features...
I use Signal right now (from Moxie Marlinspike/Whisper Systems) and would only really consider alternatives if they were endorsed by other cryptographers I know because I really just don't have a strong enough grasp of how all the machinery interacts.
However, the NEWER versions of Signal requires access to your contact to work.
For many users that is a show stopper.
Implement a way for user to search by User ID and allow user to find each other by ID in addition to phone number.
Tried just now. It does require it and doesn't work without it.
Sorry!
Signal requires access to your
contacts. We do not store your
contacts on our servers.
[Give access]A well-designed encrypted chat-protocol should work on any modern networked computing device, not just smartphones or computing devices linked to a smartphone.
I realize that phone numbers are probably hashed before being sent, with only local contact data being displayed, but it has people concerned nonetheless. It starts to err more towards convenience, ease of use, and network building above security.
Ricochet uses Tor hidden services to anonymise your social graph, which is something you don't do with Signal (not to mention that Signal does identity key lookups with phone numbers). I'm not sure there's a low-latency way to do VOIP anonymously. The best method I know of is to literally record and send audio files, which have a few seconds of latency.
If there isn't a good answer to key management, or my key is handled by JS, then it's a no-go for me.
If there is a half-way decent answer to key management, I ask what the threat vectors the system was designed for are. If a broad political statement is made, then I walk away.
While it doesn't actually vet the technical merit of the code, I feel it catches a lot of funniness.
The problem with key management is that everyone tries to solve the management problem with a single solution. A single method will always have to make choices about the threat model, which can only truly be known by the user. A single user can even have more than one threat model, depending on what they are doing.
What we need instead is some sort of configurable layer that allows the user to specify how keys should be managed by selecting what they want to trust.
They could use a default delegation to a public trust root (the PKI model, no configuration needed) for most things. Receiving a call from the bank could instead be authenticated with the key they got when they physically walked into the local branch. Chat with their immediate friends who can exchange keys on their phone when they meet up in person is easy, and a web of trust can extend that to a friend-of-a-friend. People understand the concept of vouching for someone, and over time more than one method can be used to cross-check.
Key management shouldn't be "PKI vs web-of-trust vs out-of-band-keybase-style vs manual-key-exchange vs ..."; it should be "all of the above, with the chain-of-trust exposed". Anything else is making assumptions about what the user's current needs.
Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right?
Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with?
/sorry for hijacking ;)
(Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library?
Googling reproducible builds mainly gets you Debian info, not a general description of the issue
For example:
- compiler version used
- date / timestamps at the time of compile
- build id's
We control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.
http://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-me...
When I want secure chat, I use Signal from WhisperSystems. Yeah it has usability issues, but it's obvious it's hard to do really secure and secret chat.
http://www.forbes.com/sites/andygreenberg/2013/04/17/where-k...
Not mentioned in the article is his involvement in the AT&T calling card fraud conspiracy (estimated losses $20 million) in the early '90's. It is that case that put him on the US Secret Service's radar and he's been on it ever since.
Of course, you still have the problem of deploying a secure application within the attack surface minefield of a web browser, but that's a separate issue.
[0]: https://docs.google.com/document/d/1PGS50eZB9Ud7wVKmrc0HU_FD...
So: my recommendation is, never use any secure messaging system that boots off a web page. No matter what they claim to do to mitigate the risk.
I'm actually, for a bunch of specific reasons, not super comfortable with browser extension applications either. But at least the browser tries to protect an extension you have to explicitly install and explicitly run.