So, I was interested in this statement, and looked into it barely, and on one side, its conclusions were replicated in a number of other papers[1] (despite the headlines, three years after its publication, of a simple calculation error)[2]. I'll state that neither of these points are a slam-dunk if you're a member of one political side or another. If you're a believer in austerity, you'll look at the corroborating studies; if you think that was a bad policy choice, you can argue that they're all junk science, pushed out by supporters of the status quo.
I suspect what it narrowly shows though is that this isn't the same category of error as what's being discussed here.
I think one of the things that goes unmentioned in these discussions is that while the US gets a lot of attention for this kind of activity, it has also (historically) been in the forefront of criminalization and prosecution. I may be wrong, but don't know of any other jurisdiction that prosecuted insider trading before the Eighties, and the US has had a pattern of investigating and regulating this since the 30s.
I don't think that this is a particular form of exceptionalism, beyond the US having a longer tradition of widespread, retail-owned shares, and law-making around that fact.
But sometimes I wonder when people are criticising the US as a culture, they're often choosing as the baseline that should be respected standards that were also defined in a US cultural context. What this sometimes means is that in internal US culture these points are seen as something that is heavily discussed, because there was a point where it was democratically decided and therefore could be undecided in the same way, like corporate personhood, or money-as-speech. In the case of the criminalization "insider trading", there is lively debate about whether this is actually a "good thing". That can sound horrific externally, because of course insider trading is a bad thing. But someone decided to make that a bad thing, and -- for historical accident reasons -- the edges of that debate was largely defined within the US.
(This is mostly just barely-informed speculation: sometimes issues like this emerge in international fora, or start in another culture and quickly spread. But the cultural and financial dominance of the US in the last century or so really makes these things often a point of debate in American terms, and a fixed point elsewhere. I speak here as an immigrant to the US and also someone who is dipped in global policy work, rather than someone who is stating this as a good or a bad thing.)
A lot of the United States historical influence and soft power comes from it being a nation of rules and laws. The credibility of the country provided a perception that it was a stable place to store value (investment in treasuries, greenbacks, etc). When the government is facilitating insider trading out in the open (repeatedly), we’re losing a lot more than money due to fraud.
What parts of it were confusing? I think science fiction can be confusing if you haven’t read a lot of it, because part of its art is to try and set the scene in as compact way as possible, with a combination of cues that you can work out from their context or by reference (like “laminate” and “squarely” — yes, I had to look it up), and some are the puzzles that the rest of the story will resolve (who/what is Julia? What do they want?)
It’s ok if it’s not your thing. It’s like an emotional crossword puzzle.
This is fascinating; thank you for building it. (I also enjoyed watching the flurry of visitors as soon as my Let's Encrypt certificate got assigned. It's a Dark Forest out there!)
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.
From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use
Isn't that already the case with limited plans?
For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
I kind of doubt this, as the rapidly changing nature of mobile IP addresses would mean that a periodic outbound connection would still be necessary to keep the attack up-to-date on the compromised devices current IP address. At that point, you may as well have the compromised device periodically poll an attacker-controlled server for instructions rather than jump through a bunch of hoops by getting things to work over inbound connections.
I think it should vary based on the type of service being provided. Truly mobile service, I think it can make sense to not allow servers. If its being sold as a home internet solution (a more fixed kind of plan), I think it should allow servers to at least some level of hosting services.
The main difference is there's usually limited airtime capacity for clients, especially highly mobile ones. A server could easily hog quite a bit of the airtime on the network serving traffic to people not even in the area, squeezing out the usefulness of the network for all the other highly mobile people in the area. This person moves around, pretty much doing the equivalent of swinging a wrecking ball to the network performance everywhere they go.
When its being sold as a fixed endpoint though, capacity plans can be more targeted to properly support this kind of client. They're staying put, so its easier to target that particular spot for more capacity.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.
Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
I've been asking this for a while, especially as a lot of the early blame went on the big, visible US companies like OpenAI and Anthropic. While their incentives are different from search engines (as someone said early on in this onslaught, "a search engine needs your site to stay up; an AI company doesn't"), that's quite a subtle incentive difference. Just avoiding the blocks that inevitably spring up when you misbehave is a incentive the other way -- and probably the biggest reason robots.txt obedience, delays between accesses, back-off algorithms etc are widespread. We have a culture that conveys all of these approaches, and reciprocality has its part, but I suspect that's part of the encouragement to adopt them. It could that they're just too much of a hurry not to follow the rules, or it could be others hiding behind those bot-names (or others). Unsure.
Anyway, I think the (currently small[1]) but growing problem is going to be individuals using AI agents to access web-pages. I think this falls under the category of the traffic that people are concerned about, even though it's under an individual users' control, and those users are ultimately accessing that information (though perhaps without seeing the ads that pay of it). AI agents are frequently zooming off and collecting hundreds of citations for an individual user, in the time that a user-agent under manual control of a human would click on a few links. Even if those links aren't all accessed, that's going to change the pattern of organic browsing for websites.
Another challenge is that with tools like Claude Cowork, users are increasingly going to be able to create their own, one-off, crawlers. I've had a couple of occasions when I've ended up crafting a crawler to answer a question, and I've had to intervene and explicitly tell Claude to "be polite", before it would build in time-delays and the like (I got temporarily blocked by NASA because I hadn't noticed Claude was hammering a 404 page).
The Web was always designed to be readable by humans and machines, so I don't see a fundamental problem now that end-users have more capability to work with machines to learn what they need. But even if we track down and sucessfully discourage bad actors, we need to work out how to adapt to the changing patterns of how good actors, empowered by better access to computation, can browse the web.
(and if anyone from Anthropic or OpenAI is reading this: teach your models to be polite when they write crawlers! It's actually an interesting alignment issue that they don't consider the externalities of their actions right now!)
I'm happy to bet with that skills -- or "a set of instructions in markdown that get sucked into your context under certain conditions" will stick around. Similarly, I think that the Claude Code/Cowork -- or "interactive prompt using shell commands on a local filesystem" -- will also stick around.
I fully anticipate there being a fair amount of thrashing on what exactly the right wrapper is around both of those concepts. I think the hard thing is to discriminate between the learned constants (vim/emacs) are from the attempts to re-jiggle or extend that (plugins, etc); it's actually useful to get reviews of these experiments exactly so you don't have to install all of them to find out whether they add anything.
(On skills, I think that the reason why there "aren't good examples out there" is because most people just have a stack of impromptu local setups. It takes a bit of work to extract those to throw them out into the public, and right now it's difficult to see that kind of activity over lots of very-excitable hyping, as you rightly describe.
The deal with skills and other piles of markdown is that they don't look, even from a short distance, like you can construct a business model for them, so I think they may well end up in the world of genuine open source sharing, which is a much smaller, but saner, place.
> (On skills, I think that the reason why there "aren't good examples out there" is because most people just have a stack of impromptu local setups. It takes a bit of work to extract those to throw them out into the public, and right now it's difficult to see that kind of activity over lots of very-excitable hyping, as you rightly describe.
Very much this. All of my skills/subagents are highly tailored to my codebases and workflows, usually by asking Claude Code to write them and resuming the conversation any time I see some behavior I don't like. All the skills I've seen on Github are way too generic to be of any use.
I thought skills were supposed to be sharable, but (a) ones that are being shared openly are too generic and not useful, (b) people are writing super specific skills and not sharing them.
Would strongly encourage you to open-source/write blog posts on some concrete examples from your experience to bridge this gap.
reply