doc-golix

'm not [1] the only [2] person (and, since I'm effectively 100% unknown, I'm far, FAR from the most prominent, who is arguably Bruce Schneier [3]) to criticize PGP, but at the core of it, even ignoring substantial usability issues, have you ever tried to forward a PGP message? It's sort-of possible, if you re-encrypt and re-sign everything, but it's certainly not practical and definitely not scalable. Sharing and re-sharing is the cornerstone of much of the social internet, and PGP renders it effectively impossible. Keybase has a really, really cool body of work surrounding "connect this PGP key to this physical identity", but unfortunately PGP keys are only one in a small subset of cryptographic identities, which is itself an even smaller subset of digital identities in general. I get why they've done it this way; the alternative is to write your own cryptographic protocol that nobody is using, which is a much riskier thing (speaking from experience [4]). But at the end of the day, all of Keybase hinges around using PGP (or a PGP-like approach), and I'm very skeptical that's a viable solution to the social problems we have today. [1] https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2] https://moxie.org/blog/gpg-and-me/ [3] https://www.schneier.com/blog/archives/2015/11/testing_the_u... [4] https://github.com/Muterra/doc-golix

ely impossible to buy "dumb". Every analysis and meta-analysis of IoT that I've seen has been incredibly bullish on it, and I think that's an indication of how much economic incentive there is for it. Given that, I'd say automobile ECIs are the proof in the pudding for the assertion that IoT will be unavoidably ubiquitous. As an experiment, try to find a new car that you can personally can actually buy, that doesn't have a computer in it. As the median Western consumer, that's not possible. So I'm pretty convinced that for IoT, non-participation will not remain an option. So then the question is, what do we do about those 5 issues? I tend to look at stuff like this from an economic perspective; clearly device producers haven't seen enough market pressure to give a shit about any of them. Right now, the only pressure device creators are demonstrating is a profound push to get something, anything, to market. It really is an internet of shit. That being said, even the bare minimum is really hard here. You're talking about a system architecture that our existing infrastructure simply isn't cut out to handle. Think about the challenges involved in deploying a reliable authentication system to a web-scale application, and now imagine doing it in a way that can't necessarily rely upon a central server. It's far easier to just "punt" on the second half of that, assume the traditional web paradigm (trusted third party server), and call it a day. And make no mistake, for a commercial device, authentication is absolutely required, even for home WiFi network: not everyone wants every person in their house to control, for example, their locks. Or, alternatively, imagine an AirBNB host being forced to give their guests unfettered access to their IoT vibrator (yes, they exist). These edge cases are everywhere, and they make authentication of some sort or another an absolute requirement. My hope is that someone (and by someone, in all honesty I'm talking about my own project [1]) can come along and say to device producers: 1. I understand how hard it is for you to make any IoT device. 2. I'm going to make it substantially cheaper for you to do that, but... 3. The privacy and security I've baked into my system is inseparable from your economic benefit as a device producer. The idea is to evolve that into: 4. You cannot be competitive in the IoT marketplace without privacy and security. At this point, with how completely and totally horrendous the industry has been in these areas so far, I think that's the only viable way we can achieve those goals without a tremendous amount of growing pains. [1] The project is called Hypergolix, and at this point it's basically "Dropbox for Python objects, geared towards IoT, with an emphasis on social, and secured via end-to-end encryption". We're in the process of getting a private alpha shippable, to be followed soon by a public alpha. It all works, and it's all open source, but there's some necessary stuff we need to iron out in the coming weeks. Our outdated landing page is https://hypergolix.com, but a better preview of the developer experience is on our very incomplete docs page: http://pyhgx.readthedocs.io/en/latest/index.html . The whole project is backed by a crypto protocol known as Golix: https://github.com/Muterra/doc-golix

). Ideals are great, but privacy is mostly only a secondary market concern. Hypergolix is built on top of Golix, with the goal of presenting a compelling economic argument for using the protocol. Put plainly; IoT development is a pain in the ass, and Hypergolix substantially decreases time to market for developing new applications. In the short term, I'm focusing on the Raspberry Pi, Beaglebone, etc. I'm happy to answer any questions and looking forward to the feedback. If you think the project is worthwhile, please consider contributing to our OpenCollective! Some more information: https://opencollective.com/golix (for monetary support; also backers will have access to a private pre-alpha release) https://github.com/Muterra/doc-golix (protocol documentation; includes a security whitepaper) https://github.com/Muterra/py_golix (protocol implementation) https://hypergolix.com/ (join the mailing list) https://github.com/Muterra/py_hypergolix (full Hypergolix source code)

