Veserv

Since lawyers just love engaging in language lawyering when things get to court and always use to most uncharitable interpretation of words, we have no choice but to interpret their words in the most uncharitable and technically correct fashion. In that context, let us examine their lawyer-drafted statement.

> LG smart TVs do not continuously record or transmit users’ conversations.

"or" is ambiguous in the English language. A lawyer can rightly argue that they mean exclusive or and thus they are being technically truthful as long as they both continuously record and transmit users' conversations. They can resolve this ambiguity by stating each element as a independent sentence.

"continuously" means without end. A lawyer can rightly argue that as long as the recording can end in a single instance, then they are being technically truthful.

> Speech-to-text processing begins only if a user activates a voice interaction through a supported wake-word feature or by pressing the voice (or AI) button on the remote control.

"processing begins" makes no indication as to when it ends. A lawyer can rightly argue that as long as you use a wake-word a single time or press the voice button on the remote control a single time, they can begin processing and never stop. They can resolve this ambiguity by stating that they only process audio during a session and that session has a strict maximum duration.

Also, it makes no statement as to audio processing, only speech-to-text processing. A lawyer can rightly argue that as long as they do not convert the speech to text and just directly transmit the audio they are being truthful. They can resolve this ambiguity by removing the narrowly defined "speech-to-text" and changing it to "audio". Weird their lawyers made this so specific.

> Audio used for wake-word detection is processed locally on the TV and, if no wake word is detected, audio is not converted to text, stored, or transmitted.

Narrowly defined to be only "Audio used for wake-word detection". A lawyer can rightly argue that if they make a second copy of the audio that does not go to wake-word detection, then they can convert it to text, store, and transmit it. They can resolve this ambiguity by removing the narrowly defined "Audio used for wake-word detection" to just state that they do not convert to text, store, or transmit any audio outside of a session. Weird their lawyers made this so specific.

> Voice-recognition results and related technical logs may be generated as part of processing a voice command. These records are associated with specific voice interactions and do not indicate continuous recording of conversations occurring outside an active voice recognition session.

"These records ... do not indicate continuous recording" is not a denial that they are continuously recording. It merely states that it does not indicate continuous recording. A lawyer can rightly argue that as long as they have at least one record that is not associated with a continuous recording, then they are being truthful. No need to remove ambiguity here as it would be covered by the above fixes.

> Speech-recognition results may be used to support voice-related features but are not uploaded later when the TV is offline or when connectivity is restored.

"but are not uploaded later when the TV is offline or when connectivity is restored". Again, "or". Only mentions later, no statement about "now". Their lawyers can rightly argue that as long as they upload them immediately they are being truthful.

"uploaded later when the TV is offline" is illogical nonsense, how is it uploading when it is offline? Their lawyers can rightly argue that as long as they upload later when the TV is online and the TV never lost connectivity, then they are being truthful.

They can remove the ambiguity by stating that they never upload the speech-recognition results or only retain them until the voice-related feature has completed the task. Weird how their lawyers made this so specific.

> ACR uses audio fingerprinting technology using the TV’s internal audio processor (not a speaker) to identify content and does not collect screenshots, screen recordings, video recordings, voice recordings, or other audio recordings from the TV.

Again, "or". "uses" does not mean exclusively uses. "collect" only means ACR does not collect it. This does not indicate that screenshots, screen recordings, video recordings, voice recordings, or other audio recordings are not collected by other processes. It does not indicate that they do not use the resources collected by those other processes. They can remove the ambiguity by stating that ACR does not "use" these data sources and exclusively uses audio fingerprinting technology. Weird how their lawyers made this so specific.

Truly so odd how their lawyers make such precise, minute, and nuanced distinctions for their benefit, but leave everything else so ambiguous they can rightfully argue a tortured interpretation is technically truthful. If they were lawyers on behalf of the consumers, they would never accept such ambiguous language. Must be accidental.

This is why you should not use low-resolution summarys as exhaustive and authoritative.

"Bullshit jobs are jobs which even the person doing the job can’t really justify the existence of, but they have to pretend that there’s some reason for it to exist. That’s the bullshit element."[1]

