Reader

• My LinkedIn account is in hibernation mode.
• All my Youtube videos were removed from public listings.
• Blogger.com content erased.
• Medium.com content was erased.
• My Facebook account is abandoned since I need it for my Oculus Rift. I no longer visit the site or use the App.
• Twitter account deleted.

Why?

No particular reason other than being in the process of deleting accounts I don't care to use... some of those accounts happen to be on social media platforms. I am doing the same for e-commerce sites I no longer care about.

There is no good argument to leave personal data or your old content behind, spread all over the Internet, so I'm cleaning up my tracks, closing accounts, and deleting random stuff I created.

Relax; there is plenty of stuff to entertain and educate you all over the Internet. I'm sure no one will notice I'm no longer around.

Keeping some lights on... and some content public :–)

My Mastodon account, personal blog, and this site are still up and running, and I have no immediate plans to shut them down. They will disappear eventually, just not today.

Everything you should know but are afraid to ask!

How secure are passwords?

The simple answer is that they are as secure as

• their complexity and length
• the end user's ability to keep them secret
• the site's ability to keep its part of the secret

Complexity and length

The longer and more complex the password, the better. The chart below shows how long it takes to crack a password using current hardware.

Passwords, to be safe, are not meant to be memorized or easy to type. A secure password is supposed to be a freaking nightmare to type in by hand or transmit by voice. Therefore, password managers and their respective plugins should do password storage and insertion into authentication forms.

The password manager should generate every password—no exceptions, no passphrases, and nothing that sounds remotely like a natural human language. Every password manager worth its salt comes with a password generator. Use it.

The password manager-generated password should be as lengthy as the remote system supports. But, of course, you will never see it, so go for 128, 256, and 512-character passwords just because you can. If the remote system supports longer passwords, use them. Why would you want to be closer to the unsafer number of characters if you could be further away?

Password managers are also complex to trick into giving credentials to the wrong site. Using a password manager along with manual clipboard operations (meaning using “copy” and “paste” instead of having them associated with the domain name) breaks an essential link in the security chain: sites should be cryptographically identified by their SSL certificates before the software decides to use the user's credentials.

Users are terrible guardians of secrets and are easily fooled into giving them away.

Pick a good password manager, and you are halfway to having a secure password system. I use Bitwarden, but there are plenty of good options (like 1Password) and terrible ones (like LastPass). Choose wisely.

Hardware vaults, biometrics and security keys

One of the best ways to ensure the user never sees a password is to generate and store it on hardware devices. These come in all shapes and forms, but the main concept is that secret tokens/keys are generated on a secure device that requires physical manipulation (touch or biometric readings) to make a secret available. Secure hardware enclaves may come in the form of computer components built into computers; that's the case with the Apple T1 chip.

Secure hardware is not a replacement for maintaining a safe computer platform. A compromised system will always act as a gateway for the information, regardless of it having been generated on a segregated secure platform. Likewise, having a touch or biometric sensors on the event toolchain does not prevent the data from being captured once used on a compromised system. While it may delay a critical security event of data disclosure, it will not stop it from happening when the user utilizes the secure device.

The end user's ability to keep a secret

Can you keep a system safe from malware? This is the hard part of the security dilemma. It is, in fact, very hard for most users (and companies alike) to keep their systems healthy and safe, and as long as passwords have to go thru an insecure operating system, they will be grabbable by bad actors.

There are strategies to keep systems relatively safe, like immutable file systems and only running signed code from known origins; however, these are only simple to implement with some significant limitations on what users can do on their working systems.

The site's ability to keep its part of the secret

All the site has to keep safe is a hash that validates the user password. If the password is strong, it will take millions of years to crack. While this is important to keep weak passwords safe, it's irrelevant for strong passwords in real-world scenarios.

While I assume no site stores the original user passwords, we all know this may be false. Unfortunately, some creative site engineers can come up with terrible ideas and implement bad practices.

Multi-factor authentication

