Jen's Blog

90% tech, 10% silly

Personal Information Spring Cleaning: Auth and Passwords

Back in the olden times the custom of spring cleaning was about scrubbing the soot from your wood burning stove off of the walls. But we live in the 21st century, and our heaters don’t leave much soot behind. We do, however, leave bits and pieces of our personal information all over the Internet.

A couple of years ago I adapted the custom of spring cleaning to my Internet life. I do things like audit my passwords, delete abandoned online profiles, expunge embarrassing tidbits of angst-ridden teenage blogging, and generally tidy stuff up.

It’s a wonderfully cathartic practice, and it makes online life safer to boot. So, I’m going to share my spring cleaning regimen with all of you. It’s a grouped checklist, and it’s pretty long, so I’ve broken it up into a few entries.

This entry is all about user authentication and passwords: the gateway to your personal information.

Check for breaches

Data breaches happen constantly. I try to stay on top of them, but sometimes I miss one. Luckily someone else stays on top of them, and he runs a tool for checking your accounts:

  • Enter your favorite email addresses and usernames.
  • If your accounts have been impacted, tend to those accounts first: delete them, or update logins and passwords.

Multi-factor auth

Multi-factor auth, also known as two-factor auth, is awesome. Are you using it wherever it’s available? You should be. It’s a wonderfully effective tool for personal info security.

When setting up accounts, favor the most secure option available. Generally, U2F hardware tokens are best, followed by mobile apps, and finally SMS.

  • Go through all of the providers on which you already use multi-factor auth. Can any of them be upgraded to a more secure option? If so, upgrade.
  • Scan the services listed on Look for accounts where you can enable multi-factor auth, and do so.


Strong individual passwords are important, but general password hygiene is even more important.

One of the tricky parts here is remembering all of websites on which you have accounts. I probably have hundreds. Here are places you can scan to jog your memory.

  • Your password manager
  • Your cookies: go into your web browser settings, and scan the domain names of your cookies.
  • Account confirmation emails: search your email for words like ‘registration’ and ‘verification’.

Once you have an idea of where all you have accounts, fix those passwords up.

  • Are you using a password manager? If not, get one. 1Password is pretty good, but there are free and open source options too, like Padlock.
  • Have you used the same password on any two websites? If so, fix that now.
  • Go though your most sensitive or important accounts (banks, email, cell provider), and change those passwords for good measure.


There, don’t you feel better already? That’s just step one. There’s still lots of cleaning to do, but that will have to wait for a future blog entry.

Failed attempts to explain Developer Advocacy

About 7 years ago I discovered an awesome twist on the traditional Software Engineering career: Developer Relations. Over the years and across organizations the titles have varied – from Developer Evangelist, to Developer Advocate, and even to Senior Staff Developer Programs Engineer. But, all the while, one thing has remained the same: it’s really hard to explain what the heck we do.

Today my teammates and I, inspired by #BadlyExplainingYourJob, discovered that failed attempts are actually a great way to explain our jobs. Here is a list of those failed attempts.

I go places and talk to people about products, but don’t care if you buy them.

~~ Terrence Ryan

Explain how a Developer Advocate is not the same thing as a Technical Evangelist, over and over.

~~ Paul Newson

I’m a professional translator. I translate between Real World Engineer and Google Engineer.

~~ Aja Hammerly

I help people cause trouble with code.

~~ Jen Tong

I travel the world, excited to learn about how our products are broken.

~~ Brian Dorsey

I read Hacker News and Reddit, and pretend I’m an expert on stage.

~~ Sandeep Dinesh

I collect t-shirts from conferences, and tech companies while travelling the world.

~~ Mark Mandel

I’m the one Developers yell at when the platform isn’t working how they want; And I’m the one the engineers yell at when the developers aren’t using it right

~~ Colt McAnlis

I practice abstract driven development.

~~ Myles Borins

I look for places I want to travel to, and then see if there are conferences there I can speak at

~~ Mark Mandel

I make explosion noises at my computer when demos fail and get paid for it.

~~ Aja Hammerly

And, of course, this list wouldn’t be complete without…

I’m a people person. I take the code from the engineers and I bring it to the developers.

