AWS

Picked AWS over other cloud services

🟩 Endorse

When starting, I had significant experience using AWS from past roles, and I didn't really have the opportunity to spend ramping up knowledge. AWS was the default choice. Since, I have found that AWS was a great choice. The tooling is superb. Support is reliable. Hiring engineers with experience is easy. AWS provided great stability. In seven years, we only had two downtime incidents, both of which could have been avoided with better multi-AZ replication.

DynamoDB as our primary database

🟥 Regret

I wanted to design a completely serverless service. Serverless SQL databases were not available seven years. After dealing with MongoDB’s manual server management, sharding, and scaling issues, I decided to give DynamoDB a chance. I had never used DynamoDB, but I built a POC and saw performance was good. This was before adding the use of DynamoDB Accelerator (DAX), which I knew was available to help accelerate the database more if it became necessary. DynamoDB it was.

DynamoDB has proven to be a powerful and performant database. When optimized with the correct indexes, DynamoDB performs lightning fast and for most of our application it has worked well. It completely fails in use cases where you cannot make predetermined, optimized indexes for queries. Supporting data tables with advanced filtering and searching is nearly impossible at scale with DynamoDB. Any use of a scan in production is impossible to scale. To support more complex searching, we added an ElasticSearch service and hooked into DynamoDB streams to ensure we kept ElasticSearch up-to-date.

DynamoDB’s official SDK from AWS is also limited. It is similar to most direct database libraries and does not attempt to enter the realm of an ORM. We originally used Dynamoose as our ORM, but its TypeScript support was limited, so I eventually created and open-sourced a more powerful DynamoDB library designed for TypeScript, called Dyngoose.

With a useful ORM and combining DynamoDB with ElasticSearch, we were able to handle almost every use case. The main issue became development time, many features that would be simple in SQL using a JOIN became difficult with DynamoDB. It often required loading a record to get a pointer to another record you needed to load. This can drive down performance of using DynamoDB significantly and the benefits evaporate. One use case that completely failed with DynamoDB is reporting.

Reporting isn’t always the highest priority feature for a startup, delivering features is typically considered more vital. For many businesses, they want to see the value your product and service delivers and without the appropriate reporting capabilities you lack the ability to truly show your clients the value you deliver. DynamoDB and ElasticSearch are both terrible for reporting. Eventually, you may need to build in reporting capabilities.

DynamoDB does not position itself to be the primary application for large SaaS products. This decision came down to my preference for a serverless database. Today, weighing it all, I do regret the decision. DynamoDB continues to perform admirably for us, but I believe PostgreSQL would have been the better choice and today there are great services like Neon, Supabase, and AWS Aurora which make scaling a database easier than ever. I believe an optimized Postgres database with the benefit of appropriate caching in something like DynamoDB would have performed as well and allowed us to build a more useful product for our customers.

Using Lambdas for all of our APIs

🟩 Endorse

Although the Serverless framework did not work (more below), the serverless approach of using Lambda for all of our API endpoints did. Lambda is AWS’s Function-as-Service. Every one of our APIs is processed via a Lambda behind an API Gateway. Our service does not use a lot of CPU intensive processes, our biggest being our ETL process, while most of the service was automated via events (e.g., webhooks and schedules). It was a perfect use case for Lambdas and to this day, even with supporting hundreds of thousands of patients every month, the operating cost for the service is minimal and performance is great.

Using Lambdas provided several key benefits beyond reduced operating cost:

1. Significantly lower infrastructure management costs. I didn’t need to spend time managing servers or optimizing load balancers. I never had to deal with memory leaks or runaway processes bringing down a server.
2. Consistent performance. Our application performed reliably, for all users, under almost every workload we ever encountered. The service scaled instantly, it was never down for 10 minutes while waiting for another server to come up and enter the load balance’s group of healthy targets.

There are certain technical considerations and limitations that are imposed upon you when creating an API backed entirely by API Gateway and Lambda. Limits such as:

1. Maximum of 30 seconds to respond. API Gateway restricts your Lambdas to responding in 30 seconds, known as the “Maximum integration timeout”. 30 seconds is plenty of time for 99% of requests; however, it means certain processes (e.g., exports) become difficult. Generally, this timeout forced us to design performant processes. We rarely had timeouts, but when we did, it was always nearly a mistake in how we performed a DynamoDB query where it fell back to a database scan. This timeout prevented runaway processes and forced us to review performance issues early on. To handle tasks longer than 30 seconds, we designed asynchronous workflows—either queueing jobs or using WebSockets for real-time communication.
2. Maximum of 15 minutes runtime. When you have a Lambda that runs from a non-API Gateway event, you typically have 900 seconds to respond. This is plenty of time for typical workloads. To handle tasks longer than 15 minutes, we utilized ECS Tasks on Fargate.

Designing our service to be entirely FaaS has proven to be a good call, our service continues to scale efficiently, run reliably, and is easy to maintain.

API Gateway for WebSockets

🟥 Regret

Several years into building the application, we kept finding use cases where we needed asynchronous requests that would take longer than the limited 30 seconds of the allowed HTTP API quota on API Gateway. Processes where we could not directly control the duration, such as talking to a third-party API or generating export files.

To support these requests, we added the use of WebSockets via API Gateway. We had been using API Gateway for all our HTTP/REST API endpoints and thought API Gateway would be up to the challenge of supporting WebSocket. API Gateway implements WebSocket in a Request → Response format, similar to a typical HTTP request. When you want to push a message to an open WebSocket connections, though, API Gateway falls short.

For simple request → response uses of WebSockets, API Gateway can kick off a Lambda and you can respond to the request similarly as a regular HTTP request. This works well for requests where the response only goes to the user who made the request. Of course, WebSockets can be used for so much more. We wanted to push updates to user’s browsers in realtime to support new features.

API Gateway maintains the WebSocket connections for you. To asynchronous send a message to an open connection, you use the API Gateway Management API. For every websocket message you want to send, you need to perform a request to an HTTP API. The API Gateway Management API also doesn’t support sending a message to a batch of connections. This makes for a very slow “realtime” messaging system when you have to notify a few thousands users of a single event. Without batch support from API Gateway, sending messages to thousands of users individually was inefficient.

WebSockets are great, I will continue to utilize them more in the future. However, I’d most likely self-host a WebSocket server using ws as an ECS Service behind a NLB.

Elastic Container Service

🟩 Endorse

Our serverless application eventually had the need for longer-running services that required more intensive processing. To support these processes, we looked at ECS. While Kubernetes is spectacular for deploying services, we wanted a simple solution for running jobs. The obvious choice for us was ECS.

We started running ECS on Fargate, which allowed us to scale easily and get an idea of our usage as we continued to deploy more functionality. Eventually, we moved to using EC2-backed ECS clusters, which offered several benefits for us.

One thing we did have to implement a custom solution for long-running ECS tasks. Tasks that fail to shutdown properly could hang indefinitely. We introduced a scheduled Lambda which looks for tasks that have stalled, kills them, and throws an alarm.