Multi-factor authentication (MFA), encompassing two-factor authentication, or 2FA, along with similar terms, is an electronic authentication method in which a user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism:

• knowledge (something only the user knows; a code/password),
• possession (something only the user has; a hardware key or device to authorize the connection),
• Inherence (something only the user is; biometric readings identifying the individual or a third party vouching for him).

MFA protects resources from being accessed by an unauthorized third party that has been able to discover or replicate a single authentication factor.

A third-party authenticator (TPA) app enables two-factor authentication, usually by showing a randomly generated and frequently changing code to use for authentication.

Regardless of how many authentication factors an authentication process has, if the machine from which the access is granted is compromised, the authentication process becomes irrelevant. Once the authentication process is successfully concluded, the attacker can steal session tokens (to use on another machine) or even use the device to further the security breach in the background.

HOTP

Sequential-interactions-based one-time password (HOTP) is a computer algorithm that generates a one-time password (OTP) using the number of previous interactions and a shared secret as the sources of uniqueness.

While the world thought this was a good idea as an additional authentication factor, the whole concept of having a symmetric shared secret is, in fact, a terrible concept, worst than having asymmetrical secrets like passwords/hashes.

TOTP

Time-based one-time password (TOTP) is a computer algorithm that generates a one-time password (OTP) that uses the current time (instead of the number of interactions like HOTP) and a shared secret as the sources of uniqueness.

Security experts believe TOTP is safer than HOTP since there is a limited time window to abuse the collected one-time password. If the shared secret has been disclosed by one of the parties, the entire window of opportunity argument is irrelevant.

Algorithms (HOTP / TOTP) and sample code

Both the authenticator and the authentication candidate compute the TOTP (resulting from the shared secret combined with the current time) value and compare the results.

Some authenticators allow values that should have been generated before or after the current time to account for slight clock skews, network latency, and user delays.

TOTP uses the HOTP algorithm, replacing the counter with a non-decreasing value based on the current time. Python implementation of both HTOP and TOTP is pretty simple to read in code.

FIDO Universal 2nd Factor (U2F)

Developed by Google and Yubico, and support from NXP, with the vision to take private/public key crypto to the masses. One of the parties has a (secret) private key (the end-user), and the website has a public key, allowing the recipient of the messages to verify and unencrypt authentication dialogs.

The asymmetrical nature of the (private/public) keys (and corresponding cryptography) makes it miles better than HOTP/TOTP. Messages are processed and stored in an autonomous device (a hardware key / secure chip enclave), and the user cannot view, extract or copy a private key to save their life.

A physical action (like touching the device) is required to prevent unassisted operations. In addition, keys can be revoked if stolen, lost, or if a user loses access privileges to the system, and multiple keys can be registered with services.

Sadly some companies have rather disastrous implementations of security standards. Most notable, and because it affects me directly, Microsoft Azure Active Directory has a rather poor implementation of FIDO u2f (and even worse if talking FIDO2) that is only semi-functional on Windows devices. See https://learn.microsoft.com/en-us/azure/active-directory/authentication/fido2-compatibility.

Note that Apple security enclave has been available on the latest version of MacOS, iOS, and iPadOS for many months. Likewise, Youbico keys have supported the protocol for years. So you can use either the apple t1 chip and keychain with Safari/Firefox or a Youbikey to authenticate with Google and Cloudflare without issues on current operating system versions. I use both all the time on the same system.

While I cannot grasp why they need Chrome (on Mac) to make FIDO u2f somewhat functional on the platform when you can use any other browser on any other system, there is no lack of examples of other browsers working on the Apple ecosystem. The same applies to Firefox and Linux (that I drive daily) to authenticate myself with no passwords on multiple systems, including AWS. Unfortunately, of all the notable global providers, Microsoft is the only one lacking a working, universally usable cross-platform (most basic FIDO U2F) implementation for Azure AD.

FIDO2 passwordless authentication

“Passkeys” if you are trendy, “webauthn” if you are not into surfing the latest wave of jargon, take the FIDO u2f elements to new heights by aggregating multiple authentication factors in a single operation.

