And it makes sense to me that a business would leverage that data in ways to benefit themselves.

Big fat nope on that one. This is exactly what the GDPR is about. I’m giving you my data for a specific purpose, and unless I tell you otherwise, you have no fucking business using that data for anything else. Gonna be interesting to see how this one plays out in the EU.

It’s a way to verify that an app, or any package of data really, actually comes from the source you’re expecting it to.

It’s based on some clever math, but basically, an app developer has two very large numbers that share a certain mathematical relationship, but if you only know one of them, it’s extremely hard to calculate the other one. One of those numbers (the private key) they keep securely to themselves, the other number (the public key) they publish permanently for everyone to see.

Now when the releases an app or an update to it, they put both the app and their private key into a special formula, which produces a new big number, called the “signature”. Then, they publish both the app and the signature to the play store.

Now, when your app store sees an update of the app, it won’t just blindly trust it, but first check that it’s actually legit, so that it doesn’t accidentally install a virus or something. To do that, it downloads the app and the signature, and puts them into another special function, together with the public key that was used to sign the version of the app that you currently have installed. Now the clever part is, because of the special mathematical relationship between the public key and the private key, this function can check whether the signature was in fact produced by combining the app with the private key of the developer, without actually having to know that private key. This way, it can now be sure that this app update is actually coming from the original developer - unless they have been compromised and their private key leaked.

So, technically, saying “it has the same signature” is not quite correct. The signature changes with every update. The thing that’s the same and allows to install the update is the key being used to generate the signature.

This I very close to how (asymmetrically) encrypted messaging works, btw. If you have a key pair like above, you can encrypt a message with one of the keys in a way that it’s only decryptable with the other one. This way you can have people send you encrypted messages without anyone else knowing the encryption key, not even the sender of the message.

I’m a little worried about this too… With 1Password, I’m fine with having a master password I can remember, since I know it’s only useful to an attacker if they also have access to one of my devices, or know my Secret Key. That means that a targeted, high-effort attack is necessary to get in. Proton Pass just being protected by a single password makes it way easier to run remote attacks.

someone who knows more about security

Not sure if I qualify for that, but just logically, there’s only really a difference if you are not planning on storing your email password in your password manager anyway. If you do that, it doesn’t really matter that you have the same password for both, since if your password manager is compromised, your email is just as compromised.

But, and it’s a big “but”, that’s assuming you’re using a cloud-based password manager that only requires a single master password to get into. My point of reference here is 1Password, where that’s not enough - you also need a device with which you have logged in before, or you need your long, unmemorable Secret Key in addition to your password. You cannot log into 1Password on a new device with just your master password, the way that it appears to be possible with Proton.