ECS made deploying task-based docker containers incredibly easy to manage and scale.

A single AWS Account

🟥 Regret

We remained on one AWS account for far too long. We always had strong IaC; even with the ability to automate your infrastructure, it was easier to simply have a shared AWS account for our various test, QA, and production environments.

I now strongly believe there are too many benefits to isolating environments in separate AWS Accounts.

Systems Manager

🟩 Endorse

AWS Systems Manager allowed us, with incredibly ease, to enable remote management and access to our servers. While our main API was entirely serverless, we eventually began to utilize ECS backed by an EC2 cluster. Systems Manager allows secure access to servers, which enables significantly easier access and debugging capabilities with an ECS Task failed.

CloudFormation

🟥 Regret

At first, we utilized Serverless to deploy all our cloud resources and under the hood it used CloudFormation. Eventually, we ran into issues with the way Serverless handled deployments, occasionally it determines it needs to destroy a stack and recreate it, so we had to move our persistent resources to an independent CloudFormation stack. We never really looked into better options and I have regretted it since, many times.

When we ported our resources out of our serverless.yml file, I found a library called cloudform that allowed us to build resources with strict typing. This was before tools like CDK had been available, but Terraform was very much an option. We continue to live with restrictions imposed by CloudFormation.

CloudFormation is an unforgiving black box. I am not the only one to realize this. With limited tools for testing or validating deployments locally, you often rely heavily on deploying to a staging environment to test changes. Make a mistake though and your stack will have to roll back, a fun process that can take anywhere between five minutes and five hours with very little rationale as to why.

Today, I would utilize Pulumi, which is built on top of Terraform. I find Terraform to be a tedious endeavor, however, Pulumi provides useful constructs for managing resources and intelligent defaults you do not get with CloudFormation or native Terraform. sst.dev v3 is built on top of Pulumi and provides even more developer-friendly constructs that makes it a great choice for managing applications.

Frameworks

Angular

🟩 Endorse

I picked Angular over alternatives early on for very much the same reason I picked AWS—I knew Angular. Seven years ago, Angular and React had similar popularity and there wasn’t an obvious choice like there is today. React was a great utility; however, it didn’t come packaged with all the tooling and support Angular did making React harder to build with when starting from scratched. React felt better suited to large enterprises who could put a lot of manpower into building applications (e.g., Facebook) while Angular felt like it was better suited to smaller teams. That simply made my choice easier, as Angular came out of the box with great tooling for testing, building, deploying, routing, and internationalizing I stuck with Angular.

Angular proved to be a powerful tool and has gotten better with each subsequent release. I believe it still to be a powerful framework for building and is incredibly easy to get started with. While I would still very much like to say I’d start my next project with Angular, the industry has changed. Angular has fallen in popularity and has seen many of the third-party extensions stagger and lose support for newer versions of Angular. In the past seven years I’ve seen the rise and fall of Vue.js, and today Next.js has come to dominate. Next.js provides similar tooling that Angular comes packaged with. Next.js and React have popular support.

Material

🟧 Regret-ish

I am willing to admit, my skillset when it comes to design is limited. I opted for Material because it worked well with Angular and looked fine to me. Material was a great choice for our patient-facing applications, it is familiar to users, allowing them to flow through the experiences smoothly. Material is a mobile-first responsible design, which does not work well for our clinician-facing consoles that are used on desktops and want optimized experiences as well.

I would have likely regretted using multiple UI libraries for different applications, that would have complicated the experience for the developers building the applications, who are working on several Angular applications. I’d look for a more responsive UI framework that optimizes well for desktop and mobile.

Serverless

🟥 Regret

Serverless is a utility to help build entirely serverless applications and deploy them to AWS Lambdas. It has expanded significantly over the past seven years and, however, almost everything it does has restrictions that we've had to work around. This is partially due to the limitations of the technology Serverless relies on, specifically CloudFormation. Serverless attempts to help you define your API Gateway routes and connect them to Lambdas, it then tries to package your code into zip archives and manage deployments and updates for you.

Serverless doesn't offer official local development support, a popular third-party plugin serverless-offline provides most of the essential functionality and became vital to our development process. It lacks file watch support, which we implemented as a gulp task. Early on our watch process worked well, at some point updates were made to Serverless that affected serverless-offline and our watch process had to restart the serverless-offline process with every file change, significantly slowing the development experience.

Serverless doesn't use esbuild or webpack to build your Lambdas. It zips up your entire project and tries to determine the appropriate dependencies to include, doing so per-function. This was too slow. We eventually had to build our own packaging system that would generate the packaged zips for functions to optimize build times and reduce deployment package sizes.

Serverless doesn't deploy custom resources well. To reduce the risk of Serverless attempting to destroy persistent resources (i.e., our database) we created our own CloudFormation templates and handled the deployments of custom resources entirely outside the purview of Serverless.

Today, I would utilize sst.dev for developing and deploying Lambdas. It provides a practical solution for development, it packages functions with esbuild, and it manages resources with Pulumi.

TypeScript for our APIs

🟩 Endorse

When starting, I was a strong JavaScript and Python developer, having utilized both for years working on machine learning R&D contracts for the Marines and Navy. I thought hard about what to use for our APIs and I decided to utilize TypeScript compiling to run all our APIs with Node.js. My biggest reason for this was that I knew this would be a frontend heavy service, we'd be designing patient portals and wanted superb patient experiences, so the first engineers I'd be hiring would have to be strong frontend developers. I wanted to ensure anyone I hired who may have only frontend experience could still work as a full-stack engineer on the team. I was not significantly worried about application performance, I planned to design the application to be serverless and knew that even if Node.js was slower than Python it wouldn't make the application feel slow. TypeScript allowed us to have the same language for the frontend and backend of our application. My theory held true, several engineers who have come in with heavy frontend experience have found it easy to work on the full application stack, in large part to already being extremely familiar with the language. While I still love Python, the benefits for a smaller team to empower everyone to work as a full-stack engineer are significant. TypeScript has grown in popularity and is now significantly more popular than vanilla JavaScript. Performance of JavaScript has improved significantly and is getting better with runtimes like Deno and Bun, which approaches or beats Python performance in many use cases.

There is significant value in a less complicated stack that empowers more engineers to grow into effiicent full-stack contributors.

Process

Prioritizing building the product

🟩 Endorse

Many of the decisions, both technical and business, focused on delivering value to our customers and onboarding new customers. Time spent on infrastructure maintenance and technical debt was a waste of resources. Many of the decisions, such as to utilize TypeScript and go for an entirely serverless application architecture, were made to reduce the overall time I’d spend on onboarding new hires and managing the infrastructure. To this day, most of the decisions where I did not prioritize reducing effort towards delivering value, such as using Gitlab over GitHub, I reject. In a bootstrapped startup, you have very limited resources, and the most limited of all is your time.

My suggestion is to make decisions that will drive team efficiency.

Monorepo

🟩 Endorse

