- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
If an LLM can’t be trusted with a fast food order, I can’t imagine what it is reliable enough for. I really was expecting this was the easy use case for the things.
It sounds like most orders still worked, so I guess we’ll see if other chains come to the same conclusion.
This isn’t something you can input any text into, it’s fixed, that joke doesn’t apply, you can’t do an sql injection here.
I don’t know how you can think voice input is less versatile than text input, especially when a lot of voice input systems transform voice to text before processing. At least with text you get well-defined characters with a lot less variability.
No special characters, this is speech to text, inherently sanitized inputs.
Special characters is just one case to cover. If the user says they want “an elephant-sized drink” what does that mean to your system? At least that is relevant to size. Now imagine complete nonsense input like the joke you responded to (“-1 beers” or “a lizard”). SQL injection isn’t the only risk with handling inputs. The person who ordered 18,000 waters didn’t do a SQL injection attack.
none of those issues work because there is a whitelist of specific terms instead of a blacklist
-1 cannot be selected, a lizard isn’t on the list of inputs, and my point with the sql is that this isn’t a huge attack vector like an input field on a website, this is a dropdown list, essentially.
i challenge you to come up with one relevant attack that isn’t order too much of a thing or order conflicting modifications (note of course the modifications are also essentially read from a dropdown list)
everyone here seems to believe that the input field paradigm is not solveable when the inputs are fixed, that isn’t true.
Close one, a joke was related to but not a perfect match for the present situation. Something terrible could have happened like… Uh…
Let me get back to you on that.