Legal

Sensitive Information Removal Policy

We offer this sensitive information removal process as an exceptional service only for high-risk content that violates the HASH Terms of Service, such as when your security is at risk from exposed access credentials. This guide describes the information HASH needs from you in order to process a request to remove sensitive, private information from a project. Please note: only removal requests that meet this criteria will be processed in line with the policy on this page.

Please be sure to submit your information removal request via the correct channel. Other policies for removing information from HASH can be found on the following pages:

→
If you are a government entity wishing to remove content from HASH that has been deemed unlawful in your jurisdiction, see our Government Takedown Requests page.
→
If you are a user reporting spam, abuse, or any other violation of our Community Guidelines, see our User Reports page.
→
If you are a copyright holder, see our Copyrighted Materials Policy or Guide to Submitting a DMCA Takedown Notice instead.
→
If you are a trademark holder whose name(s) are being used in a manner that may mislead or confuse others with regard to a brand or business affiliation, see our Trademark Complaints Policy.

Government entities such as a law enforcement agencies seeking information from HASH are welcome to review our Legal Requests of User Data page.

What is Sensitive Information?

For the purposes of this document, “sensitive information” refers to content that (i) should have been kept confidential, and (ii) whose public availability poses a specific or targeted security risk to you or your organization.

"Security risk" refers to a situation involving exposure to physical danger, identity theft, or increased likelihood of unauthorized access to physical or network facilities.

Sensitive information removal requests are appropriate for:

→
Access credentials, such as user names combined with passwords, access tokens, or other sensitive secrets that can grant access to your organization's server, network, or domain.
→
AWS tokens and other similar access credentials that grant access to a third party on your behalf. You must be able to show that the token does belong to you.
→
Documentation (such as network diagrams or architecture) that poses a specific security risk for an organization.
→
Information related to, and posing a security risk to, you as an individual (such as social security numbers or other government identification numbers).

Sensitive information removal requests are not appropriate for:

→
Internal server names, IP addresses, and URLs, on their own. You must be able to show that their use in a particular file or piece of code poses a security threat.
- →
  n.b. The National Institute of Standards and Technology explicitly advises against relying on "security through obscurity". You should consider changing your system's behavior.
→
Mere mentions of your company's identity, name, brand, domain name, or other references to your company in files on HASH. You must be able to articulate why a use of your company's identity is a threat to your company's security posture. See the HASH Impersonation Policy and HASH Trademark Complaints Policy for more information.
- →
  Inappropriate: a trademark violation which could be handled under our separately established HASH Trademark Complaints Policy.
- →
  Potentially appropriate: an unauthorized third-party is impersonating your organization on HASH's platform to conduct a spear-phishing campaign against your employees.
→
Entire files or projects that do not pose a specific security risk, but you believe are otherwise objectionable.
→
Requests to remove content that may infringe your or your organization's copyright rights. If you have questions about how HASH handles copyright-related matters or would like to report potentially infringing content, please review the HASH Copyright Materials Policy which governs the primary HASH website, in addition to all other HASH websites. The private information removal process is generally not intended for the removal of full files or repositories — only for the specific pieces of private information in those files. While there may be cases where files are filled entirely with private information, you must justify the security risk for the removal of such files, and this may increase the time required to process your request.
→
Trademark disputes. If you have questions about how HASH handles trademark-related matters or would like to report content containing your organization's trade or service marks, please review the HASH Trademark Complaints Policy.
→
Privacy complaints. If you wish to access, transfer, change, or delete your personal information on HASH, please contact us via our Support website.
→
Content governed by our Community Guidelines and Acceptable Use policies, such as malware or general-purpose tools. If you have questions about our Community Guidelines or believe that content on HASH might violate our guidelines, you can contact us.

Sensitive Information Removal Process

What to expect

A typical process looks like:

→
Complainant Investigates. It is up to the requesting party to conduct their own investigation and to provide us with the details we require — most importantly, an explanation of how the data poses a security risk. HASH is not in a position to search for or make initial determinations about sensitive data on any individual's or organization's behalf.
→
Complainant Sends a Sensitive Data Removal Request. After conducting an investigation, the complainant prepares and sends a sensitive data removal request to HASH. If the request is not sufficiently detailed to demonstrate the security risk and for HASH to locate the data, we will reply and ask for more information.
→
HASH Asks User to Make Changes. In most cases, we will contact the user who created the repository and give them an opportunity to delete or modify the sensitive data specified in the request or to dispute the claim.
→
Either (a) User Notifies HASH of Changes: If the user chooses to make the specified changes, they must tell us so within the window of time they've been allowed. If they don't, we will disable the repository. If the user notifies us that they made changes, we will verify that the changes have been made and notify the complainant. OR (b) User May Dispute the Request: If a user believes the the content in question is not sensitive data subject to this Policy, they may dispute it. If they do, we will generally leave it up to the complainant to contact the user and work things out with them directly, within reason.
→
Complainant Reviews Changes. If the user makes changes, the complainant must review them. If the changes are insufficient, the complainant must provide HASH with details explaining why. HASH may disable the publication's Index listing or give the user an additional chance to make the changes.
→
User May Request an Additional Window to Make Changes. If the user missed their opportunity to remove the sensitive data specified in the notice, we may allow them an additional 24-hour window, upon request, to make those changes. In that event, HASH will notify the complainant.

