blob: 0df79926e4e558fe3810bfd423c7a0db69024c24 [file] [log] [blame] [raw]
<!DOCTYPE html>
<!--
Be aware: modifying this file in any way will cause a pop-up to users telling them the privacy policy has changed.
-->
<html lang="en">
<body>
<h2>Compiler Explorer Privacy Policy</h2>
<p>
Thanks for your interest in what Compiler Explorer does with your data. Data protection is really
important to the Compiler Explorer team, and we want to be very clear about what we do with your data.
</p>
<h3>Who we are</h3>
<p>
Compiler Explorer was created by and is primarily administrated by
<a href="mailto:matt@godbolt.org">Matt Godbolt</a>,
along with a number of volunteers (including, but not limited to those listed in our "<a
href="https://github.com/mattgodbolt/compiler-explorer/blob/master/AUTHORS.md" target="_blank"
rel="noreferrer noopener">Authors</a>" documentation).
It is run on a best-effort basis, and is not a commercial product. We do our best
to keep your data safe, but welcome help from the community: See our
<a href="https://github.com/mattgodbolt/compiler-explorer" target="_blank"
rel="noreferrer noopener">GitHub project page</a> if you wish to help.
</p>
<h3>Your data</h3>
<p>
In order to process the compilation requests, your browser sends the source code you typed in the editor window
along with your chosen compiler and options to the Compiler Explorer servers. There, the source code is written to
disk and your chosen compiler is invoked on it. The results are processed and sent back to your web browser, where
they're shown. Once the compiler has completed, your source code is deleted from disk.
</p>
<p>
The source code and options are also subject to a one-way hash, which is used to cache the results to speed up
subsequent compilations of the same code. The cache is in-memory and on-disk. It's impossible to reconstruct the
source code from the hash; but the resulting assembly code (the compilation result) is stored as plain text. There's
no way to enumerate the in-memory cache contents. In exceptional cases, administrator members of the Compiler
Explorer team may be able to enumerate the disk caches and retrieve the assembly code, but with no way to trace it
back to the source code.
</p>
<p>
In short: your source code is stored in plaintext for the minimum time feasible to be able to process your request.
After that, it is discarded and is inaccessible.
</p>
<p>
If you choose to share a long URL of your code, the user interface state including the source code is encoded into
the URL as a URL hash (e.g. <code>https://godbolt.org/#ui_state_and_code</code>). For a short URL this URL is then
sent to an external URL shortening service (currently <a href="https://goo.gl/" target="_blank">goo.gl</a>) and the
resulting short URL is rewritten as <code>https://godbolt.org/g/SHORTURLPART</code>. The storage for your user
experience state in this case remains with the short URL provider, not Compiler Explorer.
</p>
<p>
Compiler Explorer keeps web logs, which contain semi-anonymised IP addresses, but no other personally identifying
information. When a long URL is clicked, the hash part of the URL is not sent to the server, so the user state
(including the source code) is NOT exposed in the web log. If a user clicks a short URL, then the short form IS
exposed in the web log (as <code>https://godbolt.org/g/SHORTURLPART</code>) and from this the source code can be
retrieved. As such, if you create a short URL of your code, your source code and other user state can in principle
be retrieved from the web log of Compiler Explorer.
</p>
<p>
In order to debug and diagnose Compiler Explorer, to help track down and block Denial of Service attacks, and to
gather statistics about Compiler Explorer's performance and usage, the web logs are archived. These logs are kept
for 5 years, after which they are permanently deleted.
</p>
<p>
Separately, Compiler Explorer uses small pieces of information stored on your computer: Cookies and Browser Local
Storage. Cookies are only used with the user's permission, and are used with external analytics services (e.g.
Google Analytics) to gather statistics on Compiler Explorer usage. This information is used to help the Compiler
Explorer team plan for future updates and hardware upgrades in order to ensure the site remains stable and
responsive. Local storage is used to remember user's settings, source code and user interface configuration, so that
it's available when the user visits the Compiler Explorer site again. This information is not transmitted to
Compiler Explorer, except as described above in order to fulfil the user's requests. There is a
<a href="#cookies" rel="noreferrer noopener">separate document</a> covering more on this. Statistics tracking
information is kept for 14 months, after which it is removed.
</p>
<h3>Your choices</h3>
<p>
Compiler Explorer is an open source project. If you are concerned about any of the data protection measures outlined
above, or about what happens to your source code, you are encouraged to run your own local instance of Compiler
Explorer. Instructions on how to do this are on the
<a href="https://github.com/mattgodbolt/compiler-explorer" target="_blank"
rel="noreferrer noopener">GitHub project page</a>.
</p>
<h3>Compiler Explorer and the GDPR</h3>
<p>
The Compiler Explorer team believes the Compiler Explorer site is compliant with the EU's General Data Protection
Regulation (GDPR). Specifically, we store no personally identifying information, we anonymise the little data that
we do have and we do not permanently store any user data.
</p>
<h4>Name and Address of the controller</h4>
<p>
The Controller for the purposes of the General Data Protection Regulation (GDPR), other data protection laws
applicable in Member states of the European Union and other provisions related to data protection is:
</p>
<div>
Matt Godbolt<br>
2626 Orrington Ave<br>
Evanston IL 60201 USA<br>
+1 3127927931<br>
matt@godbolt.org
</div>
</body>
</html>