Remix.run Logo
josephcsible 3 hours ago

This seems like the kind of technology that could make the problem described in https://www.gnu.org/philosophy/can-you-trust.en.html a lot worse. Do you have any plans for making sure it doesn't get used for that?

cyphar 3 hours ago | parent | next [-]

I'm Aleksa, one of the founding engineers. We will share more about this in the coming months but this is not the direction nor intention of what we are working on. The models we have in mind for attestation are very much based on users having full control of their keys. This is not just a matter of user freedom, in practice being able to do this is far more preferable for enterprises with strict security controls.

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.

iamnothere an hour ago | parent | next [-]

Thanks, this would be helpful. I will follow on by recommending that you always make it a point to note how user freedom will be preserved, without using obfuscating corpo-speak or assuming that users don’t know what they want, when planning or releasing products. If you can maintain this approach then you should be able to maintain a good working relationship with the community. If you fight the community you will burn a lot of goodwill and will have to spend resources on PR. And there is only so much that PR can do!

Better security is good in theory, as long as the user maintains control and the security is on the user end. The last thing we need is required ID linked attestation for accessing websites or something similar.

dTal 2 hours ago | parent | prev | next [-]

Thanks for the reassurance, the first ray of sunshine in this otherwise rather alarming thread. Your words ring true.

It would be a lot more reassuring if we knew what the business model actually was, or indeed anything else at all about this. I remain somewhat confused as to the purpose of this announcement when no actual information seems to be forthcoming. The negative reactions seen here were quite predictable, given the sensitive topic and the little information we do have.

an hour ago | parent | prev | next [-]
[deleted]
michaelmrose 25 minutes ago | parent | prev [-]

This is extremely bad logic. The technology of enforcing trusted software is without inherent value good or ill depending entirely on expected usage. Anything that is substantially open will be used according to the values of its users not according to your values so we ought instead to consider their values not yours.

Suppose you wanted to identify potential agitators by scanning all communication for indications in a fascist state one could require this technology in all trusted environments and require such an environment to bank, connect to an ISP, or use Netflix.

One could even imagine a completely benign usage which only identified actual wrong doing alongside another which profiled based almost entirely on anti regime sentiment or reasonable discontent.

The good users would argue that the only problem with the technology is its misuse but without the underlying technology such misuse is impossible.

One can imagine two entirely different parallel universes one in which a few great powers went the wrong way in part enabled by trusted computing and the pervasive surveillance enabled by the capability of AI to do the massive and boring task of analyzing a massive glut of ordinary behaviour and communication + tech and law to ensure said surveillance is carried out.

Even those not misusing the tech may find themselves worse off in such a world.

Why again should we trust this technology just because you are a good person?

enriquto 3 hours ago | parent | prev [-]

half of the founders of this thing come from Microsoft. I suppose this makes the answer to your question obvious.

blibble an hour ago | parent | next [-]

that's a silver lining

the anti-user attestation will at least be full of security holes, and likely won't work at all

sam_lowry_ an hour ago | parent [-]

Dunno about the others but Pottering has proven himself to deliver software against the grain.

dijit an hour ago | parent | next [-]

You think?

It took us nearly a decade and a half to unfuck the pulseaudio situation and finally arrive at a simple solution (pipewire).

SystemD has a lot more people refining it down but a clean (under the hood) implementation probably won't be witnessed in my lifetime.

blibble 44 minutes ago | parent [-]

yeah, the fix for pulseaudio was to throw it away entirely

for systemd, I don't think I have a single linux system that boots/reboots reliably 100% of the time these days

dijit 40 minutes ago | parent [-]

The trick is the same: use a popular linux distribution and don't fight the kinks.

The people who had no issues with Pulseaudio; used a mainstream distribution. Those distributions did the heavy lifting of making sure stuff fit together in a cohesive way.

SystemD is very opinionated, so you'd assume it wouldn't have the same results, but it does.. if you use a popular distro then they've done a lot of the hard work that makes systemd function smooth.

I was today years old when I realised this is true for both bits of poetter-ware. Weird.

blibble 27 minutes ago | parent [-]

I only use debian

pulseaudio I had to fight every single day, with my "exotic" setup of one set of speakers and a headset

with pipewire, I've never had to even touch it

systemd: yesterday I had a network service on one machine not start up because the IP it was trying to bind to wasn't available yet

the dependencies for the .service file didn't/can't express the networking semantics correctly

this isn't some hacked up .service file I made, it's that from an extremely popular package from a very popular distro

(yeah I know, use a socket activated service......... more tight coupling to the garbage software)

the day before that I had a service fail to start because the wall clock was shifted by systemd-timesyncd during startup, and then the startup timeout fired because the clock advanced more than the timeout

then the week before that I had a load of stuff start before the time was synced, because chrony has some weird interactions with time-sync.target

it's literally a new random problem every other boot because of this non-deterministic startup, which was never a problem with traditional init or /etc/rc

for what? to save maybe a second of boot time

if the distro maintainers don't understand the systemd dependency model after a decade then it's unfit for purpose

jacquesm 6 minutes ago | parent [-]

I can totally relate to this, it's gotten to the point that I'm just as scared of rebooting my Linux boxes as I was of rebooting my windows machine a couple of decades ago. And quite probably more scared.

an hour ago | parent | prev [-]
[deleted]
stackghost 3 hours ago | parent | prev [-]

My thoughts exactly. We're probably witnessing the beginning of the end of linux users being able to run their own kernels. Soon:

- your bank won't let you log in from an "insecure" device.

- you won't be able to play videos on an "insecure" device.

- you won't be able to play video games on an "insecure" device.

And so on, and so forth.

dijit an hour ago | parent | next [-]

Unfortunately the parent commenter is completely right.

The attestation portion of those systems is happening on locked down devices, and if you gain ownership of the devices they no longer attest themselves.

This is the curse of the duopoly of iOS and Android.

BankID in Sweden will only run with one of these devices, they used to offer a card system but getting one seems to be impossible these days. So you're really stuck with a mobile device as your primary means of identification for banking and such.

There's a reason that general purpose computers are locked to 720p on Netflix and Disney+; yet AppleTV's are not.

seba_dos1 an hour ago | parent | prev [-]

This is already the world we live in when it comes to the most popular personal computing devices running Linux out there.