Privacy & Security

“We take your privacy seriously” How many times have we all heard that before? At yourl we are doing something a bit different. We’re going to explain exactly what we do, and how we do it.


We don’t want your data, to be honest it’s toxic. As much as possible we try to limit what we collect. We only request your name (real or fake!) and your email (this has to be real). We don’t care about your address, your date of birth or your phone number.

We don’t use tracking cookies, and don’t plan on it. Metrics are not collected at the moment, but will be via a privacy preserving system such as fathom.

An unfortunate design of both Slack and Discord is that they send us all messages, where in reality we are only interested in those that contain links. We immediately throw away any message that doesn’t contain http/https. Even then, you may be worried about certain internal or private links. In these cases, we provide two methods to deal with this. The first being the ability to set URL filters, you can block any URLs you deem unwanted by adding to this under the settings page. Additionally, if something does slip through, you can delete the link by clicking the vertical ellipsis and selecting delete on the link. For the developers who are reading this, it is not a ‘soft delete’ where we set some flag to deleted, this is a hard delete in that it is forcibly removed from our database.

You can choose whether or not to include the message text along with each link, by default this is disabled. If a user says “Hey check out {some private data} at this will not be captured unless you explicility turn on capturing message data for that specific integration.


Warning, this is going to be technical, but transparency is something we take extermely seriously here at yourl. So venture forth! You may learn something.


We don’t collect them, or store them, we strictly rely on magic links for authentication. What this means is if we get breached and the database is accessed, you only need to worry about your links being exposed.


Here’s where things get complicated. As part of the integration process, the integrator passes us tokens. These tokens let us access your channels as well as issue various commands such as deleting the bot from the server or looking up usernames from their IDs. Each integration is encrypted with it’s own nonce with a master key that is stored in a secrets manager. What this means is the tokens for each integration is encrypted with it’s own key+nonce pair.


Like most organizations, we have secrets we need to protect. We never hard code these secrets and rely on a secrets manager service for storage and retrieval. This allows us to audit when these secrets are read and determine if a breach has occurred.

Access Control

Most startups, and even large enterprises, suffer from access control issues. With over 20 years of information security experience our engineers understand this issue and have designed the system to never expose or utilize client provided input in retrieving your information. When retrieving links or data specific to you, your ID is saved server side and only retrieved from the cookie state. The cookie state includes your user id, which is used when doing lookups or retrieval from the database. We never read your user id from data /you/ send us. This severly limits the potential for us accidentally reading other users data that was intended for you.

Cross Site Request Forgery

This type of attack requires an attacker to send you, the user, a malicious link to click on, what ends up happening is that link executes some action on your behalf. To protect against this, yourl uses two cookies, a read only cookie, and a read write cookie. The read only cookie is just that, it’s for viewing your links. The read write cookie however, is for changing your settings, or deleting data. The read only cookie is set with a protection mechanism called SameSite=Lax. This means that you can immediately access your data with this cookie, but not change it. The read write cookie however means you must visit yourl first, then you can attempt to modify your settings or data. This read write cookie is protected by setting the SameSite=strict which means it’s only sent once you are already on

SQL Injection

All queries are done using prepared statements with queries keyed to specific user ids. The database user does not have access to functions or public schemas.

Cross-Site Scripting

We audit all cases where user input is output to your pages, however Cross-Site-Scripting is difficult to protect against and we will do our best to ensure none of these issues are exploitable to the point where your data is compromised.

Server Side Request Forgery

We look up URLs, that’s what we do. This attack attempts to trick our url look up bots into looking up internal URLs. We don’t really have internal services, but as an extra precaution we have mitigations in place that block any attempts to load localhost, or private ip address based URLs.

Anything else?

If you have any questions, concerns or comments for improvement, please do not hesitiate to reach out to!