You might be conflating "cloud" with serverless. Serverless is where developers can focus on code, with little care of the infrastructure it runs on, and is pay-as-you-go.
Ethical disclosure existed before bug bounties. Someone who wants to ensure the remediation of the bug might recognize that the staff member responding to bug bounty reports is limited in their purview and might be badly trained. Upon learning that it is out of scope for the bug bounty program did the author try their security@ or another a referenced security contact?
Your characterization of this bug as one "that completely pwn your machine just by connecting it to an untrusted network" is also hyperbolic to the extreme.
Your comment gets to the crux of my thinking about LLM coding. The way I think of what LLM coding is doing is decompressing your prompt into code based on the statistical likelihood of that decompression based on training data. Basically "Build me an IOS app" -> a concrete implementation of an iOS app. The issue here is that the user supplying the prompt needs to encode all of the potential variables that the AI needs to work with into the prompt, or else the implementation will just be based on the "bog-standard" iOS app based on the training corpus, although with potential differences in the app based on other tokens in the prompt. Is natural language the right way to encode that information? Do we want to rely on input tokens to the context of a model successfully making it into the output to guarantee accuracy? I think the Kiro Spec driven development starts to get at addressing the inherent issues in LLM based coding assistance, but it is an early step.
Can you elaborate on the logic that makes preventing scrapers (note, you didn't mention actually hindering accessibility technologies) customer antagonistic?
See my other comment, but the answer here is resoundingly "No". For the communication to be end-to-end encrypted the payload needs to be encrypted through all steps of the delivery process until it reached the final entity it is meant for. Infrastructure like cloudflare generally is configured to be able to read the full contents of the web request (TLS interception or Load balancing) and therefore the message lives for a time unencrypted in the memory of a system that is not the intended recipient.
No, because there is a web server that exposes an API that accepts a plaintext prompt and returns plaintext responses (even if this API is exposed via TLS). Since this web server is not the same server as the backend systems that are processing the prompt, it is a middle entity, rather than an end in the system.
The difference here is that the web server receiving a request for Confer receives an encrypted blob that only gets decrypted when running in memory in the TEE where the data will be used, which IS an end in the system.
The point of measured environments like the TEE is that you are able to make guarantees about all the software that is running in the environment (verified with the attestation). "If the software can modify data legitimately, it can be tampered with." - the software that makes up the SBOM for these environments do not expose administrator functions to access the decrypted data.
That is where the attestation comes in to show that the environment is only running cryptographically verified versions of open source software that does not have the mechanisms to allow tampering.
E2EE is usually applied in contexts where the message's final recipient is NOT the server on the other end of a TLS connection, so yes, this scenario is a stretch. The point is that in the context of an AI chat app, you have to decide on the boundary that you draw around the server components that are processing the request and necessarily need access to decrypted data, and call that one "end" of the connection.
The point of E2EE is that only the people/systems that need access to the data are able to do so. If the message is encrypted on the user's device and then is only decrypted in the TEE where the data is needed in order to process the request, and only lives there ephemerally, then in what way is it not end-to-end encrypted?
When the server is the final recipient of a message sent over TLS, then yes, that is end-to-end encryption (for instance if a load balancer is not decrypting traffic in the middle). If the message's final recipient is a third party, then you are correct, an additional layer of encryption would be necessary. The TEE is the execution environment that needs access to the decrypted data to process the AI operations, therefore it is one end of the end-to-end encryption.
Just like your mobile device is one end of the end-to-end encryption, the TEE is the other end. If properly implemented, the TEE would measure all software and ensure that there are no side channels that the sensitive data could be read from.
An attacker with a privileged position on the network allowing them to eavesdrop (but not decrypt) traffic could use a bug like this to identify the device on the network associated with a phone number in Signal. Given nation state level adversaries, that seems like a significant privacy issue to me.
Many consumer devices can be selectively targeted for updates. The entities that control the update servers are controlled by the states that they are a part of. People seem to have forgotten that companies once felt the need to invent warrant canaries to warn when they had received non-public court orders. Presumably they can also be forced not to remove the warrant canary.
Edit: My first read had me interpret backdoor as any undetected means of gaining access to a device/system. I have updated by definition to mean using a flaw in the system left intentionally to gain access. This somewhat negates the need for my previous comment, but I'll leave this for illustrative purposes.
How user antagonistic changing code on IoT devices should be is highly dependent on the threat model for the devices. I'm happy to trust home users to flash their lightbulbs and door locks (though the company might not see that as acceptable to their brand reputation if their lock is compromised nonetheless), but I would prefer not to trust the hundreds of IT departments and engineering teams to properly vet the code they are flashing onto industrial control systems when lives are at stake - centralized authority and accountability with high visibility on the code base that is flashed to the devices is what is needed there.
Are you familiar with the academic field of security and the notion of trust in trusted computing? The IoT devices that is being discussed in the article are for industrial control systems, not necessarily your home lightbulb. The threat model is different. Do you want every municipal power company to be trusted to properly vet the code they are putting on these devices, or do you want to trust the device manufacturer to be the one who can put code on the devices?
It's really just about giving yourself enough time to think before you respond. That's the entire difference between a reaction and a response. You can use dialectical and cognitive behavioral therapies to help develop the tolerance to do that. Mindfulness and meditative practices like those in zen buddhism have proven helpful to me as well.
Perhaps you're taking an extreme interpretation of my using the word "logic" and instead you could use "wise mind" or even just "considered thought" as the response in lieu of an emotional one.
"How do you slog through something you truly hate?" - I don't.
When signals that a role is not aligned with my needs start cropping up, I begin searching for a new role passively, and as the situation develops I speed up my search.
"I felt like a complete failure because I didn't put in 100% and I felt like I let my mentor down" - to thine own self be true. I have failed to put in 100% at some jobs, and sometimes i regret it more than others. I have narratives that legitimize my laziness or lack of commitment based on some previous slight from the company, or a missed promise on their part, but I hold myself accountable.
"How do you overcome something like that and push on? It does not always seem like a sure thing"
Resilience is a wildly varying trait of folks, and depends on your emotional and mental state. "First world problems" are a great example, one when is socialized at a certain comfort level, missing that causes distress. Some working conditions are truly untenable, in which case do what you have to do, but otherwise do the best with the situation you're given.
"... is called a delusion". What I am suggesting is not delusion, it is mindfulness and cutting through delusion. When one is presented with something that elicits a fear response (whether the stimulus is rational or not) the goal is to quiet all of the "lizard brain" reactions, and instead formulate a well reasoned response. "Fear is the mind-killer" - while from fiction, still rings true to me - if you react out of fear you will short-circuit internal processes that are far better at long-term reasoning even when at the expense of short-term comfort.
While YMMV, a fear response is a choice. You can have all the rational reasons to be afraid (like the bottom of your hierarchy of needs being unmet) and choose to act out of cold rationality rather than fear. Then it becomes a self-fulfilling prophecy - if you can act without fear even when there is justified reason to be afraid, you will be able to easily do so when it isn't justified.
As someone who is more in the middle of my career rather than the end of it, I would like to echo your sentiment. I have had plenty of roles where I was tasked with things that were out of my depth, and the answer is to just not let it be. There is always a path to get the answers/skills you need to do what is asked of you, you just might not know the path yet, so the core skill (and where I think fear comes into the process) is accepting that not knowing something now is never a hinderance so long as once can do self-directed learning. The rest is reality testing if what you just learned is actually able to solve your problem. If it isn't, then repeat ad infinitum until it is.
The monetization of social and parasocial relationships (from advertising in social media to the industry around influencers and celebrities of all types) might be one of the cruelest things in modern capitalism.
In your first scenario, any connections established through the ISP-A's IP address would be routed back through the VPN connection that they came in on. If that server were to establish it's own connections to external resources, it would feasibly be able to use the 10g connection from ISP-B. It would not be able to dictate what source address was used with connections coming from ISP-B.
Ha! Thanks for the elucidation. My assumptions around the GP did include the assumption of sex, but it was more in a honeypot context rather than as an end in an of itself.
"a poor model of the world, a logical inconsistency, or just a behavior which is confusing to users"
I expect when I pull from the queue (but it was designed non-atomically) that I will be guaranteed to only grab the item once and only once, even after a failure. That expectation is wrong, but the developer may have implemented their intent perfectly, they just didn't understand that there are error cases they didn't account for.
Those images of little robots with a ball of braincells on top looks like an image that would be in a montage explaining the lead-up to humanity's destruction. But it sure is nifty.