Hacker News Reader

> I funded this team because they're high integrity software engineers first, and we built this out of need

I looked for the founders bio, a company contact info. There is nothing on their site. All I saw was a letter in the "About" section by the founder.

You might have gotten to know these guys after various meetings and due diligence process. There is nothing on their website that sells me on trusting them or the company.

I had to go the "Careers" section to see the location of the company.

When you're in the business of selling trust, you really need to focus on selling trust first and not technology (maybe they're connected ultimately) but I just don't feel I can trust this company based on the materials provided on their website.

Hope this feedback is meaningful.

How would material on a website provide trust, without a means to verify that information?

What other way is there? Have a button to “let the CEO call me and pinky promise me that the website info is truthful, complete and correct”? Would you believe it then?

That's obviously not what he's suggesting? He's just saying (and correct me if I'm wrong) that, for a company whose business is based in no small part on trust, it's a bit weird to not have any information about any of the people involved in the project.

While names, locations etc doesn't necessarily make something trustworthy - the absence of them do feel way more sketchy.

Hey, since you're here already, I have some questions (in case you're able/allowed to answer them):

What's the base operating system and hardware architecture the box is based on? It says "Linux" on the page but doesn't go into specifics.

Why not just use regular hardware, e.g. Intel NUCs, or even allow people to run your software on their own hardware (like OwnCloud does)?