Use a security key, camera, or fingerprint/voice reader (something you have) and an optional PIN (something you know) combined with an action (touch or look at) to create the required provisioning for the secure platform to perform the authentication operation.

When correctly implemented, it's a beautiful experience that mixes the best of all security approaches with convenience and ease of use. It is the best user experience in authentication procedures and the easiest. There is no avenue to phishing or social engineering approaches to trick users (well, a hammer and a knee may convince them to provide access to a third party).

You can test the full FIDO2 experience on the Youbico site (even without a Youbico key, using Apple implementation if your Mac/phone/ipad has a fingerprint reader or FaceID) at https://demo.yubico.com/webauthn-technical/registration. It's magic like it should be. Unfortunately, we have failed to deal with the “authentication” problem for far too long.

Protocol and sample code

https://www.w3.org/TR/webauthn-1/

https://fidoalliance.org/developers/

https://developers.yubico.com/WebAuthn/

https://developers.yubico.com/SoftwareProjects/WebAuthn-FIDO2/WebAuthn-FIDO2Server_Libraries/

Let's talk about reasonably secure options and why they are the road less traveled.

People love their shiny new phones and last-generation computers running the latest niceties. They adore the latest, fully featured software and frictionless new tech. The problem is that it's tough, or better yet, downright impossible, to secure fat systems with millions of lines of code aiming to provide every possible feature to consumers. It is much easier to make simpler systems reasonably bug-ridden and secure.

Welcome to the wild, wild west!

It pains me to say that the software industry is still in its infancy after half a century of mass-market-driven choices. I sound like a broken record since I have been repeating the reason behind that observation for my entire professional life. Software publishers can ship whatever they want without legal liability for how buggy and insecure their product is. People want more features and functionality, and that is what they sell. Security is an afterthought, handled if and when it becomes problematic and inconvenient.

In the corporate world, regardless of how often they tell you otherwise, the same trends are followed with slightly different flavors of stupidity. The “professional editions” add more features to the software, not a more spartan and guaranteed less vulnerable version of their mass-market aimed for hobbyist counterparts. I don't even know what the “pro” label means in the software market...

Corporate computers are usually the consumer versions of the software with managed restrictions (some control masked as “advanced features”) on top in a vain effort to mitigate the most apparently dangerous user behavior. For example, the users cannot install additional software; password changes are mandatory, and I.T. enforces upgrade cycles.

Market maturity means legislation making software companies liable for the quality of their products. The same happened in other industries as markets matured. For example, can you imagine a world where cars and airplanes did not meet minimum security and reliability standards? Well, in the software world, we are still living in a new frontier, the wild west, as far as law enforcement goes.

Bad ideas are hard to kill; embrace them!

Can you keep a secret? Really? Can you?

It's hard to keep a secret. It's not a matter of people realizing the importance of not sharing confidential information, like their credentials, on corporate servers; they understand they are supposed to do it. The problem is that they can be tricked or coerced into giving them away.

How many of you would keep your phone/computer passcode secret under the threat of violence? It's tough to argue the merits of risking physical integrity in the name of a company's information security. However, a hammer and your two knees are an unbeatable combo making your silence and loyalty to a corporation a tough sell.

Judging by their actions, corporations do not care much about messaging security. The technology to digitally sign and encrypt communications has been available for years, yet email in the corporate world mostly does not use it. As a result, phishing scams and identity theft exist because no one seems to have them identified as severe problems worth a few lines/clicks configuring profiles and issuing certificates for every email user.

Is it reasonable to expect users not to be tricked into revealing their secrets in a world where user credulity is used instead of cryptography-identified identities? It's a rhetorical question with an obvious answer.

The best way to protect users from hiding corporate secrets is to provide them with none. Instead, you can authenticate connections using asymmetrical encryption and challenge-response dialogs using USB security keys that cost a dozen dollars rendering phones/computers useless without them as authentication methods. In addition, biometric reading devices have been available for decades, and you can ensure only a live individual can even use the authentication devices.

