If we want parents to be accountable, then these platforms need to provide better tools to enable parents to do so. It is impossible to monitor the entirety of your child's behavior online through any of these platforms today. They are their own person, they make their own choices, and those choices are heavily influenced by a world the parents have increasingly less influence over, especially as they grow older.
On the flip side, I do think we should also hold companies more accountable for this. We collectively prevented companies from advertising tobacco to minors through regulation with a pretty massive success rate. These companies know how harmful social media can be on youth, and there is little to no effective regulation around how children learn about these platforms and get enticed into them.
There are infinite things worth doing, a machines ability to actually know what's worth doing in any given scenario is likely on par with a human's. What's "Worth doing" is subjective, everything comes down to situational context. Machines cannot escape the same ambiguity as humans. If context is constant, then I would assume overlapping performance on a pretty standard distribution between humans and machines.
Machines lower the marginal cost of performing a cognitive task for humans, it can be extremely useful and high leverage to off load certain decisions to machines. I think it's reasonable to ask a machine to decide when machine context is higher and outcome is de-risked.
Human leverage of AGI comes down to good judgement, but that too is not uniformly applied.
I think this particular exploit crosses multiple trust boundaries, between the LLM, the MCP server, and Supabase. You will need protection at each point in that chain, not just the LLM prompt itself. The LLM could be protected with prompt injection guardrails, the MCP server should be properly scoped with the correct authn/authz credentials for the user/session of the current LLMs context, and the permissions there-in should be reflected in the user account issuing those keys from Supabase. These protections would significantly reduce the surface area of this type of attack, and there are plenty of examples of these measures being put in place in production systems.
The documentation from Supabase lists development environment examples for connecting MCP servers to AI Coding assistants. I would never allow that same MCP server to be connected to production environment without the above security measures in place, but it's likely fine for development environment with dummy data. It's not clear to me that Supabase was implying any production use cases with their MCP support, so I'm not sure I agree with the severity of this security concern.
I don’t think the real divide is “doom tomorrow” vs “nothing to worry about.” The crux is a pretty straightforward philosophical question "what does it even mean to generalize intelligence and agency", how much can scaling laws tell us about that?
The back-and-forth over σ²’s and growth exponents feels like theatrics that bury the actual debate.
Ironically, this article highlights multiple times how successful Microsoft has been at boosting efficiency within the oil and gas industry that it's nearly an advertisement for Microsoft.
STIR/SHAKEN doesn't prevent spoofing. It can verify in certain cases when a call is not spoofed but it's fairly limited and almost entirely mobile-to-mobile phone calls. It requires IP based network connectivity end-to-end, which just isn't possible in the US. If a call gets routed through a rural network and switches back to TDM, it will drop all STIR/SHAKEN data. It will still take years for US infrastructure to be entirely IP-based. Robocallers sign their calls with STIR/SHAKEN just fine, the originators do this for them, so it's not going to be a strong deterrent in my opinion.
Devices support attestation level A display (green or grey check marks in your call logs designate this). If you haven't seen that check mark, then you probably haven't seen many A-level attested calls to your device. As far as device manufacturers go, they only care about A-level attestation, which makes sense as it has full traceback capability.
Just to help not spread misinformation, the 12 year old was released as he was a passenger and police believe he was forced by the driver (his brother) into the car.
The 13 year old driver was not released and will remain in jail until his trial.
Copilot is a lossy compression algorithm when applied at scale, I would expect some degradation in code quality if not applied appropriately. It's still a useful tool, but just like image and audio compression, a human needs to give the final output some last looks to ensure an acceptable out come.
"best" is subjective, but I do think the industry will eventually converge onto an architecture that is significantly more cost effective than current state of the art. Regardless of who is first to market, everyone is incentivized to continue down this path with their research on improving LLM performance.
TTS and STT models have decent support for streaming in chunks, but the accuracy drops the smaller the chunk size. Current state of LLMs are pretty limited in their ability to handle streaming inputs due to attention window constraints. There is some emerging research into attention sinks and caching initial tokens that look promising. I don't think we're quite there yet though.
QA has always been about risk management. There are multiple ways to manage risk, and some of those ways can be more cost effective to a business. As software shifted towards SaaS offerings, deployments (and rollbacks) became quicker, customer feedback loops also got lightning fast. Team's can manage the risk of a bug more efficiently by optimizing for mean-time-to-recovery. This muscle is not one that QA teams are particularly optimized for, thus their effectiveness in this new model was reduced. I've found that holding on to QA function in this environment can severely dilute the ownership of quality as a requirement from engineers.
QA is still extremely valuable in any software that has long deployment lead times. Mobile apps, On-Prem solutions, anything that cannot be deployed or rolled back within minutes can benefit from a dedicated QA team that can manage the risk appropriately.
The article skims over the details from the FCC, in this situation Twilio is guilty by association. They are the CPaaS provider for a company called PhoneBurner, which in-turn provides services to a Mortgage company (MV realty) who is the primary offender of the robocalls.
The FCC is taking a firmer stand and threatening those that support robocalls all the way down the chain. All CPaaS providers need to do a better job managing their customer vetting processes.