Early on, we used a monorepo; eventually we decided to split up the projects into independent repositories. The added complexity for managing releases, end-to-end testing, and additional developer overhead was not worth it. After several years, we ported back to a monorepo using Nx. Today, I would use Turborepo over Nx, I prefer how it manages project dependencies independently.

A RESTful API

🟧 Regret-ish

As our Angular applications needed data, we needed an API. As we were using Lambdas behind API Gateway, the obvious option was REST API. REST APIs are wonderful, but it becomes difficult to create useful endpoints that can fully bootstrap a user’s session. As a result, we often find our applications end up making too many requests on startup. I believe there are times for REST APIs and there are times for alternatives.

Today, I would utilize GraphQL when appropriate, in addition to REST APIs, to allow for more flexibility.

Kanban

🟩 Endorse

Early on we spent a moment on sprint planning meetings, I came from a team of a dozen engineers and I fell into the same routine. Agile didn’t work well for our when we were one or two engineers and as we grew to a whopping size of four engineers, sprint planning still would be a lot of overhead for little value.

In a fast-paced startup, where client support, sales demos, and feature development compete for attention, priorities shift constantly. Unlike Scrum, which requires sprint planning, Kanban lets us adapt instantly, ensuring we could respond to changing needs without the overhead of excessive planning.

Kanban was the right approach, and I have come to believe it a superior system for smaller teams. Maintain priorities diligently so you always know what to do next, and stay focused on your current assignment if at all possible. My primary goal when using Kanban is to minimize the times you need to pull engineers out of work they’ve begun, and to ensure they always know what they should pick up next. Continue to run retrospectives and incorporate feedback from the team into your process and product.

Cost tracking and resource budgets

🟥 Regret

Early on, our costs were minimal. We designed an entirely serverless application, and production costs remained low for the first two years. Then, as we rapidly expanded, our costs suddenly spiked to $6,000 a month, quickly eating into our limited financial resources—something that could have been easily avoided. At one point, our biggest expense was the SSM Parameter Store, due to a poor implementation of how we loaded parameters. We should have been using AWS Secrets Manager instead.

Later, adding a NAT within our VPC escalated costs again, as we hadn’t implemented the proper VPC Endpoints.

We also incurred massive, unnecessary costs due to a poorly configured AWS Backup plan, which backed up our entire DynamoDB database daily—even though we had PITR enabled and our only tested recovery process relied on DynamoDB’s native restoration capabilities rather than AWS Backup.

The key lessons here:

1. Implement a monthly budget review process for cloud expenses.
2. Investigate unexpected cost increases early.
3. Set up and use AWS Budgets to track spending and prevent surprises.
4. Always analyze new infrastructure costs before scaling.

Continuous Delivery

🟩 Endorse

We invested early in a fully automated CI/CD. A good CI/CD ensures deployments are consistently reliable. We hosted the CI/CD on Gitlab and eventually refactored it to GitHub Actions when we migrated to GitHub. Our strategy was simple: deploy early, deploy often.

We wanted to deploy features the moment it was partially visible, usable, or functional. This allowed us to incorporate feedback we built. Due to limited development resources, we usually delivered minimal viable features and moved on to other priorities for a time. We’d return to enhance features after gathering additional feedback from several clients.

Feedback is a vital part of a good SLDC. Clients typically like being part of the process.

Life without QA

🟧 Endorse-ish

We didn’t have a QA analyst for the first five years. We maintained continuous delivery continuous, regularly with numerous deployments to prod a day. While we managed to produce high-quality work and rarely had outages, it was due to diligence of every developer testing their work. It was difficult and risky at times.

Unit testing and integration tests are essential; invest in automated testing early. Write an appropriate amount of test coverage. Set a high bar for developers to test their changes thoroughly. Review every pull request diligently. Hire a QA.

Project Management

🟩 Endorse

We didn’t have a Project Manager for the first six years. Yet, we built a product that delivered exceptional value to our clients. I typically filled the role of a project manager. In my opinion, engineers make good product managers, but they rarely want to do the work.

Clients and Sales rarely ask for a feature without a purpose, but they typically ask for a solution without explaining the reasoning behind it. Often, the request is what they believe to be an “easy to implement” feature. A project manager with the appropriate knowledge of the technology can help determine the right approach. It is vital to understand the issue actually being solved by the request.

Good project managers should be technical. Engineers who want to build products that delight users need to understand the reason behind the request.

SaaS

Slack

🟩 Endorse

For development teams, in my opinion, Slack remains superior to Microsoft Teams. Slack has added many useful features over the past seven years and continued to prioritize its integration and easy for collaborative communication.

Jira

🟥 Regret

We used Jira for our development and support tickets. I have never liked it, and I didn’t like it going into the start. It was what I was familiar with. Jira remains a bloated and costly software, providing little value over many alternatives on the market today.

I would likely try out Linear for our development tickets, although I’ve not used it, I am impressed with the feedback I’ve heard, the technical design, and the user experience they focus on delivering. Linear offers a more modern UI, faster performance, and a streamlined workflow compared to Jira.

For client support tickets, I would select an omnichannel support system. Clients would rather not make tickets in a ticketing system, they want their issues heard, and they want to be replied to. You need to respond to clients telling them you are looking into the issue and will follow up, you need to follow up, customers are everything to a SaaS and through diligent customer service we grew our company. We used Jira and made it work, but it had significant overhead. A simpler tool to ensure all emails are received, issues reported during phone conversations are logged, and the issues get assigned to the appropriate team (e.g., implementation or development) is vital.

Confluence

🟥 Regret

We used Confluence since we used Jira. Confluence, like Jira, is bloated. It provides a complex organization system when you want to keep information ready at your team’s fingertips. It is vital to have a place to store company information, but it needs to be incredibly easy to add documents and information to.

Gitlab

🟥 Regret

I opted for Gitlab at the start as it was cheaper than GitHub, this was before GitHub lowered their prices to match Gitlab, and I could self-host it to improve security and privacy. I knew this application would be dealing with protected health information. The issue was managing Gitlab. We were a small startup, for several years we had only two engineers. Taking on managing Gitlab servers and runners was more overhead than it was worth. When GitHub dropped their prices, I immediately said, "yes please" and we moved to GitHub. Overall, GitHub is great, popularity is unquestionable, and they've continued to expand GitHub Actions to become a powerful CI/CD platform that I now appreciate and find more powerful than most CI/CD platforms I've worked with.

Today, I would pick GitHub from the start.

Software

JavaScript Standard Style

🟩 Endorse

Early on, I added strict linters to our codebase. My goal was not to be pedantic, but to improve the long-term maintainability of the codebase. I had little opinion as to the rules of the linter, so I picked JavaScript Standard Style as our base set of rules. The one change I made was to strictly require trailing commas, I have found it makes git diffs easier when you can see only what is being meaningfully changed.

I believe having appropriate tools in place to manage an ever-growing codebase is vital, doing it from day one will avoid the need to clean up the code in the future. Pick some rules and enforce them.

BabelEdit

🟩 Endorse

BabelEdit is a great internationalization tool, has worked well for us.

Dependabot

🟩 Endorse

