Live data from Hacker News

GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

theinsaneapp.com

121–130 of 161 posts

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#121
post #16
post #2

I thought this should have been expected. Security starts with deep understanding. Some standards and practices can help avoid some types of problems, and some are even rather effective (like airgapping your systems), but there isn't any way to assure security in general other than truly understand what you are doing. ** I feel like Copilot is the wrong direction to optimize development. This is mostly going to help…

The real evil here is boilerplate code. I've seen so much boilerplate in the Java or classic .NET Framework world, it's incredible. So many layers of DTOs, Request/Response Models and so on, that could be just generated. Or most of the time even removed completely (that would cost some "architects" their job though). This is also true for a lot of Redux or Angular/NgRx applications. So much boilerplate, that you can'…

It is true that lines of code are correlated with bugs. In fact, that's the best predictor of the number of bugs - there was some study somewhere that concluded that.

I still doubt that that's a result of DTOs.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#122
post #95
post #87

Earlier quoted context omitted.

According to many people familiar with the legal aspect training on code constitutes fair use, so can't be prevented by any kind of license.

Training, exactly. But the trained person or AI is not allowed to reproduce your exact code. But Copilot seems to do that from time to time.

Sure they can, search engines produce copyrighted material all the time. The issue comes in when people think this somehow indemnifies them as users of Copilot - my guess is, it doesn't protect you any more than if you use a search engine to copy an entire codebase for your own purposes.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#123

…Compared to 60% of circumstances in the meat-based developer control group? :)

I love that we always use the average here for these justifications. We just slowly chip away and any and all excellence. 10x memes aside, we all know what it's like to work with a truly talented and productive engineer versus your everyday schmoe collecting a paycheck. It's a story as old as time, and yet here we are doing the exact big factory industrialization techniques other industries have done and that is comm…

Wasn't there a thread here just yesterday about how 6% of some class of AI outperformed a human, but then it turned out that 0% outperformed two humans? That's also literally the lesson Uber learned the hard way when a SDV ran over a person (that zero humans is worse than one, and one is worse than two). This is also the principle behind code review, peer review, QA, middle management bureaucracy, and a whole lot of other things.

The tragedy, IMHO, is that AI models like this encourage centralizing decision making into a single black box (to the extent that external research then benefits the owner of the AI model rather than advancing public commons), whereas in pretty much every other aspect of life, we consider decentralization/redundancy of autonomy to be the solution to robustness problems.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#124

Earlier quoted context omitted.

I love that we always use the average here for these justifications. We just slowly chip away and any and all excellence. 10x memes aside, we all know what it's like to work with a truly talented and productive engineer versus your everyday schmoe collecting a paycheck. It's a story as old as time, and yet here we are doing the exact big factory industrialization techniques other industries have done and that is comm…

It may be a tragedy, but I fail to see why it is a tragedy of the commons? Which resource that is a available to all is being overused? High-paying dev jobs? Those are not a commons in the sense that tragedy of the commons implies because lower-quality devs don't stand to benefit by only taking a smaller part of the job.

This actually feels to me like a concept worth exploring. I think we lack a concise term or phrase to reference what GP was trying to communicate.

In my heart I feel similarly to GP - and it does feel a lot like how I feel about tragedy of the commons situations. Maybe there seems to be a shared opportunity for everyone if these private companies would make the most of their financial capital, market dominance, dominance in human resources, and most especially leverage their network effects.

That would lead to better things for everyone, like the invention of smartphones. But the same corporations can also waste unimaginable resources and achieve very little. Often their failures don't just have little effect, but rather the failures choke/smother the market and prevent better alternatives from being widely used.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#125

Earlier quoted context omitted.

> Security starts with deep understanding. I wonder if the way we are approaching it is wrong. We are basically putting text though a deep learning black box. The model might have learned some abstractions, but all in all it is just playing word games and trying to guess the most likely continuation of a string. Maybe we should go into the other direction and base such an AI on a really massive ontology. Instead of u…

You're touching on the "Neat -vs- Scruffy" dichotomy in AI. (But it's not necessarily a dichotomy -- they can be combined!) https://en.wikipedia.org/wiki/Neats_and_scruffies From the "Scruffy" side, there's Charles Rich's classic work on "Programmer's Apprentice". https://dspace.mit.edu/handle/1721.1/6054 https://dspace.mit.edu/bitstream/handle/1721.1/6054/AIM-1004... >The Programmer's Apprentice Project: A Research…