He talks about it a lot and the book is 368 pages. Of course you will get some variations on the general theme with some embellishments to get it to hit home. But the key aspect, which he mentions repeatedly, is the part about "even the person doing it thinks it is worthless".

[1] https://www.vox.com/2018/5/8/17308744/bullshit-jobs-book-dav...

I do not see how you are disagreeing with his definition. What do you think his definition is?

You seem to be using the definition: “A job that people think is worthless”.

The actual definition he uses is: “A job where the person doing it thinks it is worthless”.

The commonly cited fatality statistics do not discuss fault, so, absent more precise information, a apples to apples comparison should not conditionalize on fault.

Why? Well let us try to imagine a world where Waymo has the statistically average fatal crash rate, yet is never at fault. In this world, every fatal crash occurs at the Waymos. You just have a bunch of crazy drivers roving the streets causing fatal crashes against (or involving) unsuspecting, not-at-fault victim Waymos.

If that is the world, then are these crazy drivers only crashing into Waymos? Probably not, these crazy drivers would almost certainly be crashing into a statistically average distribution of unsuspecting, not-at-fault victims.

So this imagined world is consistent with the overwhelming majority of human drivers engaging in 0 fatal accidents at fault with a small, crazy roving subset being at fault for all fatal accidents. So, in that world, a Waymo that is only ask good as the statically average driver would actually be infinitely worse than the overwhelming majority of human drivers. If you only replaced the 10th percentile driver (90% of drivers are better), you would actually be increasing the fatality rate. Only by displacing that crazy subset would you actually be decreasing the fatality rate.

Are we in that world? The Waymo numbers on fatal accident involvement with no fault actually kind of point in that direction (though the mileage numbers are still too low to make a strong conclusion). Seemingly massive crash and injury reduction due to massive reduction of at-fault crashes, but the fatality reduction does not seem proportional. Another possibility is that the Waymo driving distribution is biased toward being in situation that result in more no-fault fatal crashes.

But, that is all just conjecture and thought experiments. Unless we have better data, we unfortunately should be restricting ourselves to apples to apples comparisons which, in this case, do not conditionalize on fault.

Though, to nitpick on the original post, I think that the 2 fatal crashes in 170 million miles (~85 million miles per fatal crash which is similar to the USA human average of ~83 million miles per fatality), is probably not the correct analysis. The average fatal crash is probably 2 vehicles and 1 fatality. So, the 85 million miles per fatal crash versus 83 million miles per fatality is probably fine in the crash vs fatality direction. But I am pretty certain you would actually need to double the 170 million to account for the "statistically average mileage of the other cars".

Otherwise, if we have exactly two cars in the world each with 100 million miles and they engage in one fatal crash with one fatality, then we would conclude that car 1 has 1 fatality per 100 million miles and car 2 also has 1 fatality per 100 million miles. Naively averaging them, we could conclude that the overall fatality rate is 1 per 100 million miles. Therefore, over the 200 million miles the two of them drove, there were 2 fatalitys. Obviously incorrect, so we almost certainly need to weight them by their relative proportion when aggregating them.

You are correct, I missed the adjective on my second use. As my points were exclusively about fatal crashes and I never mentioned the injury or crash rate at any point and previously used 5,500 years exclusively in relation to fatal crashes, it should be obvious that I intended to mean that and my point still stands with that correction.

Sir this is a Wendy's, I mean a discussion about autonomous vehicles. The benchmark for the autonomous vehicles in the USA is in comparison to humans in the USA. That means autonomous vehicles need to go ~5,500 person-years worth of driving between crashes to equal the mean driver. The mean US driver is a very high bar to reach for technology, that is why Waymo has just maybe barely reached that bar after nearly two decades and billions of dollars.

The fatality rate is 1.19 per 100 million vehicle miles [1], ~83 million miles per fatality. The mean driver averages ~15,000 miles per year. So, the mean driver encounters a fatal crash after ~5,500 years of driving. If you started driving when the Great Pyramid was built, you would still have another 1,000 years before you would expect to die in a fatal crash.

