[1]: https://consensus-health.torproject.org/

I also disagree more broadly with the initial moral indignation over a perceived violation of copyright law -- legality and morality are two different things, copyright law is meant to be a balanced trade-off between the public and creators but modern copyright laws are a travesty. What ever happened to the hacker ethos behind DeCSS and the anti-"illegal numbers" movement?

[1]: https://www.austlii.edu.au/cgi-bin/viewdoc/au/legis/cth/cons...

[1]: https://www.austlii.edu.au/cgi-bin/viewdoc/au/legis/cth/cons... [2]: https://www.alrc.gov.au/publication/copyright-and-the-digita... [3]: https://www.copyright.gov/title17/92chap1.html#117

Well of course it wasn't a current example -- to quote their original comment:

> Quite frustrating how archeology swings over the years from "we'll believe anything" to "we won't accept any claim without a preserved example". While some of the excesses of the past were clearly excessive ... [emphasis added]

In other words, they feel that historical examples of fanciful theories being mainstream has resulted in an over correction to modern archeology requiring unreasonably strict proof standards.

(There is a certain irony in a user called "AlotOfReading" not reading a fairly short comment carefully...)

I disagree -- the third party doctrine that allows for governments to avoid serving/addressing warrants to the people whose data is actually being subpoenaed directly leads to things like the FISA warrant-rubber-stamp courts in the US. If the data stored on third-party servers on behalf of someone is not considered "papers and effects" of that person then it is entirely justified to subpoena every email stored on mail.google.com because it's just morally equivalent to a subpoena for "all of Foomatic's business records between 2020-2025".

It seems bonkers to me that things that are essentially implementation details (such as the way that MTAs work and the lack of crypto-obfuscation in email) should allow for a legal interpretation of the 4th amendment that effectively neuters it. Letters sent via snail-mail are handled by several third parties in a very analogous way to emails but (mostly due to historical reasons, such as the fact that letters existed during the drafting of the bill of rights) we do not apply the third-party doctrine to letters.

Of course, the US government has spent decades chipping away at the privacy of snail mail, so eventually we may end up in a world where snail mail and email are treated the same way (just not in a good way).

[1]: https://docs.rs/hayro/latest/hayro/

That was my eventual plan for having a single GUI for everything, the only problem is that there isn't a really obvious way to support scanning a PDF you upload -- basically you need a pure-Rust PDF renderer and there isn't one up to the task as far as I could tell. On mobile you could scan each QR code separately (though doing this from a webapp is probably going to be a fairly awful UX and most people would prefer to photograph the whole document and get everything scanned automatically).

If you are a point hacker you could spend the points on upgrades (which tend to give you better rates than buying base tickets) but then you're paying for a minor comfort improvement that you wouldn't pay for normally -- which is a textbook example of induced consumption and is playing into exactly how airlines want you to use points.

[1]: https://github.com/cyphar/paperback

The really surprising thing is that I stopped commenting regularly a few years ago so god knows where I would've ranked back in 2020. Then again, I always had a feeling I was too verbose when writing comments, so I guess this is all the proof I needed!