~~ Myles Borins

So yeah, hopefully that worked. You have a better idea of what it is we do, right? And it sounds great? Maybe you should come join us!

Migrating CloudBleed impacted static websites to Firebase Hosting

So CloudBleed is a thing, and it’s a bummer for a lot of big websites. But, it’s also a bummer for countless tiny websites that use Cloudflare for Flexible SSL. You know, all those static websites for side projects and silly artsy things. Many of them follow this recipe:

This recipe is awesome for so many reasons. It’s on your own domain, CDN delivery just works, and it’s almost free: all you pay for is the domain registration. I used it a lot myself. But in light of CloudBleed, it’s a good time to consider other options. Here’s the recipe I’m pitching:

  • Static HTML site, likely generated by Jekyll (nothing changes here)
  • Hosted on Firebase Hosting
  • Domain mapped to a your custom domain name
  • Https provided by Firebase Hosting

Why Firebase Hosting

I’m biased (I work for Google), but honestly I don’t know of any other options for free static website hosting that also provide domain mapping and SSL. But here are some cool things about Firebase hosting anyway:

  • The Firebase part is free, so it won’t cost you any more[1].
  • You get real TLS, so you don’t have to feel dirty about using Flexible SSL any more.
  • You get redirects and rewrites!
  • You can lift-and-shift your site with minimal effort, and probably be done by later this evening.

[1] It’s free for sites under 1GB of stuff, and 10GB of traffic. This more than covers all my side projects.

Migration instructions

Oh? So I’ve convinced you to give it a spin? Follow me on a dinosaur filled adventure of static site migration as I migrate, a silly art experiment with ~10 mb of HTML and images. Once in a blue moon it’ll get a spike of traffic from who knows where, but it generally matches the traffic patterns of my other side project websites.

The files for Dinopacks were previously hosted on Google Cloud Storage, but in an earlier incarnation the files lived on GitHub Pages. It also used Cloudflare Flexible SSL.

Migrating website data

There’s no reason your site can’t be published twice, so start by copying your website data to Firebase Hosting. Once you verify it works, you can move traffic over.

