coppsilgold

TCP stack can be fingerprinted

How does that apply to Tor? It uses custom packets. The entry node may be able to obtain a TCP fingerprint but that's all.

It's not surprising that JS would out you, what I am wondering if whether or not volunteering OS information is foolish when it may not be possible to determine without JS.

Why give up information when you don't have to? Some people disable JS at least some of the time.

I believe they used to make the user-agent appear to belong to Windows but then they stopped doing it with the excuse that there are other ways to tell anyway.

The OS doesn't really matter, the amount of entropy it contains is very low. As long as the anonymity set of browser-users is large it's all good. And I believe Tor Browser accomplishes this objective.

Even Tor Browser (/mullvad-browser) gave up trying to obscure the operating system though arguably they shouldn't have. There appear to be too many fingerprinting vectors.

And those types of schemes will never see the light of day, read what they are actually proposing to implement.

Those schemes will never see the light of day, attribution is by design. Without attribution you will just see those tokens sold by the penny.

With ZKP age verification, services will not be able to track you without help from the CA. The CA will not be able to track you without help from the services. Both will contain the necessary information in their databases that when combined deanonymize you. The CA is the central authority/certificate authority.

So you should assume the government can track you, because you should assume both will be streaming those identifiers to it.

Unfortunately ZKP's aren't magic.

When not doing privacy oriented cryptocurrency (cough money laundering cough) with ZKP's, if you really want private verification you are in a position where a single actor can authenticate the entire world and no one will know it happened. And to prevent it you assemble the pieces necessary to deanonymize anyone.

Make no mistake. ZKP age verification, as proposed, will just require multiple parties to collude to figure out your identity.

They can't even implement ZKP for remote attestation due to the auth-the-world problem.

Exposing the socket directly to the sandbox is dangerous, e.g. it would let the sandbox record the host's microphone directly.

libpipewire-module-pipe-tunnel

also: <https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_req...>

Properly configured (including strict seccomp) bwrap on its own will be sufficient 99% of the time. But ultimately you are at the mercy of the enormous kernel attack surface and the 0days that result from it.

