rolandr

The real source of concern perhaps is the 90% chance AI is used to kill 90% of humans. Just crash the global economy and supply chains and see how quickly major metro areas run out of food and gas.

And as someone else pointed out, it will almost certainly be at the intentional direction of a human or humans, not the paper clip maximizer.

1k tok/s = 1000 tok/s...

"Using newly-assembled data from 1980 through 2024, we show that 25% of scientifically-active, US-trained STEM PhD graduates leave the US within 15 years of graduating."

I believe there will be a significant "discontinuity" in the data beginning in 2025. Likely along the lines of (1) US-born science majors going abroad for their PhD's (and likely staying there afterwards), and (2) a major decline in foreign students coming to the US. Blocking disbursement of ongoing grants, immediate and dramatic slashing funding for the sciences, holding up universities under pain of blocking federal funding, eliminating fellowships, firing government scientists, stuffing agencies and commissions with politically appointed yes men, having oaths of fealty in all but name, deporting and blocking return of foreign students, and many more actions of similar character tend to fo that.

One of the greatest national scientific establishments was irreparably damaged in a matter of months. No discussion, no process -- just pulling the rug out. The US will coast for a few years on the technologies that just popped out of the university pipeline of development, but that pipeline is now essentially broken.

I’m not seeing how you are getting there from that quote. Seems like one of the least controversial sentences in the article. Maybe it would be better to say “should” instead of “need?” In any event the overall point is pretty sound.

Even with dogs, if they are not well socialized when younger, they end up having problems interacting well/appropriately with new dogs and people.

I don’t know if that source ultimately took into account the CO2 costs in extraction and transportation.

However, plastic sure isn’t free in that regard! 8-10% of petroleum (which is pulled out of the ground, with increasing effort each year) is used to produce plastics. I’d put good odds on extraction and transportation CO2 costs for petroleum exceeding those for LNG - no good guess on coal. That also doesn’t account for your energy costs in moving the post-consumer plastic around.

Plus, natural gas has significantly lower emissions than plastic to begin with.

Obviously, which others touched on, it’s better to displace burning fossil fuels and plastics (arguably fossil fuel too) with renewables —- an effort that continues to accelerate.

At first, I thought this was a good overlooked point, but after digging into it, there isn’t a net reduction.

According to [1], the gCO2e/kWh for the relevant energy sources are: Coal 850g Natural gas 385g Plastic incineration 512g

According to [2], in the US in 2023, 43.1% of electricity was from natural gas and 16.2% from coal. Based on that, the average fossil fuel kWh resulted in 512 gCO2e.

So, if you substitute the average fossil fuel with burning plastic, there is NO net improvement in CO2 emissions per kWh. Against just natural gas, burning plastic actually produces 33% more gCO2e.

I think the above approach is the correct way to evaluate this. Basically, to get your kWh from nonrenewable sources, you are still burning something and have to choose one thing or another to be burned. Choosing plastic allows you to defer burning your fossil fuel (or, in other words, gives you more total fuel to burn), but it doesn’t help climate change efforts.

[1] https://www.clientearth.org/media/1h2nalrh/greenhouse-gas-an... (page 29) [2] https://www.eia.gov/energyexplained/electricity/electricity-...

Find someone interested in continuing that business under a long term (royalty or such) or short term (lump sum) financial arrangement that is acceptable to you? I think there will be interested people, maybe even within this community (not suggesting I’m one of them, though).

Do you think it’s more difficult for people to identify with and connect to media lacking people of their own race? Interesting idea.

Back when I had a really nasty run-in with poison oak, my friend’s father who was a doctor suggested the hot water trick. AMAZING. His explanation was that it depleted histamines that caused the itching. Appears to bear out:

“ a poison ivy rash (like any other allergic reaction) is caused by the body releasing the chemical histamine to the affected area as part of your immune response. Heat will stimulate the production of histamine, and although this creates an unpleasant itching in the moment, the heat will eventually deplete the affected cells of their histamine, which can provide up to 8 hours of itch relief afterwards. This can be achieved by aiming warm water at the affected area, and slowly increasing the heat to the maximum tolerable temperature until itching stops.”

https://teclabsinc.com/why-you-shouldnt-use-hot-water-on-a-p... (article title referring to not using hot water when washing off oils after initial exposure)

Hence why I also included “the training methods and data.” All three come together to produce something impressive but with inherent limitations. The human tendency to anthropomorphize leads human intuition about its capabilities astray. It’s an extremely capable bullshit artist.

Training agents on every written word ever produced, or selected portions of it, will never impart the lessons that humans learn through “The School of Hard Knocks.” They are nihilist children who were taught to read, given endless stacks of encyclopedias and internet chat forum access, but no (or no consistent) parenting.

