As far as prompt injection is concerned, I don’t think it’s a risk unless you’re using some kind of agent to go though emails, which is not a Gmail specific thing.
If we’re taking about Google scraping your data the risk is more one of them having an incorrect profile on you, but running a conversational agent is quite expensive, I don’t they would have that as a large scale part of their pipeline. Embedding and clarification models likely aren’t instruction tuned so prompt injection won’t do anything.
Sure, it’s important to be aware of future potential issues, but there’s a huge difference between I get the wrong answer when I ask a chatbot about my email vs remote code execution.
Also, one is a general security vulnerability with email as a whole, like phishing you can get scammed regardless of your email client, vs improperly implemented features in a specific library. I don’t think this is a reason to leave Gmail.
it’s important to be aware of future potential issues,
New code tends to have flaws.
I agree that there’s no strong reason to expect that the current new implement has a serious flaw. But if I was still using Gmail, I would turn the new feature off.
Anything that can be exploited in a software stack is a higher risk when exposed to the risk cesspool of modern email.
So in summary: chance that this new feature is an injection risk: low.
Risk of harm if there’s any security flaws in it: high.
Mainly that I’ve seen nothing in the terms of sevice that says they won’t sell what they know about me to employers to help employers low-ball me during a salary negotiation.
As far as prompt injection is concerned, I don’t think it’s a risk unless you’re using some kind of agent to go though emails, which is not a Gmail specific thing.
If we’re taking about Google scraping your data the risk is more one of them having an incorrect profile on you, but running a conversational agent is quite expensive, I don’t they would have that as a large scale part of their pipeline. Embedding and clarification models likely aren’t instruction tuned so prompt injection won’t do anything.
Agreed. Architecturally, there’s no reason to have a prompt injection risk, of any kind, here.
But, that was true about Log4J, as well - until we learned otherwise.
I tend toward extra caution in this modern era of libraries stacked on libraries.
Sure, it’s important to be aware of future potential issues, but there’s a huge difference between I get the wrong answer when I ask a chatbot about my email vs remote code execution.
Also, one is a general security vulnerability with email as a whole, like phishing you can get scammed regardless of your email client, vs improperly implemented features in a specific library. I don’t think this is a reason to leave Gmail.
New code tends to have flaws.
I agree that there’s no strong reason to expect that the current new implement has a serious flaw. But if I was still using Gmail, I would turn the new feature off.
Anything that can be exploited in a software stack is a higher risk when exposed to the risk cesspool of modern email.
So in summary: chance that this new feature is an injection risk: low.
Risk of harm if there’s any security flaws in it: high.
I agree. I left Gmail long ago for other reasons.
Mainly that I’ve seen nothing in the terms of sevice that says they won’t sell what they know about me to employers to help employers low-ball me during a salary negotiation.