I was able to stick to the Firebase Hosting docs through the whole process.

  1. Go to the Firebse Console, and sign up if you haven’t already.
  2. Create a new Firebase project. You need one for each static website.

  3. This is where you could upgrade to a pay account, but if your site is low traffic like Dinopacks. The free Spark plan will work fine.
  4. Attempt to install (or in my case update) the Firebase CLI.

    $ npm install -g firebase-tools
  5. Fix your npm permissions, which always seem to get weird on macOS.

    $ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
  6. Successfully install the Firebase CLI

    $ npm install -g firebase-tools
  7. Authenticate the Firebase CLI.

    $ firebase login
  8. Change into your Jekyll project directory
  9. Make a tiny change to your website, like adding an HTML comment somewhere. This is a marker you can use later to verify that all of your traffic is going to the new host
  10. Init Firebase hosting. You probably only need to diverge from the Firebase CLI defaults once: tell it that your public HTML is in Jekyll’s default directory, _site.

     $ firebase init
     🔥🔥🔥🔥🔥 🔥🔥🔥🔥 🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
     🔥🔥        🔥🔥  🔥🔥    🔥🔥 🔥🔥       
     🔥🔥🔥🔥🔥   🔥🔥  🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
     🔥🔥        🔥🔥  🔥🔥    🔥🔥  🔥🔥        
     🔥🔥      🔥🔥🔥🔥 🔥🔥     🔥🔥 🔥🔥🔥🔥🔥   ...
     You're about to initialize a Firebase project in this directory:
     Before we get started, keep in mind:
         * You are currently outside your home directory
     ? What Firebase CLI features do you want to setup for this folder? Database: Dep
     loy Firebase Realtime Database Rules, Hosting: Configure and deploy Firebase Hos
     ting sites
     === Project Setup
     First, let's associate this project directory with a Firebase project.
     You can create multiple project aliases by running firebase use --add,
     but for now we'll just set up a default project.
     ? What Firebase project do you want to associate as default? dinopackscom (dinop
     === Database Setup
     Firebase Realtime Database Rules allow you to define how your data should be
     structured and when your data can be read from and written to.
     ? What file should be used for Database Rules? database.rules.json
     ✔  Database Rules for dinopackscom have been downloaded to database.rules.json.
     Future modifications to database.rules.json will update Database Rules when you run
     firebase deploy.
     === Hosting Setup
     Your public directory is the folder (relative to your project directory) that
     will contain Hosting assets to be uploaded with firebase deploy. If you
     have a build process for your assets, use your build's output directory.
     ? What do you want to use as your public directory? _site
     ? Configure as a single-page app (rewrite all urls to /index.html)? No
     ✔  Wrote _site/404.html
     ✔  Wrote _site/index.html
     i  Writing configuration info to firebase.json...
     i  Writing project information to .firebaserc...
     ✔  Firebase initialization complete!
  11. With that done, you should verify that your site works by going to http://<your project> For example, I went to to make sure Dinopacks made it up successfully.

Yay! The content is migrated. That was easy, wasn’t it? Now for the fun part: monkeying around in DNS.

Custom domain stuff

Assuming you want to preserve all those juicy inlinks, you need to migrate your domain name. This part will take a little longer.

  1. Go back to the hosting console for your project, click the Custom Domain button, and fetch the special TXT domain verification record.

  2. You can keep using Cloudflare for DNS, and their fast updates make this process quicker. Go to Cloudflare and add the TXT record. Use an @ to specify TXT records on the root domain.

  3. Wait a few minutes for the TXT records to propagate. You can verify them using the dig command. Correctly set up records should look something like this:

    $  dig TXT
    ; <<>> DiG 9.8.3-P1 <<>> TXT
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4328
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
    ;			IN	TXT
    ;; ANSWER SECTION:		300	IN	TXT	"google-site-verification=xWOK-correct_XHorSe09bHSbaTTeryXStapLEA"
    ;; Query time: 53 msec
    ;; SERVER:
    ;; WHEN: Fri Feb 24 15:21:15 2017
    ;; MSG SIZE  rcvd: 108
  4. Return to the Firebase Hosting console and click Verify.
  5. You have a couple options now: You can add a second TXT record and have a seamless transition (Advanced), or be lazy and accept a security warning for a few minutes (Quick setup). I opted for quick setup, and the warning was gone within a few minutes.
  6. Next, change your A records at Cloudflare to point to the IP addresses provided by Firebase Hosting. Make sure they’re configured to ‘DNS Only’, and not using the reverse proxy. If you have any CNAME aliases, remove them.
  7. Wait for them to propagate. Remember that marker you added up above? It’s a good way to know that things have migrated when viewed from mobile devices. This is also a good time to click around and make sure everything still works.


You’re done! Well, mostly. You could stop now, or you could take a moment to clean up all the clutter you left behind.

  1. Remove those TXT records that you added for domain verification. They’re benign, but they don’t need to be there any more.
  2. Delete the files at your old host. For me this involved deleting the Google Cloud Storage buckets that previously served my content. I could have done this with the command line interface, but I opted to do it from the console’s web interface.
  3. Update your deployment scripts to use firebase deploy.

What ifs?

Call me paranoid, but I’m always cautious about using free services. I do a ‘what if’ thought exercise on their limitations.

  • What if I get a huge spike of traffic and I exceed the Spark plan transfer limit?
    • Pay a few bucks to upgrade to a paid Firebase plan.
    • Or, since Cloudflare is probably still your DNS, you can enable their reverse proxy to reduce load. And yes, I realise the irony of that suggestion.
  • What if I run into a weird problem and I can’t find a solution on Stack Overflow?
    • Use one of your support tickets. (Something I actually did when migrating, which had some legacy Firebase weirdness from past adventures.)


So now you’re migrated to another provider, you’re probably not paying any more, and you’re using proper SSL. Doesn’t that feel great? And if you decide you don’t like it, it’s just as easy to move to a different provider later.

If you found this tutorial helpful, let me know! If you have a better place to move your side project static websites, let me know that too. I’d love to share more options with people.


I asked you all for other hosting recommendations, and provider got lots of recommendations: Netlify. I haven’t used them, but they look like another great option to consider.