If you do anything valuable and are compromised it may get brought to the attention of whoever organized the automated attack (ex. AI agent doing interesting proprietary work that installed something it shouldn't have, chat logs got uploaded and analyzed) and they will then sell you to someone with the 0days to extract more value from you. Assuming you didn't screw up and leave a back door open somewhere of course.

There is something wrong with your setup.

I just tried:

    bwrap ... --ro-bind /run/user/1000/pipewire-0 /run/user/1000/pipewire-0 ... -- runsc ... do ... -- mpv podcast.mp3

That's good to hear! Hopefully the passt approach you are pursuing will include the ability to use an existing passt socket and not just launch one for you.

Wayland is tricky because there are memory buffers being shared between the compositor and the client. crosvm (also by google) adopted 2 custom solutions to it of which one got merged into mainline.

Achieving audio passthrough is trivial as it's just a unix socket. `-host-uds=all`

It just didn't seem fully baked yet, the 'do' subcommand works fine while the 'bwrap' alias has this problem: `bash: cannot set terminal process group (1): Not a tty`. When executing 'bash -li'. Also the EROFS feature of 'do' should probably be included in 'bwrap', it can be useful. Include overlay options.

Also some things you can do to make gvisor better are Wayland passthrough, vulkan support (or virtio native context). Being able to get gvisor to populate a network interface inside itself through a 'passt' (or 'containers/gvisor-tap-vsock') socket on the host would also be ergonomic. All of those are available on 'muvm' (based on libkrun) which if you have the time to set up is the next step in DIY sandboxing of graphical apps as well. See: <https://git.clan.lol/clan/munix>

The simplest worthwhile DIY sandbox you can have is to layer two tools: bwrap and gvisor.

    bwrap args -- gvisor args do args -- /path/sandboxee args

Standalone gvisor (not the 'do' subcommand) used to be a mess with the OCI json requirement, but recently they began work on presenting their own bwrap interface (likely to pursue AI agent uses) though I wouldn't use it myself yet.

People often look down on gvisor because they think it's some kind of syscall filter, it is not. It can use one of ptrace, seccomp or even KVM to intercept ALL syscalls and service them with it's own logic (which is in Go). Basically it's a VMM and kernel in one.

Identity theft is a thing. And if you gate a desirable commodity behind an identity it will become even more of a thing. There are 100's of millions of identities to steal.

Alpine is a good system for the boot/main rootfs because it's rock solid and has the most recent kernel. When glibc is required or when you just want to access the repositories of other distros you can unshare and pivot_root into the respective rootfs (using bubblewrap). There is also flatpak (uses bubblewrap internally).

You can also go the extra mile and use bubblewrap to initialize the desired mount environment and then enter a sandbox from it using virtualization (/dev/kvm). Some VMM's such as muvm[1] even allow for hardware acceleration and performant Wayland pass-through.

[1] <https://github.com/AsahiLinux/muvm>

This project aims to do exactly what I described but defaults to Nix: <https://git.clan.lol/clan/munix>

I believe it's a great deal worse than that. All the metacognitive insight we do have may just be confabulation and we are fooled into believing that we have it because the process for conjuring it is good at finding a plausible answer.

When you read about and observe the split-brain patient experiments the appropriate response is abject horror at the implications.

The Opus model as usual impresses. Gave it a paper link with bullet point instructions and constraints (while baiting it to perform some mind reading of my intentions) and it implemented production ready code + the requested attack simulations: <https://gist.github.com/coppsilgold/00d3cd490cb7f8ffc3fe5c1c...>

The subject is Tardos traitor-tracing codes.

I'm sure the frontier labs figured out very clever ways to leverage user input and actions as data for training and signals for RL. DeepSeek wants in on the game.

    > Almost all human traits are partly genetic and partly due to the environment and/or random. If you could change the world and reduce the amount of randomness, then of course heritability would go up.

It implies that the only environment that matters is either purely random (truly random accidents, circumstances) or non-systematic (results from non-linear interaction of environment and genes).

When stated that way it almost feels like a tautology because this is what genes exist to do in the first place. To control the interactions of their vessel and environment to the maximum degree. And from the perspective of an individual gene, all the other genes are part of the environment too.

    > There is no such thing as “true” heritability, independent of the contingent facts of our world.

I was actually curious about this myself back when everyone was chiming in about how it was physically impossible.

This is first and foremost an engineering problem as you need to design a system that will both tolerate high heat and be able to pump even more heat to the radiators. The high temperature seems to be the primary objective to design for unless launch costs become absurdly low.

Yes, with blind signatures you still have a central authority which voluntarily 'launders' tokens for you. When you present it your certificate and ask it to give you a blind signature it can reject the certificate.

However if someone extracts a key and keeps it private, and instead gives out unblinded tokens there is nothing you can do other than rate limit - realistically, an adversary is going to trial different rates anyway to figure out which don't make them an outlier.

If A adopts a Blind Signature scheme it implies A is cooperating in establishing privacy infrastructure. If A is so malicious that it would advertise a sound privacy system and then it immediately sabotages it that's a different matter...

    Content Decryption Module (CDM) in your browser or Mobile SDK generates the license challenge

The "license challenge" (it might be a mistake I think it's supposed to be a license request) is just a packet (that can be saved and later sent to anywhere) and it contains the encrypted certificate which doubles as your HWID. An adversary needs to control the private key of the license "server" the challenge is for (this is a privacy measure introduced to prevent the CDM from offering the HWID to anyone who wants it). Now if you want the HWID you need to work for it (one time) by stealing a private key, bribing/blackmailing employees or issuing secret edicts ("here is a new license server we need a certificate for"). Working for Hollywood is also an option I suppose.

Pirates sacrifice devices when they publish ripped content due to the certificate being revoked after Hollywood downloads the torrent and by doing things like this:

    For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user.

you present the same unblinded signature to both services

You would never do this as it defeats the entire purpose of using blind signatures to begin with.

The way it would work with blind signatures is that the server will know the device that comes to it to request a blinded signature and will be able to rate limit how often that device asks it.

But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). This token can then be used once either because its blacklisted after use (and it expires before the next day starts for example).

The desired property of blind signatures is that given a token it's information theoretically impossible to determine which blinded signature it came from (because it could have come from any of them) even if the cryptographic primitive is broken by a mathematical breakthrough or a quantum computer. There is technically the danger that if the anonymity set is too small and all the other participants collude you can be singled out.

Correlating times is a threat vector that needs to be managed either by delaying actions (not tolerable by normal users) or by acquiring tokens automatically and storing them in expectation. Or something other I haven't thought of probably. There is also a networking aspect to this, you will need a decentralized relay server network that masks origin of requests.

There is a problem where it's becoming increasingly harder to determine which internet packets that are coming to your service are at the behest of a human in the course of normal activities or an automated program.

If all the internet was is static content, that wouldn't be much of a problem. But we live in world where packets coming to your service result in significant state changes to your database (such as user generated content).

I suspect that we are currently in the valley of do-something-about-it on the graph which is why you see all this angst from the big players. Would Google really care if automated programs were so good that they were approximating real humans to such an extent that absolutely no one can tell? I suspect they would not only be happy with such a state of affairs, they would join in.

I simplified the process in my description. The DRM ID Android has is not what I was referring to.

I was referring to the static private key that is stored in the silicon. At any time an application can initiate a license request process using DRM APIs which will elicit an unchangeable HWID from your device. The only protection is that it will be encrypted for an authorized license server private key so collusion may be required (intel agencies almost certainly sourced 'authorized' private keys for themselves). Google or Apple also has the option to authorize keys for themselves. In 'theory' all such keys should be stored in "trusted execution environments" on license servers and not divulge client identities for whatever that's worth: <https://tee.fail>.

Requiring authorized silicon (and software) isn't even the biggest problem here.

They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device 'ID' is used to acquire an ephemeral 'ID' from an intermediate server) but it's just a show because you don't know what those intermediary severs are doing: You should assume they log everything.

And this just the remote attestation vector, the DRM 'ID' vector is even worse (no meaningful indirection, every license server has access to your burned-in-silicon static identity). And the Google account vector is what it is.

Using blind signatures for remote attestation has actually been proposed, but no one notable is currently using it: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>

There are several possible reasons for this, the obvious one is that they want to be able to violate your privacy at will or are mandated to have the capability. The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting which may not be good enough for them - an adversary could set up a farm where every device generates $/hour from providing remote attestations to 'malicious' actors.

This is not sufficient. Do they give you a blind signature?

Because what you described does not preserve your anonymity if the government and the service collude.