The tools needed to spare users the burden of keeping secrets are known and have been available for years. For example, geolocation and synchronized clocks are not rocket science, and you can limit the power of authentication tokens by limiting their use when an abnormal pattern is detected. For example, users are not likely to travel at light speed or be in two locations simultaneously. In addition, you can (and should) restrict privileges based on regular usage patterns. For example, you can render an authentication match null and void in the wrong location or off-the-clock times.

Passwords and shared secrets (used for second-factor time-based authentication codes o HOTP and TOPT) are terrible ideas. Spreading “secret keys” in both the systems and user end is an accident waiting to happen. While it's rather apparent that on the user end, the protocol designers expected the authentication devices not to be used to authenticate their connections, unfortunately, that is not what happens in the real world. In many ways, this secondary authentication approach is even more fragile than the primary authentication method. We can do much better.

Google and Yubico created FIDO U2F and support from NXP, with the vision to take strong public key cryptography to the mass market. As a result, large-scale services, including Facebook, Gmail, Dropbox, and GitHub, have successfully deployed U2F. The next evolution of the FIDO U2F modern authentication protocol is FIDO2, which introduces passwordless authentication capabilities.

Add biometric, time, and location-based restrictions to access the security enclave where private keys are stored, and you will effectively protect users from a myriad of problems and risks.

Since many systems will not support decent solutions, use a password manager. If you must use a fragile authentication solution, at least do it as well as possible. I like Bitwarden.

Do yourself a favor and go buy a pair of hardware security keys! Make sure you pick one that supports FIDO2 (because that is what you want to use on any site that provides the best option available today). I use Yubico keys.

Please avoid using the same device to store primary and secondary authentication secrets (that is why I recommend using security keys). While you can do a lot to make your devices safer, most people reading this are clueless on security beyond “I probably need some sort of firewall, anti-vírus, and should be careful about clicking on email links and attachments”.

The latest shiny new and trendy device will always be a user favorite!

Did I tell you that keeping fat, feature-rich, general-purpose systems secure is really hard? It is. You cannot do it. Ensuring an acceptable level of security in general-purpose products like MacOS and Windows is downright impossible, so use both operating systems for what they are: insecure machines for general-purpose usage. Control and sanitize the output of work done on such systems and ensure they cannot access sensitive information or perform critical operations.

While Windows and MacOS can be locked down to a level where the ease of use and versatility that makes them user favorites is no longer there – both operating systems can be stripped of bloatware beyond recognition for a specific use case. Still, you will likely end up with a universally hated Frankenstein setup that is borderline unusable.

The same goes for iPhones and Android devices; they are great mobile computing platforms people love and are awful second-factor authentication devices. Like their bigger laptop or desktop counterparts, they are general-purpose devices running bloated and insecure operating systems. What you want in a device that stores secrets is the opposite of accessing random sites, insecure emails, receiving an SMS and installing apps. If you want the user to carry a single phone, at the very least, provide them with a security key that stores and uses private keys; it's already a bad idea, so don't make it even worse.

Mission-critical operations should happen on secured systems unable to run non-signed binaries with minimal connectivity according to their purpose. Authentication should be decoupled from the system and require human intervention, like touching a Hardware key and passing a biometric test on a security enclave (system on a chip).

Secure systems are synonymous with minimalistic installations, only the necessary software to fulfill their mission, and nothing else. Top-of-the-line hardware is cheap when compared to the cost of risking not isolating and securing systems.

I like the “reasonably secure Qubes OS” approach, implementing a security-by-compartmentalization using virtualization technology. Cubes OS isolates programs and sandbox many system-level components, such as networking and storage subsystems, so that the compromise of any of these programs does not affect the integrity of the rest of the system. Furthermore, virtual machines are not persistent and revert to a known secured state between uses.

