Sanzig

> Even the tiniest MCU can typically perform more than one cryptographic operation per second. If your MCU has any cycles to spare at all it usually has enough cycles for cryptography.

Well, no. If you can do 1 AES block per second, that's a throughput of a blazing fast 16 bytes per second.

I know that's a pathological example, but I do understand your point - a typical workload on an MCU won't have to do much more than encrypt a few kilobytes per second for sending some telemetry back to a server. In that case, sure: ChaCha20-Poly1305 and your job is done.

However, what about streaming megabytes per second, such as an uncompressed video stream? In that case, lightweight crypto may start to make sense.

Sometimes, the little guy does win, but only after a lengthy court battle: https://en.wikipedia.org/wiki/Nissan_Motors_v._Nissan_Comput...

The other thing is the vast majority of UF6 in the fuel cycle is low-enriched (reactor grade), so it's not useful for building a nuclear weapon. Access to high-enriched uranium is very tightly controlled.

You can of course disperse radiological materials, but that's a dirty bomb, not a nuclear weapon. Nasty, but orders of magnitude less destructive potential than a real fission or thermonuclear device.

The first P25 standards came out in 1989, so encrypted police radios were certainly starting to be deployed in the early 90s. Obviously, adoption rate depended on the department budget, with many rural departments taking until the 2010s to finally switch.

A couple of bright physics grad students could build a nuclear weapon. Indeed, the US Government actually tested this back in the 1960s - they had a few freshly minted physics PhDs design a fission weapon with no exposure to anything but the open literature [1]. Their design was analyzed by nuclear scientists with the DoE, and they determined it would most likely work if they built and fired it.

And this was in the mid 1960s, where the participants had to trawl through paper journals in the university library and perform their calculations with slide rules. These days, with the sum total of human knowledge at one's fingertips, multiphysics simulation, and open source Monte Carlo neutronics solvers? Even more straightforward. It would not shock me if you were to repeat the experiment today, the participants would come out with a workable two-stage design.

The difficult part of building a nuclear weapon is and has always been acquiring weapons grade fissile material.

If you go the uranium route, you need a very large centrifuge complex with many stages to get to weapons grade - far more than you need for reactor grade, which makes it hard to have plausible deniability that your program is just for peaceful civilian purposes.

If you go the plutonium route, you need a nuclear reactor with on-line refueling capability so you can control the Pu-239/240 ratio. The vast majority of civilian reactors cannot be refueled online, with the few exceptions (eg: CANDU) being under very tight surveillance by the IAEA to avoid this exact issue.

The most covert path to weapons grade nuclear material is probably a small graphite or heavy water moderated reactor running on natural uranium paired up with a small reprocessing plant to extract the plutonium from the fuel. The ultra pure graphite and heavy water are both surveilled, so you would probably also need to produce those yourself. But we are talking nation-state or megalomaniac billionaire level sophistication here, not "disgruntled guy in his garage." And even then, it's a big enough project that it will be very hard to conceal from intelligence services.

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

I have two Tapo units at home, they seem to be working fine without an internet connection.