e-to-many) control over sharing. That can be enforced cryptographically. It would be nice if that same protocol also had a consensus algorithm for data deletion, so we could avoid this whole "right to be forgotten" vs "free speech" debate. There is at least one example of such a protocol. I know, because I'm the one developing it [1], and I've been incredibly frustrated at how difficult it's been to build awareness, because my name isn't, for example, Richard Stallman. [1a] https://github.com/Muterra/doc-muse [1b] https://www.youtube.com/watch?v=W3wFU4VIhww [1c] https://www.indiegogo.com/projects/ethyr-modern-encrypted-em...

avascript to look for unique browser identifiers 2. XSS, CSRF, etc 3. Legitimate cross-site communication So clearly our existing solution to the "how do you securely execute dynamic, untrusted code" problem isn't cutting it. There's a lot of research (and production code, for the record) going into potentially better approaches though, so I think it's likely we'll see change, if we can get past the inertia behind today's hairball. [1] Incidentally this is exactly the approach we're taking with implementations of the Muse protocol (https://github.com/Muterra/doc-muse), which uses encryption to provide private content/sharing/identity management on untrusted servers.

pable of eventual decentralization [1], doesn't that imply heavy use of cryptography? I can't imagine a digital network where you can create privacy (and therefore agency) any other way. And yet clearly, government entities like the FBI are publicly railing against encryption as a useful tool for terrorists and criminals. Plenty of people, myself included, find this policy debate to be frighteningly under-informed, but if your goal is to avoid government attention to maximize the chances for success, it's not our opinion that matters, it's the FBI's. So I think think this kind of friction is unavoidable, implying the smart money is on people who can cleverly minimize its impact. [1] On a related note, I'm working on exactly this problem, at a protocol level. If you're curious, check out our documentation repo https://github.com/Muterra/doc-muse

And different organizations will have different requirements for trust: for example your bank is going to have very different requirements to "name" your account than, say, Facebook. Informally I've called this the difference between identity authentication vs identity verification, but I know that's not ideal terminology -- does anyone have a better suggestion? [1] https://github.com/Muterra/doc-muse

er determine what data is acquired, stored, shared, etc. If this mischaracterizes any of the above protocols, I would be really grateful for corrections. It's to everyone's benefit to understand the high-level technical details of these projects. However, the system architecture described above is not, in my mind, a tenable approach to distributable social applications. Simply put, this kind of "private server as my digital avatar" + "protocol so avatars can talk" paradigm completely misses the appropriate choice of abstractions and division of concerns for social applications. First and foremost, this is still yet another example of "privacy by promise". It just so happens that the promise is given to you by the servers of whomever you're sharing with. But then, as data is decrypted at rest, you must also trust their coding ability, their deployment ability, their... this gets very messy, very quickly. The security footprint for implementing these protocols is immense. Secondly, this approach focuses on one specific use case: websites. The vast majority of publicly-networked applications will, at some point, have a need to perform identity, sharing, or content management. However, they may not necessarily have anything to do with text: for example, a distributed sensor network might communicate only using binary messages, but that doesn't make it any less social. Since bytes are the more basic unit, any general-purpose social protocol should therefore support them natively. A much more robust approach is to address the "social protocol" at a much lower level: to provide only the bare minimum that any social application will need, giving transport-layer bytestreams cryptographically-enforced privacy with many-to-many capability. Only then can you escape requiring everyone to operate their own web service, which is, I firmly believe, an unrealistic goal. [1] https://github.com/Muterra/doc-muse [2] https://raw.githubusercontent.com/tent/tent.io/master/source... [3] https://github.com/bartekrutkowski/hubzilla/blob/master/exam... [4] https://wiki.diasporafoundation.org/Federation_protocol_over...