wowana.me
website source
commit 8faa8498f96d5e3fe0bdf5773c4c5a584c013e3a parent 86a02cec41ad1b9ad36bb648d98f07b9d52f688d Author: opal hart <opal@wowana.me> Date: Fri, 26 Jun 2020 07:59:03 +0000 blog: backfill with old posts (finally) Diffstat:
| A | src/blog/decentralisation---lets-start-with-messaging.md | | | 191 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | src/blog/tls-certificates.md | | | 104 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| A | src/blog/update.md | | | 7 | +++++++ |
| A | src/blog/welcome-why-ill-give-blogging-another-try.md | | | 46 | ++++++++++++++++++++++++++++++++++++++++++++++ |
4 files changed, 348 insertions(+), 0 deletions(-)
diff --git a/src/blog/decentralisation---lets-start-with-messaging.md b/src/blog/decentralisation---lets-start-with-messaging.md @@ -0,0 +1,191 @@ +# decentralisation - let's start with messaging +<!--[time 201712050619.04]--> + +in lieu of the recent net neutrality talk, a mesh networking project +started out of 4chan /g/ in hopes of building a better, open internet. I +have always been interested in decentralisation, distribution, and +peer-to-peer mesh, so I set up [a wiki](https://mesh.gentoo.today/) to +aid in collaborationm, to showcase helpful documentation for new users, +and to connect ourselves with other meshnet projects around the globe +such as [sudomesh](https://sudoroom.org/wiki/Mesh) and +[/r/darknetplan](https://reddit.com/r/darknetplan). best of luck to /g/ +and to the other groups in achieving this goal for an improved internet. + +I currently cannot contribute to the physical network itself, as I do +not have the appropriate hardware, nor am I in any close proximity to +anyone who would be interested in forming a local mesh with me. but I +can still think about what could be the best software and protocols to +use as replacements for current proprietary, trust-based systems. one of +those things is messaging. + +currently we have instant messaging such as Facebook Messenger, XMPP, +and SMS; group messaging such as IRC, Slack, and Discord; voice chat +such as telephony, Mumble, TeamSpeak, Skype; forums, Reddit, +imageboards, NNTP; and E-mail. and of those, I personally want people to +contact me over XMPP, E-mail, IRC, or SMS. that means I have four +addresses I can offer someone and I have to rely on the assumption that +the other person uses at least one of those protocols. already, this is +a hassle, right? all these protocols and products offer certain +solutions to issues in other protocols, so we're spread thin, and either +we have to use them all or we have to cut ties with the people we want +to contact. on top of that, we have several contact lists to keep up +with, and overall it's just one big complication. + +## comparison + +first off, why do we have so many protocols? what do they perform +differently? why do people stick with them? I'll try to explain what +sets each platform apart from the rest so we can gather an idea of what +people want. + +for messaging: SMS, XMPP, social networks +(Facebook/Hangouts/AIM/Yahoo!), Discord, matrix.org, IRC, and other +services such as WhatsApp are prevalent. SMS has origins from the phone +network as a result of the rise of mobile phones, and now that many +people have a phone number, it's no surprise why SMS is also in common +use: everyone has it and it's practically free. social network and +proprietary IM services have been around for ages, and people might +stick with them because they've had accounts since the initial craze and +because with some of them they can maintain a relative level of +anonymity, since they don't have to use their phone number unlike SMS. +or, they might stick with them because almost everyone today has a +Facebook or Google account for social networking or mail, so as with +SMS, <q>everyone has it and it's practically free</q>. + +with IRC we see the introduction of easy-to-join group chats, as well as +the idea of ephemeral identities. IRC is a simple yet robust protocol +that allowed anyone to join with very little barrier to entry, choose +whatever nick they want, and either join channels or talk in private +queries with friends. because of its simplicity, it has achieved +widespread adoption by the FOSS community, by governments and +businesses, and by hobby groups. it has also been used as the backbone +for several popular services such as Twitch and Pesterchum. + +XMPP, Discord, and matrix.org all come about at different times, but +they all have a common theme: they allow easier use on multiple devices. +XMPP and Matrix also have protocols for end-to-end encryption, and +Discord has the added benefit of voice (and now video) chat. they are +essentially the <q>next level up</q> of IRC, although they all cause as +many issues as they try to fix. XMPP is poorly implemented, and because +it uses (nonconformant) XML for its stream protocol, we see few people +willing to actually create their own clients (as opposed to something +like IRC where I can make a rudimentary client in my sleep if I wanted). +there are so many XMPP extensions (see the <abbr title="XMPP Extension +Protocol">XEP</abbr>) and because of this, each client is more than +likely only going to support their own portion of the available XEPs, +creating a gradual divide between clients and essentially devolving the +entire protocol to its bare basics, removing any perceived benefit it +has over other simpler protocols such as IRC. Discord is proprietary, +there are no plans to allow for privately-hosted infrastructure, there +are no plans to open the Discord protocol, and apparently there are no +plans even to fix most of the bugs regarding usability as well (at +least, they haven't replied to my E-mails with anything hopeful yet). +and then there's the new player, Matrix, which aims to become a +federated (like XMPP) protocol with group chat (like IRC), message +history (like Slack), and encryption (with +[double-ratcheting](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm)). +too bad Matrix's implementations are slow and buggy, the specification +relies on HTTPS and JSON (arguably not the best choice if you're signing +and encrypting messages, or if you're sending any binary data because it +all gets base64-encoded), and the whole air of it has a hint of +unprofessionalism to me. they seem to value UX features such as in their +official client, Riot, over security and performance fixes. + +---- + +for voice, the contenders are thinner: telephony, Skype, TeamSpeak, +Mumble, Google Voice, and Discord. like SMS, telephony should be obvious +-- it was the first real thing to come out that let people communicate +verbally over long distances. Skype is the most famous to offer voice +and video chat, albeit as a proprietary service, but since it pretty +much popularised this, it is still in wide use today. while Skype used +to be peer-to-peer, Microsoft bought it out and now the infrastructure +is centralised, which brings us to TeamSpeak: a client/server VoIP +application targeted to gamers. however, TeamSpeak is proprietary just +as Skype is, so up next is Mumble which is a libre, open standard for +VoIP that sadly has less exposure in the gaming community than the +alternatives. Google Voice is in use because, again, people have Google +accounts and it's essentially one-click to get a VoIP phone number +through them. I mentioned Discord's popularity for voice earlier; it +claims to be a direct competitor to Skype and TeamSpeak so its goal is +to keep on the competitive edge against those two. + +---- + +for forums: NNTP/USENET, BBSes, software such as phpBB, imageboards, and +Reddit. this is pretty much laid out in chronological order, and for the +most part it's a natural progression (USENET was out first, before the +Internet, and everyone used it for communication and filesharing; BBSes +were an answer to dial-up modems since they were text-only with limited +graphics and filesharing capabilities; conventional forums from the rise +of the WWW, where everyone wanted their home on the Internet). +imageboards are set apart by their anonymity and ephemerality, while +Reddit pretty much replaces the need for forum communities by allowing +everyone to have a subreddit regarding their own topic or interest, with +the added bonus (or misfeature, you decide) of being able to vote on +submissions and comments. + +---- + +and then of course, we have a need for electronic mail. so far E-mail is +the de-facto answer for this; most online services require one to have a +working address in order to register or perform any sort of transaction. +Bitmessage and I2P-Bote (among others) exist as well, but at this point +they're only used by enthusiasts, and they each have their own issues. + +## culture + +all of these platforms have their own communities, and with these, +cultures were born. everyone has their own memes and inside jokes, +related either to members of the community or to the platforms +themselves. this creates a form of attachment and nostalgia around the +platforms, which is another reason people will stick with any given +medium even well after it has <q>died out</q>, decreased in popularity, +been obsoleted by another objectively better platform. + +if we want progression, we're going to have to set the belief aside that +our community will die out with the medium. the two are realistically +disjointed and we should treat it as such. + +## so, what's the issue? + +as I have mentioned, we have so many communication platforms, resulting +in so many addresses to manage, and each with their fair share of issues +(IRC and XMPP are growing less standard between clients as features are +added; Discord, Skype, Google, Facebook, et cetera are proprietary and +when they die, the whole platform dies -- they aren't sustainable; phone +and SMS are not secure at all and have severe limitations due to the +dependence on the phoneline (and increasingly cellular radio) networks. +most of these don't have decent standards for message signing, +encryption, and secure transport. some of these have spam issues, or +compatibility issues, or UX issues, or scalability issues, or moderation +issues; the list goes on, really. + +## what's the fix? + +I've been thinking for a while that we would probably best benefit from +a protocol which is conceptually sound: required baseline of security, +required open standard, required decentralisation so there is no single +point of failure, forward compatibility with future advancements in +crypto and transport, et cetera. right now I think I've written enough +about this, but I will surely update when I solidify some of my ideas +toward an ideal communication platform that will aim to fix the issues I +see with existing platforms. right now I believe in a +<q>registration-but-not-registration</q> system where anyone can join, +automatically have a keypair generated for them that will be used as +their handle, so they can chat without worrying too much about coming up +with passwords or verifying E-mail addresses or whatever. I want to keep +mobile devices in mind; I personally want something I can bring up once +on all my devices and have the same message history, same chatrooms and +queries, same state overall. I don't want to tell people that I'm +unavailable on one platform because I'm on my phone or whatever; this +shouldn't be something I need to worry about. I shouldn't need to tack a +PGP or OTR key or a TLS certificate on top of everything else; the chat +should be secured and verifiable out of the box. + +for a forum platform, I'm not entirely sure yet; I have been focused on +IM, conference, voice, and mail for now. I want those four things +together, all using one address, all using similar high-grade open +encryption schematics, all using reliable redundant decentralised +infrastructure. I want a mix of all the good from the other platforms, +and I want it to be easy to use and adopt. diff --git a/src/blog/tls-certificates.md b/src/blog/tls-certificates.md @@ -0,0 +1,104 @@ +# TLS certificates +<!--[time 201712051236.50]--> + +[two blog posts in one week, but this was on my mind today so I figured +I'd publish it now] + +another thing I wrote back in 2016: + +> I use self-signed certificates for all TLS-enabled servers I set up. I +> know there are freely-available certificates being handed out by +> authorities, and I know that Let's Encrypt exists. I do not refrain +> from requesting a CA-signed certificate because I am too lazy to do +> so; if I wanted, I would ready a CSR right away and get that taken +> care of. There is only one key reason I abstain from getting my +> certificate signed by a root signing authority: they are too +> centralised. +> +> Let's take it from the top: when you install a new operating system, +> be it Windows or Linux or Mac or a mobile device firmware, the system +> will most likely come preloaded with root certificate trusts. Who +> decides to trust these? You haven't hand-picked them, and most people +> don't even bother looking at the list of authorities their system +> trusts. Not to mention, most people don't even recognise half the +> companies and organisations that provide certificates. So, you're at +> the whim of others – all you can do is hope they have your best +> interests at heart and that they aren't screwing you over, +> accidentally or on purpose. In reality, quite a few authorities are +> lazy with checking if a CSR is valid or just a spoof attempt. As long +> as they profit, they don't really have your security at heart. +> +> And of course, high-profile companies can and do get hacked. This +> holds true for certificate authorities as well. And the more widely +> used a CA is, the more susceptible to attack it will be. Also, while +> this does not apply to everyone, there are workplace, school, and +> governmental filters that are put in place to censor certain sites +> deemed to be unacceptable for access, as well as to detect obscene or +> unsafe (malware) content. In order for a filter to be effective for +> these purposes, it must intercept all your traffic; HTTP is +> straightforward, but HTTPS requires the firewall to strip, analyse, +> and re-encrypt the content that passes between you and the webserver. +> In doing so, it relies on each computer in the network having its own +> certificate installed and accepted. End users may not be fully aware +> that this is going on, and they may believe they are completely safe +> because their browser is not warning them at all. This may be +> acceptable if everyone understands what this filter does and if the +> filter is configured correctly, but that isn't always the case. My +> high school's filter made no distinction between valid and invalid +> certificates, so I could unknowingly be put at risk for accessing an +> unsafe site that appears to my browser to be safe. Plus, if people +> wanted to use their own devices on the school network, they were +> required to install the root certificate even though they were not +> made aware of the consequences this would have. +> +> So that's one issue: most people don't even explicitly trust the +> certificates installed on their system. Even if you are aware of the +> root certificates you trust, you cannot fully trust that they will +> remain uncompromised and trustworthy in the future. Let's Encrypt was +> proposed as a solution to the skimpy checks most authorities put their +> customers through; Let's Encrypt uses a cryptographic proof to verify +> that you are the owner of your server. While this is a great step in +> the right direction, it does not change the fact that Let's Encrypt is +> still a centralised certificate authority, and thus is fallible to the +> same issues as every other authority. +> +> In contrast to the common SSL/TLS methods of verification, SSH +> actively encourages you to accept key fingerprints on a per-server +> basis. There is no metadata attached to this (e.g. <q>this key is +> valid on domain.xyz and www.domain.xyz</q>) that can be changed to +> fool you into accepting the certificate – there's just an arbitrary +> fingerprint that tells the complete truth about who the server is, +> straight to the point and no bullshit. PGP operates in much the same +> way, except that there is certain metadata on keys that describe the +> owner and their E-mail address. With both of these, the key owner can +> disclose the fingerprint via whatever channels he deems secure, +> meaning that an adversary has a harder time compromising this +> information. TLS certificates have fingerprints as well, but most +> client software obscures this in favour of a less helpful <q>this may +> be insecure</q> warning. +> +> A compromise would be to provide a simple-to-use and +> simple-to-understand web of trust system that combines the benefit of +> <q>lazy</q> and indirect trusting (<q>I trust my friend's judgment, +> therefore I would like to accept all the certificates that he +> does</q>) with the benefit of decentralisation (points of weakness are +> smaller and more dispersed, making damage caused by compromise much +> more tolerable than if a large CA was compromised) and direct trusting +> (<q>I know that this site is what it says it is</q>, similar to the +> <q>add exception</q> function already available in most client +> software). Right now we do not have the luxury of a well-thought trust +> system that is straightforward, unobtrusive, and secure. So for now, I +> will opt only for the <q>secure</q> option since it is the most +> important in this scenario. After all, if you want <q>straightforward +> and unobtrusive</q> without <q>secure</q>, why don't you just use +> HTTP? + +to put my money where my mouth was, I did create my own CA to use with +all my websites, and that worked relatively well for about a year. but +lately I have found that some XMPP servers will not federate with +servers that have untrusted certificates, so it was time for me to make +a decision: compatibility or security. I bit the bullet and now I'm +using Let's Encrypt certificates on all my websites and servers, forced +TLS on websites/E-mail/XMPP (and soon IRC), and overall I guess it's a +good move even though I'm upset with the CA system. hopefully one day we +have a better system in place to address the flaws of the CA system. diff --git a/src/blog/update.md b/src/blog/update.md @@ -0,0 +1,7 @@ +# update +<!--[time 201712140131.20]--> + +busy this week, but I'm using Alpine Linux as my main operating system +now, because I've grown tired of using Windows 8.1 on my laptop. I will +get that set up with PGP and use it to sign my future (and possibly my +past) blog posts. diff --git a/src/blog/welcome-why-ill-give-blogging-another-try.md b/src/blog/welcome-why-ill-give-blogging-another-try.md @@ -0,0 +1,46 @@ +# welcome (why I'll give blogging another try) +<!--[time 201711181325.54]--> + +last Friday (10 Nov 2017) I felt unusually motivated to organise quite a +few aspects of my life. among those included finally setting up TFA on +some of my online accounts, adopting a better password-management system +than I had, and composing some to-do lists. recently, I have also been +more interested in philosophy, spirituality, and faith/scepticism in the +unknown, and I felt it would be constructive to be able to lay my +thoughts out in front of me rather than keep them in my head. and while +I'm at it, why not do it online so others can consider a thing or two +from what I'm thinking? + +I have previously written a few guides and opinion pieces but they are +scattered about and people will not bother looking for them, really. I +want to continue this trend of guiding, helping, collaborating with +others so that we may all improve our knowledge and possibly build a +better world worth living. + +here's what you should expect if you do decide to keep up with my site: + +* I hope to create weekly posts -- I have plenty of subjects listed out + already, so a shortage of ideas is not an immediate threat at all. I + probably have enough to last me a few months at this rate. +* I accept feedback, currently only over E-mail at <opal@wowana.me> so + just put in the subject that you're replying to a specific article I + wrote. if your query warrants a public reply, I'll write a response on + my next blog entry. +* I want each entry to focus as a sort of canary. I experimented with a + PGP canary in the past with limited success, mainly because I knew + that nobody was checking it and it took me too much effort to generate + canaries. maybe now I have a better system: I'll simply PGP sign my + posts, maybe with a recent news article at the end of my post, and if + I haven't posted a blog entry in a week or two then that must mean + something's happened with me or my stuff. + +please E-mail me if you're actually interested in keeping up with my +writing and my PGP canary; it would really help me stay motivated to +write quality content and to maintain a level of cryptographic trust +with whoever cares about my well-being. but of course, if no one ends up +reading my blog, I'll hopefully still find it useful as a sort of diary +to collect my thoughts and process them more thoroughly. + +I'll see how this experiment goes and dive right in next week. this week +I have a school research paper due and some upcoming tests, so I'm too +busy to put my efforts in my personal projects.