The mean driver in the context of the USA driving environment is shockingly safe. Being safer than even the mean human driver in the USA is hard and takes a shocking amount of data to verify. Anybody downplaying it as "lol humans are so unsafe" to argue the problem feels easy to solve or can be solved by the end of the year with a little bit of elbow grease is utterly clueless.

[1] https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...

A public, well documented safety defect for multiple years with clear, incontrovertible evidence:

https://bsky.app/profile/realdanodowd.bsky.social/post/3lz6h...

https://www.jalopnik.com/1983251/tesla-train-tracks-investig...

https://www.jalopnik.com/1971193/tesla-full-self-driving-mig...

https://www.nbcnews.com/tech/elon-musk/tesla-full-self-drivi...

They still have not been able to solve the challenging problem of stopping when there are bright, flashing red lights and loud horns after over a decade of furious work and years of public reports.

But Tesla Robotaxi will totally be ready to serve half the US population by 8 months in the past. Railroad crossings are just the hardest nut to crack unlike simpler problems like full autonomy.

Just like learning calculus. The hardest problem is learning how to add. Once you get that it is just a few months to calculus.

Only if you think penetrating holes in a paper vest and then patching those holes constitutes “improving”. If that worked Windows and Linux would be impenetrable fortresses with all the holes that keep getting punched in them.

Cyberdemolitions expertise is about as relevant to cybersecurity as gun making is to bulletproof vest making. Necessary for validation, but not very related to the fundamental engineering and technology.

That makes as much sense as saying that better gun technology results in body armor that can stop it. It might incentivize that, but in no way "results" in that; the fundamental technologys underpinning advancements in offense versus defense are fairly different.

What is the "same one"? Define item in "I" formally.

Are we talking about Values? Then inigyou is correct.

Memory locations? Then it is trivially true, but that does not prevent me from writing 0 into every memory location.

Value + Memory location? Then it does not work for arrays since we are modifying the memory locations by moving the values between them.

The abstract notion of manipulable things in a indexable order? You need to show how that correlates to reality in a way where you can not put in a hole even larger than this one you are trying to close.

To loop back, this very discussion shows how non-trivial it really is and how much thought actually needs to be put into handling even "trivial" problems. Almost everybody who talks about how we can replace these complex implementations with simpler, understandable specifications has little to no experience with the difficulties of actually creating correct specifications. Anybody who would bring up sorting as "trivial" either has no idea what they are talking about or is so far ahead that they have weird ideas as to what constitutes as "trivial". In both cases, their opinion is highly divorced from practical reality.

That is not to say that it is not worthwhile or even that the specifications are "more complex". It is quite possible the specification is still simpler despite the difficulty, but it is also likely the complex implementation was already totally incomprehensible and a simplified specification is also incomprehensible, it is now just formally incomprehensible.

You are correct.

However, that specification is not trivial. Almost nobody correctly articulates property 1 when first encountering the problem if they do not already know the answer or are already aware it is a trick question (and even then most software developers still fail).

Furthermore, that also sidesteps the problem of formally specifying what a permutation is. Unless you have a grab bag of already proven powerful theorems, the author is most likely also going to make a error doing that as well even if we start at a proof abstraction level comparable to normal programming.

Reality is that trivial problems admit trivially wrong specifications exceedingly easily. There is little reason to assume that much more complicated problems that are hard to even articulate will magically support obviously correct specifications that are simpler and more understandable than the code.

Huh? Sorting does not have a trivial specification. In fact, it is usually used as the first example of how easy it is to make specification errors because it seems trivial, but is actually not.

You are objectively wrong. The math is straightforward to show that you can operate on a ciphertext securely in some cryptosystems.

Consider two integers M1 and M2.

Consider RSA with private key (E), public key (D), and public modulus (N).

Encrypt(M, E, N) = mod(pow(M, E), N).

Decrypt(C, D, N) = mod(pow(C, D), N).

mod(Encrypt(M1, E, N) * Encrypt(M2, E, N), N) = mod(Encrypt(M1 * M2, E, N), N).

So, for all RSA encryption, multiplying the ciphertexts results in a ciphertext that is the multiple of the plaintexts. However, unless you can break RSA, you can not determine what numbers you multiplied or what the final multiplied number is.