Dependabot is a tool to manage your dependencies and help keep them up to date. It is incredibly helpful to continuously keep dependencies up to date. If they stagnate, it becomes much harder to handle upgrades. Having an automated tool has become a must.

Snyk

🟩 Endorse

Security was always important for us, my background was in military contracts and I had an expertise with information security. Working with PHI, we needed to take security seriously from day one. Snyk was a great tool to help us with that, it integrated into developer IDEs to help them avoid mistakes to begin with, integrated into our pull requests to avoid committing mistakes, and monitoring dependencies for vulnerabilities. We eventually added its infrastructure and container scanning tools. Put these kinds of tools in place early on.

Hardware

Apple MacBooks

🟩 Endorse

Apple MacBooks are a fantastic product and a great device for developers.

There are only two hard things in computer science: cache invalidation and naming things.

After many years as a software engineer, I have a proposed revision to this statement:

There are only three hard things in computer science: cache invalidation, naming things, and timezones.

See xkcd #2867.

This is a cross between two other grille cheese recipes, one by Alton Brown and the other by Chef John.

Ingredients

• 2 slices sourdough or hearty country bread
• 2 tablespoons unsalted butter, at room temperature
• 40 grams (~1.5 ounces) extra sharp cheddar cheese, grated
• 40 grams (~1.5 ounces) Gruyere cheese, grated
• ½ teaspoon dry mustard
• ¼ teaspoon freshly ground black pepper
• ¼ teaspoon smoked paprika (optional, depends on what you’re pairing with the grilled cheese)

Directions

1. Grate your cheeses; then combine the cheeses, mustard, paprika (if using) and pepper in small bowl.
2. Melt 1 ½ tablespoons of the butter in a nonstick skillet over medium-low heat. Place bread slices in the skillet on top of the melted butter.
3. Spread about 75% of the cheese mixture on one slice of bread; place the other slice of bread, butter-side up, on top of the cheese. Spread half of remaining cheese on top of the sandwich.
4. Melt remaining ½ tablespoon butter in the skillet next to the sandwich. Flip the sandwich (carefully) onto the melted butter so that the cheese-side is facing down. Spread remaining cheese on top of the sandwich. Cook sandwich until cheese on the bottom is crispy and caramelized, 3 to 4 minutes. Flip sandwich once more and cook until cheese is crispy and caramelized on the other side, another 3 to 4 minutes.

In the original recipe, the mixture calls for a saffron-infused crust and the filling comes out like soup, which doesn't work well for a pie filling. I've removed the use of the saffron crust; while I enjoy saffron, using it the crust is a waste and the flavor never comes out well. I also have changed most of the filling, starting it with a roux, so the result is something that only slightly resembles the original recipe.

So here's my version:

Ingredients

