static/policies/privacy.html - compiler-explorer - Rivoreo Source Code Repositories

 <!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>

 <!--
 No need to update this! It's done by the CLI build process
 -->
 <span id="last-changed"></span>
 <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/compiler-explorer/compiler-explorer/blob/main/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/compiler-explorer/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 compilation and execution 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. If your request was to have your code executed, the
     resulting executable is run. The outputs from compilation and execution are processed and sent back to your web
     browser, where they're shown. Shortly after this process completes, your source code is deleted from disk. If, in
     processing your query, an issue with Compiler Explorer is found, your code may be kept for up to a week in order to
     help debug and diagnose the problem. Only the Compiler Explorer team will have access to your code, and only for the
     purposes of debugging the site: we will never share your code with anyone.
 </p>

 <p>
     If you choose a Microsoft compiler, then your code may be sent to and compiled on a machine administrated by
     Microsoft. Such code is covered by the <a href="https://privacy.microsoft.com/en-US/" target="_blank">Microsoft
     Privacy Policy.</a>
 </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 or binary output (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 compilation output, 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. In very rare cases your code may be kept for a little longer (at
     most a week) to help debug issues in Compiler Explorer.
 </p>

 <h4>Short links</h4>

 <p>
     If you choose to share your code using the "Share" dropdown, then the user interface state including the source code
     is stored. For a "Full" link, this information is encoded into the URL as a URL hash (e.g.
     <code>https://godbolt.org/#ui_state_and_code</code>). For short URLs, the interface state is stored on Compiler
     Explorer's servers, and a shortened name uniquely referring to this data is returned. The shortened name comes from
     a secure hash of the state, and without knowing the name it is infeasible to access the data. Only Compiler Explorer
     administrators can access this data directly. Obfuscated IP addresses and creation time are stored alongside this
     data, to enable spam detection. Links of this form look like <code>https://godbolt.org/z/SHORTNAME</code>.
 </p>

 <p>
     Prior to storing data itself, Compiler Explorer used an external URL shortening service
     (<a href="https://goo.gl/" target="_blank">goo.gl</a>) and the resulting short URL was rewritten as
     <code>https://godbolt.org/g/SHORTURLPART</code>. The storage for the user experience state in this case remains with
     the short URL provider, not Compiler Explorer.
 </p>

 <h4>Application, web and error logs</h4>

 <p>
     Compiler Explorer keeps application 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>
     Compiler Explorer uses Amazon's web serving, load balancing and edge caching systems. 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 logs from these systems are archived. These logs contain the full IP addresses
     of requests. They are kept for no more than one month, after which they are permanently deleted.
 </p>

 <p>
     If your web browser experiences an error, we use a third party reporting system (<a
         href="https://sentry.io/">Sentry</a>). This keeps information, including your IP address and web browser user
     agent, for no more than 90 days.
 </p>

 <h4>Executing your code</h4>

 <p>
     For certain configurations, we may support executing the results of your compilation on the Compiler Explorer
     servers. Execution occurs in a heavily locked-down, isolated environment. We have made reasonable efforts to protect
     both the Compiler Explorer site and other concurrently-processed requests from information leakage due to rogue
     executions.
 </p>

 <h4>Cookies</h4>

 <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 the 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/compiler-explorer/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 312 792-7931<br>
     <a href="mailto:matt@godbolt.org">matt@godbolt.org</a>
 </div>

 </body>
 </html>
	<!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>

	<!--
	No need to update this! It's done by the CLI build process
	-->
	<span id="last-changed"></span>
	<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/compiler-explorer/compiler-explorer/blob/main/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/compiler-explorer/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 compilation and execution 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. If your request was to have your code executed, the
	resulting executable is run. The outputs from compilation and execution are processed and sent back to your web
	browser, where they're shown. Shortly after this process completes, your source code is deleted from disk. If, in
	processing your query, an issue with Compiler Explorer is found, your code may be kept for up to a week in order to
	help debug and diagnose the problem. Only the Compiler Explorer team will have access to your code, and only for the
	purposes of debugging the site: we will never share your code with anyone.
	</p>

	<p>
	If you choose a Microsoft compiler, then your code may be sent to and compiled on a machine administrated by
	Microsoft. Such code is covered by the <a href="https://privacy.microsoft.com/en-US/" target="_blank">Microsoft
	Privacy Policy.</a>
	</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 or binary output (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 compilation output, 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. In very rare cases your code may be kept for a little longer (at
	most a week) to help debug issues in Compiler Explorer.
	</p>

	<h4>Short links</h4>

	<p>
	If you choose to share your code using the "Share" dropdown, then the user interface state including the source code
	is stored. For a "Full" link, this information is encoded into the URL as a URL hash (e.g.
	<code>https://godbolt.org/#ui_state_and_code</code>). For short URLs, the interface state is stored on Compiler
	Explorer's servers, and a shortened name uniquely referring to this data is returned. The shortened name comes from
	a secure hash of the state, and without knowing the name it is infeasible to access the data. Only Compiler Explorer
	administrators can access this data directly. Obfuscated IP addresses and creation time are stored alongside this
	data, to enable spam detection. Links of this form look like <code>https://godbolt.org/z/SHORTNAME</code>.
	</p>

	<p>
	Prior to storing data itself, Compiler Explorer used an external URL shortening service
	(<a href="https://goo.gl/" target="_blank">goo.gl</a>) and the resulting short URL was rewritten as
	<code>https://godbolt.org/g/SHORTURLPART</code>. The storage for the user experience state in this case remains with
	the short URL provider, not Compiler Explorer.
	</p>

	<h4>Application, web and error logs</h4>

	<p>
	Compiler Explorer keeps application 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>
	Compiler Explorer uses Amazon's web serving, load balancing and edge caching systems. 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 logs from these systems are archived. These logs contain the full IP addresses
	of requests. They are kept for no more than one month, after which they are permanently deleted.
	</p>

	<p>
	If your web browser experiences an error, we use a third party reporting system (<a
	href="https://sentry.io/">Sentry</a>). This keeps information, including your IP address and web browser user
	agent, for no more than 90 days.
	</p>

	<h4>Executing your code</h4>

	<p>
	For certain configurations, we may support executing the results of your compilation on the Compiler Explorer
	servers. Execution occurs in a heavily locked-down, isolated environment. We have made reasonable efforts to protect
	both the Compiler Explorer site and other concurrently-processed requests from information leakage due to rogue
	executions.
	</p>

	<h4>Cookies</h4>

	<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 the 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/compiler-explorer/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 312 792-7931<br>
	<a href="mailto:matt@godbolt.org">matt@godbolt.org</a>
	</div>

	</body>
	</html>