• 0 Posts
  • 8 Comments
Joined 2 years ago
cake
Cake day: June 24th, 2023

help-circle
  • This has messed with me for the longest time. 24h just wraps around at 24, simple modulo 24 arithmetic.

    12h? The hour and am / pm wrap around independently, and hence I am always confused whether 12pm is supposed to be midnight or noon. Zero based would have made more sense (with x pm being x hours after noon…)


  • Also ImageTragick was a thing, there are definitely security implications to adding dependencies to implement a feature in this way (especially on a shared instance). The API at the very least needs to handle auth, so that your images and videos don’t get rotated by others.

    Then you have UX, you may want to show to the user that things have rotated (otherwise button will be deemed non-functional, even if it uses this one-liner behind the scenes), but probably don’t want to transfer the entire video multiple times to show this (too slow, costs data).

    Yeah, it is one thing to add a one liner, but another to make a well implemented feature.


  • Saying AI = LLMs is an severe oversimplification though. LLMs and image generators are subsets of AI that are currently most prominent and with which is most commonly knowingly being interacted with, but pretty much every formal definition is wider than that. Recommendation algorithms, as used on YouTube or social media, the smart (photo) search, are further examples of AI that people interact with. And fraud detection, learning spam filters, abnormality (failure) detection, traffic estimation are even more examples. All of these things are formally defined as AI and are very much commonplace, I would not call them niche.

    The fact that LLMs and image generators are currently the most prominent examples does not necessarily exclude other examples from being part of the group too.

    Using AI as a catch all phrase is simply a case of overgeneralization, in part due to the need of brevity. For some cases the difference does not matter, or is even beneficial. For example, ‘don’t train AI models on my art’ would only marginally affect applications other than image generation and image analysis, and covers any potential future applications that may pop up.

    However, statements ‘ban AI’ could be easily misconstrued, and may be interpreted in a much wider manner than what the original author may have intended. There will be people with a variety of definitions to what does or does not constitute AI, which will lead to miscommunication unless it is clear from context.

    It probably wouldn’t hurt clarifying things specifically and talking about the impact of a specific application, rather than discussing what is (or is not) to be classified as AI.


  • We rarely prove something correct. In mathematics, logical proofs are a thing, but in astronomy and physics it is moreso the case that we usually have a model that is accurate enough for our predictions, until we find evidence to the contrary, like here, and have an opportunity to learn and improve.

    You really can’t ever prove a lot of things to be correct: you would have to show that no more cases exist that are not covered. But even despite the lack of proven correctness for all cases, these models are useful and provide correct predictions (most of the time), science is constantly on the lookout for cases where the model is wrong or incorrect.


  • Yes, true, but that is assuming:

    1. Any potential future improvement solely comes from ingesting more useful data.
    2. That the amount of data produced is not ever increasing (even excluding AI slop).
    3. No (new) techniques that makes it more efficient in terms of data required to train are published or engineered.
    4. No (new) techniques that improve reliability are used, e.g. by specializing it for code auditing specifically.

    What the author of the blogpost has shown is that it can find useful issues even now. If you apply this to a codebase, have a human categorize issues by real / fake, and train the thing to make it more likely to generate real issues and less likely to generate false positives, it could still be improved specifically for this application. That does not require nearly as much data as general improvements.

    While I agree that improvements are not a given, I wouldn’t assume that it could never happen anymore. Despite these companies effectively exhausting all of the text on the internet, currently improvements are still being made left-right-and-center. If the many billions they are spending improve these models such that we have a fancy new tool for ensuring our software is more safe and secure: great! If it ends up being an endless money pit, and nothing ever comes from it, oh well. I’ll just wait-and-see which of the two will be the case.


  • Not quite, though. In the blogpost the pentester notes that it found a similar issue (that he overlooked) that occurred elsewhere, in the logoff handler, which the pentester noted and verified when spitting through a number of the reports it generated. Additionally, the pentester noted that the fix it supplied accounted for (and documented) a issue that it accounted for, that his own suggested fix for the issue was (still) susceptible to. This shows that it could be(come) a new tool that allows us to identify issues that are not found with techniques like fuzzing and can even be overlooked by a pentester actively searching for them, never mind a kernel programmer.

    Now, these models generate a ton of false positives, which make the signal-to-noise ratio still much higher than what would be preferred. But the fact that a language model can locate and identify these issues at all, even if sporadically, is already orders of magnitude more than what I would have expected initially. I would have expected it to only hallucinate issues, not finding anything that is remotely like an actual security issue. Much like the spam the curl project is experiencing.