blog-thenewoil-org-ahtqki.txt (13532B)
1 [1]The New Oil 2 3 Skiff Should Be A Reminder To Us All 4 5 February 18, 2024 6 7 Last week, encrypted email, cloud, and calendar provider Skiff announced they 8 will be shutting down in six months after being acquired by Notion. This has 9 understandably caused a lot of frustration in the privacy community as many 10 people were initially quite excited about Skiff. Several other privacy outlets 11 – including [2]Michael Bazzell, [3]Privacy Guides, and even our own [4] 12 Surveillance Report – have all discussed our own frustrations, lessons learned, 13 and plans going forward. But really, this is nothing new. Two years ago (nearly 14 to the month), [5]CTemplar also suddenly shut down, and we saw nearly the same 15 scenario play out (with different reasons being given by the companies). So 16 this week, let’s take a moment to reflect back on the second email shutdown The 17 New Oil has survived and see what lessons we can take away for the next 18 inevitable disruption. 19 20 Reminder: Beware the Little Guys 21 22 In the above-linked CTemplar blog post, I wrote that “in the privacy space, we 23 are very skeptical of new services.” Since then, I’ve seen a shift away from 24 that. I’m not a fan. On the one hand, I’ve [6]written in the past about how no 25 service or tool is perfect and how we should always be striving for better 26 services that improve upon those shortcomings. In the CTemplar post, I also 27 mentioned the value of supporting the little guy and how every major 28 organization was once a “little guy.” However, I think that the privacy 29 community has taken this mentality too far. Not a week goes by that I don’t see 30 some new forum post, email, or [7]Surveillance Report question about some new 31 service I’ve never heard of before. It’s great that so many new people are 32 recognizing the room for improvement and stepping up to the challenge, and that 33 so many privacy enthusiasts stand ready to support these efforts. But in the 34 CTemplar post, I also touched on the fact that starting a new service is really 35 hard and riddled with uncertainty. It could be a Big Tech or government [8] 36 honeypot. Even if it’s not and the creators are genuine, it’s incredibly easy 37 to accidentally screw up implementation and allow for bugs and vulnerabilities 38 (if it happens to the big, well-funded giants on a regular basis, why would the 39 small, cash-strapped startups be any safer?). And of course, any new company in 40 any industry must compete, and that’s never a sure thing no matter how much 41 money you throw at something or else there’d be no such thing as “box-office 42 bombs” and venture capitalists would have a far higher [9]success rate. 43 44 I know that advice is contradictory, but life is complicated, contradictory, 45 and messy. Still, two things can be real – like how new services should be both 46 supported but also treated cautiously. It’s okay to donate to a new service you 47 believe in that you think is doing interesting things, but you probably 48 shouldn’t immediately move everything over to be your primary service. 49 Relationships have some pretty consistent rules and characteristics across the 50 board, whether it’s with a potential romantic partner or a corporation. One 51 such rule is to go slow. You wouldn’t propose marriage on the first date, so 52 why on earth would you move all your most sensitive data into a brand new 53 service you just discovered that’s less than two years old and just launched 54 their first stable release six months ago and you can’t find any expert reviews 55 of it? Explore, support, but temper your excitement. Wait to see what the 56 experts say and if the service really is here to stand the test of time. 57 58 Reminder: Control Your Data 59 60 This is a topic I clearly need to discuss more: the tech space in general – but 61 especially the privacy space – is rife with ephemeral projects, whether because 62 they get sold, abandoned, or forced out of business. The single best way to 63 defend against this is to control your data, and the best way to do that – I 64 think – is to think in “standards.” The internet was never Netscape, Explorer, 65 Firefox, or Chrome (or apps, for that matter). It was always HTTP, TCP/IP, the 66 OSI model, and other such standards. These have been improved upon over time 67 (such as HTTPS and DoH/DoT), but the core standards have never changed. And 68 they're open! Accessing [10]The New Oil today is no different than accessing 69 Myspace in 2003 or the [11]CERN website in 1991, except it’s probably a lot 70 faster, easier, and better-looking (no offense, Proton/CERN alumni). 71 72 If you don’t know what any of that stuff means, don’t worry about it. Here’s 73 the point: try to think about how to reduce your data to a standard – 74 preferably an open one – and then preserve that. For the record, I don’t mean a 75 literal web standard like the ones above, but I do mean the same ideas and 76 principles. Bear with me and I’ll come back to that. Since this post was 77 inspired by Skiff (and built off my CTemplar post), let’s take email for 78 example. Like it or not, email isn’t going away any time soon. Nearly all 79 websites require email to sign up for an account, for example, and lately 80 there's been a big push for services to forgo a password logon entirely and 81 instead email you a link every time you sign in. (Not a fan.) However, email is 82 an interoperable standard. Whether you use Proton, Tuta, Mailbox, or Gmail, 83 that login link is going to get sent to you. So regardless of whether you’re 84 wanting to check out a new provider or simply improve your own data 85 sovereignty, the question to ask here is “how can I think of email as a 86 'standard' to ensure that I retain control of my email no matter what?” The 87 most extreme option here is to self-host your own email server, but that’s 88 generally not recommended unless you’re an expert – there’s too many 89 opportunities for things to go wrong and suddenly your emails will be blocked 90 (possibly both sending and receiving) and you may not have any idea for a long 91 while. Instead, the next-best option is to control the email address, because 92 then you always control where the emails go. You’re not bound to a specific 93 provider, which means you can migrate for any reason – shutdown, censorship, 94 better options, etc. The good news is that this is incredibly easy to 95 accomplish. You simply buy your own domain name from any reputable registrar 96 for a few bucks a year, and most email providers have instructions on how to 97 set it up. Then, if you decide you want to use a different provider, you just 98 look up their instructions instead. 99 100 Now, of course, experienced readers will go “email isn’t a standard, Nate.” And 101 you’re 100% right. As I said, I don’t mean to think in literal standards like 102 HTTP or TCP/IP. What I do mean is think in terms of “universal” and 103 “interoperable” – like a standard. As I said earlier, email is universal. 104 Proton, Tuta, Gmail, Yahoo, every email provider is built on the exact same 105 standards that make email function, such as SMTP, RFC 5322, and MX DNS records. 106 Of course, Proton & Tuta offer different protections and technical features 107 than Gmail and Yahoo (and even each other) but the core product is identical: 108 an email is an email and will be delivered to or sent from anywhere (not 109 including restrictions such as company or government censorship). As such, you 110 can think of an email the same way you think of any standard: how can I ensure 111 that I always receive my emails, send emails, and have my emails? As I said, 112 the first two are easily accomplished via custom domains: if you ever have 113 issues or find a better provider, simply migrate over with a few clicks and 114 some help from the provider and you’re golden. The last one can be accomplished 115 by exporting your emails, a feature that going forward I will consider a 116 non-negotiable requirement to be listed on The New Oil because of situations 117 exactly like this. Most providers also let you import emails, allowing you to 118 transfer as if nothing ever happened. Backing up your emails via exporting on a 119 regular basis and owning a custom domain essentially untethers you from any one 120 given provider for email, making you independent, resilient, and in control of 121 your own data. 122 123 Practical Application 124 125 This thought process can be applied to nearly anything. “How can I save this 126 file in a format that’s compatible with other word processors or operating 127 systems?” “How can I save my backups in a format that’s recoverable and usable? 128 ” “What would I do if this messenger shuts down tomorrow?” Not to victim blame, 129 but perhaps the biggest failing with the Skiff fiasco – and CTemplar before it 130 – was not asking these kinds of questions in advance and planning ahead. One 131 should always have an exit strategy and backup plan in place, even with the 132 most trusted and long-standing services, and one should always look for 133 opportunities to reduce their dependence on these platforms as much as 134 possible. (Note: I would like to recognize that some people are truly living 135 paycheck to paycheck and cannot afford to pay for a custom domain or even a 136 premium email aliasing service. This is valid, and I still encourage you to ask 137 these questions and come up with solutions that are within your means, even if 138 they’re less than ideal.) 139 140 It is, of course, worth noting that there’s only so much you can do. You can’t 141 literally own your own domain registrar, and even if you could you couldn’t own 142 the organization who makes the kinds of decisions that affect your specific 143 domain. Therefore you can never 100% be certain of your domain name. But even 144 as an everyday individual, you can rest assured that it would take a lot to get 145 your domain name revoked or taken away, and for most of us that’s simply not 146 something to even worry about. Likewise, for a lot of apps, you can export your 147 data but it may only be readable by that same app. It’s important to be aware 148 of these limitations and ask if you’re comfortable with them. I am a [12]Qubes 149 user, and I don’t expect that to change any time soon. My backups from Qubes 150 can only be read by another Qubes device, and for me that’s okay. The purpose 151 of these backups is to have them as literal backups – to be able to reload them 152 on another Qubes device in the event of theft, loss, or damage of my Qubes 153 laptop. On the other hand, I want my emails to be portable so that I can open 154 them with another provider (or at very least, another program) so that I don’t 155 lose all my past correspondence if I ever have to migrate services. These are 156 two very different use cases that warrant consideration. 157 158 Whatever services you’re using today, there’s a near 100% chance you won’t be 159 using most of them in 10 years. Whether they shut down or whether you simply 160 migrate to something that better suits your needs, the software you’re using 161 will almost certainly change in the future. The question is if you’ll be ready 162 when that happens. Everyone who was depending on Skiff directly must now 163 scramble to migrate and pray that they didn’t overlook anything when the dust 164 settles. Don’t be caught in that situation when the service you depend on sheds 165 this mortal coil and joins the choir invisible. If you’re lucky, you’ll decide 166 that the time is right to move on to another project and have all the time you 167 want to make the switch. We can’t always be so lucky. The best time to plant a 168 tree is 20 years ago. The second best time is today. I’ll end with what I said 169 when CTemplar shut down: 170 171 Controlling your data is important and powerful. It makes you independent, 172 it makes you resilient, and it makes your life simpler by being prepared 173 for when things change – and in tech, things are always changing. Part of 174 threat modeling is planning for what could go wrong and then putting 175 systems in place to mitigate it if it happens. Maybe you weren’t affected 176 by this CTemplar situation. That doesn’t mean you won’t be affected by the 177 next one. Be sure to review the products and services you use and plan 178 ahead. There’s always room to improve. Take this time to learn some lessons 179 and apply the necessary changes to your own posture. 180 181 You can find more recommended services and programs at [13]TheNewOil.org, and 182 you can find our other content across the web [14]here or support our work in a 183 variety of ways [15]here. 184 185 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 186 187 published with [16]write.as 188 189 [piwik] 190 191 192 References: 193 194 [1] https://blog.thenewoil.org/ 195 [2] https://inteltechniques.com/blog/2024/02/12/lessons-learned-from-skiffs-shutdown/ 196 [3] https://blog.privacyguides.org/2024/02/11/this-week-in-privacy-8/ 197 [4] https://apertatube.net/w/ftu35a7ZFgYguE6emeX9r5?start=10m3s 198 [5] https://blog.thenewoil.org/ctemplar-is-dead-aka-lessons-about-email-sovereignty 199 [6] https://blog.thenewoil.org/the-self-destructive-quest-for-perfection 200 [7] https://surveillancereport.tech/ 201 [8] https://usa.kaspersky.com/resource-center/threats/what-is-a-honeypot 202 [9] https://techcrunch.com/2017/06/01/the-meeting-that-showed-me-the-truth-about-vcs/ 203 [10] https://thenewoil.org/ 204 [11] https://www.history.com/news/the-worlds-first-web-site 205 [12] https://www.qubes-os.org/ 206 [13] https://thenewoil.org/ 207 [14] https://thenewoil.org/en/links/ 208 [15] https://thenewoil.org/en/support/ 209 [16] https://write.as/