Thanks for the term and the resources! Sometimes one has a vague idea and it's really nice to see that this is a thing people put thought into.

Funny that I would describe a solution based on machine learning as scruffy and a solution based on bayesian logic and knowledge databases as neat, whereas Wikipedia defines it the other way around.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#126
Well, of course. GPT-3 has no underlying model of meaning. It's just autocomplete with a bigger data set. Used on natural language, it produces text that looks reasonable for about three paragraphs. Then you realize it's just blithering and has nothing to communicate. (Like too many bloggers, but that's another issue.)

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#127
post #20

Earlier quoted context omitted.

(I have been professionally programming Java backends for the past 16 years). Java is not the culprit here. I think it is something that happened on the way that has something to do with J2EE and patterns craze we had a decade ago or two ago. It doesn't help that frameworks like Spring and their documentation go out of their way to propagate these boilerplate-heavy patters. Copying these lazy patterns is shortest, ea…

I'm working on a Dart / Flutter project where most devs are coming from Java and Android backgrounds. For me, coming mostly from JavaScript, TypeScript, and Python, the amount of pointless over-engineering is very frustrating. We need to jam through every change through 10 layers now, because of "clean architecture". The team is very slow and can't implement even small changes quickly. The worst part is that I feel l…

> We need to jam through every change through 10 layers now, because of "clean architecture".

I feel like this is a rather unfair comment because it doesn't sound like a situation created by "clean architecture."

Granted, you probably should not try and force every detail into this architecture just like you should not rewrite a perfectly good library just because it does not fit into it nicely. But even then; drilling through half a dozen or more layers for every change sounds just wrong. There should not be just any kind of separation in your program. There should be a separation of concerns.

The real problem seems to me a culture in which "We do $X because of $AUTHORITY." is regarded as a sensible answer to criticism. I have worked with exceptionally confident, almost blinkered, people in charge of the big picture and never once have I heard a bullshit answer like that.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#128

Earlier quoted context omitted.

You're touching on the "Neat -vs- Scruffy" dichotomy in AI. (But it's not necessarily a dichotomy -- they can be combined!) https://en.wikipedia.org/wiki/Neats_and_scruffies From the "Scruffy" side, there's Charles Rich's classic work on "Programmer's Apprentice". https://dspace.mit.edu/handle/1721.1/6054 https://dspace.mit.edu/bitstream/handle/1721.1/6054/AIM-1004... >The Programmer's Apprentice Project: A Research…

Thanks for the term and the resources! Sometimes one has a vague idea and it's really nice to see that this is a thing people put thought into. Funny that I would describe a solution based on machine learning as scruffy and a solution based on bayesian logic and knowledge databases as neat, whereas Wikipedia defines it the other way around.

There's some fascinating historical back-story and quotes on the talk page of that wikipedia entry, and also an interesting question about how machine learning is neat:

https://en.wikipedia.org/wiki/Talk:Neats_and_scruffies

>Roger Schank first used those terms "scruffy" and "neat" at an AI conference in the 1970s. He proudly called himself a scruffy. 71.183.59.144 (talk) 02:17, 26 October 2011 (UTC)

>The terminology is sourced to the late 1970s or early 1980s and originated by Schenk according to this:

>"In particular, certain personality traits go hand and hand with certain styles of research. Schank and Abelson hit upon one such phenomenon along these lines and dubbed it the neats vs. the scruffies. These terms moved into the mainstream AI community during the early 80s, shortly after Abelson presented the phenomenon in a keynote address at the Annual Meeting of the Cognitive Science Society in 1981. Here are some selected excerpts from the accompanying paper in the proceedings:"

>The article quotes a lengthy excerpt of this keynote address, some of which I include below

>“The study of the knowledge in a mental system tends toward both naturalism and phenomenology. The mind needs to represent what is out there in the real word, and it needs to manipulate it for particular purposes. But the world is messy, and purposes are manifold. Models of mind, therefore, can become garrulous and intractable as they become more and more realistic. If one’s emphasis is on science more than on cognition, however, the canons of hard science dictate a strategy of the isolation of idealized subsystems which can be modeled with elegant productive formalisms. Clarity and precision are highly prized, even at the expense of common sense realism. To caricature this tendency with a phrase from John Tukey (1969), the motto of the narrow hard scientist is, “Be exactly wrong, rather than approximately right”.

