No it won't but if it did would take just few hours for china to shoot a bunch of them down and with how tightly packed their orbits are the debree would take care of the rest.
I’m not so sure debris would help take down other satellites in that orbit. The orbit is very low so much of the debris that ends up with a deviation in its orbit will fall down. Even if it doesn’t there’s still air resistance up there which may cause more of the debris to deorbit before jt has time to hit other satellites.
And I doubt China would want to make LEO impossible to move through anyway. It’d affect China badly as well
potentially very dangerous for everyone if they did that. could make it impossible for even them to make a launch. Kessler Syndrome is nothing to toy with.
> "Researchers call for development of anti-satellite capabilities including ability to track, monitor and disable each craft / The Starlink platform with its thousands of satellites is believed to be indestructible"
"Easy to bring down" vs. "believed to be indestructible"—some tension there!
If you're talking about nuclear weapons, their major effect on satellites (Starfish Prime as the reference point) isn't EMP effects, but ionizing radiation—creating a persistent radiation belt of MeV electrons. (A physical process that took months to disable some satellites). Beyond that I don't know much.
Not feasible. That would entail putting shrapnel into orbit (unlike extant anti-sat weapons which are short-range suborbital), which would mean a full orbital launch for every satellite target orbit. There's hundreds[0] of Starlink orbital groups already, so that'd require hundreds of independent orbital launches in a short timescale—far beyond China's launch capabilities today.
(On general principles, you could argue you'd need 1:1 launch vehicle parity (number, not payload) to defeat a satellite constellation this way. For each satellite launch, you'd need one corresponding anti-satellite launch into that same, newly-defined orbit).
If you make a dense-ish cloud that cuts across the Starlink orbits you'd eventually intersect them all if you could make the artificial debris field last It wouldn't require that many different counter orbiting fields to cover most of the orbits.
Yes but there's so many starlinks that you're going to get lots and lots of collateral damage to sats from allies and enemies alike. It's going to be a huge footgun.
Not much else uses those orbits right now. Other comms satellites and surveillance birds are all higher up. The debris would in theory also clear pretty quickly and should be fairly contained so the cascade of additional damage might be relatively small too. Hard to know that without a huge simulation budget to see how high the shattered satellite bits might get tossed.
For your shrapnel to hit the satellite, it needs to be at the same height and inclination. Otherwise, your shrapnel will likely miss the targets.
Starlink satellites are pretty low and experience a lot of drag, with square-cube law working against you. Your shrapnel's orbit will likely decay pretty rapidly.
JWTs are just too fat, and JS users often forgets encoding is not encryption.
I've seen some news site trackers send JWT in url/header to some 3rd party tracker. Content is no surprise, my full name, and email address, violates its own privacy policy.
Otherwise it's very open and handy, from inspecting a jwt token I can learn a lot about the architectural design of many sites.
Unfortunately, it seems like 99% of the industry decides which token to use based on Medium articles, LLM responses or how many unmaintained packages that implement this thing they can find on NPM.
JWT is mostly used as an access token, but for the vast majority of use cases it's a bad fit. If you've got low traffic no strict multi-region deployment requirements, random IDs are the best approach for you. They are extremely lean and easy to revoke. It's pretty secure: the only common vulnerabilities I can think of with this approach are session fixation[1] and timing attacks[2]. Both attacks are preventable if you take just a few simple precautions:
1. Always generate 32-byte session IDs using a cryptographically secure random number generator on authentication. (Never re-use existing session IDs for new logins)
2. Either use a cryptographic hash (e.g. SHA-256 or Blake2b) of the session ID a the database field used when querying sessions or make sure that the Session ID field is indexed with a hash-based index (B-trees are susceptible to timing attacks).
In cases where you really cannot use Session IDs, your service is usually big enough and important enough to use custom Protobuf tokens even a more special-purpose format like Macaroons. These formats give can be far more compact and give you full control on designing for your needs. For instance, if you want flexible claims (with most of them standardized across your services), together with encryption, you can use a combination of Protobuf and a libsodium secret box envelope.
I use JWT and a half dozen other standards, not by choice though, I wished I could do what you suggest it would simplify everything a ton, but I'm not going to roll my own multi-org/SSO/2FA auth platform. Needing those auth features is what made me use these standards not because my app is big, it's not it's tiny.
> or make sure that the Session ID field is indexed with a hash-based index
Using a hash index instead of a btree isn't a 100% guaranteed solution because there may be craftable collisions (because e.g. postgres's index hash is not cryptographic) which cause fallback to linear comparison across the values inside the hash bucket:
sessionID is vulnerable to stealing cookies. Some games - if you lose your session cookie, you might as well lose your account and everything you have on it.
you can of course bind sessionID to the IP address, but this is extra effort you need to put.
in JWT land you can just put the IP addressed inside the payload and forward requests with non-matching IP to reauth and regenerate JWT for their new IP in case customer is roaming networks
One of my ex asked me complete the exercises in SICP with her in chez scheme, every day I'm tempted to use Racket, it's like python in the language class (all batteries included). I see people did some wonderful work with Racket, but I'm not sure if toy lang or is also used in production.
My told a story that when they were college students and broke, they just went to a scrape yard for car parts. Today me and my homelab friends just scraping ebay and local industrial waste sites to get routers, switches, and server parts. We had a good luck with LTO-5 and LTO-6 tapes and tape libraries, also for NICs it's pretty easy to get connect-x 5 and 6 at an acceptable price, CPU/MEM are ok, motherboards are difficult. You just set a spec, buy whatever is available atm, then wait until you can get a whole server. It's often a long process, and itself can become a hobby. (took me 3mo, my friend 2 years to get an "ideal" server)
Well, pricing out is real, even the junk parts are now at least 20% pricier than pre-covid, and I really hated myself for not bidding for SN2010M at $700 ~ $1500 range. Those are beautiful beasts.
I would recommend getting started with lazyvim (lazyvim.org). Once you're comfortable with the editor, you can change the config to kickstart.nvim and start customizing it to your liking. That's what I did and I have no regrets. LazyVim allowed me to switch without sacrificing productivity. I was on it for a year before I decided to make my own config
There's LoRa runs on 450/900 MHz with complete stack for transmitting and relaying messages. There's even modern encrypted protocol (meshstatic) built on it.