A quick note on forks:

→
HASH allows users to "fork" one another's projects. In essence, this means that users can make a copy of a project such as a type or a block in HASH into their own namespace. As the license or the law allows, users can then make changes to that fork to either push back to the main project or just keep as their own variation of a project. Each of these copies is a "fork" of the original project, which in turn may also be called the "parent" of the fork.
→
HASH will not automatically disable forks when disabling a parent project. This is because forks belong to different users and may have been altered in significant ways. HASH does not conduct any independent investigation into forks. We expect those sending sensitive information removal requests to conduct that investigation and, if they believe that the forks also contain sensitive information, expressly include forks in their request.
→
If at the time that you submitted your notice, you identified all existing forks of that projects, we would process a valid claim against all forks in that network at the time we process the notice. We would do this given the likelihood that all newly created forks would contain the same content. In addition, if the reported network that contains the reported content is larger than one hundred (100) projects and thus would be difficult to review in its entirety, we may consider disabling the entire network if you state in your notice that, based on the representative number of forks you have reviewed, you believe that all or most of the forks contain the content reported in the parent project.

Sending a request

These guidelines are designed to make the processing of requests to remove private, sensitive information as straightforward as possible.

Before submitting a request:

→
Ask users directly first. Before sending us a request to remove data we strongly recommend attempting to contact the user directly first, and resolving it one-on-one. They may have listed contact information on their public Index profile page or in the publication's README file. They may not realize that their publication contains sensitive content, and by getting in touch directly to explain your request you can avoid confusion and encourage prompt amicable resolution. This is not a required first step, but it is often productive and appreciated. It may also lead to a faster resolution time.
→
No bots. You should have a trained professional evaluate the facts of every request you send. If you're outsourcing your efforts to a third party, make sure you know how they operate, and make sure they are not using automated bots to submit complaints in bulk. These complaints often include data that does not pose any security threats, and they do not include sufficient explanations, requiring additional back-and-forth and resulting in delays, even when the complaint is valid.
→
Send the correct request. We offer this sensitive data removal process as an exceptional service only for high-risk content. We are not able to use this process to remove other kinds of content, such as potentially infringing content, and we are not able to process any other kinds of removal requests simultaneously while processing sensitive removal requests. We will be able to help you more quickly if you send in your sensitive data removal requests separately from any requests to remove potentially infringing content. If you are unsure whether your request involves only sensitive data or also involves other legal matters, please consult legal counsel.
→
Submit requests only once. While we process sensitive data removal requests as quickly as possible, due to the volume of requests we process, it may take some time for your request to be reviewed. Additional requests, or multiple requests from additional points of contact, may result in delays.
→
Make your request specific. Due to the type of content HASH hosts we need complaints to be as specific as possible. In order for us to verify that a user has removed reported sensitive information completely, we need to know exactly where to look.

When submitting a request, you MUST include:

→
A working, clickable link to each file within a project containing sensitive information. (Note that we're not able to work from search results, examples, or screenshots.)
→
Specific line numbers within each file containing the sensitive information.
→
A brief description of how each item you've identified poses a security risk to you or your organization. It is important that you provide an explanation of how the data poses a security risk beyond merely stating that it does.
→
If you are a third party acting as an agent for an organization facing a security risk, include a statement that you have a legal right to act on behalf of that organization.
→
Optional: Let us know if your request is particularly urgent, and why. We respond to all sensitive information removal requests as quickly as possible. However, if this request is especially time-sensitive, such as a very recent credential exposure, please explain why.

You can submit a request to remove sensitive information via our contact form. Please include a plain-text version of your request in the body of your message. Sending your request in an attachment may result in processing delays.

Disputing a request

If you received a sensitive information removal request from us, you can dispute it by replying to our email and letting us know — in as much detail as possible — why you think the content in question is not sensitive information subject to this Policy.

Create a free account

By signing up you agree to our terms and conditions and privacy policy