Why Static Websites Need HTTPS
People here are bringing up the difficulty for a regular user to set up HTTPS.<p>I want to go one further: WHY does a regular user need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain?<p>It used to be worse - you had to have your own machine or use some crappy shared hosting service. Amazon figured out that letting people share managed virtual machine instances was good savings. That’s now called “the cloud” but it’s still under the control of some landlord - Amazon, DigitalOcean, etc.<p>Let’s face it, the easiest thing we have today is some web based control panel by CPanel running on some host that charges $5&#x2F;month or something.<p>It’s 2018. Why don’t we have something like MaidSAFE and Dat working yet? We should have:<p><pre><code>  1) End to end encryption

  2) One giant, actually decentralized cloud composed of all nodes running the software

  3) Storing chunks of encrypted data using Kademlia DHT or similar

  4) Maybe even periodic churn on the back-end so you can’d find and collude with the servers hosting the chunks

  5) All underlying URLs would be non-human-readable and clients would display (possibly outdated) metadata like an icon and title (this metadata may change on the Web anyway). Storing and sharing could occur using QR codes, NFC bluetooth, Javascript variables, or anything else. For static files, the links could be content-addressable.

  6) All apps and data would be stored encrypted in the cloud and only decrypted at the edges. They would run on the clients only. Apps could also be distributed outside the cloud, but usually just via a link to a cloud URL.

  7) Communities would likewise be just regular users, rather than private enterprises running on privileged servers running some software like github is now. No more server side SaaS selling your data or epic hacks and breaches. 

  8) Users would have private&#x2F;public key pairs to auth with each community or friend. They would verify those relationships on side channels for extra security if needed (eg meet in person or deliver a code over SMS or phone). Identity and friend discovery across domains would be totally up to the user.

  9) Private keys would never leave devices and encryption keys would be rotated if a device is reported stolen by M of N of other devices.

  10) Push notifications would be done by shifting nodes at the edges, rather than by a centralized service like Apple or Google. In exchange for convenience, they can expose a user to surveillance and timing attacks.
</code></pre>
No more waiting endlessly to be “online” in order to work in a SaaS document. The default for most apps is to work offline and sync with others later.<p>No central authorities, CAs or any crap like that. Everything is peer to peer. The only “downside” is the inability to type in a URL. Instead, you can use one or more indexes (read: search engines) some of which will let you type existing URLs, or something far more user friendly than that, to get to resources.<p>Domains and encryption key generation would be so cheap that anyone can have a domain for a community of any kind, or even just for collaborating on a document.<p>There won’t any longer be a NEED for coupling domains to specific hardware somewhere, and third party private ownership&#x2F;stewardship of user-submitted content would be far less of a foregone conclusion, fixing the power imbalance we have with the feudal lords on the Internet today.<p>Once built, this can easily support any applications from cryptocurrency to any group activities, media, resources etc.<p>If you are intrigued by this architecture, and want to learn more or possibly get involved, contact greg+qbix followed by @ qbix.com - we are BUILDING IT!