In Germany there was/is a startup, Protonet (https://protonet.com/), that had almost the exact same idea a while ago. They went bankrupt though and one of the reasons was that it cost a ton of money to design and produce their own hardware, which also looked very cool (orange hexagon!) but didn't provide much added value beyond what a normal, boring-looking compact PC could provide (at 500 € less than their box for the same specs). They also marketed their own OS, which was based on a modified Linux distribution, modified open-source software and a shiny management layer on top as well. They found out that developing and maintaining a Linux fork isn't so easy either, so they eventually canned it. So what's different about Helm in your opinion?

We spin our own build of Linux using Yocto.

We are using an ARM-based SoC from NXP. We chose this to ensure that the device can only run signed, trusted code by implementing secure boot and signature verification of software updates. We will make a developer program available in the future.

I didn't use Protonet so I shouldn't speculate about what's similar or different about the products. I think we are in a time right now where people have a strong desire to own their data and are looking for a viable alternative to the cloud. They key, beyond building something very private and secure, is in nailing the experience and we're excited to share more about that.

Cool, thanks for sharing that info! While I think your approach is a bit extreme I hope you'll succeed, we need more solutions that put privacy, security and transparency first. It would be awesome if one could run your software on regular hardware though, as I really prefer a securely hosted server at a local data center to a computer sitting in my living room. Also, one year of limited warranty seems rather short for a product that is supposed hold my most important data.

Thanks for your encouragement! I appreciate the feedback and keep tabs on our GitHub for what we open source down the road.

We spin our own build of Linux...We are using an ARM-based SoC from NXP.

Okay, so that narrows it down to the i.MX family.

We chose this to ensure that the device can only run signed, trusted code by implementing secure boot and signature verification of software updates.

Maybe read this?

https://blog.quarkslab.com/vulnerabilities-in-high-assurance...

From the technical specs, it's almost certainly the i.MX 8, which as far as I know is not affected or listed on any of the errata for that vulnerability.

I missed the part on the tech page that listed the A72, so yeah it's an iMX8.

Hopefully the HAB fix is the reason for the 8. Otherwise this seems like overkill for the work involved.

Good guess and we looked at the i.MX but did not select that line of SoCs. We are using the Layerscape line of SoCs from NXP

You say Helm solves or will solve all these problems.

But if I don't actually need to be able to reach the box in order to use my email - if it will work even when the box is offline, powered-down, stolen, or destroyed - then what, exactly, is the point of the $500 box itself?

It's not privacy, it seems. If it were private, how could it work when the box is offline?

I'm not opposed to a "pay for your email instead of it being ad-and-surveillance-supported" model. I just don't see the point of paying $500 for a box that you're telling me the service will function just fine without.

Stolen? The data is secure - keys are stored in secure enclave, and storage is encrypted.

Down? There's continuity of service if you have a 2nd box online, and it's as easy to restore from a live backup as an iPhone from iCloud.

Email is the first app, and there will be more.

Why do I need to buy a physical box? Cant they give me a dedicated EC2 Micro instance instead? Solve the ISP issue, and the speed/ connectivity/ power etc?

It's easier to convince someone that it's securely 'theirs' with hardware than if it seems like just another cloud email service?

But then they spend a lot of time being a hardware company, no?

So? It's a necessity of establishing trust with the customers.

How about a VM that I can host at a location of my choice? On prem, ec2, or a dedi somewhere?

>if you have a 2nd box online

For $1000 I get 2 boxes I can't use for anything else right now (and still not very reliable inside my home), whereas with Fastmail (for example) I can get an email service for 20 years @ $50/yr that is very reliable. I'm not sure of the value proposition for this thing.

I like the idea as I run my own home server for about ten years now (Nextcloud (calendar, address book, file-sync), DynDNS, XMPP, NFS, IMAP, ...). At first, I thought how you are going to send emails from consumer IP-ranges, but then I read that you are using a gateway with a static IP address. Cool.

I think it is a great idea to have a device which is as simple to use as a router but focused on typical cloud services. As security is a critical aspect of the whole idea, the subscription service is a smart move too. Maybe you should offer a monthly subscription too (consumer friendly).

Are there any plans to start shipping to Europe in the near future?

Thanks for your comment! Yes - we are working on making the product available in Europe early next year. Please sign up for our mailing list on our website and we'll keep you posted!

I like the idea. But can it handle multiple domains? Also, if I put one in my brother's house, can it connect the two and use them as fail over? That will eliminate my worry about outage and backups.

I believe multiple devices are in the roadmap... I know because I ordered a 2nd one for my office so I would have self-backup and instant recovery.

For now, a single domain per server. And yes, mirroring support is coming with 2 servers so you will have the fail over that you mentioned.

If I can trust someone to do off-site cloud backups of my e-mail, why can't I trust the same person to run a Fastmail-like service so I don't have to have a $500 server in my house to get e-mail?

Because with Helm only you hold the encryption keys.

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?

Yes, this is what protonmail.com offers.

> 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.

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?

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?

https://cloud.google.com/shielded-vm/ ?

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.

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.

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?

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.

Does it matter if Helm is pushing auto-updates?

It matters as long as Helm as a company is not compromised. This is true of Apple devices too, and when pushed, they stood up.

Doesn't Helm have RCE on the device at all times? Doesn't all e-mail come in on an EC2 instance, and go out over an EC2 instance?

I don't understand why you're so upset about this. If you don't think the product is a good value for your time and money, that's fine: don't purchase it.

I think Helm comes with some obvious trade-offs, but the product looks nice and I think (judging from other HN comments) there's a market for it. I don't know if it's a large market for this to be a success, but it seems interesting at least, and at first blush the product looks well-made.

I don't think this product is exactly for me as my main email, but it could be interesting as a side email service, or one for really sensitive emails. Depending on the price point, I'd consider purchasing. If the price point is too high or the maintenance costs are too large, then I won't. What's the big deal? That trade-off not working for you or me doesn't mean the product shouldn't exist.

Because it bothers me when someone sells a "secure" product where the security measures are unrelated to the threat model. The Helm server is connected to the open Internet, which means that physical possession of the Helm server is not the only or even main thing necessary to secure it from compromise. Because of how it works, the server still has a dependency on cloud providers -- you need cloud backups and the public endpoint for the ssh tunnel to get around ISP packet sniffing. Since I still need to trust other people's servers for this to work, why the focus on owning your own server?

How would you realistically completely remove the need for the relay server while still allowing the customer to run the server on a typical home internet connection?

Flip it around: don't run the server on a typical home internet connection but instead run it in a data center.

Hey cwyers - this is a good question. Our offsite backups use keys that only a Helm customer has access to. They are created during the setup process and stored on a USB thumb drive we include in the box as well as your phone. We will be publishing how this is done using duplicity so people can see the details of how it works.

Would it be possible to elaborate more on the problems pointed out by the OP of this thread? Like clean outgoing IP? Moreover what happens exactly when the box melts? Because sooner or later some box will crash. Where will the service run in case of disaster? How long will I stay without email?