This is not a fully homomorphic system as it only allows multiplication, but it is a existence proof that you can do operations on ciphertext that apply to the plaintext without being able to recover the plaintext unless you can break the encryption directly.

Shadow memory mappings are only needed when you do not have hardware virtualization or when doing nested virtualization.

From the page: "it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization"

That is not to say that it is not a serious vulnerability though.

You can prove a program is correct and terminates for all inputs and, absent a hardware or other assumption vulnerability that breaks the abstract machine assumptions, there would be no inputs that "break" anything. In fact, almost any human-designed program that is correct and terminates would not just be provable, but "easy" to prove algorithmically (in the theoretical sense, in a practical sense existing techniques are insufficient to prove complex programs).

Even ignoring isolation guarantees that could generically prevent unbounded escalation for arbitrary programs, you can just reject anything that is not "easy" to prove. Humans are really dumb, so anything that is not directly proven or easy to prove automatically is almost certainly not correct, so you can just err on the safe side and just reject them if you care about global correctness.

> You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security."

That sentence is grammatical nonsense. Try again to articulate your point so it is coherent.

Furthermore, you have still failed to present any historical examples for literally any of your bullet points or articulate any of the claimed upsides you purport have failed to pan out. In contrast, I have pointed out two frequently claimed upsides, reliability and security, that have demonstrably succeeded to such a degree that prevailing monolithic systems were largely replaced with microkernel systems in domains where reliability and security are highly valued such as aerospace and defense. To the extent that monolithic systems are still used, they were either the legacy option that has not been replaced or chosen where cost reduction is the highest priority, not security and reliability.

> FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority.

Frankly, I find it baffling that you think that nuclear weapon systems, military jet fighters (which are network connected by the way), and commercial jetliners (also network connected) have lower reliability and security requirements than commercial networking equipment. And this is ignoring the fact that commercial networking equipment is some of the worst with respect to reliability and security. Cisco, one of the largest vendors in the space, routinely has trivial remote authentication bypasses allowing complete takeover. Here is one from last month: https://app.opencve.io/cve/CVE-2026-20181. One from earlier this year: https://app.opencve.io/cve/CVE-2026-20079. Or this one: https://app.opencve.io/cve/CVE-2026-20127. How about this one: https://app.opencve.io/cve/CVE-2026-20182.

Commercial networking equipment security is a joke. Find me literally any technical person who would claim that Cisco can defend against state actors. I will wait.

You have a serious misunderstanding of the consequences of the undecidability of the Halting Problem. The Halting Problem says you can not prove the precise halting behavior in every problem. Precise and every are very important qualifiers.

If you sacrifice precise and widen it to: "Halt" and "Maybe run forever, but might just take longer than the age of the universe and is thus irrelevant for actual programs we might choose to run" then it is decidable for every problem.

Every means that there exist programs, in the infinity of all programs, that can not be proven. It does not mean that no program can be proven. Programs that are 10^8000000 instructions long that are intentionally obfuscated count in every. Human-designed programs that humans want to be correct and are reasonably sure are correct are extremely well-behaved in comparison and their provable termination can almost always be reasoned about.

Generally speaking, human-designed programs are almost always implicitly being constructed in the space of programs that will terminate (possibly relative to a event loop). At every step of the process you only extend using provably terminating constructions. Few humans will have a loop condition like: "Terminates if the Goldbach Conjecture is true" which is one of those sorts of things that makes it hard to prove termination. Just stay away from unproven conjectures in your loop conditions and you will probably be fine.

You did not claim that microkernels were less commercially successful.

You claimed that microkernels suffer from the same security problems that plague commercial monolithic kernels such as Linux, Windows, macOS, iOS, Android, etc.

You claimed without evidence, and I quote, “none of the upsides have panned out”.

In contrast, microkernels have completely dominated the field, displacing prior monolithic kernel solutions, in domains where reliability and security are not the lowest priority. All you have really supported is that the broader commercial IT landscape continues to prefer easily hacked systems as long as they can save a buck.

> history has proven

What history? What proof? What evidence?

What commercial microkernel systems are you referencing that suffer from trivial LPEs? Or whole system DoS from unprivileged code execution? To the extent that you argue your alleged failure modes are fundamental.

