We've been working hard in the run up to the holiday season and we're really happy to release some of the new features we've been working on!

Launching Report URI

On November 1st 2017 I took Report URI from being a hobby project that I ran on a shoestring budget to being a commercial service so it could become sustainable and grow. You can read details in my blog The next steps for Report URI and some interesting things we had to deal with during and after launch in 301s, 302s, 307s & 308s: Report URI's journey to a permanent redirect. Since then I've detailed how we helped one of our commercial customers go Malware hunting with CSP and during all of this time we have of course been working on new features behind the scenes. Today I can announce the first batch of new features that we've just released!

Improved filtering

One of the most important things to be able to do with your reports is to find the ones that you want and the ones that are important but you can't do that if they're drowned out in noise. We've been constantly developing our inbound filters over the almost 3 years that the service has been running using the literally tens of billions of reports we've processed in that time. With an impressive bird's-eye view of the wider reporting ecosystem we can spot noisy reports based on their presence across literally thousands of sites and use that information to fine-tune our filters.


We have a whole selection of filters that can be configured by the user and additional filtering that takes place at our edge and upstream to ensure that as little noise as possible make it through into your account. Based on my fairly average set of filters that I have configured for my account you can see that roughly 1/3rd of the reports sent to my account are discarded and do not count towards my total monthly usage.


Improved searching

Further to the improvements above to reduce the amount of noise that makes it into your account, we've also released some new features for searching for reports in your account too. Previously you could get quite specific with how you wanted to search for reports based on the disposition of the report, the time/date, hostname, path, directive and whole bunch more stuff, even the browser.


Some of our Enterprise customers wanted to get even more specific and be able to search for a combination of hosts and/or paths, so we built the feature and made it available to everyone for free, on your existing plan.


You can now specify a semicolon, space or comma separated lists of hostnames and or paths to search on for both the UIR fields and the Blocked URI fields too. This means you can get really specific and for example could search for reports on your test and pre-production domains but exclude your production site. It means you can also do things like look for reports in /account/;/billing/ for the path which would exclude /blog/ if you only wanted to look at particular, high-value areas of your site. Further to that, we wanted to make the path searches even more powerful so we also introduced wildcards which can be placed in the right most positition of a path.


In the example above I'm searching on /c*;/a* which will just find any path starting with the letters c or a across all of my sites but this can be used to filter down on paths where you may now know the exact path value. If you had a section of your site where the path was /user/{$guid} or /user/{$username} it could be quite tough to search for reports from those particular paths. Now you can simply use the filter /user/* to achieve that instead. These features are not documented on the site yet but they are available to use right now if you want to try them out. We also took the hostname filtering one step further and implemented wildcard searches there too.


You can also combine multiple hostname filter, for either the document URI or the Blocked URI, and they can contain wildcards in as many of them as needed.


It was a little bit more difficult to do the wildcard hostname filtering compared to the path wildcards because of some constraints in Azure Table Storage, our underlying storage mechanism. I will write those up in another technical blog post but for now you can start using wildcards in your searches with the wildcard as the rightmost component of the path and/or the leftmost component of the hostname.

Info Icon

To try and provide helpful information exactly where you need it, we've added little 'i' icons throughout the site that when clicked will open a modal dialog and offer more information on the appropriate feature. You may have noticed them across the top of the report tables and the Filters page shown above and various other places throughout the site too.



Requiring 2FA for Team Members

Another requirement that was driven by our enterprise customers was the ability for the owner of a team to require that all team members have 2FA enabled on their account. It was a great idea and we really saw the value in it so we've built it, tested it and deployed it to all of our customers that can create teams.


Once this option is enabled you will not be able to switch to a team account without having 2FA enabled on your own account.


This means that team owners can now enforce a higher level of security on all of the accounts that can access and view the report data stored in the team account.


This is small release compared to some of the things we have in mind for 2018 but we wanted to build some little extras over the holiday season. I'm really excited to be getting closer to talking about some of the amazing things we have planned in the near future too. We're going to be making CSP a breeze to deploy and maintain, manually editing policies will become a thing of the past, there are going to be integrations you didn't think possible and so much more. Stick with us and see what we have in store.