• 1 pie crust (you can make this, but honestly, ones from the grocer work)
• 1 package (12 strips) of bacon (avoid use of thick cut, it won't crisp in the same way)
• 1 stick of butter
• 2-4 tablespoons of flour
• 1 small onion, diced
• 1 large carrot, cubed
• 1 small potato, cubed
• 1 pound of meat (steak tips or lamb shoulder preferred, but this is a stew so you can use chuck, stew meat, or even regular ground beef), cut into 0.5-1" cubes
• 1/2 cup low/reduced-sodium vegetable stock
• 1 tablespoon of rosemary
• 1 tablespoon of thyme
• 3 bulbs of garlic, minced

Prepare the bacon

1. Preheat oven to 400F
2. Form a lattice from the bacon, weaving the strips together into a square
3. Roast bacon on a cooling rack set inside a half-sheet pan for 15-20 minutes, until just starting to become crispy
4. Remove from oven, allow to cool

Prepare the crust

1. Place pie crust into a pie dish. One with higher edges preferred over the most classic dessert pie dish. Ensure the pie crust goes up to the edge of the dish.
2. Blind-bake the pie crust per directions, usually requires baking for 15 minutes at 425F.

Prepare the filling

1. Reserve 1 tablespoon of the butter.
2. Melt the rest of the butter over low-medium heat.
3. Slowly add 2 tablespoons of the flour, mixing constantly, until flour if fully incorporated. You may need the additional flour. We're trying to make a roux, no lumps of the flour should remain. Once all desired flour is added, continue to stir the roux and allow it to cook for 1-2 minutes. It'll darken slightly, this allows the flour to fully incorporate and is important to remove any floury taste.
4. Add the vegetable stock. Continue to mix to incorporate.
5. Turn temp down to low.
6. Allow mixture to cook, stirring occasionally, for 10 minutes. The mixture will thicken as the stock incorporates.
7. In a separate pan, add reserved butter and then cook the onions until they start to become translucent.
8. Add carrots and potatoes to onions, continue to cook until onions have browned, potatoes and carrots are softened.
9. Once onion, carrot, potato mixture is cooked, add mixture to the gravy-like filling mixture along with any juices and remaining butter from pan.
10. Add some bacon grease from the tray you baked the bacon on to pan.
11. Brown your meat in the pan, strain, then add meat back to pan.
12. Sprinkle meat with herbs, toss.
13. Once meat is mostly cooked, reduce heat and add minced garlic to meat.
14. Allow meat to cook until just before desired doneness, do not allow garlic to burn.
15. Add meat to the filling.
16. Allow the filling to cook, to fully incorporate flavors, on low, for at least another 10 minutes and up to two hours, stirring occasionally. Using more time hear allows flavors to really develop. The mixture will continue to thicken and reduce as steam escapes.
17. Taste the filling, adding salt, pepper, or more seasoning as desired.

Prepare the pie

1. Add filling to blind-baked pie crust.
2. Place the crispy bacon lattice atop pie, this acts as the top pie crust.
3. Bake in the oven for 30-45 minutes, allowing the filling to fully set and solidify (made possible thanks to the roux).
4. Removed from oven and allow mixture to cool slightly, 10 minutes at least, before cutting; otherwise the filling may still splatter out.
5. Enjoy.

It is easy to call JavaScript an “all-purpose programming language”. It allows someone to easily create desktop, web, mobile, and embedded apps and services with a single programming language. It’s a great first-language to learn for new developers.

MongoDB, however, is the weakest link in this popularized technology stack. Someone coming out of a bootcamp, whose only database of knowledge is Mongo, will often struggle as they build an application. I worry for those individuals who might walk out thinking they have all the tools necessary to do something great. They may be thinking MongoDB is an “all-purpose database”.

For anyone who hasn’t​ struggled to scale Mongo in production: Mongo is an incredibly easy database to use and develop with, but it’s not an all-purpose database. Mongo is a document-store database. While Mongo is flexible, it cannot possibly do everything a growing service demands.

That’s the thing: no database is all-purpose.

Let’s compare: Databases vs. Delivery Service

Let’s compare different types of databases to aspects of a delivery service. Imagine your application provides a product. Imagine that product is a vacuum cleaner.

Your product if nifty and neat, therefore, it’s​ in high demand. You want to be able to deliver these amazing vacuums to your customers quickly and efficiently!

Delivering products has a lot of logistics problems. There is no “one way” to deliver a product, you need different capabilities for different purposes.

Let’s compare.

Semi-trailer Trucks

A semi is quite versatile. It can do just about everything. You could even store all your vacuum cleaners on your semis. You can, if necessary, drive your semi up to your customer’s doorstep and drop off their brand new vacuum to them.

You can tell though, a semi isn’t going to be great at doing everything. Certainly storing all of your vacuum inventory on semi trucks can’t be the most efficient method; what happens when you run out of space? You’d have to buy another semi truck. You might also have difficulty finding the right vacuum you need to deliver due to having too many extra vacuums in the way. Often though, a semi won’t work for that last-mile delivery, getting the vacuum on the customer’s doorstep. Semi trucks are too big to fit on some streets or in some driveways.

Document storage databases, like MongoDB, are like a semi truck. Storing all of your data in a document-store can get you started, but it’s not going to be efficient. When you have enough data, you need to start sharding your database. This can add a lot of complexity finding the right data (or vacuum) when you need it. Document-stores aren’t optimized for searching, so searching over your data sets, even with an index, can be slow. It can be difficult to optimize queries to return only the data you need, resulting in a lot of wasted effort transmitting unnecessary data. Additionally, it isn’t quite fast enough to provide the blistering fast performance your application might demand.

Clearly using only semi trucks isn’t the best idea. What else do we need to make our delivery service work?

Warehouses

If semi trucks cannot provide the best storage for all of your vacuums, could you stored the vacuums you aren’t actively delivering in a warehouse? A warehouse is definitely going to be able to help keep your vacuums safe. With some foresight you can organize your warehouse so it’ll always be easy to find the right vacuum when you need it. Clearly, any good delivery service needs a warehouse.

SQL databases, like MySQL or PostgreSQL, are like warehouses. They are perfectly designed for storing all the data you need to organize and store.

Just like actual warehouses, SQL databases requires proper setup to scale. Without the proper foresight into your database setup, as you add data it will will increase retrievable times significantly, making your service slower. A poorly designed database will destroy your application’s ability to scale as the amount of data it’s indexing and organizing grows.

So what you might say? Rather than trying to organize your pile of vacuums, you might say “Let’s just buy another acre of land and expand our warehouse!” That doesn’t scale infinitely, just like throwing hardware at your failing database’s scaling needs. It cannot last.

There are times, even when your warehouse is perfectly organized, that retrieving the right vacuum from your inventory is still too slow. Warehouses are really only designed to hold your vacuum cleaners.

Since a warehouse cannot drop a vacuum off at a customer’s doorstep, if used only warehouses you’d have customers coming to pickup their order from your warehouse. That would be terribly slow and inconvenient to your customers. Clearly a warehouse isn’t going to be very good at those last-mile, to the doorstep, deliveries.

It is starting to feel like you’re going to need a warehouse and semi trucks; but clearly warehouses still have weaknesses. What can we do about that?

Warehouse Robots

Robots are cool, aren’t they? When a warehouse has enough of those amazing vacuums being stored, it slows down the time it takes to find a specific one. What if we used robots to help us get the right vacuum even faster?

Warehouses often use robots to retrieve inventory from their shelves. This speeds things up, helping the products get to customers faster, while putting less pressure on the non-robotic employees of the warehouse.

Warehouse robots are similar to an indexing service, like Solr. An indexing service helps speed up searches on top of your massive amounts of data you keep in your databases. This performance can help reduce the time it takes to find whatever it is your application needs. As you continue to get more inventory in your warehouses, it becomes increasingly more important to have good indexing and automation.

Using warehouse robots can certainly help us speed up warehouses when they need to perform difficult searches. Now you’re getting to a reliable delivery service! If you use all three of the current options: semis, warehouses, and a robots, your delivery service will do pretty well! But what if you continue growing and have to optimize your delivery service even more?

Vans

As we know, a warehouse can’t even attempt to make a last-mile delivery; and semi trucks have a lot of challenges making it all the way to our customer’s doorsteps. So what about what about a van?

A van is much smaller than a semi, so it can fit down those narrow roads and onto tight driveways. That would allow our drivers to get those vacuums to our customers even faster! A van is nimble and capable of tough crowded city roads or a country road.

A van is comparable to a key-value store, like Redis or any memcache. A key-value store is extremely fast! It provides amazing performance for data that’s been loaded into it from another data source, making it perfect for caching to help make the entire service faster.

Unfortunately, vans are cramped. You definitely cannot use them for storing your inventory. Even if you can expand the storage space, the design limits you to getting the vacuums out in a limited number of ways.

Key-value stores provide amazing performance, but they rely heavily (or entirely) on a server’s memory to provide this performance. They also have limited retrieval options, many have zero querying support, can only lookup by a specific key. It’s almost impossible to search a key-value store. They’re simply not designed for it.

Clearly your delivery service needs warehouses and either semi trucks or vans. Possibly all three! Depending on how popular our delivery service is, we might still need those warehouse robots. If you are using all of these options at your disposable, is it possible to outgrow what these provide us?

Delivery Logistics

Sometimes a delivery service has too much going on. Sometimes it might just be getting so complicated, having multiple warehouses, dozens of semi trucks, potentially hundreds of vans and robots helping us out. We really need something to help piece everything together.

We clearly need something to help with these logistics. Something that can help us keep track of where everything is, whose is whats, and whats is whose.

You need an operations manager. You need someone, or something, that can stay aware of the high-level details, just the status of things. An operations manager doesn't need to know exactly how much inventory is available or when the earliest delivery possible might be; but the operations manager would help speed up operations between services, provide helpful logistics, reporting, insight, and analytics.

A graph database, such as Neo4j, is a great tool for this. While you’d be hard-pressed to use a graph database for storing any inventory, it can certainly help with that network of information. It can help speed up those messier queries and help you quickly know the exact status and location of the data you needed.

Clearly we now have a scalable delivery service. One that will allow us to continue to grow through new challenges and handle delivering any amount of vacuums our customers demand.

Takeaway

I hope you’ve come to realize that a single-database service will almost always eventually fail on its own, like a delivery service that has only one type of mechanism to deliver a product. To build an application that can scale under a constantly growing demand, you may need to use a variety of tools. While a database like MongoDB is going to help you get started, if you don’t plan for growth you’ll quickly find challenges managing your growth.

I hope more people start mentioning the importance of using the right tool for the job and learn about the types of technologies that are available to help you through even the toughest scaling challenge.

Ingredients

• Marinade:
• 1/2 small onion, chunked (if using food processor), diced fine (if without the assistance of a food processor).
• 1/4 cup of soy sauce (traditionally brewed preferred)
• 2 tablespoons of firmly packed brown sugar (dark preferred)
• 2 tablespoons of lemon juice
• 2 large garlic cloves
• 1 teaspoons of salt (only if using low sodium soy sauce)
• Meat:
• Half a rack of lamb chops or 4 filet mignon steaks
• Cheese:
• 6oz goat or blue cheese

Create the marinade

1. Place ingredients for the marination into food processor, whirl until onion and garlic are diced fine.
2. Pour marination into a 1-gallon zip lock bag, place your prepared meats (see below) into the bag.
3. Refrigerate for minimum of 30 minutes, ~6 hours preferred.

Prepare the meats

1. For lamb: Add the cheese pockets by cutting a small slit on the backside of lamb chops, about 1/2” deep, to the bone.
2. For steaks: Add the cheese pockets by cutting a small slit on the side of the steak about 1/2” deep.

Preparation for grilling

1. Heat grill to 425°F
2. Remove chops or steaks from marinade, reserving the liquid.
3. Stuff cheese pockets with your choice of cheese.
4. Place meats on grill, cook to desired doneness.

Using your leftover marinade

Consider your options. I recommend #2.

1. Baste the meats once with reserved marination liquid.
2. Turn marination into sauce. Heat in a pot on the stove until it just starts to boil, keep temp low and simmer for 3-5 minutes until thickened.

Ingredients

• 16 oz sour cream
• 16 oz cottage cheese (preferably with chives)
• 1.5 tsp Lawry's seasoned salt
• 1 Tbsp garlic powder
• 1 Tbsp dehydrated onions
• 1 Tbsp dehydrated dill

Process

Mix all ingredients, preferably the night before to let the onion and dill hydrate and absorb moisture.

It can be hard to taste test because the onion and dill flavor will strengthen. The color should be visibly, but very sightly, red from the seasoned salt. Dill should be visible throughout the mixture, enough to get a little with every chip.

If you use fresh drill, add a bit less as the flavor is strong. The mixture might end up more watery, but flavor will be good.

There’s a lot of chatter and concern about S.J. Res. 34, a pending resolution that will allow Internet Service Providers (ISPs) to record your activity and then sell that information. From what I have read, most people are focusing on your “web history.” This focus is harmful because there are many additional types of information that can reveal details about you, and you cannot solve this simply by using a VPN.

Even worse, people are out there have invalid conceptions of what data will be available; some are going as far to try and get money from people who are uninformed. That is very wrong. Let’s explore exactly what an ISP will be able to know about you.

To keep terms consistent, I will use the FCC’s term of BIAS (“broadband Internet access service”) to refer to all internet service providers (ISPs).

Why does this matter?

While this article isn’t going to get into the nit and grit of why you should care about your data and privacy, even if you think you have nothing to hide or to be concerned about, it’s important to understand what this resolution will do, if passed. It specifically will dismantle the FCC’s rule “Protecting the Privacy of Customers of Broadband and Other Telecommunications Services” (81 Fed. Reg. 87274). This set of FCC rules and regulations are more extensive than just protecting your web browsing history, it protects and prevents the recording of several sets of specific information by your BIAS.

What information does the FCC’s Privacy Regulations protect?

The FCC’s regulations protect the following information from being collected without the consent of the customer. A BIAS already has the technical ability to record this information, and could do so with customer consent, but they want to record this information without the customer’s consent. That by itself might make sense if it was purely for the operation of the service, but they explicitly want to sell this information, claiming that doing so will allow them to offer targeted marketing and thereby lower the cost of the service to their customers. While I highly doubt that they’ll ever lower the service cost, it is important to know that it has always been possible for your BIAS to see the information the FCC protected by claiming it was sensitive information. For those who are truly concerned about their privacy, even now these suggestions can help you improve your privacy and protect your data.

These are the categories of information the FCC’s regulations protected:

• Broadband Service Plans
• Geolocation
• MAC Addresses and Other Device Identifiers
• IP Addresses and Domain Name Information
• Traffic Statistics
• Port Information
• Application Header
• Application Usage
• Application Payload
• Customer Premises Equipment and Device Information

Let’s break down what this information means

Let’s go through the list above, breaking down what it means and think of ways to protect this information (if possible).

Broadband Service Plans

The FCC regulations stated that the Internet package you get from your provider is sensitive. This is because it reveals information about the quantity, type, and amount of use your home consumes. If you have a higher tier package, you might be more interested in video games, online video streaming services, or want more adult porn advertisements than someone with a lower speed.

This included protecting all types of services: mobile, cable, fiber; whether you are contract, prepaid (monthly); and included protecting the network speed, price, data caps, and data usage/consumption.

Besides changing your Internet provider (see below), there are not a lot of realistic options available. You could (if you don’t have a cap) consume several terabytes of data a month by seeding legal torrents like Ubuntu, CentOS, or become a host for Wikipedia dumps. Doing so will skew this information, hiding your actual usage amounts. Of course, you can also setup your own Hyperboria connection and hope that more services start to support the meshnet.

Geolocation

“Geo-location is information related to the physical or geographical location of a customer or the customer’s device(s), regardless of the particular technological method used to obtain this information.” — Federal Register / Vol. 81, № 232, Section 87282, #65

The FCC claimed that any means of determining your geolocation is considered private, and is not allowed to be recorded or shared without the consent of the customer.

Many devices, including laptops, tablets, and phones have built-in GPS. Your device will not simply report your location to your BIAS, so what is more likely is that they’ll use your home address, or data about your street, town, or region to allow for targeted individual to regional marketing.

You are usually legally required to provide your address to an Internet service provider; as a result, there is little you can do to protect this information. Your only option is to switch providers to a service that cares about you.

MAC Addresses and Other Device Identifiers

The FCC regulations stipulate that collection of device identifiers, of any kind, are protected. Each networking device has at least one MAC address; this is a unique identifier of that device’s networking hardware.

While a MAC address is only revealed during the link layer of networking, depending on your broadband service this may be an issue. If you are connected directly to the Internet or using service provided hardware for your modem or router, then this information can easily be collected.

This, I am happy to say, you can do something about. If you’re using any service provided equipment (e.g. modem or router), you have two options. The first is to stop using the provided hardware entirely. That might help save you money longterm; there is often charge for “Equipment Rental Fee” for the privilege to use their crappy hardware anyway. Instead, buy your own hardware to replace it.

Replacing your service provided hardware depends on your service provider, it may not possible, so the second option that everyone has is to add your own device between your devices and your service provider. Many people already do this by having their own wireless router. Simply be sure that all of your devices connect to it first, this will report only a single MAC address to your BIAS, one that will show itself to only be a gateway device of some kind, keeping the actual devices you use private.

A third option, that doesn’t require buying hardware, would be to use a MAC address spoofer to have your devices lie about their MAC addresses. This can lead to a lot of complications and difficulties, but for those advanced users who want to protect themselves, it is available.

The use of a VPN would not protect you from revealing this information.

IP Addresses and Domain Name Information — Domain Names

While the FCC bucketed this category as “IP Addresses and Domain Name Information”, we will look at these as two separate issues because we can solve for them differently. Let us first look at the Domain Name Information. The FCC had this to say:

“We also conclude that information about the domain names visited by a customer constitute CPNI [Customer Proprietary Network Information] in the broadband context.”

A domain name is simply the name of a website that is human-readable, something like “fcc.gov”, “medium.com”, or “google.com”. These are simple for us humans to read and understand — for a computer, however, they need to be translated into an address that can be routed to. For this, computers use DNS or the “Domain Name System.” Simply, someone buys a domain they’d like to use, and they point it to the server they’d like computers to talk with whenever that domain is requested.

Your BIAS provides your default DNS provider as well, and the FCC was careful to ensure that they protected you regardless of the DNS provider you used:

“Whether or not the customer uses the BIAS [Broadband Internet Access Service] provider’s in-house DNS lookup service is irrelevant to whether domain names satisfy the statutory definition of CPNI.”

Your DNS provider is essentially the database you request when your computer needs to know the IP address a domain points to. This is necessary because there are too many domains and the IP address that a domain points to updates too frequently to have this entire database available locally on your computer. While your BIAS provides your default DNS, you can easily swap the DNS provider. Many good, free alternatives exist. Google Public DNS and Cisco OpenDNS are two very popular alternatives.

However, your use of an alternative DNS provider does not protect you! Back in the day DNS was first developed, the focus was on getting this little thing known as the Internet working before the focus of privacy and security was even raised. So DNS is not encrypted or secure. Even using an alternative DNS provider, your BIAS is able to track the domains that you are looking up, thereby revealing the domains you are requesting. This happens even if you are visiting secured web pages using HTTPS.

You have a few options here, the easiest available to most is to use DNSCrypt, which has clients for most devices and is very easy to setup and use. Other possibilities may include DNSSEC, DNSCurve, and DANE.

Whether or not you use a VPN, your DNS requests may not be encrypted by your VPN client, or you might end up using your BIAS’ as the DNS provider, so swapping DNS providers and encrypting your DNS requests is always beneficial.

IP Addresses and Domain Name Information — IP Addresses

We now enter the more difficult of the two issues bucketed together by the FCC, the IP addresses you are requesting. Domain names translate directly into IP addresses, so after your computer has (hopefully securely) determined the IP address it needs to connect with, your computer needs to make the request to that IP address. The FCC did protect you here:

“We conclude that source and destination IP addresses constitute CPNI in the broadband context because they relate to the destination, technical configuration, and/or location of a telecommunications service.”

This protection would go away; now your BIAS can easily record the IP address you are requesting. At the same time, the destination address you are connecting with can see your source IP (your home’s unique IP address). An IP address alone tells a service a lot about you. If it’s unique enough, it may reveal exactly who you are, but it always reveals your BIAS/ISP and your geographic region.

This has long posed a major privacy concern to many people and there are many services such as Private Internet Access which provide a means to protect you from leaking this sensitive information. The most popular means is a VPN.

A VPN, or “Virtual Private Network,” keeps your home’s IP address protected while also encrypting and securing all your requests so that your BIAS cannot determine the true destination of your requests. Only the VPN provider will now be able to link your originating home’s IP with the true destination IP. For that reason, many of the more privacy-concerned VPN providers do not record any information.

Most VPNs protect you by implementing IPSec or a similar protocol, which is a protocol designed to encrypt all connections at a lower-level of the request, so that your applications do not need to be aware their requests are being hijacked and routed through a VPN. This makes using a VPN extremely easy. Some client software include additional privacy, security, and bandwidth saving features such as malware protection, ad & tracker blocking, and compression. A few offer real-time image and video compression to save your even more bandwidth, which can be extremely useful for mobile devices or specific geographic regions.

So this can be easily solved for! To prevent your BIAS from seeing the IP addresses you are visiting and the destination server from seeing your source IP, start using a VPN.

You can setup your own VPN, but it requires knowledge of setting up servers and running commands. For most you can search for and find a VPN provider easily. Just be careful to find one that does not log your traffic and one that is large have enough bandwidth that your traffic is not extremely slow. I personally use Private Internet Access. I’ve been using them for several years, however, there are other options out there.

Why is a proxy not an option? While you get very similar results while using a proxy as you do when using a VPN, the downside is that a proxy generally does not encrypt your connections. This means that the destination might not be able to see your source (your home’s) IP address, but your BIAS can certainly see all your traffic still. Some proxies, like HTTPS proxies, can encrypt connections, but they only support encrypting your web traffic. This means that it is not easy to configure a system-wide proxy (although apps like Proxifier do exist for that). As a result of using only a proxy, much of your computer’s traffic will not be encrypted, secured, or kept private.

Why is Tor not an option? Tor is actually a good option, but it is a limiting one. While Tor may be private, it is generally not used for the entire system, so many apps, just like when using a proxy, will still reveal information. Tor is also not great when making insecure connections (like HTTP vs. HTTPS), as it means many people along the way can both see and change the data being transmitted. Tor is decent to use when in a pinch, but it’s not going to solve all the problems.

Without the use of a VPN, you cannot hide all of the IP addresses you are requesting from a BIAS (although a secure proxy and Tor can hide some). Once the IP address you are requesting is known, it is a simple matter of doing a reverse DNS lookup on the IP addresses to get an idea of the websites you are visiting. If the connection is secure and encrypted, they’ll still know the website you are loading, but not the page or data being sent or received.

Traffic Statistics

Traffic statistics cover a range of information, including the destinations being requested (which I mentioned above, you can hide with the use of a VPN), but also including the amount of data consumed broken up either by month, by day, time of day, and including the size of data and packets.

Even when using a VPN, the amount of traffic consumed can reveal information about your habits. However, the size of packets by connection can also reveal details like whether you are streaming a video, downloading large files, or browsing the web. While you might be able to hide the specific video being watched, file being downloaded, or website you are visiting; you cannot hide this information from BIAS providers.

The FCC protects mobile services from selling your call history, including the number you spoke with, the duration, and time the call was placed or received. The FCC similarly protected our Internet habits, but you will lose this protection and regardless of the use of a VPN a BIAS can determine valuable information from the way you use our connection.

This again is another point where our only option is to switch providers to one that protects our data.

Port Information

A port is a number that helps both the sender and the receiver of a connection request know what service is being requested. This, alongside the IP address of a request, is protected by the use of a VPN. Without the protection of a VPN, even now, each connection your computer makes has a port associated with it that reveals information about your habits. This happens even if you are connecting to secured websites. There is a list of popular ports used by applications on Wikipedia.

Your BIAS can view this port, to know the type of application you are using, determining information about your habits. Such as traffic on port 80 or 443 reveal you are browsing the web, or traffic on port 6881–6887 reveal you are using a BitTorrent client. Securing yourself with a VPN protects this information from being revealed to your BIAS.

Application Header

We’re now getting into a category of tracking that should truly worry all people. The FCC defined Application Header as:

“The application will usually append one or more headers to the payload; these headers contain information about the application payload that the application is sending or requesting. For example, in web browsing, the Uniform Resource Locator (URL) of a Web page constitutes application header information. In a conversation via email, instant message, or video chat, an application header may disclose the parties to the conversation.”

The FCC was exactly right. Many requests reveal a lot of information in those connection headers, including the domain you are requesting, the page being requested, the application you are using (i.e. web browser you are using), and request headers like the search terms you are requesting. Now, many web servers are encrypted using TLS/SSL (HTTPS), so for any encrypted connection, none of this information is revealed to anyone except the destination server.

This is also true when using a VPN. Even when using a VPN, any insecure connection is still going to be visible to the VPN provider. Whenever you make an insecure connection, there is exposed risk of a MITM attack (“man in the middle”). A MITM attack allows anyone between your computer and the destination to change the request or response, without either party being able to tell it was changed. This has been a security risk for a very long time and is why there are movements like Let’s Encrypt making it easier for website providers to encrypt their traffic supported by major services like Mozilla.

To protect yourself, you should always use encrypted connections when they are available. I strongly recommend the use of HTTPS Everywhere, a browser extension that works with Chrome, Firefox, and Opera to automatically reroute your request to be secure when a website supports encrypted connections.

I use HTTPS Everywhere with the additional feature to “Block all unencrypted requests” enabled. Doing this poses a noticeable impact on the usability of the Internet, but it protects me. Services such as eBay.com do not support whole-site encryption, as a result, whenever you browse ebay.com the searches you perform and products you look at are revealed to your BIAS. That is unacceptable to me and I refuse to use eBay again until they fix this major flaw to their users privacy. Many other similar situations exist, but all the good websites out there support full encryption. For the most part, blocking all insecure requests does not affect my usage of the Internet. (Although, I wish Amazon’s short urls http://a.co/… supported HTTPS, because when people share a link to an Amazon Product, I now don’t have a way to hide the product I am about to view).

Application Usage

A BIAS still might be able to determine the applications you’re using to generate connections, regardless of you using a VPN. Due to the variety of ways a BIAS can collect information about you, it is possible to use heuristics and machine learning to determine this information. The applications used, such as your web browser (e.g. Chrome, Firefox, Opera), messaging, email, music/video streaming, or torrent applications all generate traffic. They do so in unique ways and have unique characteristics that make it possible (if difficult) to determine even when you use an encrypted secure connection.

To truly hide this information, your best chance is to use a VPN with a client that supports good encryption.

Beyond just the application you use, many services are unique enough that with a VPN and encrypted connection it is possible for your BIAS to determine specific habits. Specifically, streaming technologies from unique services like YouTube, Netflix, Spotify, and many video games are optimized enough (to save bandwidth) that their unique patterns of requests can be determined even through the encryption. While your BIAS might not see the specific video being watched, they can determine the service, time of day, and size of requests to get an idea of the kind of videos you are watching. You cannot protect yourself from this data gathering, without the regulations the FCC put in place.

Application Payload

Every connection has two parts key parts, the headers (discussed above in “Application Headers”) and the payload. While the headers reveal information about the pages and metadata about the clients being used, the payload is the actual content of a request. This is the HTML content of a web page, that makeup the body and text you see. It is also the content of every image, video, and file requested or downloaded.

Similar to protecting your Application Headers, any secure connection protects this information from being revealed. The use of a VPN can help hide more details from your BIAS, but you should always prefer the use of a secure connection over an insecure one, so install HTTPS Everywhere.

Customer Premises Equipment and Device Information

I’ve touched on this in the “MAC Addresses and Other Device Identifiers” section, that hardware provided by your BIAS is suspect and should be untrusted. However, the FCC specifically claimed that the hardware they provide should be protected. This means that the model of the devices they provide cannot be sold, as that might reveal the service, package, or capabilities of your service. They protect this specifically because the FCC similarly protects customer of mobile/wireless service providers by not allowing mobile services to sell information about the mobile devices being used, such as the mobile of cell phone you use. While your mobile service knows that information, they cannot reveal or sell it to others. The FCC wanted to protect us similarly, even if the hardware was provided by the BIAS.

While you cannot protect yourself from this data being collected, you can make the information they have less meaningful. Even if you are forced to use provided hardware (e.g. router, modem), you can often adjust its settings to lock it down, disable shared wireless signals. Or, even better, add your own hardware to the mix, as to not reveal anything about your home’s actual devices such as their MAC addresses.

Takeaways

I realize this is a lengthy article, but it is necessary to see how much information is truly at risk, and while you can do a lot to protect yourself, you are not in control of much of the data that is going to be collected and sold about us.

For those who want to do all they can, the list is this:

1. Switch providers (see below) if at all possible, to one that will not sell your data.
2. Use a VPN to protect and encrypt your traffic from your BIAS and to hide your source (your home’s) IP address from others.
3. Enable DNS security, use DNSCrypt or DNSSEC and change your DNS provider.
4. Use HTTPS as much as possible, install HTTPS Everywhere.
5. Be sure to use a device you control as your Internet gateway, so none of the device’s unique identities can be revealed. Setup your own wireless network and replace any provided hardware if possible.

If you take these precautions, this is the kind of information your BIAS will be able to know and sell about you:

1. Your Internet plan, including price, speeds, and data caps.
2. Your Internet usage, including data consumption, and times of days you use it.
3. Your geolocation (down to your address).
4. The manufacturer of your gateway/router device (possibly).
5. Potentially be capable of identifying the services you use for video or music streaming, or that you play video games.
6. Without a secure VPN, the IP address (and domains through a reverse DNS lookup) you communicate with.

For those with misconceptions, I am not trying to downplay the severity or the damage that removing these regulations will have on the privacy of American people. I do want to make it clear that anyone who believes your BIAS will have unlimited access to your traffic is mistaken, and any information being sold by a BIAS will not be a list of all of the websites you visit unless you allow them to have that information.

Talk to your representatives and support eff.org which works to help improve our right to privacy.

Switching Internet Providers

Since I mention it as a possible solution many times, I thought I’d share some notes on your options for switching service providers.

For broadband services

For broadband use, switch to a local provider rather than using a big provider such as Comcast or Verizon. While that is difficult in many regions of American, some regional services might exist in the form of a DSL provider, or in specific regions, you might have local companies you can support.

Additionally, consider joining a Hyperboria community near you (or starting one) or trying out other similar means to decentralize the Internet a bit like ZeroNet.

For mobile services

Worth mentioning is mobile services as well, including your cell phone service provider. Many providers such as Google Project Fi, Ting, Charge.co, and others care about their customer’s privacy and protect it.

FAQ 1: What if I cannot use a VPN

I’m just going to address this concern now, as I know it will be mentioned a lot. There are many downsides to using a VPN, primarily, that it slows your network speeds and may cost you money for the additional services and bandwidth.

For those who cannot use a VPN and who cannot switch BIAS providers to one that protects your privacy, I understand this. For myself, I don’t particularly care if my BIAS wants to see I am accessing google.com or reddit.com; as long as they cannot read my search terms, emails, and the specific posts, news, and comments I am reading.

In cases like this, be sure to use encrypted DNS (DNSCrypt) and only use secure connections (HTTPS Everywhere) and protect what you can. Reverse DNS is not 100% accurate, so your BIAS will still not always be able to determine the websites you visit by IP address alone.

Otherwise, Tor and HTTPS Proxies are available to at least protect your web browsing habits.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!