In this post, we will cover changes coming to Chrome (and other browsers) that affect how third-party cookies are handled—specifically SameSite changes, how to test to see if your site is impacted and how to fix it.

Blog post cover image showing a jar with cookies in it

What is SameSite and why the big change?

Back in May 2019, Chrome announced its plan to develop a secure-by-default model for handling cookies. This initiative highlights Chrome’s promise of a more secure and faster browsing experience. Chrome's...


As part of our Blackhat Europe talk “Reverse Engineering and Exploiting Builds in the Cloud” we publicly released a new tool called Terrier.

Announcing Terrier: An open-source tool for identifying and analysing container and image components.

In this blog post, I am going to show you how Terrier can help you identify and verify container and image components for a wide variety of use-cases, be it from a supply-chain perspective or forensics perspective. Terrier can be found on Github ...


This blog post is adapted from a lightning talk by Ben Fritsch at Ruby on Ice 2019.

There can be a number of reasons why your application performs poorly, but perhaps none are as challenging as issues stemming from your database. If your database's response times tend to be high, it can cause a strain on your network and your users’ patience. The usual culprit for a slow database is an inefficient query being executed somewhere in your application logic. Usually, you can implement a fix in a number of common ways, by:


Update: On closer inspection, the lock type was not on the table, but on a tuple. For more information on this locking mechanism see the internal Postgresql tuple locking documentation. Postgres does not have lock promotion as suggested in the debugging section of this post.

I maintain an internal-facing service at Heroku that does metadata processing. It's not real-time, so there's plenty of slack for when things go wrong. Recently I discovered that the system was getting bogged down to the point where no jobs were being executed at all. After hours of debugging, I found the problem was an UPDATE on a single row on a single table was causing the entire table to lock, which...


This blog post is adapted from a talk given by Julián Duque at NodeConf EU 2019 titled "Let it crash!."

Before coming to Heroku, I did some consulting work as a Node.js solutions architect. My job was to visit various companies and make sure that they were successful in designing production-ready Node applications. Unfortunately, I witnessed many different problems when it came to error handling, especially on process shutdown. When an error occurred, there was often not enough visibility on why it happened, a lack of logging details, and bouts of downtime as applications attempted to recover from crashes.

Julián: Okay. So, as Brian said, my name is Julián Duque, it will be...


Browse the archives for engineering or all blogs Subscribe to the RSS feed for engineering or all blogs.