We are a transparent company.
And we want you to understand the design choices, threat models, and systems architecture we used.
We have a team of experienced Cyber Security Experts committed to building strong tools
We are a well funded venture backed startup of 11. Our investors include Y Combinator, Lightbank, Aquiline, Haystack, and other established funds. We have included bios on our backend and devops engineers for reference.
Han Wang is a Captain in the Army Reserves Cyber Operations Group and holds a Master’s in Computational Mathematics and Engineering from Stanford. Han has worked at Lawrence Livermore National Laboratory and DARPA and Han was the Officer in Charge of an US Army cyber team while deployed in Iraq and the Middle-East in 2016. The team assessed computer and network infrastructure for security weaknesses across 13 bases in 7 countries. Furthermore, Han was sent to South Korea to act as Cyber Liaison between US Forces Korea and the Republic of Korea’s Joint Chief of Staff during 2017 Ulchi Freedom Guardian Exercise, ultimately missing YC’s demo day.
Josh Silver was previously at Riverbed and F5. At Riverbed, he focused on network equipment quality assurance. Josh verified network and transport security behavior over multiple models of Riverbed SteelHeads SaaS. At F5 he worked on the team that maintained the daemon responsible for communicating with network HSMs over PKCS11. This daemon controlled key creation, encryption, decryption, and signing with network HSMs.
Joe Rouvier was the senior devOps engineer for the Neumob CDN network (acquired by CloudFlare). He also created and managed the Neumob SSL Certificate Authority to provide content distribution over HTTPS. Prior to Neumob, Joe was the Senior Site Reliability Engineer at Bitcasa where he created and maintained a database wrapper library which transparently handles encrypted and non-encrypted database without requiring knowledge of encryption keys.
We do not salt or hash passwords.
In our current codebase, we do not salt or hash or store user provided passwords. We do use AES 256 with your supplied Paladin password + padding to encrypt any username and password you supply us. We do not store your password in plaintext or in a form able to decrypt your data anywhere in our servers. This is why we ask you to supply it every time your browser restarts.
We do not use Mersenne Twister for cryptography.
We only use AES256 and CryptoJS (the best in class Javascript encryption library) for encryption and decryption.
We do use the Chance.js library which depends on Mersenne Twister as a PRNG (Pseudo random number generator) for random sampling to generate strong passwords.
We do not read unencrypted data that passes through our network infrastructure.
Since the web is going the way of HTTPS, we made sure our traffic analysis algorithms are able to function on both HTTP or HTTPS. To that end, we make our traffic filtering decisions based on source/destination IP, destination domain name, and DNS records of source/destination domain. These data points are available for both HTTP and HTTPS traffic and we do not treat one different from the other when making network filtering decisions.
If we go down, your internet does not stop.
We load a 4 byte file from an Amazon S3 bucket we control every 10 seconds to ensure you’re able to communicate through our servers. If our servers are down, we disable our TLS traffic tunnel and your connection goes direct to the internet. This is a standard approach also used by Google. Ref:
https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
We do not ever store any of your emails when we analyze them for phishing.
When you open an email in the browser, we send the message Id of the email to our Firebase Cloud Function backend. We pull the message from Google/Microsoft with the OAuth credentials previously given, analyze the email and send the results back to you. We then purge the email from memory and nothing is stored.
We do not have loose API keys in the source code.
The Firebase and other client side keys you see in our Chrome extension are there by design as this is recommended practice by Google. See: https://firebase.google.com/docs/web/setup#add_firebase_to_your_app
We are not an an ad blocker though we defend against malicious ads.
We are not an ad-blocker. However, any malware delivered through an ad network will be blocked when they communicate to/from an attacker controlled server. If you’re looking for an adblocker, we recommend you choose from the great selection available in the Chrome store.
Our cross-site protection works.
We use the XSS, https://www.npmjs.com/package/xss, Javascript library to protect against URL based cross-site scripting. This well tested library is trusted by over 14,000 developer every week.
Steps we are taking to demonstrate our accountability:
- Always remain transparent in our dealings with our users, the press, and partners
- Initiating software audits and pen-testing. We will be releasing the findings as soon as they’re available
- Make ourselves available 24/7 to address the concerns of our users, press, partners and the public
If our goal is to make cyber protection easy for everyone, then we are duty bound to be transparent, accountable, and provide as much context to anyone who asks as possible (without raising security risks) in order to avoid the spread of misinformation.
We are here to make Cyber Protection Easy, not more complicated.