I created a new subnet and an associated WiFi SSID for it, connected the Tapo cameras, and set them up to act as RTSP cams. I then firewalled the subnet off from anything other than my Frigate NVR server and gateway. They still work fine, they are streaming video to Frigate without complaint. Maybe because they have DNS from my gateway still? (I should probably block that off, it's a common data exfil vector).

Very annoying that internet connectivity is required for initial setup, I'll agree there. They could have just had a bare bones web interface.

Interstellar space is pretty empty, and we have good models for it thanks to the radio astronomy community. Dispersion is low enough to be nearly negligible, even over tens of light years.

Determining theoretical interstellar link rates is a fairly straightforward link budgeting exercise, easier in fact than most terrestrial link calculations because you don't have multipath to worry about.

It would be a lot more efficient to use erasure coding + heavy interleaving with other traffic so that you can withstand a maximum predicted outage period.

Most of what they do is Layer 2 and above, so it's hardware agnostic - prototyping on a Pi is fine.

Their work is gaining traction. DTN Bundle Protocol has been baselined for the LunaNet specification, which a bunch of private companies are designing to for lunar relay networks. Bundle Protocol is also currently on the CCSDS standards track so it should be formally part of the CCSDS protocol suite soon.

For those unaware: CCSDS is the Consultative Committee for Space Data Systems, they set widely used standards for spacecraft communications protocols. Basically anything beyond Earth orbit flies some variant of a CCSDS protocol stack, and a substantial chunk of missions in Earth orbit do as well, particularly if they are government funded. It's an international effort, China and Russia participate too so that everyone can communicate if need be.

I think it's both. It wasn't a problem when browsers were simple content display engines, but now that they are full VMs for application software, they need some of that capability just to function. FWIW, I think this was a mistake, but the genie is out of the bottle.

I suppose one technical mitigation might be a permissions dialog when a script requests access to a high-risk API like canvas or WebGL. But that's unfortunately something that won't work for most users, who will just click through the dialog.

TIL, thanks! The usual convention of calling them "cookie dialogues" sure obfuscates that.

Since fingerprinting is mostly client side, it should be detectable. If you serve a web page with a fingerprinting script, that should be an automatic big fine.

The fingerprint collection happens mostly using client-side JS (a bit of server side with HTTP headers, but the really high entropy stuff is client side).

Conceivably you could develop some sort of heuristic that detects when a script is simultaneously poking at a whole bunch of APIs associated with common fingerprinting techniques (canvas capabilities, WebGL, screen size, installed fonts, etc) and then kill it. But it is certainly much harder than blocking cookies.

Browser fingerprinting is one of those things that should be outright illegal - it is far more of a threat than tracking cookies ever were. But it hasn't permeated the public consciousness like cookies have, so regulators seem to ignore it.

I wonder if domain validation might be a good addition to this? You could encode a public key in a TXT record for the domain, and if present, vet could check a signature in the shell script against the key in the TXT record. It wouldn't stop attacks where the owner lost control of the DNS records, but it would stop the "webserver hijack" attack vector.

(Not affiliated with Cerebrium, just did a bit of looking into this a little while back).

Runpod outsources much of their infrastructure to small players that own GPUs. They have recently added some requirements on security and reliability (eg: some level of security audit such as SOC 2, has to be hosted in a real DC, has to be in a locked rack), but fundamentally they are leaning on small shops that slap some GPUs in a server at a colocation facility. This personally would make me nervous about any sensitive workloads.

My impression is that Cerebrium either owns their own GPU servers or they're outsourcing to one of the big players. They certainly don't have the "partner program" advertised on their site like Runpod does.

Nextcloud, particularly with the Collabora Office integration for real-time collaborative document editing. It's got some rough edges but I'd say it suits the majority of use cases now. I suggest spinning up a copy of the community edition in a VM to give it a spin, I was pleasantly surprised. There is a lot of money getting poured in right now as entities outside the US are exploring ways to ditch American software.

Ah, okay, well if you already have the IPv4 address space available for all your customers that's a different story. I can understand why you want to wait to dual-stack in that case.

I do think NAT64/464XLAT is a pretty good architecture for new ISPs that can't get their hands on IPv4 space, though. Or even MAP-T, but CPE support isn't really there yet.

In principle, IPv6 core networks can actually be very beneficial for small providers just starting out if they're not able to get IPv4 addresses for their customers and are forced to use CGNAT.

In an IPv4-only CGNAT setup, all the traffic has to flow through the CGNAT gateways, and that gear is stupidly expensive. Having IPv6 in the mix means that anything that supports IPv6 (such as most streaming services) won't hit the CGNAT gateway and can just be routed natively. This can really save money on CGNAT hardware.

For implementation, you can use NAT64/DNS64 for your CGNAT setup and implement 464XLAT on the CPE. This keeps your whole edge network IPv6-only so you don't have the complication of maintaining two parallel configurations on the edge.

There is also MAP-T, which is even lighter on infrastructure since it pushes all the state into the CPE and avoids the complication of stateful CGNAT. But unfortunately CPE support for it is pretty limited at the moment.

If you already have to do CGNAT, why not IPv6 as your core network with NAT64 at the border and 464XLAT on the CPE? It gives you best of both worlds.

Surprised they aren't deploying NAT64/DNS64 with 464XLAT on the CPE. You get essentially the same setup as CGNAT for IPv4 services but your whole core network is native IPv6 so you only have one set of address space to manage and your customers will be able to directly connect to anything IPv6 related.

Ah, whoops, you're right! Somehow my brain defaulted to Kelvin. So 740 K down to 290 K. Carnot COP alone is only around 65%, you'll be lucky to do half that, you need the stuff outside to survive heat and sulfuric acid, and you'll need to power it somehow. You could run it off a nuclear reactor, but your reactor will not be very efficient since it has to sink heat at over 700 K.

> Also it is one thing to get a person to 70 Bar in experimental conditions. It is another to actually stay at that pressure for prolonged periods and do anything useful.

Fully agreed - you'd have to test this long term in a hyperbaric habitat on Earth. You may end up needing some sort of medical or pharmaceutical intervention to make it possible. Very risky.

Even firmer in the realm of science fiction. It'd be a good hard sci-fi novel though.

Humans have already survived simulated dives in hyperbaric chambers to around 70 bar with no long term effects, so in theory you may be able to have Venusian astronauts live in a habitat at ambient pressure if 90 bar is similarly tolerable (obviously would still need heroic measures for cooling, an approx. 200 K temperature differential is no joke). Getting enough gas there to pressurize the hab could be difficult, the deep dive experiments used a hydrogen/helium/oxygen mixture and I doubt you can recover helium through in situ resource extraction. And you would need some sort of acclimatization system to get the astronauts from their half-bar or so transit environment down to the surface - maybe a balloon that slowly descends over the period of a few days.

So yeah, pretty much science fiction for now!

I really like the STM32 ecosystem, but you have hit the nail on the head - there's too many variants. You really don't need 200 variations of a basic M0+ part, and having all those SKUs hurts availability because you're playing roulette when it comes to what will actually be in stock when your CM goes to order parts.

> but if you work at a place they're interested, they care about you.

And also worth noting that "place a hostile intelligence service may be interested in" can be extremely broad. I think people have this skewed impression they're only after assets that work for goverment departments and defense contractors, but really, everything is fair game. Communications infrastructure, social media networks, cutting edge R&D, financial services - these are all useful inputs for intelligence services.

These are also softer targets: someone working for a defense contractor or for the government will have had training to identify foreign blackmail attempts and will be far more likely to notify their country's counterintelligence services (having the penalties for espionage clearly explained on the regular helps). Someone who works for a small SaaS vendor, though? Far less likely to understand the consequences.

> Also do chips in space need casing or could the wafers be just exposed on that back layer?

Even in LEO they benefit tremendously from radiation shielding, even a couple millimeters of aluminum greatly reduces the total ionizing dose. Also LEO has the issue of monatomic oxygen in the thermosphere which tends to react aggressively with the surface of anything it touches. An aluminium spacecraft structure isn't really affected, but I don't think it'd be very good for a semiconductor wafer.

> Pakistan (freed from fear of international condemnation) drops a nuke in India

India is also a nuclear state, so this is pretty unlikely unless the wheels really come off the deterrence strategy. North Korea attacking South Korea perhaps, but even that seems unlikely as it would greatly anger NK's closest ally of China.

While many websites are bad for large unoptimized payloads sizes, they are even worse for latency sensitivity.

You can easily see this when using WiFi aboard a flight, where latency is around 600 msec at minimum (most airlines use geostationary satellites, NGSO for airline use isn't quite there yet). There is so much stuff that happens serially in back-and-forth client-server communication in modern web apps. The developer sitting in SF with a sub-10 ms latency to their development instance on AWS doesn't notice this, but it's sure as as heck noticeable when the round trip is 60x that. Obviously, some exchanges have to be serial, but there is a lot of room for optimization and batching that just gets left on the floor.

It's really useful to use some sort of network emulation tool like tc-netem as part of basic usability testing. Establish a few baseline cases (slow link, high packet loss, high latency, etc) and see how usable your service is. Fixing it so it's better in these cases will make it better for everyone else too.

Yubikey does TOTP on-board, but you need to connect it to a phone or computer (no display or on-board power). It solves a different problem, where you want to have your TOTP credentials on a tamper resistant hardware security module. It doesn't solve the "don't want to carry around a phone for TOTP" problem.

Hmm. I wonder if there would be a market for a super simple TOTP authentication device with an e-paper display. Kind of like those RSA tokens with the LCDs, but more modern and able to hold any number of TOTP credentials.

Getting the credentials loaded could be a bit of a pain without a camera for QR code scanning. Easiest solution would be via Bluetooth to a companion app, which you would probably want anyway for periodic time sync (likely wouldn't be worth it to embed a GNSS receiver just to update the time).

Probably be a pretty small market, but as a niche Kickstarter device? I could see a small but loyal customer base.