>The one tendency points inside the mind, to see what might be there. The other points outside the mind, to some formal system which can be logically manipulated [Kintsch et al., 1981]. Neither camp grants the other a legitimate claim on cognitive science.... an unnamed but easily guessed colleague of mine (Schenk?), who claims that the major clashes in human affairs are between the “neats” and the “scruffies”. The primary concern of the neat is that things should be orderly and predictable while the scruffy seeks the rough-and-tumble of life as it comes ... The fusion task is not easy. It is hard to neaten up a scruffy or scruffy up a neat. It is difficult to formalize aspects of human thought that which are variable, disorderly, and seemingly irrational, or to build tightly principled models of realistic language processing in messy natural domains.

>What are the difficulties in starting our from the scruffy side and moving toward the neat? The obvious advantage is that one has the option of letting the problem areas itself, rather than the available methodology, guide us about what is important. The obstacle, of course, is that we may not know how to attack the important problems. More likely, we may think we know how to proceed, but other people may find our methods sloppy. We may have to face accusations of being ad hoc, and scientifically unprincipled, and other awful things."

>Source is Chapter 5 of this book edited by Schenk and published in 1994, titled "Beliefs, Reasoning, and Decision Making: Psycho-logic in Honor of Bob Abelson". Article needs clean-up, which I am doing now.--FeralOink (talk) 13:58, 2 August 2021 (UTC)

https://books.google.com/books/about/Beliefs_Reasoning_and_D...

>How is machine learning neat?

>Machine learning is only provably correct for the known examples it was trained for. If that is not an adhoc approach to AI, then I don't know what is. Big data is the epitome of a scruffy. No model, just data, not formalism, besides fitting a curve/model to the given data. It is the exact same approach that scruffies follow: abstracting from examples for specific sub tasks.

>Just because some mathematical methods are employed, like optimization for a sub-problem, i.e. curve fitting, does not make the approach itself neat.

>Obviously, scruffies also use mathematically rigorous approaches, when employing provably correct algorithms, such as searching trees, or certain signal processing approaches.

>So far, the only valid "neats", are those doing GOFAI: they use a minimal model and deduce everything based on it, with no added assumptions or axioms along the way.

>Machine learning is only based on added assumptions/axioms: the training data. New for each problem, no general model.

>Yeah, I noticed that too. Not sure who introduced machine learning to the article. I'm trying to clean up, e.g. removing the jargon about scruffies just being casual hackers throwing stuff together in an ad hoc manner. I don't know enough about the people involved though. I know about the methods you mention (curve fitting, converging series, mathematical modeling) but not necessarily who did what. I don't even know whether most of these guys, the neats OR the scruffies, would be comfortable with "big data" (i.e. lots of specious results with very low cost of being wrong).--FeralOink (talk) 10:48, 3 August 2021 (UTC)

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#129
post #44

Earlier quoted context omitted.

You would have to not host your code publicly either, right?

Merely hosting your code publicly seems like it wouldn't give GitHub the right to train AI models on it. You could even say it's against your terms of use. And to do it, they would have to go out of their way to find your repo on the web and clone it—unlikely. My impression (NOT A LAWYER) is that by hosting your code in a public repo on GitHub, you agree to their terms and give them the right to "read" your code incl…

It's not even very clear whether training an AI on OSS code is violation of those licenses. So unless you make your code public clearly under a proprietary license that clearly rejects such use, you can't really prevent people from doing that anyway.

Just imagine, there's really nothing preventing people from scraping your blog to train their natural language processing AI or whatever, why would code be any different? Even if you put up a big sign saying you don't consent to having your data ingested by a neural network, I doubt it will get noticed anyway...

People have been taking large OSS codebases (eg. Linux kernel) for various statistical analyses. AI is just doing the same thing in a more sophisticated manner.

Re: GitHub Copilot Generated Insecure Code in 40% of Circumstances During Experiment

#130

…Compared to 60% of circumstances in the meat-based developer control group? :)

I love that we always use the average here for these justifications. We just slowly chip away and any and all excellence. 10x memes aside, we all know what it's like to work with a truly talented and productive engineer versus your everyday schmoe collecting a paycheck. It's a story as old as time, and yet here we are doing the exact big factory industrialization techniques other industries have done and that is comm…

I disagree. 40% is not great, but unlike the masses of developers, this is a single system that can improve over time. Further, a system that can do most of the work but requires a security specialist to polish it is still a useful tool. What's important to recognize is that this is not a terribly novel concept. Unsecure code is written every day.
Post reply on HN