mirror of
https://github.com/compiler-explorer/compiler-explorer.git
synced 2025-12-27 10:33:59 -05:00
ef264acace
A whole bunch of changes I've been meaning to make: - Clarify things and put the TLDR at the top - Remove my own darn address etc (after checking this is OK) - Clarifying the goo.gl situation - Paving the way for the explain feature
56 lines
3.8 KiB
Markdown
56 lines
3.8 KiB
Markdown
## Compiler Explorer and Privacy
|
|
|
|
_This is a summary of our Privacy policy, not a legal document, and might be incomplete._
|
|
|
|
_For the full Privacy policy, see `static/generated/privacy.pug`, or visit https://godbolt.org/#privacy_
|
|
|
|
The main Compiler Explorer site (at https://godbolt.org/) has a cookie and privacy policy, and it's expected that any
|
|
changes to the code are in compliance with those policies. It's worth taking a look at them if you're touching any area
|
|
of the code relating to storing or logging user data.
|
|
|
|
Specifically, we must remain compliant with the EU's GDPR law, which applies to EU residents wherever they are in the
|
|
world. The main way to think about the GDPR, and privacy in general, is the user should be in control of their data. As
|
|
such we go to great pains to explain what we do with their data, and that we don't store any user-identifying
|
|
information. Of course, we _do_ (at least temporarily) store their source code, which may be precious and sensitive. We
|
|
are transparent with what we do with their data. When making short links, we send an encoding of their source code for
|
|
storage, and again we must be clear how that process works.
|
|
|
|
Users have rights over the data they create: so in theory they could ask for any data stored on them to be removed. We
|
|
have no way of tracking data (a short link, perhaps) back to an individual user, and when I asked some experts on this
|
|
the consensus was that we're OK not to supply this. If, however, we ever have user attribution (e.g., we start having
|
|
accounts), we need to support the user being able to close their account, and/or delete any data they created (e.g.,
|
|
short links). All this makes perfect sense and would probably be done anyway, as it seems useful!
|
|
|
|
We anonymise IP addresses so there's no exact mapping back to an individual using an IP. Not that it's trivial to map an
|
|
IP to a user anyway.
|
|
|
|
We shouldn't store data forever: our web logs are set to delete after 32 days. Amazon infrastructure logs
|
|
(separate from our web logs) also contain full IP addresses and are kept for 32 days. Compilation analytics logs
|
|
are kept for up to 1 year - these contain hashed source code (not reversible), compiler options, and usage patterns
|
|
to help us improve the service. Lambda and API Gateway logs are kept for 7-14 days.
|
|
|
|
Short URLs do turn up in the web logs: from the short URL of course one can easily extract the source code embedded in
|
|
that short URL. Users are notified of this in the privacy policy. The ultimate recourse for users concerned about this
|
|
is to not use the main Compiler Explorer but instead run their own local service, which is relatively straightforward.
|
|
|
|
We also integrate with third-party services with user consent: Claude Explain sends code to Anthropic for analysis, and
|
|
we use Sentry for error reporting (which keeps IP and browser info for up to 90 days - note this is controlled by Sentry's
|
|
retention settings, not our code). Users can control whether their code is stored for diagnostic purposes through a
|
|
setting that defaults to enabled but can be disabled.
|
|
|
|
Important: The actual retention periods are configured in our terraform infrastructure, not in the application code.
|
|
Always verify that the privacy policy matches the terraform configuration when making changes.
|
|
|
|
### Admins
|
|
|
|
A very small group of people have administrator rights on the public Compiler Explorer. Those individuals can:
|
|
|
|
- Read the logs
|
|
- Log in to the running Compiler Explorer compilation nodes
|
|
- Access the S3 storage where caches and stored information may be kept
|
|
- Access and modify the EFS storage where compilers are stored
|
|
|
|
In short, administrators can see everything that goes on. It is expected that administrators keep this deep
|
|
responsibility in mind when performing actions on Compiler Explorer, and that they keep users' privacy at the forefront
|
|
of their minds when using their administration privileges.
|