Legal matters are almost never black and white. If someone does something illegal using my service, and some other 3rd party sues me as party to that illegal behavior, from a legal perspective having a clause like "no criminal behavior allowed" in there makes it easier for your lawyers to argue "my client clearly didn't intend to authorize/facilitate such behavior". This argument is of course made much stronger if it is paired with behavior, like banning (or attempting to ban) the criminal user as soon as the activity was identified.
But if you are paranoid you should speak with a lawyer in your jurisdiction.
If you don't think this is a DDoS with archive.today visitors acting as an unwitting/unwilling botnet, how do you think this normally works? It's not any more sophisticated. There is not much functional difference between someone telling my smart fridge to ping https://gyrovague.com and a website telling my browser to do it.
I don't think it's a botnet. To me that implies that the software that runs on your computer is a service that talks to a C&C server or to other bots P2P, forming the net(work) part of a botnet. In this case it is not a bot downloading a payload from a C&C, but a user intentionally visiting a website which downloads and runs the payload. It does not really work as a botnet since the web browser is not a service that will continually talk with a network of other servers to get a new payload.
Try ignoring what the payload is as it does not really matter in defining what is or isn't a botnet (though botnets typically imply malicious or sketchy payloads).
In regards to it being a DDoS it leans more in the yes direction due to the intent of it, but it also sites sending traffic to other sites is part of the web. You can embed things from other sites like images and then those others sites will fulfill those requests. The web didn't restrict pages to only send requests and load content from the same domain.
Would be interesting to see if there is other personality overlap with people that feel this way, which people could use as a pre-test for whether or not they would enjoy the experience of having kids.
I wonder if there would be something identifiable in common if we fMRI'd your brains, as while you are definitely not alone it does seem like a pretty strong exception that makes the rule.
Sure, give me a verified badge on dating marketplace apps (Feeld, Fetlife in my case) based on my fMRI imaging interpretation. Use it as input for the matching algo. Way more useful than simply putting "neurodivergent" in a profile imho. Adjacent to "If your policy doesn't exist in code, it doesn't exist."
You confused AWS with Amazon distribution and warehouses, and you are doubling down ? Likely or not, much of the world's infrastructure runs on or through AWS data centers. Attacks like this can cause significant disruption.
Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access.
MCPs have provided any easy way to side-step that baggage.
e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily configure my tooling to give an LLM (e.g. Claude Code) unlimited read access to some system (by allowing all read-only tools) without likewise giving the LLM write/destructive access.
Obviously you can design APIs/CLIs with this in mind, but up until now that has not been a primary concern so they haven't.
That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.
I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).
Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.
Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?
I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield).
An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to be more "agent compatible".
Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.
You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.
But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.
