Yep, me too. I have Thunderbird running in the background essentially as an email backup, but I wind up using the web version more. However Thunderbird and Bridge work extremely well that I forget they're running in parallel.
I'm a recent Google GSuite refugee, so it's hard breaking the habit of web based mail I suppose.
And my contingency plan if I can no longer self host, is export from one of my devices and import into the cloud version of Bitwarden. I don't see myself needing to do that, but you never know.
Yep, same. After this last G Suite fiasco, I finally moved my domain off Google onto another host that I pay for. It's nice to know I'm supporting a platform that cares more about privacy than Google.
Plus, it lit a fire under me to rely on Google services less and less. I had a second Google One account that I stopped paying for as well, cause f them.
As long as your spf record allows Google to send mail, you can.
You need to setup an "App password" on your Google account. Then, when you create an alias, you enter smtp.gmail.com and your app password credential as the smtp server.
I prefer it since 1080p takes less resources to drive, therefore gets better battery life. On a 14" display, I think 1080p looks more than fine. If I want a hidpi display, I'll just dock to an external display.
The only way to get the original quality photos is by using Google Takeout. Before Google made changes to Drive, you could use rclone (https://rclone.org/) to sync originals. That no longer seems to be the case, unfortunately.
I definitely would not want to use a hostile machine to access my servers remotely, period.
Sure, this will let you bypass outbound port restrictions, but it doesn't help in the slightest if every keystroke is keylogged.
They use the "-k" curl flag throughout their code (disabling ALL certificate validation), since I assume is to make initial configuration easier. Rather than fix this going forward, they created a workaround document which all new and existing customers need to follow to secure their setup.
I agree with most of the article. However, what I do disagree with is how they lump "security experts" into a single category:
Computer experts like to pretend they use a whole different, more awesome class of software that they understand, that is made of shiny mathematical perfection and whose interfaces happen to have been shat out of the business end of a choleric donkey.
I'm sorry, but there are vastly different grades of security experts. Security experts make Kali Linux. I'm pretty sure everyone runs their user as root despite it being created by security experts.
Now, look at the OpenBSD developers in comparison. Sure, bugs are found as they inevitably are, but they make it very difficult to take advantage of bugs that might be disastrous on other operating systems. They use privilege separation throughout their operating system (and packages if possible), announced recently their way of making ROP-chain exploits basically useless, and relink their kernel any time it's booted so that no two instances are alike (even if it's the same version on another computer). Using defense in depth is key. Unfortunately it's easy to talk yourself up in this field and not walking the walk.
There's a reason OpenSSH is such a highly deployed application and yet isn't constantly having RCE bugs. Sure there are bugs (as all software inevitably has), but there are definitely different degrees of security experts that the article fails to mention and lumps them all in one bucket.
Is it though? In most installation guides I've dealt with they recommend disabling it since it can cause random issues. i.e. The Percona XtraDB install guide.
I find that it's way too complicated of a layer that most people can't/won't learn. Compare this to the OpenBSD pledge and unveil which doesn't get in the way, and there's no way to disable them.
If you make something overly complicated, with the ability to disable it all too easily, then it won't get used.
Yes, some devices are getting more difficult to repair. However, Microsoft and Samsung aren't the ones lobbying to make it ILLEGAL to fix device.
Apple has sued over people taking displays that were still good, but just needed the glass replaced. This is a trivial repair and has been done forever in the IT industry. To the car analogy: it's like replacing the windshield and selling the vehicle. Then Honda sues you because the Honda logo is still on the car.
This has nothing to do with security and is totally over Apple wanting full control over a device that someone purchased with their own dollars. To say it's to do with security is asinine.
Apple isn't perfect either. I'm not trying to defend Google, but Apple is going after the right to repair and trying to make it illegal for you to repair your own device, let alone 3rd parties to.
So if you're someone who respects your right to repair and won't pay for Apple products, and the other option is an advertising company, what options are there left?
LE certs can still be used in those cases. We use LE extensively for the (somewhat critical) project I'm on. We centralize all certificate creation from our deployment server(s), so that we just push the certs out when the servers are built.
Doing it this way means we don't rely on the LE servers being up all the time, since we renew at the 1 month remaining point. If they're down for a day two, they'll just renew after they're back up. It also means our loadbalancers don't need access to the DNS system to handle the DNS-01 challenge required for wildcard certs :)
Neat concept, but there's no cost to running your own internal CA and having MongoDB trust that instead. Since you're already likely going to be running automated tools to deploy MongoDB (I assume), you can generate your own certificate/key pair then. This is how we do it where I work.
One of the big issues with generating the Let's Encrypt cert on demand is that if the LE API servers are ever down, you won't be able to create a cert.
I'm a recent Google GSuite refugee, so it's hard breaking the habit of web based mail I suppose.