Shameless plug: I wrote a project a few years ago to create PDF-based backups with sharded keys which would do exactly what I suspect you want[2], unfortunately I got stuck at the "make a nice UI for it" stage (everything works but it's just a CLI tool at the moment). I guess I should take a look at using an LLM for that these days... (I used this to store my password manager root password and necessary keys to pull and decrypt the encrypted backups of my server.)

[1]: https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing [2]: https://github.com/cyphar/paperback/

I'm guessing you're referencing my comment, that isn't what I said.

> But the team is not even willing to make promises as big as yours.

Be honest, look at the comment threads for this announcement. Do you honestly think a promise alone would be sufficient to satisfy all of the clamouring voices?

No, people would (rightfully!) ask for more and more proof -- the best proof is going to be to continue building what we are building and then you can judge it on its merits. There are lots of justifiable concerns people have in this area but most either don't really apply what we are building or are much larger social problems that we really are not in a position to affect.

I would also prefer to be to judged based my actions not on wild speculation about what I might theoretically do in the future.

A lot of the concerns in this thread center on TPMs, but TPMs are really more akin to very limited HSMs that are actually under the user's control (I gave a longer explanation in a sibling comment but TPMs fundamentally trust the data given to them when doing PCR extensions -- the way that consumer hardware is fundamentally built and the way TPMs are deployed is not useful for physical "attacks" by the device owner).

Yes, you can imagine DRM schemes that make use of them but you can also imagine equally bad DRM schemes that do not use them. DRM schemes have been deployed for decades (including "lovely" examples like the Sony rootkit from the 2000s[1], and all of the stuff going on even today with South Korean banks[2]). I think using TPMs (and other security measures) for something useful to users is a good thing -- the same goes for cryptography (which is also used for DRM but I posit most people wouldn't argue that we should eschew all cryptography because of the existence of DRM).

[1]: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... [2]: https://palant.info/2023/01/02/south-koreas-online-security-...

As an aside, it is a bit amusing to me that an initial announcement about a new company working on Linux systems caused the vast majority of people to discuss the impact on personal computers (and games!) rather than servers. I guess we finally have arrived at the fabled "Year of the Linux Desktop" in 2026, though this isn't quite how I expected to find out.

> Attestation of what to whom for which purpose? Which freedom does it allow users to control their keys, how does it square with remote attestation and the wishes of enterprise users?

We do have answers for these questions, and a lot of the necessary components exist already (lots of FOSS people have been working on problems in this space for a while). The problem is that there is still the missing ~20% (not an actual estimate) we are building now, and the whole story doesn't make sense without it. I don't like it when people announce vapourware, so I'm really just trying to not contribute to that problem by describing a system that is not yet fully built, though I do understand that it comes off as being evasive. It will be much easier to discuss all of this once we start releasing things, and I think that very theoretical technical discussions can often be quite unproductive.

In general, I will say that there a lot of unfortunate misunderstandings about TPMs that lead people to assume their only use is as a mechanism for restricting users. This is really not the case, TPMs by themselves are actually more akin to very limited HSMs with a handful of features that can (cooperatively with firmware and operating systems) be used to attest to some aspects of the system state. They are also fundamentally under the users' control, completely unlike the PKI scheme used by Secure Boot and similar systems. In fact, TPMs are really not a useful mechanism for protecting against someone with physical access to the machine -- they have to trust that the hashes they are given to extend into PCRs are legitimate and on most systems the data is even provided over an insecure data line. This is why the security of locked down systems like Xbox One[1] don't really depend on them directly and don't use them at all in the way that they are used on consumer hardware. They are only really useful at protecting against third-party software-based attacks, which is something users actually want!

All of the comments about DRM obviously come from very legitimate concerns about user freedoms, but my views on this are a little too long to fit in a HN comment -- in short, I think that technological measures cannot fix a social problem and the history of DRM schemes shows that the absence of technological measures cannot prevent a social problem from forming either. It's also not as if TPMs haven't been around for decades at this point.

[1]: https://www.youtube.com/watch?v=U7VwtOrwceo

This is basically true today with Secure Boot on modern hardware (at least in the default configuration -- Microsoft's soft-power policies for device manufacturers actually requires that you can change this on modern machines). This is bad, but it is bad because platform vendors decide which default keys are trusted for secure boot by default and there is no clean automated mechanism to enroll your own keys programmatically (at least, without depending on the Microsoft key -- shim does let you do this programmatically with the MOK).

The set of default keys ended up being only Microsoft (some argue this is because of direct pressure from Microsoft, but this would've happened for almost all hardware regardless and is a far more complicated story), but in order to permit people to run other operating systems on modern machines Microsoft signed up to being a CA for every EFI binary in the universe. Red Hat then controls which distro keys are trusted by the shim binary Microsoft signs[1].

This system ended up centralised because the platform vendor (not the device owner) fundamentally controls the default trusted key set and is what caused the whole nightmare of the Microsoft Secure Boot keys and rh-boot signing of shim. Getting into the business of being a CA for every binary in the world is a very bad idea, even if you are purely selfish and don't care about user freedoms (and it even makes Secure Boot less useful of a protection mechanism because it means that machines where users only want to trust Microsoft also necessarily trust Linux and every other EFI binary they sign -- there is no user-controlled segmentation of trust, which is the classic CA/PKI problem). I don't personally know how the Secure Boot / UEFI people at Microsoft feel about this, but I wouldn't be surprised if they also dislike the situation we are all in today.

Basically none of these issues actually apply to TPMs, which are more akin to limited HSMs where the keys and policies are all fundamentally user-controlled in a programmatic way. It also doesn't apply to what we are building either, but we need to finish building it before I can prove that to you.

[1]: https://github.com/rhboot/shim-review

I've been a FOSS guy my entire adult life, I wouldn't put my name to something that would enable the kinds of issues you describe.

That being said, I guess the act had precautions to stop it from reducing the copyright protection for edge cases like these?

[1]: https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act

Maybe I've just been lucky so far, but as an Aussie it is hard to overstate the fact it is even possible to travel almost anywhere within the country and between several other countries by train for fairly cheap is already quite miraculous to me. Yeah, I've run into a fair few issues and it was annoying but that goes for every country I've been to (Japan had the least by far but trains still get delayed there more often than people think and I've also run into situations as in TFA where if I didn't speak Japanese things would've ended up worse).

I'm not sure I'd even put DB in my "bottom three" in terms of overall experience. Should it be much better? Of course. But if you listen to Germans it sounds like DB is the worst train network in the universe by a clear margin, and that's just obviously not true.

Also, your own blog lists an leak from 2024 about a Facebook partner bragging about this ability[1]. You don't find the claim credible (and you might be right about that, I haven't looked into it), but I find it strange that you are asking for an example that your own website provides?

[1]: https://futurism.com/the-byte/facebook-partner-phones-listen...