> none of the upsides have panned out

Again, what history? What proof? What evidence?

One of the stated upsides relative to monolithic kernels is superior reliability. There are numerous microkernels reliable enough for usage in critical flight systems. None of the standard commercial monolithic kernels are even in the vicinity of that.

Another of the stated upsides is superior security. There are multiple microkernels secure enough to be platforms for systems that need to be secure against state actors. None of the standard commercial monolithic kernels are even in the vicinity of that.

History has proven the opposite of your claims. The concrete evidence is the opposite of your vague unsupported assertions.

Have they figured out how to implement free() yet?

Last I looked you need a garbage collector to deallocate at which point you might as well use Java which is actually designed for that use case.

Sure, this is why virtualization is a valuable feature, it is just not the basis of security/isolation.

One of the points I am making is that when deploying on a modern multi-tenant VM-based platform, VM orchestration is analogous to process orchestration. However, you orchestrate the units, VMs, in a very different way to how you would orchestrate processes on say Linux. If your platform orchestrates, configures, and operates processes the same way a VM-based platform orchestrates, configures, and operates VMs and your implementation is solid then you would see similar security benefits. Virtualization is not the key. It just kind of looks that way because virtualization is usually paired with a fundamental re-architecture.

In greenfield application development or cases where you would do single-application VMs, you would target processes/platform directly. Only in situations where you are literally lifting code from a different OS environment that you can not or will not port to the native model would you need to go through a VM. If you orchestrate them the same way and your operational models for them are similar, then you will usually see similar outcomes. This is how it works in high security microkernels/separation kernels which simultaneously allow native processes alongside VMs. Virtualization is a feature to allow non-porting, it is not security/isolation; that is already provided underneath.

Yes, you do enjoy evading the argument. You continuously point at implementation and operational model differences as proof that virtualization is the key factor. Theo's argument is literally that virtualization versus non-virtualization is irrelevant compared to implementation and operational model deficiencys. If you make garbage implementations and operational models, then you get garbage virtualization. If you have a good implementation and operational model then you do not need virtualization for "security".

As independent evidence for this point, virtualization is not the basis of security/isolation in seL4. You have isolation without any virtual machines. Virtual machines are just a feature on top that can leverage the existing isolation functionality to also provide isolated virtual machines. Of course, a secure deployment then requires you to leverage this foundation with a good operational model and system design since you can always make a insecure system even atop a good foundation. This demonstrates that virtualization is not necessary for a secure base, nor sufficient to achieve highly secure systems.

Just to hammer in the point that you are heavily misinterpreting Theo's response, this is the full sentence at the start of the post that Theo was responding to:

"Virtualization seems to have a lot of security benefits. Rootkits can lie to DomU but not Dom0, and of course snapshotting, migration etc is really nice."

Wow, amazing, rootkits can never be in Dom0 because Xen has "virtualization" magic pixie dust. Theo is pointing out how this is nonsense and virtualization will only provide security if you can create implementations without glaring security holes. Furthermore, you should not just listen to the people who brought you insecure system 1 when they tell you that this time for sure they are going to give you secure system 2; maybe have just a little bit of cynicism and ask for some evidence first.

Cool, show me a LPE in a seL4 deployment. Do you believe that is easier or harder than finding a KVM escape?

Since you are varying the security basis, implementation, and operational model simultaneously when you are comparing KVM to Linux to argue that the security basis is the important factor, I get to as well. Except mine is actually more fair because the design of a seL4-based system is actually much more similar to the design of a multi-tenant KVM-based system than the design of the KVM-based system is to the design of a Linux user environment.

Great, then falsify it. Point at a system with the same operational model as KVM-based multi-tenant systems with large numbers of platform vulnerabilitys.

Let us review a standard operational model:

Virtual machines are usually pre-allocated their total RAM. Virtual machines are usually pre-allocated a number of cores and pinned to them. Virtual machines are usually only allocated a small number of devices such as a virtual block storage device and virtual network device upon which they implement a in-VM filesystem and network stack. Virtual machines usually have no access to shared services provided by the hypervisor.

