We're happy to announce that we have introduced several dashboard improvements for Lists.

Today we've released a new option to filtering timestamps - the ability to compare a timestamp to the current time, in order to e.g. find users that signed up "in the last 2 hours". This filter opens up the possibility of creating Policies that flag users that signed up and then quickly did something suspicious, like creating 10 new content posts. Seeing high velocity abuse from new accounts like this is very common across multiple types of services.

We're excited to release our updated onboarding flow for new Castle accounts. There are many ways to start using Castle, so to make it more streamlined we've listed the most important steps to create visibility into your application and get a good foundation for protection in place. This includes default Lists and Policies for common cases of fraud and abuse, as well as recommendations for notifications.

We've made it easier to create a filter that targets one or more specific Policies. This filter is leveraging the same tab-system that we introduced for Lists and Signals a while back. With this change it's easy to evaluate a specific Policy based on historic data and get an overview of how many users or devices (or anything else) were affected.

We've launched the ability to use your company Google account to sign up for a new Castle account. Also, if you've already created a Castle account using email and password, you can now seamlessly use Google to log in instead.

Today we're happy to announce a much asked for feature: the support for Regex in string filters. Being able to search data by Regex opens up endless possibilities of finding those needles in the haystack. For example:

Small update - With the Castle event filters you're able to use standard operators like equals, not equals and for numeric values you've been able to use greater than and less than. For convenience, we've now added two new filter options for numeric values:

We've released version 2.2.0 of castle.js, which includes new options for how browser storage is used. There are two new parameters that can be provided in the storage field:

We've added a new filter for querying whether an event is considered "authenticated" vs. "anonymous". Authenticated events mean that it was caused by an authenticated user. An example of a non-authenticated is a failed login event, where the credentials match a known user, but where it’s not confirmed that it actually was triggered by the legitimate, authenticated user. Same with password reset requests.

One of the more common asks among our customers is the ability to set up Slack alerts whenever suspicious behaviors are detected. Today we're excited to launch our updated Slack alert feature, which allows you to get notified whenever something is added to a List in Castle. This is great when you want to get notified whenever e.g. a user exhibits a behavior for the first time, such as sharing accounts or doing something repetitive such as sending tons of spam messages