Oopsie Woopsie!

We did a fucky wucky UwU! A real bingo bango! Ouw engineews awe working VEWY hawd to fix it :3! Why don't you join ouw RP Discord server so we can help you OwO

Enable the blackbox to verbosely log all events into LocalStorage for debugging purposes! Note that these logs are *very big* and it's not recommended you share them with anyone outside the development team.

Hewwo! Dis should be included in youw error repowt.
Error thrown: undefined in undefined.js:1:1.
Stack:
undefined
UA: undefined
Location: undefined
Endpoint: undefined
_ratelimited? undefined
Token metadata: undefined
Profile?: undefined
profile-cache?: undefined

Access denied

Access Denied!

Looks like you're not allowed in here!
Have you tried logging in?

elixi.re Privacy Policy

Date of this Privacy Policy: July 13th, 2020.

A history of changes to this Privacy Policy can be found here.

GDPR references

The official GDPR text can be found here.

An interactive version of it can be found here.

On updates to this document

The Service reserves the right to update this document as the Service owners see fit. Major updates to this document will be communicated to the Users of the Service via their primary communication channel (Email).

Glossary

  • Snowflake: A standard for unique identifier numbers first developed by Twitter. Snowflakes are generated by the service.
  • shortname: An identifier generated by the service composed of letters and numbers.
  • object: Depending on the context, means both a file and a shorten.

On countries

The Service owners are located in Turkey, Brazil, and the United States.

The Service's servers are located in United States and Germany.

The Service uses Cloudflare, a US-based company. More information here.

The Service uses Backblaze, a US-based company. More information here.

On advertisement

The Service does not run advertisements. Because of that, the Service will not run tracking to run advertisements for the User.

The Service will not sell User information.

Personal Data stored

Data on a single User

  • Snowflake.
  • Usernames.
  • Emails, reasonings behind:
  • So the Service owners are able to directly contact single users in the case of a data breach.
  • So the Service owners can manually broadcast important information related to the Service to all users
  • Hashed passwords (with bcrypt):
    • The Service is unable to reveal the user's plaintext password using the stored, hashed version.
  • Consent to data processing.
  • "Paranoid" mode.
  • More here
  • Which domain and subdomain the User is using.

Metadata on files

Other than the actual file data being stored to fulfill the purpose of the Service, the service stores this metadata about it:

  • Snowflake.
  • MIME type.
  • Shortname.
  • SHA256 Hash of the file contents.
  • File size.
  • Uploader's ID (a User).
  • Deleted state:
  • Domain:
  • Files are tied to a single domain.

Metadata on shortens

Other than the actual URL the shorten is redirecting to, the service stores the following metadata:

  • Snowflake.
  • Shortname.
  • Shortener's ID (a User).
  • Deleted state:
  • Domain:
    • Shortens are tied to a single domain.

On the "Deleted state" of files and shortens

The service does not want to risk having incorrect images be displayed on links to deleted images, so, to counteract that, we store objects' metadata even when the actual object information is deleted (and inaccessible from anyone, including the Service owners).

The deleted metadata is moved to a dummy account for anonymization.

On Paranoid Mode

To decrease the probability of malicious users brute-forcing all possible shortnames on the Service to have a mapping from shortname to file data, the User can opt-in to what is called "Paranoid Mode" where every generated shortname for their file will be longer.

On Personal Data which is extrapolated

"extrapolated" in this context means data that isn't directly stored but can be acquired by manual intervention.

  • User's IP Addresses
    • We do this to protect the stability of the service by blocking IP addresses and users that damage the service.
  • Discord usernames and discriminators

On the Service owners accessing Personal Data

The Service owners reserve the right to manually look into a User's personal information and object data/metadata for maintenance or ToS enforcing purposes, the second purpose is to maintain a positive image of the Service.

Users who break the ToS will have their Personal Data opened for the Service owners only. The Service owners might announce the account checking with the User IDs.

Metrics collected

To keep the technical security and positive reputation of the Service, we collect metrics which may or may not be published to the general public, as described below:

Public metrics that are not tied to any User, or are generated by the Service:

  • Requests per second.
  • Responses per second.
  • Errors per second.
  • Page hits per second.
  • How many tries it took to generate a shortname.
  • How long it took to get a response to a certain request (response latency).
  • How long it took for the Service to process a User's file.
  • Total amount of users in the Service.
  • The total amount of active users in the Service.
  • The total amount of inactive users in the Service.
  • The total amount of files in the Service.
  • The total amount of files' storage in the Service.
  • The total amount of files uploaded per hour.
  • The total amount of shortens in the Service.

Metrics the Service collects and will not be publicized:

  • Total amount of users who consented to data processing in the Service.
  • Total amount of users who have uploaded to the Service per hour.

On the use of Personal Data

This is the personal data the service directly accesses:

  • Emails
    • So that the Service is able to broadcast important messages about the Service to the Users.
  • Hashed passwords
    • We use hashed passwords as input to certain cryptographic operations related to the generation of User's authentication tokens.
    • Nobody has access to the User's password hash, given any of the User's authentication tokens.

Third-party Actors and the Service

The Service uses Cloudflare to provide resilience against DDoS attacks. Because of every interaction through the Service passing through Cloudflare, Cloudflare may run tracking or analytics which we (the Service) can't disable.

The Service owners agreed to the GDPR Data Processing Addendum on Cloudflare on official domains on May 22, 2018.

On unofficial domains

We allow unofficial domains to be used in the Service. Unofficial domains are owned by third parties which are not the Service owners.

Usernames of these third parties may be publicly tied to their domains.

The third parties providing these unofficial domains may not respect this Privacy Policy as the Service does, we can not enforce the actions declared in this Privacy Policy on third parties and their unofficial domains.

The most Service owners know is that third parties can look on their Cloudflare accounts' analytics and see aggregated information on who is using their unofficial domains.

The Service does its best to keep bad third party actors away by:

  • Removing unofficial domains that have evidence on a bad action by a third party
  • Running daily checks on all domains to detect:
    • Configuration errors.
    • Servers trying to redirect traffic to a malicious website.
    • Servers trying to redirect traffic to a malicious Elixire instance.

On data leaving servers owned by the Service

The Service owners backup all images sent in the Service every 12 hours automatically. The Service owners backup the Service's database every 30 minutes automatically.

Both of those backups are stored on the B2 service provided by Backblaze (which is a US-based company). Database backups are encrypted with all the Service owners' PGP keys. Image folder backups are encrypted using a strong passphrase available to some owners of the Service.