So we have a operational model where you have to pre-allocate RAM to a process. You have to pre-allocate a whole core and pin the process to it. The process has no access to a global filesystem, network stack, or devices. The process has access to exactly one file, which is logically similar to a virtual block storage device, and a single raw network socket, which is logically similar to a virtual network device. The process has no ability to form a socket to another process, form a new file, or even have any way of interacting with other processes at all. The process has no access to shared services of any kind.

The chasm between that operational model and any commercial IT operating system is immense, being basically the polar opposite in every dimension in the direction of security. Default-deny instead of default-allow. Shared-nothing instead of shared-everything. What you have there is a system even more static and simple than what runs on most microkernels. That is the comparable class of platforms with a similar operational model.

To demonstrate that virtualization is the key factor, you need to demonstrate that actually comparable systems with similar operational models like microkernels have more platform vulnerabilitys than comparable KVM-based, or even just hypervisor-based, systems. Which, again, flies against the face of evidence as the systems that are actually used in high security applications designed to protect against state actors are separation kernels instead of hypervisors.

Virtualization is responsible for effectively none of those security benefits.

It is the reduction to a smaller “kernel” that is responsible. If you applied the same design and operational model to running regular old processes instead of virtual machines you would also get a system with less security holes than the grossly insecure rat’s nest that is Linux, Windows, or whatever other commercial IT OS you have in mind.

Virtualization is almost entirely orthogonal, if not harmful, to security of the platform and operations. It is not magic pixie dust that makes your operational model more robust. You need a robust operational model, then you can have a robust operational model with virtual machines.

There is a reason why the most secure systems in the world are separation kernel architectures instead of hypervisors even though most of those systems do support virtualization as a feature, just not as the basis of their security propertys.

Claims do not support themselves. The claim is unsupported by evidence and thus the burden of proof is on them or you to produce that evidence.

As the author and implementer of the algorithm allegedly prepared, ran, and analyzed benchmarks they obviously, by far, have the easiest time producing the evidence for their claim. Your argument that the poster needs to go read, implement, integrate, and benchmark the algorithm to to generate evidence to counter the absence of evidence for the claim is ridiculous. It would be as easy as 1-2-3 for the author to present their evidence to meet their burden of proof, yet you are demanding a extraordinary level of effort by the poster to present evidence against when they do not even have the burden of proof.

This is further ridiculous because the author or you would merely need to support the positive claim, where as you are demanding the poster demonstrate the negative, and all this before there is any evidence.

You should really stop with the unnecessarily combative tone when your entire model of argumentation is completely backwards in every respect.

Writers make conscious trade offs between time, cost, feasibility. Are writers language engineers? Literally everybody makes trade offs, that is not a distinguishing aspect.

I am confused how you got to “make the minimal thing that ticks of [sic] all of the must requirements”. I said engineering was about objective guarantees. Requirements are a derivative and means of that.

Making things better, more efficient, cheaper, etc. is not at odds with that. If you guarantee that level of performance and achieve it, then you have produced a acceptable instance meeting your guarantees. If you fail to meet your guarantees, then you have something unacceptable.

Despite the tolerances of a rocket-quality screw being far better than a car-quality screw being far better than a toy-quality screw, a car-quality screw does not get a pass in rockets because it is “better” than a toy-quality screw. It needs to meet the guarantees.

When you would rather have nothing over something that pretends to meet its guarantees, then you are probably in the vicinity of engineering.

To add on, engineering is about objective guarantees to meet objective responsibility.

This bridge is rated for 10 tons. This chemical process produces 1 mg 99% purity crystals. This biological process produces 90% pure insulin. This circuit handles 1 kA.

Engineering is not about better or worse it is about acceptable or unacceptable.

This naturally results in a desire for requirements so you can meet your guarantees. Specifications so you know what guarantees you need or what you are provided and how those map back to the real responsibility. Standards so you can consistently solve common problems.

Why do we judge an organization by their leader and head executive who has complete control over direction and operations? Who individually has a controlling interest which can and has been used to elect himself the leader? Who regularly, openly, and publicly talks about how he needs to have control over the operation of the organization to be willing to run it?

You would be hard pressed to find a person who is more responsible or more representative of their organization than that.