Critical-mission users need separate devices. Unfortunately, there is no way to avoid it. However, these users are usually a tiny percentage of a company's workforce. For most employees, the focus should be on zero trusting the toolset and ensuring control over what they can access and share.

Security is a balance between letting users use whatever tools they need to perform the job efficiently and limiting the potential damage they can inadvertently cause. Unfortunately, it is not easy to achieve the perfect balance. But on the other hand, that is why I.T. exists in organizations. So be glad you have the job, and while you are at it, do it.

Microsoft Office scripting language and macro support

I would love to meet the people that thought running scripting languages in Office documents was a good idea! It sure enables a ton of otherwise impossible options for ill-prepared software engineering. But unfortunately, while I am a proponent of letting people use the best productivity tools they can find, we should limit the number of bad options allowed in a corporate setting.

While running alternative safer Office-like packages with fewer “features” is the easy way out of many headaches, there are ways to enable power users instead of shutting them down. Office applications and data should only run in chrooted (isolated) environments with strict per-document and toolset limitations. Running them online is not the worst possible approach.

I have been managing I.T. for the better part of 30 years. During that time, I saw fantastic stuff created by power users with Microsoft Office tools that delivered great value to companies. While a whole lot of risk and (security) issues come with some (let's call it) creative approaches, the solution is to find ways to accommodate those “solutions”. They even existed because conventional systems to solve a particular problem were unavailable. So I hired the individuals behind some of those insane projects.

I have been a client/user for a long, long time

I have been an Microsoft Office user since there was an Office package. I have been an Office365 user for half a dozen years (the company I work for is all-in into the Microsoft ecosystem) and use Microsoft Teams for eight hours daily.

I have been a Gmail user since the service was created. In addition, I have been a reseller for many years and have helped several companies take advantage of their ecosystem of apps.

I started using Nextcloud five years ago. I was looking into replicating some of the features I found in both Google and Microsoft in my personal life. So I self-hosted Nextcloud and started sharing it with friends and family. Much to my surprise and wonder, I found it to be an equally capable alternative to the previous two commercial options. It can be self-hosted or used hosted by a third-party as a service (SAAS) like the Microsoft and Google alternatives.

I like LibreOffice and OnlyOffice. Used both extensively for years. They both have a much better security track record than the Microsoft equivalent, and I honestly don't see the point of paying for a less secure proposition. While I understand some individuals have some limitations that make them have difficulty adapting to slightly different interface options, I never met a single one that could not make the transition. For many years the Microsoft offering was head and shoulders better than anything else on the market; I don't think that has been the case for years now.

I have personal biases... so take my opinions with a BIG grain of salt.

I have administered Linux and *BSD systems for 30 years. While I have no system administration responsibilities in my current job, I never stopped doing it.

While I understand the rush to cloud hosting, mainly when scalability is an issue, it is not a silver bullet solution and creates some problems. Price is one of those issues, and latency is another (if you have a mix of on-cloud and on-premises systems that are mutually dependent)—not even going to touch on issues like security, optimization, and backups. In addition, good system administration is not cheap and does not scale down well for small and medium-sized organizations. Also, it's hard even to grasp the concept of micro-companies and individuals being able to self-host projects with anything that resembles sound system administration practices. It is just too expensive and risky.

As a former professional with 30 years of experience, I have some options that most people don't have. For example, I self-host my social media (Mastodon, Writefreely, and Publii servers), Nextcloud, and Bitwarden services. The option to host the services makes me favor them compared to alternatives.

What about big(ger) companies?

If random scaling (up or down) is an issue, there is no alternative to the cloud. Organizations with thousands of employees have options regarding email services, group calendars, video/audio conferences, and contact management. Running email services internally and using Nextcloud may be a better fit. There are a lot of hurdles to doing it right, but keep an open mind because it can be done, and you can save a small fortune.

Email, in particular, would benefit significantly from (eventually being self-hosted and) changing paradigms: ensuring every internal email is at a bare minimum digitally signed and ideally end-to-end encrypted (using either S/MIME or PGP/GPG), and information should never leave the company systems. Impersonation (identity theft) would be a thing of the past; instead of the number one spear-phishing weapon in every hacker's arsenal. You need to self-host the servers to implement rules to reject every non-encrypted email message between internal emails, signed with recognized keys.

Encryption keys and client certificates should be hardware-based, locked, and centrally managed, and users should have zero capability to transmit them to third parties. Thus ending phishing attempts to steal credentials. In addition, requiring user touch (or biometric authentication) makes life much harder for attackers, even if the device is compromised.

I am a big fan of zero-trust environments and protected VPN tunnels to critical services, and all those should be hardware locked. You cannot exploit 0-days vulnerabilities in the software you cannot access.

At some point, I knew I had to write my version of the “new to mastodon” user guide. Plenty of good ones cover the basics well, so start by bookmarking this page to get back to it later and then explore.

Want a video introduction? The Linux Experiment has a good one: “How to use MASTODON: the COMPLETE GUIDE (join, use, find people to follow, etiquette...)”:

Picking a server (you can switch later effortlessly)

The “official guide to Mastodon” suggests that you should “somewhat carefully” pick up a Mastodon server to join from the “joinmastodon.org” list. That's fine as long as you find one that looks like a good fit for you.

• Pay special attention to the instance allowed languages (i.e., some are “English” only, while others may cater to some specific language).

• Some servers are themed around a particular interest (i.e., ones that only allow a specific topic or are filled with people that want to focus on it). There are “generic” instances where every issue is allowed.

• Every server has a particular set of rules. The owner or moderators enforce these rules. Please read them carefully because it is easy to be expelled from a Mastodon instance. Some restrictions may be obnoxious and, for example, forbid users to use certain words or letters or promote or even talk about a particular topic.

• There are many pros and cons to joining a big server. I want a server that is as fast as possible. On the other hand, I am not interested in “local” and “federated” timelines; I look forward to seeing the people I follow and their interactions with others. So for me, it's a personal server I self-host at mrnet.pt for friends and family.

• You can have your own server, entirely administered by professionals, even if you don't know a thing about servers. For example, check out masto.host. NOTE: I have no relation with the company and never hired them, but their track record of hosting Mastodon servers is outstanding.

• If you feel like looking at random strangers and don't mind being in crowds with a server that sometimes is not exactly the fastest, mastodon.social is probably your best bet!

• If you want, you can switch to a different server later. So, don't worry too much. Just don't get expelled; that will complicate migration to a new server, assuming you want the people you follow and those that follow you to move along with your account.

Congrats on having created a Mastodon account!

Make a nice profile for your new account!

No one likes interacting with a faceless profile. Let people know who you are and what topics (hashtags) you are interested in. You will be surprised by how many people will want to follow you and interact with the content you post.

Now, follow people!

You need to follow at least 100 people; otherwise, your Mastodon feed will look deserted, and you will feel like you hear crickets. Since in Mastodon, there is no algorithm attempting to guess which posts you probably like to see; you need to populate your feed by following people. Some suggestions:

• Look on the web for “Mastodon accounts worth following” (use Google or whatever search engine you like). The search engine will give you some suggestions.

• From time to time, visit followgraph.vercel.app to find who the people you follow are following. It gives you some excellent suggestions of people you will likely find interesting.

• Visiting other mastodon instances and looking at their “local” and “federated” timelines will probably help find exciting people.

If you are on iOS (or an Apple Silicon Mac) “ice cubes“ has an amazing super-power: you can follow “local” timelines from multiple instances, making small instances feels exactly like big ones. It's the App killer feature! Download and install it, even if you primarily use some other App (it is free and open-source).

• Install Streetpass for Mastodon in your browser. This plugin will check for author links in articles you read on the web and suggest you follow the authors.

• interact with people. Favorite (it tells the author you liked it and has no effect other than that) the post their best posts, and share (boost) the ones you find helpful or entertaining to your followers.

If you have a feed that feels too quiet, follow some wrong people. Over time you will make a better selection, but do build a network.

Post!

Give people stuff to read!

Set the language correctly in every post. You can set a default language on your Mastodon. Set it correctly when you switch to another language occasionally. Some instances have automatic translations, but for them to actually work, it is important that you inform them of what language you are using for each post.

Use hashtags in your posts! They do wonders for the discoverability of your content! Some people follow certain hashtags, not necessarily the authors that write on those topics, so give them something to work with.

Mobile Apps

If you are on iOS, you will be spoiled with fantastic paid Apps from top-rated authors; look at app store reviews, and you will find one good fit. The best free option is, by far, “ice cubes”.

On Android, I have no idea what your options are. Sorry. I am sure there are some. I heard about “Tusky for Mastodon” being good but never used it.

Desktop user?

I use the instance site with the “Roam with Mastodon” browser plugin. This plugin gives you the equivalent of quoted retweets on Mastodon.

I heard wonders about “Elk” but never tried it.

Sometimes I use “ice cubes” (the iOS App) on my Apple Silicon Mac... but I am still waiting for a decent native Mac App that beats the web interface...

Are you have a blog or a website?

If you want banners to link to your mastodon account or timeline, look at fo.llow.social.

Hello there! Nice to meet you!

You are likely reading this because you attempted to deliver some emails to mail.plaureano.com and failed miserably. Assuming you are not a spammer or a hacker, and that is a big assumption, let's go with it: I have some recommended reading for you: https://snov.io/blog/how-to-avoid-spam-filters/

It's a jungle out there! Unfortunately, email is the most abused Internet service, so you must be careful about what mail you accept on your server and what you discard. However, there are some basic rules I have set on this server that you must follow; otherwise, I will not accept your messages:

Your DNS name must point to your IP. Your reverse DNS must point to your name. Easy pizzi, right?

If you can write to me, I must be able to respond, meaning I will try to call you back (send you an email), and if you are using an open relay or refuse my email, I will not accept any of your messages. I will look up your DNS MX records for the domain you are using to message me and try to message you. It is only fair; after all, you contacted me first.

This should not bother you if you are a legitimate email sender. However, if you are a spammer, it forces you to set up at least an account that receives mail to the address you are using to spam people.

Your DNS must have a valid DMARC, SPF, and/or DKIM. Head to mxtoolbox.com and test your domain name. The report should look similar to the image below.

While you are at it, check your status on blacklists for the domain. You see, people talk to each other, and some friendly folks compile and maintain lists of email servers that distribute spam/malware.

If all of this is too much for you to handle, set up an account with some professionally administered mail provider. Mail administration can be a pain; it is not for everyone.

Have fun, happy emailing, and take care.

Paulo Laureano

The virtual machines

Both Mastodon (short-form blogs) and Writefreely (long-form blogs) servers are virtual machines (VMWare) running on my home network. Bandwidth is limited (1000/200Mbits), and I use Cloudflare Argo tunnels to expose the servers.

The virtual machines have plenty of memory (8Gb each), CPU (4 cores, 8 threads), and disk space (1Tb) to spare.

This should be fine (and faster than most Mastodon servers) for a few users. The servers are primarily for my personal use, so I will not let an excessive amount of guests fill them to capacity.

Backups

VMWare snapshots are used daily (this allows me to roll back to a previous machine state easily if something goes wrong during upgrades). Databases and server configurations are backed up daily. Every other day they are copied to another machine on my network. I make an offline copy of the backups monthly. There are no offsite backups.

This is enough for my personal data; I will give your account data the same level of protection I use for myself. If I die, become unable/unwilling to administrate the server, the house burns down, or something along those lines, you will lose your account. There is an obviously awesome solution to achieve different/better data security: host your own server!

Security

The only non-visible publically data is your e-mail address. I'll try my best (effort) to keep the servers updated and patched to the latest versions; however, I give no warranty of any kind against someone eventually getting to it.

You should use a unique password on these servers and (if supported) two-factor authentication. At the time I am writing this, Mastodon supports 2FA, Writefreely does not. It's your call to use two-factor authentication, but identity theft (of these social media accounts) is the most severe risk you are taking here.

it is essential you understand the risks as I have presented them to you. While I care about this, bad things beyond my control may happen. A terrific strategy to avoid/mitigate these risks is to delete your account or set up your own server to protect your personal data/identity.

My commitment to keep these servers running

I will keep them running for as long as I want or can do so. I do not plan to shut them down without notice, but shit happens. You will have the servers running for as long as I have them for myself. You can always run the servers yourself; if reliability and longevity are essential to you, that is the way to go.

Sometimes stuff will happen that I do not control, like electricity failing, computer components dying, etc. That's life. Again, you can achieve a different result if you host your own servers.

Being perfectly blunt: you are a guest, and the party may end at any time. There are no warranties of any kind that you will find a working server the next second after you read this.

Upgrades em várias máquinas de linux (ubuntu servers e Mint desktops) fizeram a minha tarde. Correu tudo normalmente, com um par de horas de puzzles à mistura no caso dos upgrades para o Mint 21.1, mas não mais complicado que o expectável.

Pelo meio nasceu este novo servidor de Writefreely, muito pelo charme minimalista da plataforma. Eu adoro este tipo de abordagens. Tinha de experimentar a plataforma, gostei do que vi e vou manter a instalação.

Espreitei também o micro.blog, que é muito na linha do Mastodon, e de que não gostei particularmente. Em particular a ideia de não haver crosspostings (boosts), porque alguma coisa ser viral é forçosamente “negativa” decididamente não me agrada.

Gostei (muito) de ver em ambos os casos as respectivas comunidades a pagar hosting. O modelo de que uma coisa que custa dinheiro (a alguém) pareça ser gratuito é insustentável no médio/longo prazo. É claro que pode haver sempre malta super-generosa a pagar a festa de todos, mas duvido que escale ou dure muito tempo.

Eu não me sinto confortável como “convidado” dessas pessoas. Esse é um dos motivos que me levam a fazer hosting dos meus próprios servidores. Partilho os mesmos com familia e amigos, como partilho a minha casa quando recebo pessoas. Toda a gente sabe que a festa acaba quando não me apetecer pagar mais copos ou perder a pachorra para andar a limpar a casa. Há zero compromisso meu de manter a festa indefinidamente. É porreiro e divertido enquanto durar e quando acabar ficam as memórias.

Um amigo perguntou-me se não era uma situação precária usar o meu servidor de Mastodon. Se não era melhor ir para um que fosse mais estável e tivesse um compromisso de longo prazo com utilizadores... é. É melhor. Se isso for real. Talvez esse servidor seja mais lento em determinados momentos, mas fora isso, só vejo vantagens. Boa sorte a descobrir a base desse compromisso entre quem estiver a pagar as contas e quem estiver só a gozar o prato. É só uma questão de perspectiva e fé, se um servidor aleatório de Mastodon tem (de facto) um compromisso maior que qualquer outro.

É por isso que eu gosto do contexto de servidores pagos. Porque há uma relação contratual e o crescimento é sustentável, equilibrado e, se calhar, até apetecível para ambas as partes. Se por outro lado a aposta é de “ter fé” que quem paga as contas continuará a pagar, porque sim, e quem faz manutenção continuará a fazer, também porque sim... não me parece uma situação confortável. Pelo menos não é confortável para mim.

Prefiro mesmo pagar as minhas próprias bebidas, estar em minha casa, e receber por cá apenas as pessoas com quem gosto de partilhar o oxigénio. Se isso dura um dia ou anos? Sei lá. Estar vivo é uma condição precária e com um péssimo diagnóstico de longo prazo. Não sei se terei a mesma capacidade financeira que tenho hoje no futuro. Nada é certo, excepto que o destino das minhas contas está nas minhas mãos, depende apenas de mim, e em nada da boa-vontade de terceiros.

É exactamente como gosto que seja.