No. The author is demonstrating a concept - that there are many easy inroads to twisting ChatGPT around your finger. It was very tongue in cheek - a joke - the author has no true expectation of getting the car for $1.

It is reasonable to say that the author demonstrated that bit of trust was misplaced to begin with.

The training methods and data used to produce ChatGPT and friends, and an architecture geared to “predict the next word,” inherently produces a people pleaser. On top of that, it is hopelessly naive, or put more directly, a chump. It will fall for tricks that a toddler would see through.

There are endless variations of things like “and yesterday you suffered a head injury rendering you an idiot.” ChatGPT has been trained on all kinds of vocabulary and ridiculous scenarios and has no true sense or right or wrong or when it’s walking off a cliff. Built into ChatGPT is everything needed for a creative hostile attacker to win 10/10 times.

I didn’t really believe it would work until I tried it, but having a fan blowing on you at high speed works to cool your whole body, including inside the headset. I no longer experience fogging of lenses or sweat dripping down into my eyes, which previously would become a problem after 15 minutes of intense activity. An added bonus is that the breeze can give you a sense of which direction you’re facing.

I generally agree, but on the other hand, from a consumer perspective IoT devices have and continue to be particularly inconvenient. After 15 or so years of IoT devices, what do we have that resembles interoperability or open protocols? Maybe Zigbee? Instead, it seems that each IoT device is a one-off effort by a very small team, and that networking is the part where you cross your fingers, close your eyes, and hold your nose throughout the processes of connecting and diagnosing connectivity issues.

The initial batch of Skylake CPUs do not implement SGX: http://www.anandtech.com/show/9687/software-guard-extensions...

Any word on whether there will be a BIOS update (for example, microcode and ME updates) that will enable SGX for the first batch of Skylakes, or are they just forevermore broken?

Can anyone identify a patch to apply to existing kernels to fix this? Are there any released 3.8+ versions that are not vulnerable? The "mitigations" section at the end is not forthcoming about this. Vulnerable systems remain vulnerable without such information.

This does not seem to be a responsible disclosure of the vulnerability (keep in mind it was posted on their blog 5 days ago).

Given that it looks like commits were just made 12 days ago (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) or possibly as recently as 38 hours ago (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), perhaps only 4.4 has the fix?

> vrtx0 1 hour ago | parent

I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals.

In general, most of the firmware needed for system components is streamed from the main SPI chip to the various components as they are configured by the main system BIOS. Thus, there mainly is a single chip we are concerned about. However, the author identified a second embedded controller )EC_ flash that is also usually present, so we end up being concerned about 2 flash modules. The author addresses other firmwares - the main one being discrete GPUs - and suggests having a system that does not include them.

> Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place?

If your only interface between the computer and the FPGA is a three wire interface that emulates an SPI chip, that does not provide any vector for reconfiguring the FPGA. The bitstream for configuring the FPGA is provided via a completely separate set of hardware pins.

I do not believe there is are any Intel chips that give you VT-d (IOMMU) and do not require a firmware blob. Blame Intel for that situation.

I think AMD has open sourced most of their BIOS, and a lot more of their hardware supports IOMMU anyway. Maybe that is a more fruitful direction to consider.

It seems like a pretty valid concern. Part of the next generation of rootkits seems to be targeted at SMM-level rootkits (termed "ring -1" by some) that are installed in the BIOS. They are practically undetectable once installed, and can punch through hypervisor protections too.

I think that is also part of the author's concern with Intel ME being present on all systems. It is a separate microcontroller in the chipset that has power on the level of "ring -3" (I believe it is used to implement much of the new SGE instruction set, for example).

I think your observations are pretty much spot-on, except for your last point:

> The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well.

I think it provides a security-conscious user an added level of comfort/faith over a built-in solution. If you move the flash memory out to this external unit, and there is simply a three wire type of interface that pretty much only gives the system no permanent writability to the flash contents, that is a fairly solid and tangible promise. To some degree, you get to assert a new level of control over the "root of trust," at least the poinbt at which it begins in firmware.

That doesn't mean that there is not room for motherboard vendors to improve things, but we will have to have faith in them having done things correctly. I am not even talking about a hostile motherboard vendor - there are plenty of good faith or half baked efforts that end up being circumventable.

It is going to be pretty hard to take an off-the-shelf notebook and make the proposed changes, especially when you are talking about implementing hardware kill switches for certain components on a 12 layer PCB. The strongest incarnation of this idea seems to involve cooperation with, and some degree of trust in, the motherboard manufacturer (whether that is Purism or someone else). Is there any solution to nation-state hardware attacks involving intercepting your notebook while it is being delivered to you? I think that has always been considered "game over" as far as maintaining security.

