Hacker News Reader

Comment by Lucasoato | Hacker News Reader

One thing I really miss is a standard way to block any copilot/ai code completion tool from reaching specific files. That’s particularly important for .env files, containing sensitive info. We don’t want leaking secrets outside our machine, imagine the risks if they become part of the next training dataset. That’d be really easy to standardize, it’s just another .gitignore-like file.

View on HN

So Cody allows you multiple ways to manage this.

In the Cody settings.json file you can disable autocomplete on entire languages/file types.

Additionally, we recently rolled out a Cody Ignore file type where you can specify files/folders that Cody will not look at for context. This feature is still in experimental mode though. https://sourcegraph.com/docs/cody/capabilities/ignore-contex...

With Cody, we have a relationship w/ both Anthropic and OpenAI to never use any data submitted via Cody users for training and data is not retained either.

> With Cody, we have a relationship w/ both Anthropic and OpenAI to never use any data submitted via Cody users for training and data is not retained either.

Can you say more about this? Is it public? Contractual? Verifiable somehow?

Hi - yes it is all outlined in our Terms of use for Cody

https://sourcegraph.com/terms/cody-notice

Sections I-IV :)

I see that it’s outlined there, I’m just curious how you gained the confidence to believe them (anthropic / openAI). Do you pay for auditors or do they have or provide some other evidence that gives you confidence that they won’t train on this data?

Neither Anthropic and OpenAI seem to be particularly mature organizations so while maliciously lying to their customers (you) about this would surprise me, “accidentally” not separating data sources would not be very surprising at all…

GitHub employee here

This does exist in GitHub Copilot - it’s called content exclusions: https://docs.github.com/en/copilot/managing-github-copilot-i...

I’m not sure if Cody has a similar feature, or if there’s any move towards a standardised solution.

Not just any subscriber is allowed though:

> This feature is available for organization accounts with a Copilot Business subscription.

And even if you exclude the moment anyone starts a chat the files are read and sent and could form suggestions:

> Excluding content from GitHub Copilot currently only affects code completion. GitHub Copilot Chat is not affected by these settings.

Both quotes from your link

> Not just anyone is allowed though:

Does it mean engineers created the feature but managers disabled it for some users?

It's called Price discrimination (https://en.wikipedia.org/wiki/Price_discrimination) almost all SAAS use it.

In this context, it means that I (a hobbyist) get to enjoy copilot at a discounted rate because there are some feature (context exclusion) which were costly to implement that I am not using. So it makes sense for me to take a less expensive plan which only includes the core features without the cruft. If there is any of these additional feature that I need, then I just need to pay for the engineering time that went into them, which takes less than a few seconds, it's just a button to click on. Fair and square.

Could you make this feature available to every subscriber?

These types of tools should exclude all files and directories in the .gitignore as standard operating procedure, unless those files are specifically included. Not just because of secrets, but also because these files are not considered to be part of the repository source code and it would be unusual to need to access them for most tasks.

It should probably use .gitignore as a default then you can opt in / out further. This would be a securer default than everything in.

.gitignore unless there’s a specific .codyignore ?

Or maybe a set of sensible global default ignores, based on the usual suspects from gitignore.io or suchlike ?

We need a standardized .aiignore file that everyone can work with. Aider does this with .aiderignore. They all just need to agree on the common filename

And format. The glob spec that gitignore uses isn’t necessarily trivial.

I created a cli tool that copies a GitHub or local repo into a text file for llm ingestion. It only pulls the filetypes you specify.

https://github.com/jimmc414/1filellm

I agree, but you really shouldn't keep unencrypted secrets locally to begin with.

Most secret managers allow you to either specify value references in .env files, or provide a way of running programs that specifically gives them access to secrets.

I wouldn’t want Cody interrogating my local Terraform state or tfvars, for example. There might not be unecrypted secrets in there, but there’s configuration data that I don’t want to disclose too.

Why not just use .gitignore itself? It's also unlikely they want to train on build files and such.

That makes sense but not everyone uses git. A new file that you can point to your gitignore in would probably be a good idea.

If you do not use git, you might not be GitHub's target audience.

That's clever, but GitHub is recognized as the way to do things, so I've seen a couple repos where the only commits are of binaries to download, which technically uses git, but I wouldn't really say that's using git.

You can purchase GitHub copilot and use it (even for corporations) and not use GitHub.

My company buys copilot for all devs, but doesn’t use GH or GHE

But your company doesn't use Git? That's all you need for .gitignore.

I often start a new project and work on it using Copilot for quite a while before making it official, running "git init" and creating a .gitignore file.

You shouldn’t have sensitive secrets on your workstation in your .env file though. It’s not what it’s for.

Where would I keep them instead? I always wonder. Let’s say I am developing an app against OpenAI API. Where do I put the OpenAI API Key in VS Code?

As far as I know .env file is the main supported way of setting environmental variables in VS Code.

Reply on news.ycombinator.com