But to be clear, the rule is against unofficial mirroring. Officially sanctioned methods are fine.
3,282 karma · joined June 2, 2016
But to be clear, the rule is against unofficial mirroring. Officially sanctioned methods are fine.
Hah, I did not expect that. I can't imagine any end users will be able to name that one.
But yeah, it's hilarious that they're pushing this so hard when the Google Play Store still has so much malware.
That being said, I can see this being useful for a similar use case where encrypted ZIPs are useful. When malware testing, you sometimes want to avoid accidentally running the malware or exposing it to antivirus software until briefly before testing begins. Encrypted zips (as well as simple transformations like ROT13 or reversing the bytes in the file) can help control the moment the malware is unleashed. This HTML based tool could be useful for doing this in network sandboxed systems, with the specific property that it's testing the antivirus behavior when the file is marked as browser downloaded.
Sounds like the proper response is "my car has been disobeying me for the past 30 minutes, so crushed is fine" and then get out
This is the one I'm referring to, it used some very dumb `Math.random()`-with-unverified-incantations code that should have been obvious if anyone had just looked at it. This one is responsible for the majority of hackable bitcoin addresses. It's really embarrassing that this kept going until 2020.
(At one point this would have been a tricky situation, though, because around 2009-2013 when bitcoin wallets were first being generated in web browsers, Internet Explorer didn't provide a CSPRNG API. Because of the prevalence of IE, an in-javascript CSPRNG would have been justified as a fallback if it had proper cryptographic mixing of mouse input entropy and perhaps timing execution jitter entropy as well, along with good entropy estimation to decide when enough seeding has been performed to start generating keys. Some wallet websites actually did mouse entropy collection at the time (e.g. https://www.bitaddress.org), but often with dubious mixing. Might have been best to just ban Internet Explorer.)
> Libbitcoin / Milk Sad (2023)
Mersenne twister... likewise should have been identified as not even remotely correct. Not a serious CSPRNG at all. Similar to the CryptoJS case.
> Trust Wallet Browser Extension (2023)
Also Mersenne twister, similar to the CryptoJS case.
> Trust Wallet iOS / Trezor Library
Time-based seeding, with an exceptionally weak PRNG with only 32 bits of state. Similar to the CryptoJS case.
> Android SecureRandom (2013)
This is a buffer bug that caused existing seed data to be overwritten by newer data rather than correctly appending it. The serious cryptographic primitives weren't broken, just the input. But it is genuinely scary. Unlike the other examples, it wasn't immediately identifiable because it gave the appearance that a CSPRNG was being implemented, and being a platform API it is just as scary as the Debian bug in 2008.
You mean javascript libraries that do a bit of Math.random() and a miniscule amount of mixing, that had been widely considered poor practice for years while old bitcoin wallet generator websites were burning users with it?
Has any actual serious CSPRNG exposed bitcoin wallets?
Can this actually be done without an ISBN or DOI number?
If you actually have a serious use case that needs 24/7 unmonitored agents, you can assemble all of the data the agents need locally and avoid these insanely obvious and well documented risks associated of running a random word generator with the ability to HTTP POST.
(And just in general, please stop subjecting the rest of the world to any automated actions that cannot be reversed by a human override. Same goes for cloud services subjecting users to quick non-appealable bans based on faulty automated detections. Or the current rollout of predictive policing technologies across the world. Or the automated bomb targeting in the ongoing Gaza genocide. )
In my view, proliferation of highly automated technology is not the concern, but rather its diffusion into human systems without thought put into whether it even meets our requirements for basic ethics, domain-specific correctness, and ways to mitigate a fuckup when it does happen. In this case, the detrimental diffusion into human systems was only allowed because someone made a decision (no access controls on the bot) that we can already easily characterize as a mistake that will need to be both mitigated (via a massive upgrade in cyber defense, especially with the help of AI fuzz testing but also more stringent compilers/linters/formal verifiers) and prevented from happening in legitimate regulations-abiding organizations in the first place. This kind of stuff will be slowed down at some point as we learn from hard mistakes, but the current craze is getting quite stupid.
If it's the one I'm thinking of, this device includes a read-only ~100KiB USB mass storage device filled with .lnk files to remind you to register the device to get your bundled digital goods (a bunch of DAW plugins).
You might want to try connecting the interface with Windows and install the focusrite driver. This will set the device to a "pro audio" mode, unlock the higher sample rates, and permanently make it stop behaving as a mass storage device. Not sure if this fixes Haiku OS USB audio compatibility, but it's a good bet and helps avoid the annoying mass storage device volume.
If you don't have a Windows machine to do this on, you can do it in a libvirt or qemu virtual machine on Linux using USB host device passthrough. Once you do it, it doesn't have to be done again, I'm guessing they implemented this with an eFuse.
Wait, does this mean Nvidia won't have GPU acceleration for apps under XWayland anymore? Or is EGLStream not what I think it is?