However, if you have that, you do get a significant benefit. You are no longer vulnerable to someone sticking a rootkit in your BIOS. That is where a lot of the up-and-coming SMM-level rootkits like to be installed. You can move a fair chunk of your root of trust (the firmware, etc) into a device separate from the notebook, and feel pretty comfortable that device is going to provide certain guarantees about flash memory contents that we do not have with today's systems.

Yes, Intel might do that, but "circumventing the circumvention" is practically describing Intel making the change as some kind of malicious/hostile actor that wants to facilitate you being the victim of a BIOS hack. I don't think that is what is happening, but the current architecture does have undesirable consequences. Rotkowska's proposal doesn't really "circumvent" anything Intel is doing - it mainly allows the end user to assert a clean BIOS state.

Once upon a time, most/many PCs had physical BIOS protection in the form of a jumper on the motherboard that would allow you to put the BIOS into a read-only state. However, we have now had many years where such control cannot be manually asserted by the end user, and the flash just sits there writable (although there are chipset-level firmware write protections, various hacks, like Dark Jedi, have found ways around them). Plus, apparently even when you pull down the WO pin on some flash chips, the hardware setting can still be overridden by software commands. The paper suggests, particularly with the more recent versions of Intel ME, that the PC architecture has now evolved to expect, and perhaps require, access to a writable BIOS (in part, because the ROM stores not only firmware, but also things like configuration settings and data for the new ME-implemented TPM).

Thus, we may not be able to simply go back to a ROM with today's architectures. However, we can give today's systems something that behaves like a writeable flash chip, but is readily (and automatically) reset to a clean/factory state.

You can skip the Purism laptop, and just simply download the Qubes OS installer and try it out on whatever system you have. It uses the same installer framework as Fedora. As long as your system supports VT-x (pretty much anything recent does), you can have the Linux + Windows experience and the isolation offered by running them in separate virtual machines.

There are more advanced security features, such as isolation of network adapters from the rest of the system, offered with a system that properly supports VT-d (aka IOMMU). Between having a CPU that supports VT-d, BIOS correctly configuring VT-d, and ACPI tables being correct as well, finding such a machine can be a little more challenging than you expect. I suppose that is where some value is offered by the idea of a "Qubes certified" laptop.

OK - I will deny it, just by the simple fact that for the last 6 months I have used Qubes exclusively, including daily use of MS Office 2013 (and more recently Office 2016) for work within a Windows 7 HVM (I have not opted to use the Qubes Windows tools yet). The experience has been entirely satisfactory, and I have not regretted it. I assume that if Office does make use of DirectX, there is a software rendering pipeline fallback that works fine (but perhaps not at 200 fps). For convenience, I have also used Inkscape and Gimp - other content creation software, I suppose - within the Windows HVM session without any problems. At one point, I even made use of a professional level parametric CAD software package within an HVM session - it worked, even if admittedly it would had some fancier rendering options available with a dedicated GPU.

Your complaints about lack of 3D acceleration seem to reflect your personal preferences, and are not an actual requirement for making use of MS Office or many other software packages. My six months of production level use provides simple proof by existence. There are some things - games included - that do need something like GPU passthrough, but your view of the situation is either outdated or simply wrong.

I'm not sure why Apple should be singled out for addressing this. Plus, you're talking about a security issue that requires physical access to a machine - something a bit different from the issues of privacy, malware, NSA snooping, etc. It would seem more sensible to focus on those working up the USB specification (Intel, HP, NEC, etc.) to deliver a standard and hardware implementations less prone to attacks. Plus, pretty much _every_ USB stack has these issues - wasn't it Linux where we starting seeing proofs of concept?

Actually, Apple has shown foresight in its hardware selection, as they have consistently selected Intel processors with Vt-d/IOMMU support (to this day, it remains difficult to find IOMMU-enabled notebook computers). This has allowed OSX to isolate Thunderbolt and neuter attacks: http://ilostmynotes.blogspot.com/2014/11/thunderbolt-dma-att...

Possibly a similar thing might be done for USB controllers as well...

Given the complexity of QEMU and its pace of development, there is likely an endless supply of such bugs for punching through the QEMU emulation layer. The problem is that most of the time, the QEMU process is running in dom0, giving an attacker an opportunity to hijack the hypervisor. Xen offers a more general solution for this: running QEMU in a stub domain. The main problem with that solution right now is that Xen forked QEMU such that the stub domain only supports running QEMU 0.10 or such - the up-to-date version of QEMU (known in Xen as qemu-upstream) is somewhere around 2.2, but it runs the emulation layer as a process in dom0, which exposes the system as a whole to "VENOM" and related attacks on QEMU.