Theres some interesting security ideas you could try to solve with something like this. With an open source service that is hosted by someone else, you never know what is actually running. You can't trust it.

I was thinking about something similar a few months back, and I think it could be doable. You'd need a CI service that creates reproducible builds, and a hosting service that can show what build artifact is currently loaded. You'd allow the public to view the state of the service. I think it could work with heroku or similar.

That gets me closer to: I trust the code, and I trust the hosting service (I.E. AWS), but I don't need to trust the person running the code as I can verify that it matches what's on GitHub.

This—the ability to audit what's running on the backend you're talking to—is in large part what people get out of smart contracts on e.g. Ethereum. You can take the contract source code from GitHub, compile it (deterministically), and validate that the deployed-on-chain smart-contract binary is the same. The blockchain nature of the platform then ensures that the contract will do exactly and only what you "expect" it to do (i.e. it'll do the same thing "in production" that it does when you test it on your own machine, since any node that tries to execute the code differently would diverge its state from the consensus, and be ignored.)

In essence, a Turing-complete smart-contract blockchain is a deterministically-trustworthy compute-hosting service. It's one that has the disadvantage of all the overhead distributed auditability requires; but at least has the advantage (compared to centralized compute-hosting with remote-attestation) that it already exists and is usable right now for real-world use-cases.

(And you can also reduce the blockchain-y overhead by moving whatever backend business logic you can out of the "trust kernel" into untrusted regular machines, and then just having the "trust kernel" do the important stuff. CryptoKitties is a good example of this: the only thing their smart contract does is track who owns what kitty, because that's what people would try to dispute by forging transactions. The rest of the stuff is state in a regular centralized RDBMS, because it's dictated by the service, rather than by user input, and so is not under dispute.)

Ethereum is basically one big cloud computer, with a shared runtime.

Everyone gets a copy of the code AND all the data/state, and can execute all instructions.

Problem is that it’s too slow/expensive to do anything useful.

But perhaps the killer app for blockchain is buried somewhere in this concept.

Just because you dont understand how to do something useful using ethereum doesnt mean that no one knows how to do something useful with ethereum.

Please investigate ethereum name system(ENS) and Handshake name system.

> The ... host guarantees...

This is a really hard problem with "solutions" that usually run counter to privacy and, you know, controlling the machine consuming your electricity. Remote Attestation has come a long way, but (at least on Linux) still in its infancy.

First time I hear about "Remote Attestation", got any trusted sources/resources for someone to read up on it more? (besides Wikipedia and it's sources)

Here's some words Red Hat folks wrote[0] about Keylime[1][2], "open source scalable trust system harnessing TPM Technology,"[3] written in python and rust, originally created within MIT Lincoln Labs.[4] It leverages TMP 1.2 and 2.0[5] and also involves/includes/references code from Intel[6] and Cloudflare[7].

[0] https://next.redhat.com/2019/06/25/keylime-using-tpm-to-secu...

[1] https://keylime.dev/

[2] https://www.youtube.com/watch?v=Qhr_aVBCZPw

[3] https://github.com/keylime/keylime

[4] https://www.ll.mit.edu/news/laboratory-staff-develop-new-cyb...

[5] https://github.com/tpm2-software

[6] https://www.intel.com/content/www/us/en/architecture-and-tec...

[7] https://github.com/cloudflare/cfssl

Well, you could try googling for DRM, same beast different name.

This comment seems needlessly user-hostile, much like the same DRM you are railing against.

True true, wasn't meant to be hostile but I see that I wrote my comment unkindly.

I do think the point stands though. They are names for the same technology. How it is used, and who uses it will determine what type of spin I'd put on it.

Monitoring the integrity of a trusted audio decoder in my system's kernel: DRM

Monitoring the integrity of an open source tool that I bought and paid for: remote attestation.

Both will come down to various arrangements of trusted computing enclaves, asymmetric cryptography and groups trying to bypass said arrangements.

I couldn’t agree more. DRM is just hardware and software. It’s a tool and implementations matter. HDCP is one of those implementations that seem like a good idea but which have all kinds of side effects that make the product the DRM is part of (HDMI in this case) much less useful for certain fair use law abiding use cases. As long as we have the interoperability exception for breaking DRM there’s a way around but it would be better if interoperability was a requirement of accessibility standards in the first place.

Agreed, something like "Netlify for virtual machines" would be useful.

You could probably get close by auto-deploying from GitHub Actions but you wouldn't get the main benefit of a service like that (having ops done in a clean way without having to think much about it).

Without having any experience in the field, aren't lambda functions supposed to provide something like that?

Sorry I'm not getting the main value prop from this. I'm mainly an ops person. Can you please explain what that service would look like?

Netlify (primarily) takes a git repo containing a program to generate a static site and turns that into a live running website that automatically updates when the generator repo changes. You don't have to think about configuration or security or updates and you don't have to maintain a server.

Ideally this would be a service with the same ergonomics but the outcome isn't a hosted static website but a machine (somewhere in the cloud) running whatever the user wants. "Tedious" tasks like hardening, monitoring and upgrading (and redeploys) would be handled by the service provider, as opposed to the user.

For people who like doing ops this might not sound appealing but developers (especially single devs and small teams) often just wanna focus on their app, not their ops, even more so when it comes to continous maintenance.

Addendum: I think Laravel has some of this covered in their ecosystem with tools like Forge and Envoyer. But I've never tried any of them so I can't judge.

This is what Platform-as-a-service (PAAS) is and has been around for a long time. Google's Appengine, Heroku, and many others offer it.

Since then we've seen "serverless" or functions-as-a-service (FAAS) which is just smaller bits of code (down to a single javascript function) but the same concept of everything else being managed by the provider. This is AWS Lambda, Cloudflare Workers, Google Cloud Functions, etc.

The latest offerings now take a Dockerfile or container image that you build, which means you can run anything on any stack while the provider manages the rest. Google Cloud Run, AWS Fargate, Azure Container Instances, Fly.io, Zeit Now, etc.

Have you heard of platform as a service, like Heroku or gigalixr? That's exactly what that is, pretty much.

Oh so that's what that is! I always thought Heroku was just more expensive VPSes.

The host would prove that the source available online is the exact same code running on the instance, so you know that it wasn't modified by the developer/bad-guy before it went into production.

What you are describing is almost exactly how Codius is envisioned to work. Our company is actively working on this right now and it is close to being in an alpha/beta state.

Checkout codius.org

You should really look into GitLab. It's free to self-host the whole thing if you want, and there's a full CI/CD pipeline (you can plug whatever you want in there).

It's miles and leaps beyond what GitHub offers (different target I suppose).

You'd still have to code the linking to a wallet part, but that's definitely doable.

The GP poster's point was that the hosting service needs to prove to the consumers of the app that what's running on the hosting service is the same code they can browse through on GitHub.

When you're both the developer and the consumer, you can certainly prove this to yourself (to five nines of confidence or so) by just setting up the hosting yourself. But we're talking about the case of a centralized backend for a multiuser service, e.g. a forum, where the users want to not have to trust the moral fibre of the person who set up the server, but merely trust that the infrastructure used in the hosting guarantees that it can't run anything other than the codebase (that they control.)

Fair point, I overlooked this. My mistake.

Different target, yet again.

Checkout Binderhub - https://binderhub.readthedocs.io/en/latest/