Just a heads up, this includes support for Return YouTube Dislike, which tells a third party service what videos you click on and has no measures to ensure anonymity like SponsorBlock does. The option for disabling it doesn't seem to do anything.
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.
This FAQ is hilarious. I guess the default assumption is that if kids say something they don't actually mean it or know what it means. But no, they do. Often they are just using language in a more advanced generalized way than you, rather than being confined to distinct boxes. Children's brains are language factories.
It seems google is going to allow an "advanced flow" that is scam resistant by requiring the user to wait 24 hours before they can start installing their own apps. It sucks, but assuming they don't change the plan again, F-Droid should be able to continue working.
It's already live, I had to go through it last week. It's in developer options, then it asks if you're moving the selector to allow the installation of non-play store apps because you're being asked to by someone.
Then it starts a 24 hour timer. When that hits zero, you have 1 hour to go back in and select that you want to install apps on a device you own and paid money to own.
It's not scam-resistant at all. Any scammer will gladly work around this and send someone to one of many malicious apps in the play store, or a malicious URL, or even just set an appointment to call Grandma back the next day.
They're not necessarily wrong about it being scam resistant, based on some of the research into the psychology of scams. Adding time defuses the urgency of phone scams, leaving plenty of time to seek a second opinion from family members or the internet, and forcing the scammer to re-explain what the original goal was. It's too much time to breathe and defuses the fight or flight reaction needed for a high success rate. You mention URLs, but a web browser based scam page doesn't accomplish much, because the scammer's goal with fake apps is to acquire persistent remote access (akin to how the AnyDesk Android app uses accessibility permissions for Teamviewer-like remote access to an entire phone).
But yeah, it's hilarious that they're pushing this so hard when the Google Play Store still has so much malware.
What? It only stays enabled for exactly 1 hour after the 24 hour timer?
I was under the impression that it would stay enabled permanently after waiting the 24 hours once.
IIRC, it's the button to permanently activate it that is only available for one hour. Once you do manage to press it, you've permanently enabled it. If you miss the window, you have to start the 24 hours again.
So basically Google is being now more of an asshole than Apple (that now allows app sideloading and third party stores, at least in the EU). I'm and Android user since the beginning and for once I'm start considering for the next phone that I could as well get an iPhone, basically all the good open stuff of Android is long gone (back in the days I used to flash a new ROM every week), and at least Apple is better in regards of privacy than Google.
> Because, in the applied world, upstream bugs in "secure" system RNGs have been the cause of stolen crypto [...]
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?
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.
Refusing the platform's CSPRNG for such nonsense reasons is perhaps the dumbest form of POSIX worship. This is obviously an area where platform feature detection makes sense, there's no reason to follow a religion of standards adherence when it directly leads you into harm's way
Not POSIX/C99 worship as much as the very practical issue that a lot of C code which used to compile just fine stopped compiling once compilers defaulted to using C23. To use POSIX calls while compiling with -std=c99 (so I don’t have to update my code should C29 or what not come out) one needs to declare, for each .c file which uses a POSIX call, the version of POSIX the C file is compatible with.
reply