I don't follow the war anymore but I used to follow twitter OSINT accounts supporting both sides; I find it hard to imagine pro-Russian accounts posting on bsky or fedi?
Dunno about fediverse, but there's definitely a bunch on bsky. Or there were, at least; I've blocked a bunch, and my feeds don't show me more, so maybe they're gone.
I see. The following two statements (headlines) stand out:
* We should not sell powerful chips or chipmaking equipment to China
* We should crack down on industrial-scale distillation operations
That's not quite a ban of local ML inference, but it basically says that he doesn't want companies in China to create their own state of the art models.
While it is definitely over a decade at this point (over two in fact), some of this likely comes from the term [citation needed], that originated on Wikipedia, as a cynical backhanded response to unsourced claims. It has become a catch-all. Language and how it evolves is a pretty interesting subject.
> There should be absolutely no expectation of privacy when using public streets.
Strong disagree. Life in public areas is often still part of private life. And we should treat it with the respect and privacy that it deserves. You going to the doctor? That's part of your private life. You meeting with an old friend to catch up? Also private, even though you do it in a public cafe.
It seems like (to my very uneducated mind) the founders were worried about the tyranny of government. We have the bill of rights and a constitution designed to limit government powers.
But then there are people who weaponize rights against the people in favor of the government.
A private company creating a mass-surveillance network of tracking everyone in public is absolutely a weaponization of rights. Rights designed to keep our government accountable. Our rights that give us tools to prevent government from weaponizing privacy against us (secret juries, secret trials, secret government employees, records etc citing 'privacy' as a reason for secrecy).
In the USA? Any café you go to is reasonably likely to have cameras, both inside and outside. If you mean driving to a doctor's office, you probably pass by hundreds of cameras along the way: video doorbells, dash cams, Teslas, Waymos, gas stations, ATMs, traffic-flow cameras, etc. If you are in one of the many cities with tens of thousands of existing non-Flock cameras, you are likely passing many more.
Independent cameras, often not networked let alone internet connected are not the same thing as a single entity controlling a huge, internet capable, always on, cloud recording panopticon.
Logistically the first limits things like police access by units of both access and time (is it recording? Does the memory card overwrite? Did it expire before a warrant was issued?)
Putting that all in a convenient console and handing direct god eye view to police with a "oh you need a warrant first, wink wink", massively reduces friction for abuse of power.
When the police ask for video evidence, they simply ask. They do not need a warrant. They might need a subpoena to force someone to hand it over, but I’m guessing that’s incredibly rare because people and businesses with cameras generally want to help. The issue is the incredible waste of time and money. It is incredibly inefficient to send a team out to collect footage instead of simply checking Flock, Axon, etc. No doubt, that hurdle prevents abuse, but it also hinders legitimate investigations. I would prefer strong safeguards against abuse while still allowing for real investigative wins.
> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles.
It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.
Sandboxing the process only works well when the malware requires more capabilities than the software itself.
So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.
Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.
(as I and others have mentioned in the thread): The attacker can just move the malicious code from build.rs to lib.rs (ie. build-time -> test/execution-time).
Then the problem is the language, as the grandparent observes.
I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?
> Is it common for closed source software to give the source code to customers to build?
Yes, somewhat common. I work in embedded, and where a supplier gives us the ability to build their code it is a lot easier for us to deal with the next time we need a new build from them.
Closed source software could apply too, if the execution model supports it (e.g. WebAssembly). Just because the format is binary and "unreadable", its permissions (accessible functions) don't have to be
I know that firmware (and software in general) has bugs. But I wonder why modern firmware for UEFI has to be so complex, that it needs updates on a regular basis. It would be nice to have a dead-simple hardware-initialisation system that doesn't need regular updates and that only has very limited attack surface.
The bootloader part of UEFI FW is quite straightforward. It requires updates due to vulnerabilities found in it and also to update certificates.
However modern FW of PC clones don't only contain a bootloader and a "simple" hardware initializer. Modern laptops have tens of sensors, power measuring parts, power controllers, completely remote management (Intel ME / AMD PSP), embedded controller code for fingerprint, embedded controller code for keyboard etc.
Companies ship a new product line every single year. This churn causes nothing but shitty FW to be developed. Moreover the component manufacturers also slightly change things every single year. That's why sleep sucks with PCs. That's why Fn shortcuts don't always work correctly. That's why batteries drain.
Everything is fixed in the 6 months to a year following the launch in PC industry. Then they start to work on the new model and only supply security updates.
That is the dream isn't it? But there's no such thing since even a simple one that requires no updates would have some sort of vulnerability that needs an update, and the cycle continues.
I agree. But we could still try to have a smaller hardware initialisation system. And if there is the occasional need to patch a security vulnerability, then that patch is probably a lot more straightforward.
Not a hardware engineer so feel free to fact-check all of this.
My understanding is Coreboot is a minimum-viable firmware implementation to get your hardware initialized ... and not much else.
Once Coreboot is ready you then use "Payloads".
Payloads can be as varied as booting into Linux directly, GRUB directly, or a whole UEFI/BIOS implementation.
SeaBIOS is a whole FOSS BIOS implementation (commonly used for emulators like QEMU) and is somewhat tractable according to my prior research (~50k lines of C).
My comment about CPU support is due to modern systems using UEFI - the payload for that is TianoCore EDK2. It's quite large (900k+ lines) and while it has much more eyes on it, if minimalism is what you're looking for I doubt it would qualify.
That leaves you with systems from before ~2013 or so - assuming you can even flash Coreboot to them, which only supports a handful of systems.
I suppose you could just jump into Linux though. Perhaps it's silly to do anything else.
If the update is only for supporting new hardware, then there is usually no benefit to the user. They already have a machine that is supported by a previous firmware version. Only in those cases where a user upgrades the hardware there might be a benefit.
Why can't the BIOS/UEFI offer some basic initialisation functionality and then the OS (Linux, Windows, ...) does a more advanced initialisation? Why does it have to be so complicated?
> After carefully removing the tick with either tweezers or a tick-removal tool, you place it into the kit’s “Tick Crusher.” The grinder pulverizes the tick’s chitinous exterior, exposing the internal contents where the Borrelia burgdorferi is located
Depends on what your goals are. If you want to be well-informed for the nerdy water-cooler talk in the office kitchen, then you need to read a lot. Otherwise, just don't worry about it, because important topics get re-posted. If you missed something the first time, then you still have good chances to catch it the second or third time.
reply