10-20 years ago running a social network platform was viable for individuals. Today, in the era of information warfare, SEO, trolling and in general magnitudes more bad actors, it's almost impossible.
Friend has encountered things like people uploading illegal content and then reporting to hosting provider or various terrorist or political organisations publishing their manifestos and vile content then making death threats for taking it down and so on.
Also no ads, means how the platform is going to survive once provider runs out of money or figures out it is not as easy as it looks like?
Good points! paperboat.website is very simple and focuses on friends sharing their blog posts which each other, which helps limit regular users' exposure to potential malicious activity.
I expect it's going to be tricky if the user base grows but I'm not planning to compete with larger social networks. It's primarily a space to create personal sites and blogs and my plan is to keep it around as long as possible. If users decide to purchase memberships, I'll have even more time to make sure it stays secure and up to date. If not, I'll still run this for me and my friends which is a huge motivation for me already.
They don’t need to prove that. The government or whatever would have to prove that they aren’t checking ages, by going to the site and seeing a lack of age verification.
Garbage In, Garbage Out. If you're working under the illusion any tool relieves you from the burden of understanding wtf it is you're doing, you aren't using it safely, and you will offload the burden of your lack of care on someone else down the line. Don't. Ever. Do. That.
Security through obscurity is not a great idea. This is what Apple's current approach is. For instance if your iPhone is infected with malware, there is no anti-virus software that can find it, because Apple doesn't let software to have such deep access that is needed for scanning.
> Apple doesn't let software to have such deep access that is needed for scanning
Normalizing "security" software running in the background to "scan" things has proven a social and technical disaster. Users think it's normal to have such activity (and receive random "virus alerts"), leading to over two decades of social engineering scams, fraud, and malware-delivery. On top of that, "security" software has a habit of creating its own security holes and problems. Look at game anti-cheats (one was just on the front page the other day), the CrowdStrike incident, etc.
OS vendors should simply deliver a secure OS. That isn't easy, but it's still easier and more reliable than shipping third-party "security" software after the fact.
The issue isn’t “normalising pop-up virus scanners” or letting random vendors hook the kernel. It’s verifiability. On Apple platforms, the security model is explicitly “trust us bro”. You cannot independently inspect the system at the level required to detect certain classes of compromise, because Apple forbids it.
A platform where compromise is, by design, undetectable to the owner is not “more secure”, it’s merely less observable. That’s security through opacity, not security through design.
Yes, third-party security software has a bad history. So does third-party everything. That doesn’t magically make a closed system safer. It just moves all trust to a single vendor, removes independent validation, and ensures that when something slips through, only the platform owner gets to decide whether it exists.
“The OS vendor should deliver a secure OS” is an aspiration, not an argument. No OS is bug-free. Defence in depth means independent mechanisms of inspection, not just a promise that the walls are high enough.
Apple’s model works well for reducing mass-market malware and user error. It does not work for high-assurance trust, because you cannot verify state. If you can’t audit, you can’t prove clean. You can only assume.
That may be a perfectly acceptable trade-off. But let’s not pretend it’s the same thing as stronger security. It’s a different philosophy, and it comes with real blind spots - which to some people make Apple devices a non-starter.
It's not security by obscurity. It's security by minimizing the attack service by being extremely picky about what you sign. When it is paramount that the code you sign is correct you can't go signing a ton of different projects from people who may not even care about security as much as you do.
>For instance if your iPhone is infected with malware
Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
We're talking about the verification of the boot chain, and last I heard, Pegasus has never subverted that: its strategy is to break back in after every reboot.
Not really, airlines do the same thing. Cockpit security protects you against hijackings from any of the 200-odd crazies in the cabin, but not the 3-4 "trusted" individuals in the cockpit.
The way things are headed, it's getting hard to trust the people in Apple's metaphorical cockpit.
AI also quickly goes off the rails, even the Opus 2.6 I am testing today. The proposed code is very much rubbish, but it passes the tests. It wouldn't pass skilled human review. Worst thing is that if you let it, it will just grow tech debt on top of tech debt.
Next iterations of models will have to deal with that code, and it would be harder and harder to fix bugs and introduce features without triggering or introducing more defects.
Biological evolution overcomes this by running thousands and millions of variations in parallel, and letting the more defective ones to crash and die. In software ecosystems, we can't afford such a luxury.
An example: it had a complete interface to a hash map. The task was to delete elements. Instead of using the hash map API, it iterated through the entire underlying array to remove a single entry. The expected solution was O(1), but it implemented O(n). These decisions compound. The software may technically work, but the user experience suffers.
If you have particular performance requirements like that, then include them. Test for them. You still don’t have to actually look at the code. Either the software meets expectations or it doesn’t, and keep having AI work at it until you’re satisfied.
How deep do you want to go? Because reasonable person wouldn't have expected to hand hold AI(ntelligence) to that level. Of course after pointing it out, it has corrected itself. But that involved looking at the code and knowing the code is poor. If you don't look at the code how would you know to state this requirement? Somehow you have to assess the level of intelligence you are dealing with.
Since the code does not matter, you wouldn’t need or want to phrase it in terms of algorithmic complexity. You surely would have a more real world requirement, like, if the data set has X elements then it should be processed within Y milliseconds. The AI is free to implement that however it likes.
Even if you specify performance ranges for every individual operation, you can’t specify all possible interactions between operations.
If you don’t care about the code you’re not checking in the code, and every time you regenerate the code you’re going to get radically different system performance.
Say you have 2 operations that access some data and you specify that each can’t take more than 1ms. Independently they work fine, but when a user runs B then A immediately, there’s some cache thrashing that happens that causes them to both time out. But this only happens in some builds because sometimes your LLM uses a different algorithm.
This kind of thing can happen with normal human software development of course, but constantly shifting implementations that “no one cares about” are going to make stuff like this happen much more often.
There’s already plenty of non determinism and chaos in software, adding an extra layer of it is going to be a nightmare.
The same thing is true for every single implementation detail that isn’t in the spec. In a complex system even implementation details you don’t think you care about become important when they are constantly shifting.
That's assuming no human would ever go near the code, and that over time it's not getting out of hand (inference time, token limits are all a thing), and that anti-patterns don't get to where the code is a logical mess which produces bugs through a webbing of specific behaviors instead of proper architecture.
However I guess that at least some of that can be mitigated by distilling out a system description and then running agents again to refactor the entire thing.
> However I guess that at least some of that can be mitigated by distilling out a system description and then running agents again to refactor the entire thing.
The problem with this is that the code is the spec. There are 1000 times more decisions made in the implementation details than are ever going to be recorded in a test suite or a spec.
The only way for that to work differently is if the spec is as complex as the code and at that level what’s the point.
With what you’re describing, every time you regenerate the whole thing you’re going to get different behavior, which is just madness.
You could argue that all the way down to machine code, but clearly at some point and in many cases, the abstraction in a language like Python and a heap of libraries is descriptive enough for you not to care what’s underneath.
The difference is that what those languages compile to is much much more stable than what is produced by running a spec through an LLM.
Python or a library might change the implementation of a sorting algorithm once in a few years. An LLM is likely to do it every time you regenerate the code.
It’s not just a matter of non-determinism either, but about how chaotic LLMs are. Compilers can produce different machine code with slightly different inputs, but it’s nothing compared to how wildly different LLM output is with very small differences in input. Adding a single word to your spec file can cause the final code to be unrecognizably different.
And that is the right assumption. Why would any humans need (or even want) to look at code any more? That’s like saying you want to go manually inspect the oil refinery every time you fill your car up with gas. Absurd.
Cars may be built by robots but they are maintained by human technicians. They need a reasonable layout and a service manual.
I can’t fathom (yet) having an important codebase - a significant piece of a company’s IP - that is shut off to engineers for auditing and maintenance.
It’s not about optimizing for performance, it’s about non-deterministic performance between “compiler” runs.
The ideal that spec driven developers are pushing towards is that you’d check in the spec not the code. Anytime you need the code you’d just regenerate it. The problem is different models, different runs of the same model, and slightly different specs will produce radically different code.
It’s one thing when your program is slow, it’s something completely different when your program performance varies wildly between deployments.
This problem isn’t limited to performance, it’s every implicit implementation detail not captured in the spec. And it’s impossible to capture every implementation detail in the spec without the spec being as complex as the code.
I don’t think it is possible to solve without AGI. I think LLMs can augment a lot of software development tasks, but we’ll still need to understand code until they can completely take over software engineering. Which I think requires an AI that can essentially take over any job.
In big corporations that's how it is. Developers are told to only implement what is in the specs and if they have any objection, they need to raise it to PM who will then forward it to the system architect etc.
So that creates the notion as if the design was something out of reach. I met developers now who cannot develop anything on their own if it doesn't have a ticket that explains everything and hand holds them. If something is not clear they are stuck and need help of senior engineers.
reply