Proton Mail, the leading privacy-focused email service, is making its first foray into blockchain technology with Key Transparency, which will allow users to verify email addresses. From a report: In an interview with Fortune, CEO and founder Andy Yen made clear that although the new feature uses blockchain, the key technology...
But it’s not public. It’s a private blockchain. The immutable ledger aspect only matters if everyone can see the ledger. Otherwise we take at face value all of the things you said. Assume they run one node and that one node is compromised by a malicious actor. The system fails. Extend it to a limited number of nodes all controlled by SREs and assume an SRE is compromised (this kind of spearphishing is very common). The system fails again.
Sure, you can creatively figure out a way to manage the risks I’ve mentioned and others I haven’t thought of. The core issue, that it’s not public, still remains. If I’m supposed to trust Proton telling me the person I’m emailing is not the NSA pretending to be that person (as the Proton CEO suggested), I need to trust their verification system.
Yen said Proton might move the feature to a public blockchain
I’m not interested until it’s public. Additionally, building out the chain then dropping it to rebuild a new public one is rewriting history, which violates the whole “immutable” part of “immutable ledger.”
… which gives a timing attack and the ability for bad actors to impersonate someone. I agree with you that, once public, this is a good idea. You cannot convince me that this is a good idea if done privately because there is no way to trust but verify, especially in the highly sensitive contexts they want trust in.
If it’s not public, I won’t trust it. You trust it blindly because it’s in beta. We’re not going to come to an agreement over these mutually exclusive positions.
A fork assumes the old chain continues to exist instead of being completely replaced. Without insight into the chain, which is we can’t have until it’s public, you can’t make any guarantees of immutability.
Put differently, I’ve got a revolutionary new financial encryption system. It can safely act as the middleware between you and any vendor. You can trust me with your credit card numbers because of my years experience and industry clout. You can’t see my system and I won’t do a PCI audit because it’s in beta. You can totally trust me though.
Your only response to valid criticism about the lack of verification is pointing to the state of development as if that magically washes away all of the criticism. It doesn’t.
While I do have many tinfoil hats, basic fucking trust measures do not require me to pull them out. This is cryptography 101 shit not anything complicated.
You don’t understand basic trust relationships. I don’t really care about your opinion. I already called out that your blind trust in beta software conflicts with my security fundamentals so we’re at an impasse. Once you understand why validation is important or can show why a critical component of trust architecture is somehow not necessary, I’d be happy to be happy to reconsider your opinion.
It doesn’t matter what the tech is, if you can’t audit it, you can’t trust it.
Also a single private blockchain owner is just a blackbox data store, not a blockchain. I’ve already explained how it’s vulnerable to very simple attacks, much less the complicated attacks that will be thrown at something like this.
Untestable security claims for sensitive information are useless. I’m a huge fan of Proton and I’m excited to test this but only once the blockchain is public. Until then there is no way to verify the trust so there is no trust.
If you disagree, I might have something for you. I’ve got the strongest financial encryption known to man on top of the best transit system ever that makes it super easy to do stuff. It’s all based on blockchain, of course. Just give me your credit card info and bank details. It’s in beta so I won’t let you audit it, but unless you’re shilling you don’t have a problem with that.
Yeah I guess I missed the part where security fundamentals weren’t supposed to be a part of a secure product. Do you mind explaining how a product centered on trust can be developed without trust? I think that would really help me understand why you think repeating the word “beta” allows a security-focused company to sidestep normal foundational components.
I don’t think we read the same article. We’re talking about a product those goal is secure verification of identity, correct? Something all about security?
I’m okay with people using burner email addresses to get my free content, I just need to be able to filter them out of my list so it doesn’t drive up bounces and hurt deliverability.
AWS SES, for example, is fucking rabid about bounces. Being able to filter out addresses you know are going to bounce is pretty important.
Can a list like this be used for anti-privacy measures? Absolutely! Does that mean we should never create lists like this? For me that depends on whether or not you think we should prevent encryption because bad actors can use it for bad purposes.
The beauty of open source code is that you can fork this project and add that. The repo maintainer seems to have a simple litmus test for whether or not something should be on the list: is it something that will cause a bounce for email distribution? That’s a really subjective test so you kinda have to talk to the repo maintainer about answering it. I suspect they feed it into a library, perhaps one of the ones linked, for use with their platform, so their problem is most likely solved.
You’re getting into very sketchy territory by saying a dev who is using a public GitHub repo to solve their problems needs to take it down because of how others are abusing it. Should the original dev be punished by their email provider because they shouldn’t be allowed to use this? Should anything that has potential harm be required to be a private repo? Who gets to decide all of that?
In the interest of specifics, can you point to where this specific list has done harm? I spent a fair amount of time looking around to make sure I wasn’t going out on a limb for someone with neutral views.
So you’re lumping this resource into a bucket with other resources that were malicious but you have no direct connection from this resource to harm you claim it causes? You’re saying a dev using this list to allow people to download free content but prune emails to save his bounce rate is doing bad things and needs to convert their FOSS use-case to yours?
Who gets to decide? You didn’t answer that and in the interest of good faith I’ll pull that one down as the important one since it follows from the argument I feel you’re making.
The biggest reason not to use a single account like this is that you lose everything if you lose the owning account. It’s bad advice to say you should absolutely do one or the other. It’s good advice to consider the risks.
Do I use an aliasing service that allows me to change the account emails point to? Yes. Can I access those accounts with access to my email? Yes.
The issue here is that if you lose access to social network that logs you into those things, you lose the account. If you have an actual account, not delegated access, you can still access the account with the social account.
I’m struggling to find some good article examples because Google is rolling out inactive account deletion and that’s polluting my search results. So go test this out yourself: go try to change the account name/email, password, or MFA for any of those accounts you use social auth for. Try figure out how you would log into without that social account. Next do the same thing with an account you don’t use social auth for.
In theory, my email only serves as a way to verify me and spam me. A good account may require an email for communication and should allow that email to be changed without losing the account, in the same way the good account will let me change the password, the MFA, and ideally even the username (looking at you Steam). Same as a phone number. We’re beginning to see a move toward that flexibility. Most accounts with MFA allow it.
Sometimes people genuinely don’t know correct syntax. If you’re going to call that a shortcoming, you’re an ignorant walnut. Intellectual superiority is a shitty way to pretend to be better than someone else. It often incorrectly assumes everyone types the same language with the same proficiency which is a very provincial assumption.
What about infrastructure costs? Are you comfortable making someone else pay for your access? What about the design and implementation of the API? Should all software be free?
Please note that I’m not trying to support this decision at all. I personally feel like API access is similar to SSO for enterprise stuff (check out sso.tax). I also feel like there should be some level of compensation and even profit so people can focus on building stuff like this. It’s really hard to define what that is, especially without transparent costs, which I don’t believe OpenSubtitles shares? Also they use super predatory ads so I don’t think they have any high ground to even suggest what I’m talking about.
Proton Mail CEO Calls New Address Verification Feature 'Blockchain in a Very Pure Form' (tech.slashdot.org)
Proton Mail, the leading privacy-focused email service, is making its first foray into blockchain technology with Key Transparency, which will allow users to verify email addresses. From a report: In an interview with Fortune, CEO and founder Andy Yen made clear that although the new feature uses blockchain, the key technology...
Proton domains blocked as disposable in disposable filter (github.com)
I hope it is a way to solve this…
Why you should never use Facebook or Google to log in to third party websites - what to do instead (tilvids.com)
I know You! (lemmy.world)
So Kissinger must have had use to someone? What did he do right and for who?
It stands to reason he must have been doing something right to have stayed so close to the halls of power....
OpenSubtitles.org is shutting down it's previous API. Now only authenticated access allowed. (blog.opensubtitles.com)