The purchasers of the cameras, ie HOAs, law enforcement, etc, own the data. They are also the ones routinely caught abusing this. This is a real problem that should be dealt with by enforcing laws against the people improperly using the data.
I'm not sure what a realistic solution is for Flock to try and manage data they do not own nor if it makes sense for them to deny access to data they are not the owners of.
This is false. the HOAs and LEOS have access to the data. Even if the contract specifies that the data is owned by these organizations, they are not the true owners.
signull is more of an anonymous sh*tposter than a known industry insider, but I think this does capture the sama contribution to OpenAI very well. At least from an outsider who follows this stuff based on vibes.
That twitter story isn't anything unique to OpenAI or Google, it's just classic "big public corp vs private startup" culture. Once you have to worry about the SEC, shareholders, antitrust, regulations, lawsuits, etc. it's very, very difficult to avoid turning into "big corp" culture.
Sama, and any other founder, will always have a difficult fight against bureaucracy, and once you let a little bit in, the bureaucracy's sole purpose becomes to grow itself.
Google is facing a legitimate innovators dilemma here. It makes sense to have all this process when youre protecting a $4.5 trillion golden goose. The tragedy here is that one predictable outcome of this situation is google deciding to considerably cut research funding when they figure out it just serves to bootstrap future competitors.
This is when it makes sense to split your business up into multiple smaller businesses. The government should be doing this via anti-trust but they have dropped the ball there so, at this point, the corps really need to just do it to themselves to better compete.
Or maybe just have your R&D teams focused on doing R&D with zero corporate interference. Staff it with personal assistants whose only job is to ensure the researchers have whatever they need and are never bothered with meetings or other corporate shenanigans. The assistants could then be the proxies to management to provide feedback to management, but only on best effort and still staying the fuck out of the way of the researchers.
Easey peasy was said with a wink, although technically speaking it would be easy -- if they didn't have their heads up their ass.
A dear friend of mine was doing R&D at a startup where management poured on a bunch of low-level management work that took him away from his joy, which was developing new tools and approaches to solving customer problems. He left, and went to another gig that promised him complete freedom to invent and discover. That job is at a Fortune 500 company that is slowly starting to pull its head out of its ass.
Google bloat gave us transformers. Apple bloat gave us a usable touchscreen only, pocket computer (famously an entire org within Apple had developed an iPod-based approach that was competing with what was released)
The leaps forward need bloat. A startup can execute on specific vector direction way better.
Now back to your point, what did X deliver with its lean ops? It seems that it needed 2 bailouts (one from xAI, and one from space X)
I disagree. It's not about the culling, it has never been, and actually, it makes things worse. You spend countless hours and tons of money recruiting talented people not to lay them off because you don't want a bureaucratic org.
If the issue is inefficiency, tons of meetings, too much team alignment etc, then that's the issue that you need to tackle, and these issues can already appear in a 50-100 employee company. Sure, that's an easy problem to solve with a smaller size but unless you hired people for no reason, these people have a very specific set of problems to tackle and are often, in these companies, the best in class to tackle them, culling half of the company isn't going to make things better.
It's impossible to disambiguate but advertiser tools, brand safety, targeting, reporting etc all need a lot of ongoing effort. If it gets harder to advertise effectively on Twitter, those dollars can very easily go elsewhere.
Eh, what has X/Twitter delivered since the cull? It’s basically in maintenance mode. Which is fine if that’s what you want to do, but Google and Apple definitely don’t (and I’m glad for that)
Has been in more of a maintenance mode with a multiple of those people. If anything, the pace of the product has improved. Regardless of what you think about Musk, the company he bought was a bloated mess.
Google is competing with nvidia (TPU), AWS (GCP), Netflix (youtube), Tesla (waymo self driving), OpenAI (Gemini), Microsoft (Workspace), Apple (Android)....
I'm wondering why Ren'Py is never mentioned here at all. Judging from that comparison it seems to be much more powerful than these alternatives. But maybe I'm misunderstanding what these tools are actually for.
This page came about because of how long it took PQC to get standardized. This was a slow enough process that a whole slew of QKD vendors arose and sold a lot of products promising this as a solution to dealing with quantum computers and harvest now decrypt later attacks. Many of those products did not do a great job at actually preventing listening in on their lines since QKD is an ongoing field of research where new issues are routinely being discovered.
> QKD is an ongoing field of research where new issues are routinely being discovered.
This always bothers me a bit. QKD is on a very solid theoretical footing — if you have an authenticated classical communication channel and an actual quantum communication channel that sends actual qubits that are genuinely only in the basis you think they’re in, then it’s secure, full stop. It’s been proven for decades.
But this is hard (hint: a commercially useful quantum computer does not exist yet), so people fudge it with optical techniques that approximate, poorly, what is needed. And the result is not secure.
I wouldn't call it "solid theoretical footing". The rough sketch of QKD is
1. BB84 key exchange requires an authenticated channel. typically you do this with a
2. Carter-Wegman MAC, which is information-theoretically secure, but requires shared randomness that cannot be reused.
Successful protocol execution refreshes randomness (you can net gain from it), so you can communicate back and forth continuously when everything is working. An MiTM who simulates a network failure though can expend some of your pre-shared randomness (without it being refreshed). If they do this enough, they can exhaust your shared randomness, and bring down the link until you exchange more shared randomness somehow out of band. if you want to maintain information theoretic security, this might involve e.g. a courier with a USB or whatever (or a carrier pigeon, who knows).
This is still "secure", but is also a significant issue any QKD (even "real" QKD) has that classical cryptography does not have, and has always made me question the "solid" story for QKD.
QKD is interesting from the PoV of perfect secrecy. But AFAIK with e.g. BB84, the basis orientation communication (used to detect OTP delivery eavesdropping) is done with Wegman-Carter (unconditionally secure) authentication using... a pre-shared key.
So if you're only interested in computational security that is post-quantum, why not pre-share a symmetric key for some AEAD scheme? You'll get forward secrecy with hash ratchet and neither provides future secrecy in principle.
Neither solves the bootstrap and QKD requires a really, really expensive and complex infrastructure just to provide perfect secrecy which we're fine without.
In my opinion, QKD (implemented correctly) performs key exchange, basically like Diffie-Hellman except that it’s secure even against an adversary with unlimited computing power. If I had a quantum computer and a quantum network anyway, may I’d use it, but probably not with Wegman-Carter. If not, I wouldn’t.
(BB84 is from 1984. The terminology was different, and the understanding of what mattered in cryptography was different.)
BB84 (and QKD overall) requires authenticated channels. You have to get those somewhere. You can get them from an information-theoretically secure MAC, but it has significant downsides. You can get them with computationally secure primitives, but then there's no point in using QKD in the first place. You cannot instantiate QKD securely without one of those two choices though.
> You can get them with computationally secure primitives, but then there's no point in using QKD in the first place.
I don’t entirely agree. You can build a computationally secure authenticated channel using symmetric primitives (e.g. hashes) that are very, very likely to survive for a long time. And you can build comparably secure asymmetric authentication schemes from the same primitives (hash-based signatures are a thing).
But to build a classical key exchange system, you need more exotic primitives (Diffie-Hellman or public-key encryption / KEM schemes), and the primitives of this sort that are supposedly post-quantum secure have not been studied for nearly as long and have much more structure that might make them attackable.
Not to mention that attacking the authenticated channel in QKD cannot give a store-now-decrypt-later attack.
The point is there is no public key capability in BB84 that requires pre-sharing a symmetric key.
You absolutely do get forward secrecy with pre-shared keys. You just need to make the protocol derive the next key with a cryptographic hash function, and deliver the iteration count with the packet so the recipient knows which key is the correct one. This is called a SCMIP or hash ratchet, and it's used e.g. in Signal protocol.
(As implementation details, you'll also want to hash the hash ratchet counter with the key to prevent theoretical loops, and you'll probably want to encrypt the ratchet counter during delivery with static header key, or the very least authenticate it.)
I think the author makes some interesting points, but I'm not that worried about this. These tools feel symmetric for defenders to use as well. There's an easy to see path that involves running "LLM Red Teams" in CI before merging code or major releases. The fact that it's a somewhat time expensive (I'm ignoring cost here on purpose) test makes it feel similar to fuzzing for where it would fit in a pipeline. New tools, new threats, new solutions.
That's not how complex systems work though? You say that these tools feel "symmetric" for defenders to use, but having both sides use the same tools immediately puts the defenders at a disadvantage in the "asymmetric warfare" context.
The defensive side needs everything to go right, all the time. The offensive side only needs something to go wrong once.
I'm not sure that's the fully right mental model to use. They're not searching randomly with unbounded compute nor selecting from arbitrary strategies in this example. They are both using LLMs and likely the same ones, so will likely uncover overlapping possible solutions. Avoiding that depends on exploring more of the tail of the highly correlated to possibly identical distributions.
It's a subtle difference from what you said in that it's not like everything has to go right in a sequence for the defensive side, defenders just have to hope they committed enough into searching such that the offensive side has a significantly lowered chance of finding solutions they did not. Both the attackers and defenders are attacking a target program and sampling the same distribution for attacks, it's just that the defender is also iterating on patching any found exploits until their budget is exhausted.
That really depends of the offensive class. If that is a single group with some agenda, then that's just everyone spending much resources on creating solution no permanent actor in the game want actually to escalate into, just show they have the tools and skills.
It's probably more worrying as you get script kiddies on steroids which can spawn all around with same mindset as even the dumbest significant geopolitical actor out there.
> These tools feel symmetric for defenders to use as well.
I don't think so. From a pure mathematical standpoint, you'd need better (or equal) results at avg@1 or maj@x, while the attacker needs just pass@x to succeed. That is, the red agent needs to work just once, while the blue agent needs to work all the time. Current agents are much better (20-30%) at pass@x than maj@x.
In real life that's why you sometimes see titles like "teenager hacks into multi-billion dollar company and installs crypto malware".
I do think that you're right in that we'll see improved security stance by using red v. blue agents "in a loop". But I also think that red has a mathematical advantage here.
>> These tools feel symmetric for defenders to use as well.
> I don't think so. From a pure mathematical standpoint, you'd need better (or equal) results at avg@1 or maj@x, while the attacker needs just pass@x to succeed.
Executing remote code is a choice not some sort of force of nature.
Timesharing systems are inherently not safe and way too much effort is put into claiming the stone from Sisyphus.
SaaS and complex centralized software need to go and that is way over due.
I mean, yeah you can have the joy of being right from the heights of the hill you are standing upon. But It seems like you grasp the heart of problem being discussed.
How do we deal with the floods threatening those living in the valleys and slopes?
How do bug bounties change the calculus? Assuming rational white hats who will report every bug which costs fewer LLM tokens than the bounty, on expectation.
For the calculus to change, anyone running an LLM to find bugs would have to be able to find all of the bugs that anyone else running an LLM could ever find.
Correct me if I'm wrong, but I think a better mental model would be something like: Take the union of all bugs found by all white hats, fix all of those, then check if any black hat has found sufficient unfixed bugs to construct an exploit chain?
An LLM Red Team is going to be too expensive most people; an actual infosec company will need to write the prompts, vet them, etc. But you don't need that to find exploits if you're just a human sitting at a console trying things. The hackers still have the massive advantage of 1) time, 2) cost (it will cost them less than the defenders/Red-Team-As-a-SaaS), and 3) they only have to get lucky once.
This + the fact software and hardware has been getting structurally more secure over time. New changes like language safety features, Memory Integrity Enforcement, etc will significantly raise the bar on the difficulty to find exploits.
> These tools feel symmetric for defenders to use as well.
Why? The attackers can run the defending software as well. As such they can test millions of testcases, and if one breaks through the defenses they can make it go live.
Right, that's the same situation as fuzz testing today, which is why I compared it. I feel like you're gesturing towards "Attackers only need to get lucky once, defenders need to do a good job everytime" but a lot of the times when you apply techniques like fuzz testing it doesn't take a lot of effort to get good coverage. I suspect a similar situation will play out with LLM assisted attack generation. For higher value targets based on OSS, there's projects like Google Big Sleep to bring enhanced resources.
Defenders have threat modeling on their side. With access to source code and design docs, configs, infra, actual requirements and ability to redesign / choose the architecture and dependencies for the job, etc - there's a lot that actually gives defending side an advantage.
I'm quite optimistic about AI ultimately making systems more secure and well protected, shifting the overall balance towards the defenders.
Defenders have the added complexity of operating within business constraints like CAB/change control and uptime requirements. Threat actors don’t, so they can move quick and operate at scale.
It's clear, from watching Russia fail to be completely sanctioned that this is not watertight. The question I have is: have these sanctions added a money laundering tax to doing business? How much? What is the cost of enforcing the sanctions vs the added cost and is that worth it?
I don't know if this has been explored, bit I think it's an interesting follow on to "all or nothing" watertight sanctions.
Yes, that's pretty much the main goal with sanctions (and things like export controls): no-one expects them to be impossible to work around, but they should impose some (ideally very large) extra costs and limit the scale. For some things this is more or less built into the regulations with de-minimis rules that tacitly cap the cost multiplier at 10x or so.
On a national scale sanctions aren't there to stop a country from doing things or forcing regime change. They're there to cost enough money to circumvent that it robs them of growth over time to make them into a non-threatening poor backwater over a decades long period.
This is basically what the US did to most of its "makes actual stuff" economy over the past 50yr.
When it comes to banking laws and the like it's not about being watertight. It's about holding enough water that what leaks out is small enough you can crush it with the state jackboot without enough collateral damage to really piss people off and that the cost of circumvention is high enough that you can't make "real money" outside the law at scale.
In theory it prevents failures of the allocator that would allow reading uninitialized memory, which isn't really a thing in Go.
In practice it provides a straightforward path to complying with government crypto certification requirements like FIPS 140 that were written with languages in mind where this is an issue.
If a magazine for parents of severe-peanut-allergy children ended every "may contain undisclosed peanut" recall article with a "Here's our current top 3 brands for child peanut safety: ...", would anyone refer to that as reeking of journalistic bias?
How 'bout if Consumer Reports published a "We Tested 17 kitchen garbage disposals" article, and their 1-paragraph summary of the worst-rated model said "buy one of our 3 top-rated models instead"?
(Yes, I know you're giving a "proper" response. And that very few journalists might say "buy X, Y, or Z instead" about a 900 lbs. gorilla like Cisco. Recall my "Daydream" disclaimer.)
Well the idea behind tokens is that they should be time and authZ limited. In most cases they are not so they degrade to a glorified static password.
Solutions like generating them live with a short lifetime, using solutions like oauth w/ proper scopes, biscuits that limit what they can do in detail, etc, all exist and are rarely used.
I'm not sure what a realistic solution is for Flock to try and manage data they do not own nor if it makes sense for them to deny access to data they are not the owners of.
reply