While I fully agree with this, this quote bothers me:
>Shorter packets can cost around $20, while longer packets can cost upwards of $150 when ordered with the cheapest binding option
Does a student need to print out multiple TYCO Packets ? If so, only the very rich could afford this. I think educations should go back to printed books and submitting you work to the Prof. on paper.
But submitting printed pages back to the Prof. for homework will avoid the school saying "Submit only Word Documents". That way a student can use the method they prefer, avoiding buying expensive software. One can then use just a simple free text editor if they want. Or even a typewriter :)
If it makes you feel better, I just bought a used zoom h4 for cheap - it still works, but it uses mini-usb and I long ago toss those cables because I didn't have anything that used them. (I have a full audio workstation with a 18i20 interface in my office, but sometimes I want something portable)
Which is to say those might become useful someday again... Are they worth storing is a different question - since I'm looking for the cables anyway - both of the cables you mentioned can be bought for $5-$10, and the mini-usb I need is as cheap as $3. It will cost more more in shipping than the cable. (though I will likely look for something else I need to get free shipping)
I also have a hard time letting go of expensive cables merely because they were expensive. For this reason, I probably have as many parallel SCSI cables as I do USB cables, despite not having used a parallel SCSI device in years, including several 15+ meter HD68 cables that only work with high-voltage differential SCSI, despite owning exactly one HVD device.
OTOH, it's a large, loud, heavy, and ugly IBM 3590 tape drive that I'd rather not need to have at arms length to use.
If it makes you feel any better I’ve had to buy back cables that I have thrown away because I hadn’t used them for 15 years - and then found a project where I need DB9, SCSI, FireWire 800, Component to VGA converter or some relic.
Another reason they call me the cable guy at home ( though mainly because I probably have at least 800 cables in my studio )
Latest for me was the ill-fated "mini VGA" cable Apple used on like 2 iBooks and the original Xserves... I couldn't find one when I needed it. But now I have like 8 of them, which I got in a box of random old Mac stuff recently!
Was, IBM hired me to teach watson law, what I saw as a mess, more management than developers. I was laid off 5 weeks after starting, the project was cancelled within the year
IBM is too dysfunctional to innovate like Big Tech has been
And yet Big Tech depends on technology owned by IBM, and also has luck the company isn't one that routinely does lawsuits due to patents.
Anything Red-Hat touches, like GNOME, GCC, Linux kernel, postman, anything Java is mostly done by Oracle, Red-Hat and IBM as the main ecosystem corporate drivers, PS3 used Cell,....
It wasn't a parlor trick and could have evolved into a useful product doing a small, basic subset of what LLMs do today. The problem was IBM's leadership didn't have the slightest understanding of the technology, thought they'd invented ChatGPT and pushed it into applications far beyond its potential, e.g. diagnosing cancer.
Deep Blue was also a bit of a parlor trick. It relied on a ton of special-purpose hardware - literally a rack of custom-made chess ICs. It's neat that it worked, but it didn't have any wider applicability.
> But from past threads in a Linux Forum, seems this only applies to people using the Apple IOS App for Patreon. Not sure if using Apple Laptops. But if you use Patreon's WEB Site directly, the fee cannot be collected by Apple.
Moreover, the fee only applies to the subscriptions made using Apple's payment system. That being said, in most jurisdictions their payment system is the only one developers can use in an app. IMHO, this is the real problem.
Yep, the tax comes from using the Patreon's in-app purchase system. Using a browser on an iPhone/iPad or any other device will not be taxed. Seen many creators putting in their bios suggesting people use the browser instead of the in app purchase.
Patreon fought this for a while but Apple has all the leverage unfortunately.
I can’t remember being more enraged than when I learned my YouTube premium was more expensive per month than it needed to be because I had signed up on iPhone, so many people wasting money every month, and YouTube isn’t allowed to mention the option to pay on web
If they weren’t a public company, you’d think they were the mob. I’ll never trust the Apple ecosystem ever again
>used to surreptitiously track when somebody reads an email
Not in my email client, mutt. I use Thunderbird once in a great while. For some reason I thought there was an option to stop that and I enabled it. Will need to check the next time I fire up Thunderbird.
You. The money quote about the current state of Linux security:
> In fact, right now, your data is probably more secure if stored on current ChromeOS, Android, Windows or MacOS devices, than it is on typical Linux distributions.
Say what you want about systemd the project but they're the only ones moving foundational Linux security forward, no one else even has the ambition to try. The hardening tools they've brought to Linux are so far ahead of everything else it's not even funny.
This is basically propaganda for the war on general purpose computing. My user data is less safe on a Windows device, because Microsoft has full access to that device and they are extremely untrustworthy. On my Linux device, I choose the software to install.
Propaganda begins with reframing. What russia is waging is not a war, it's a special military operation. War is peace. Data on Windows is secure. Linux's security is far behind.
What are you talking about? This has nothing to do with general purpose computing and everything to do with allowing you to authenticate the parts of the Linux boot process that must by necessity be left unencrypted in order to actually boot your computer. This is putting SecureBoot and the TPM to work for your benefit.
It's not propaganda in any sense, it's recognizing that Linux is behind the state of the art compared to Windows/macOS when it comes to preventing tampering with your OS install. It's not saying you should use Windows, it's saying we should improve the Linux boot process to be a tight security-wise as the Windows boot process along with a long explanation of how we get there.
Secure boot is initialized by the first person who physically touches the computer and wants to initialize it. Guess who that is? Hint: it's not the final owner.
It's only secure from evil maker attacks if it can be wiped and reinitialised at any time.
You seem to be under the impression that you cannot reset your Secure Boot to setup mode. You can in the UEFI, doing so wipes any enrolled keys. This, of course assumes you trust the UEFI (and hardware) vendors. But if you don't, you have much bigger problems anyway.
Is it possible someone will eventually build a system that doesn't allow this? Yes. Is this influenced in any way by features of Linux software? No.
It is certainly influenced by the features of Linux software. If Linux does not support this then this preserves a platform as an escape route where this is not possible and this substantially reduces the incentive to provide certain content and services (!) only when this is enabled.
Yes you. The parts being expanded upon happen after the shim is authenticated by SecureBoot and are fully in your control. The scary part has already happened, Linux distros support SecureBoot right now and have for a while. Right now the current state of the Linux boot process is all the downsides (in your view) of SecureBoot with none of the upsides because very little is authenticated after that.
> we should improve the Linux boot process to be a tight security-wise as the Windows
I hope this never happens. I really want my data secure and I do have something to hide. So, no Microsoft keys on my computer and only I will decide what kind of software I get to run.
So to I guess spite Microsoft or something you're going to make your data less secure?
Turning off SecureBoot only means any rando can decide what software runs on your device and install a bootkit. Not authenticating the rest of the boot process as outlined here (what Microsoft calls Trusted Boot) only means that randos can tamper with your OS using the bits that can't be encrypted.
> Turning off SecureBoot only means any rando can decide what software runs on your device
I see it as exactly the opposite: turning SecureBoot on means someone else can and will decide what software runs on my device.
> spite Microsoft or something you're going to make your data less secure
We all know very well Microsoft's track record with security and with data protection measures and practice. Trusting Microsoft is... irrational, let's put it that way.
Considering that (for example) your data on ChromeOS is automatically copied to a server run by Google, who are legally compelled to provide a copy to the government when subject to a FISA order, it is unclear what Poettering's threat model is here. Handwringing about secure boot is ludicrous when somebody already has a remote backdoor, which all of the cited operating systems do. Frankly, the assertion of such a naked counterfactual says a lot more about Poettering than it does about Linux security.
Just an assumption here, but the project appears to be about the methodology to verify the install. Who holds the keys is an entirely different matter.
I'm sure this company is more focused on the enterprise angle, but I wonder if the buildout of support for remote attestation could eventually resolve the Linux gaming vs. anti-cheat stalemate. At least for those willing to use a "blessed" kernel provided by Valve or whoever.
I might be behind on the latest counter-counter-counter-measures, but I know some of the leading AC solutions are already using IOMMU to wedge a firewall between passive DMA sniffers and the game processes memory.
> resolve the Linux gaming vs. anti-cheat stalemate
It will.
Then just a bit later no movies for you unless you are running a blessed distro. Then Chrome will start reporting to websites that you are this weird guy with a dangerous unlocked distro, so no banking for you. Maybe no government services as well because obviously you are a hacker. Why would you run an unlocked linux if you were not?
rust-vmm-based environment that verifies/authenticates an image before running ? Immutable VM (no FS, root dropper after setting up network, no or curated device), 'micro'-vm based on systemd ? vmm captures running kernel code/memory mapping before handing off to userland, checks periodically it hasn't changed ? Anything else on the state of the art of immutable/integrity-checking of VMs?
And once you remove the friction for requiring cryptographic verification of each component, all it takes is one well-resourced lobby to pass a law either banning user-controlled signing keys outright or relegating them to second-class status. All governments share broadly similar tendencies; the EU and UK govts have always coveted central control over user devices.
I don't like few pieces and Mr. Lennarts attitude to some bugs/obvious flaws, but by far much better than old sysv or really any alternative we have.
Doing complex flows like "run app to load keys from remote server to unlock encrypted partition" is far easier under systemd and it have dependency system robust enough to trigger that mount automatically if app needing it starts
There are genuine positive applications for remote attestation. E.g., if you maintain a set of servers, you can verify that it runs the software it should be running (the software is not compromised). Or if you are running something similar to Apple's Private Compute Cloud to run models, users can verify that it is running the privacy-preserving image that it is claiming to be running.
There are also bad forms of remote attestation (like Google's variant that helps them let banks block you if you are running an alt-os). Those suck and should be rejected.
> There are genuine positive applications for remote attestation
No doubt. Fully agree with you on that. However Intel ME will make sure no system is truly secure and server vendors do add their mandatory own backdoors on top of that (iLO for HP, etc).
Having said that, we must face the reality: this is not being built for you to secure your servers.
> Trusted boot is literally a form of DRM. A different one than remote attestation.
No, it's not. (And for that matter, neither is remote attestation)
You're conflating the technology with the use.
I believe that you have only thought about these technologies as they pertain to DRM, now I'm here to tell you there are other valid use cases.
Or maybe your definition of "DRM" is so broad that it includes me setting up my own trusted boot chain on my own hardware? I don't really think that's a productive definition.
there are no other things. The entire point of remote attestation is to manage(i.e. take away) rights of user that runs it, unless you own entire chain, which you do not on any customer device
> Interesting. So what did the attestation say once I (random Internet user) updated the firmware to something I wrote or compiled from another source?
So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
> So your device had no user freedom. You're not doing much to refute the notion that these technologies are only useful to severely restrict user freedom for money.
Would love to hear more of your thoughts on how the users of the device I worked on had their freedom restricted!
I guess my company, the user of the device that I worked on, was being harmed by my company, the creator of the device that I worked on. It's too bad that my company chose to restrict the user's freedom in this way.
Who cares if the application of the device was an industrial control scenario where errors are practically guaranteed to result in the loss of human life, and as a result are incredibly high value targets ala Stuxnet.
No, the users rights to run any code trumps everything! Commercial device or not, ever sold outside of the company or not, terrorist firmware update or not - this right shall not be infringed.
I now recognize I have committed a great sin, and hope you will forgive me.
Hacker News has recently been dominated by conspiracy theorists who believe that all applications of cryptography are evil attempts by shadowy corporate overlords to dominate their use of computing.
Buddy, if I want encryption of my own I've got secure boot, LUKS, GPG, etc. With all of those, why would I need or even want remote attestation? The purpose of that is to assure corporations that their code is running on my computer without me being able to modify it. It's for DRM.
I am fairly confident that this company is going to assure corporations that their own code is running on their own computers (ie - to secure datacenter workloads), to allow _you_ (or auditors) to assure that only _your_ asserted code is also running on their rented computers (to secure cloud workloads), or to assure that the code running on _their_ computers is what they say it is, which is actually pretty cool since it lets you use Somebody Else's Computer with some assurance that they aren't spying on you (see: Apple Private Cloud Compute). Maybe they will also try to use this to assert "deep" embedded devices which already lock the user out, although even this seems less likely given that these devices frequently already have such systems in place.
IMO it's pretty clear that this is a server play because the only place where Linux has enough of a foothold to make client / end-user attestation financially interesting is Android, where it already exists. And to me the server play actually gives me more capabilities than I had: it lets me run my code on cloud provided machines and/or use cloud services with some level of assurance that the provider hasn't backdoored me and my systems haven't been compromised.
How can you be "pretty sure" they're going to develop precisely the technology needed to implement DRM but also will never use or allow it to be used by anybody but the lawful owners of the hardware? You can't.
It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
The technology needed to implement DRM has been there for 20+ years and has already evolved in the space where it makes sense from an "evil" standpoint (if you're on that particular side of the fence - Android client attestation), so someone implementing the flip side that might actually be useful doesn't particularly bother me. I remember the 1990s "cryptography is the weapon of evil" arguments too - it's funny how the tables have turned, but I still believe that in general these useful technologies can help people overall.
The technology already exists and also there is unmet industrial market demand for the technology. Incoherent. If it already exists as you say, then Lennart should fuck off and find something else to make.
> It's like designing new kinds of nerve gas, "quite sure" that it will only ever be in the hands of good guys who aren't going to hurt people with it. That's powerful naïveté. Once you make it, you can't control who has it and what they use it for. There's no take-backsies, that's why it should never be created in the first place.
Interesting choice of analogy, to compare something with the singular purpose to destroy biological entities, to a computing technology that enforces what code is run.
Can you not see there might be positive, non-destructive applications of the latter? Are you the type of person that argues cars shouldn't exist due to their negative impacts while ignoring all the positives?
>Shorter packets can cost around $20, while longer packets can cost upwards of $150 when ordered with the cheapest binding option
Does a student need to print out multiple TYCO Packets ? If so, only the very rich could afford this. I think educations should go back to printed books and submitting you work to the Prof. on paper.
But submitting printed pages back to the Prof. for homework will avoid the school saying "Submit only Word Documents". That way a student can use the method they prefer, avoiding buying expensive software. One can then use just a simple free text editor if they want. Or even a typewriter :)
reply