Hacker News new | past | comments | ask | show | jobs | submit login

But that's completely orthogonal to owning a piece of hardware. You could run a managed cloud e-mail service where only the users hold the encryption keys, too. How is this a hardware problem?



> You could run a managed cloud e-mail service where only the users hold the encryption keys, too. How is this a hardware problem?

This is the key question, in my mind. There's only one reason I'd want to own the hardware—to manage/add/create my own services and handle my own backups because I don't trust a company's involvement in these[0].

If this is so tightly controlled that I can't add my own services and I can't restore a backup without Helm's involvement, why do I even want the hardware?

[0] I don't mean that I don't trust them in a privacy sense. I mean that I don't trust them to make sure the backups are actually working and able to be decrypted and restored. Or be able to be restored without their software/hardware. There doesn't seem to be any transparency wrt/ these concerns.


This is a valuable and useful criticism and we're going to talk about this at our next board meeting.

How do you know who to trust? You surely have to trust someone. It feels generally true that we can trust Apple since we pay them for hardware and their ongoing business interest is in protecting their revenue streams through their hardware and iOS app store, which means you are aligned.

Generally for Helm that's a good case. That's why we charge money for this hardware and software: it aligns interest.

Free cloud services are not truly free and that's what most people seem to be OK with... but not all people.

This is the classic trade-off. Open source software you can read the code but usability suffers. For the people on HN, most people can run their own servers, but for normal people that's not an option.

Apple has managed to create a computing environment that is highly usable for normal people. This is what Helm is trying to do too.


So, we're in agreement that this sort of thing should 1) be paid for, 2) not readable by the provider, and 3) maintenance-free for the user.

I still don't understand why this is a hardware play. There are advantages to owning the hardware but none of those advantages seem to apply here.

The hardware feels like a bit of an albatross.


I don't see how we should automatically trust them because we "own" the hardware. If its not open source and able to be verified by third parties, what does it matter if we have the "keys"? $500 for proprietary hardware just seems odd considering the goal here.


How could it NOT be a hardware play? Then how else can you verify and trust that you know what code is running in some datacenter in who knows where?


It doesn't matter what code is running server side, as long as decryption happens client side and the keys are never transmitted to the server.



If you want to truly control your data, you've got to control your hardware too. See: Lavabit.


But going all the way to the end of that tradeoff is so expensive. It seems like a Helm VM would be 90% as secure and also 90% cheaper.


But with Helm, we don't control the hardware, do we?


What’s the intersection between people without the know-how to run their own servers and the people who understand what tech companies do with data well enough to feel that this is a big enough need?

In my experience, the average person doesn’t really understand what GMail or Facebook or whoever do with data or the extent of their knowledge about individuals. Even basic things like lookalike audiences or retargeting across the web regularly blow people’s minds.

I hope this project is successful, partly because that would show that people do understand these things enough to view Helm as solving an urgent need. I wonder if we’re there yet.


We use duplicity for backups so there's nothing proprietary in our approach. There will be more transparency coming in a series of technical posts about how the product works, what open source software we use, etc. Appreciate the feedback - we'll keep this in mind as we move forward.


I understand that this is a new product launch and you can't have all answers to all questions front-and-center on the website on day one. With that in mind, kudos to you and garry for being so active in these threads.

I definitely look forward to these posts!


Thanks!


One key principle for Helm is that you always hold your encryption keys to all your data— Helm and outside parties should never get access to that. So the backups are encrypted, and the Helm device itself stores your data in an encrypted fashion on its storage, and has a secure enclave such that those keys never enter user memory space.

Hosted services like protonmail (great option) support some key management but that's rare. Most everyone stores all your data in the clear, and that sets you up for Facebook-style hacks where people just steal a database en masse, and/or leave you open to warrantless wiretap which has been a problem for email services broadly in the past.

I want to point out that email is just the first part of what Helm wants to do. What is super valuable is that Helm can run its own software and add things like distributed anonymized VPN, or file sharing, and these things are all federated in a way that wasn't possible before.

Not everyone is going to care about this, but enough people should. People reading this thread should care: decentralization and federation of this sort is the way we maintain an open Internet. You can take down individual nodes but you can't take down millions of them. That's the ultimate goal of Helm.

Remember, there's no such thing as a cloud, it's just someone else's computer.


> You can take down individual nodes but you can't take down millions of them.

This statement indicates a lot of passion (and I side with it in spirit), but it feels irrelevant and out of place wrt/ this product.

My data is only (available from) my own private Helm server. If mine gets taken down, the existence of millions of other "nodes" doesn't help me. Helm the company can help me with new hardware and my backups, presuming that they're allowed to—but what if they aren't. Then we're back in the same place.


I mean, assuming we’re talking about a government trying to shut down or snoop on an email service –

They’re probably not going to go door to door confiscating millions of devices; the cost to do that would be astronomical. You’d still be at risk if they were targeting you personally, but not if they were targeting all Helm users en masse. That’s a big improvement. And even if you were targeted personally, you’d at least be in a position to defend against surreptitious snooping, assuming that took the form of agents physically entering your home to hijack the device.

Of course, there’s a lot of counterfactuals baked into that scenario. Helm does not currently have millions of users, for one. For another, the EC2-based proxy service run by Helm is a single point of failure that someone could take down, though supposedly Helm will release tools to replace it with your own server. And most problematically, the closed-source software could be silently subverted by Helm in an update, with no reasonable means for the user to detect this, even in theory.

Still, it’s a lot better on that front than most cloud email services.


Yes, this is what protonmail.com offers.


You're right. It's because devices / IOT make more sales than completely open source software - e.g. it's more valuable to invest in.


Then the keys are on the premises of the cloud company. Also data has to be at one time unencrypted in computer's memory. When there is a physical access to the computer you can't do much to ensure your data's safety.


With public key encryption, a cloud provider doesn't need your private keys to encrypt data that can be only viewed by you—they need your public key.

In the parent, the private keys are not on the premises of the cloud company.


I may not understand how things work, but how can a SMTP server function without private keys? How can it pass the hand shake? Does parent describes different scenario?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: