The new(er) mid range chipsets indeed are so so nice now. Pretty/fully modern process nodes, battery efficient, still very respectable cores.
Really glad to see we've finally landed at a place where finding an old refurbished flagship is not the only logical choice, where the mid-range has a lot going on for it.
Just wish we had some mainline kernel support, could put Debian on these things! I've had a OnePlus 6T (2018) that supposedly does pretty ok that I've been meaning to try Mobian on, and it felt like for a bit Snapdragons were getting better and better Linux support. But that motion seems to have really tapered off in the last ~2 years?
I had a Moto X4 which was quite cheap for $200 or $250. It did everything perfectly. No discernable lag for any operation. Plenty of storage. Great battery life. I can't imagine "needing" more phone than this.
Unfortunately it reached the end of its (security) updates so I figured it would be unsafe to keep using it since I have banking apps on the phone. Sad.
Non-generic adapters are fixed in custom ROMs/LOS, on stock Android 16 my ZTE modem is still reporting as usb0 due to MAC address local bit, while Huawei dongle works just fine.
Android phone to android tablet USB tethering is also local MAC and non-functional.
Still using a very old Tab S 10.5 from 2014 running a bit slow with LOS 21 - Android 14.
Started with Android 4 KitKat, stuck with Linux kernel 3.4 :)
5.4mm thickness, 3GB RAM (enough for 32-bit), 2TB SD card works, watching movies/shows with the AMOLED look as good as a recent OLED TV. Truly ahead of their time.
SDR content with mDNIe dynamic enabled comes surprisingly close to HDR content on an HDR display, colors can be a bit too staturated though.
After a decade, the battery lasts a week for daily hour e-book with black background. 3 hours of video playback.
However, it restarts at 30% battery when running at full brightness with a white background.
Disabling Wi-Fi significantly extends standby time compared to modern hardware.
Caveats: Slow web browsing and no H.265 hardware decoder.
1440p H.264 60Mbit is the max (Display is 1600p).
Most content providers and streaming services are slowly moving away from AVC, so it's stuck at 720p H.265 on CPU.
Back in 2014, I couldn't have imagined using hardware that was over a decade old.
Arguably, rolling your own crypto (in this case AES which is customizable) requires a very careful implementation, beyond RNG.
Since dart/flutter is multi platform, using Random.secure for animation has it's own performance issues with interfacing host entropy RNG.
The majority of Dart/Flutter users are creating UI apps.
Few browsers with security policies and OS combination does not allow access to the entropy with Flutter Web in which Random.secure will fail, this isn't exclusive to Dart/Flutter. [1]
NaCL [0] offloads these concerns for developers, especially indie/startup.
Rolling your own security requires nothing more than gumption and willingness to deploy. That doesn't mean it's good security but it means people will do it whether they know all the golden rules. After all, rolling insecure security requires missing 1 small thing in a haystack of thousands and it doesn't matter you reviewed the language defaults when OS version blah blah from vendor xyz defaults to something insecure "because you should have checked the defaults". The same goes towards "this library does these kinds of things so there is no value in languages having secure defaults too" type thinking, they aren't convincing arguments for what security posture of other things should or shouldn't be.
I'm more a fan of "make the defaults as secure as you can reasonably expect to get away with for each step of the way". It'll never be as secure as everyone wants but if you but up against "it's as secure as people would want to put up with by default" then things are at least at a good starting point for others to build from. The hard part is finding out what people are willing to put up with and which tradeoffs are worth it. That default random number generators "only" go at GB/s on most PCs because they produce really good random numbers is probably an easy tradeoff though.
When I wrote a Random class for use at Amazon, I made SecureRandom (which couldn't be seeded, and was a multi-source DRBG) the default, and you had to intentionally choose InsecureRandom. This is how it has to be, and in this case there should only be Random, and Random.insecure IMO.
The author acknowledges early on that `Random.secure` is there to provide randomness where it needs to be secure, but then spends the entire article fretting over how the other source of randomness isn't. But it's not supposed to be!
Applications have plenty of reason for cheap, stable, or otherwise controlled forms of randomness and shouldn't have to pay the penalty for -- or face the reproducibility limitations of -- secure randonmness when that's not what they need. It's both useful and traditional for standard libraries to either include both forms, or to leave the secure form for other libraries to contribute.
If an application uses the wrong supply of randomness for their needs, that's an application error. And if developers writing security-sensitive code don't know to think anticipate this distinction and avoid the error, then that sounds like there was a project management error in assigning them such a sensitive task.
Well the article still has a point in that the insecure PRNG is neutered for seemingly no reason, contrary to developer expectations.
But I think we should, as language developers and users, be well beyond the point of pushing out and accepting insecure defaults with a little documentation disclaimer - especially if even the Dart developers themselves can't catch misuse of their own insecure APIs in widespread tools.
At the end of the day, we don't live in a computing world where true randomness is that resource-intensive anymore, and user-facing applications should basically always be relying on it. Non-randomness should really be the opt-in, when developers can actually justify that the performance penalty is a problem. Otherwise, I don't need library authors prematurely optimising my programs at the cost of security.
(There is a similar related discussion to have about the pervasiveness of floating points in programming languages when most applications would be better served by a more expensive, but more precise, numerical representation - since they rarely do that much calculation.)
It’s not random, that’s the point. If you neuter it so much that it’s only useful for a specific use case then make sure it’s named something relevant and specific related to that use case!
I'd say it's because Proton does not employ actual cryptographers or security engineers. They do seem to have a lot of marketing folk, interns, and particle physicists, allegedly.
Currently using https://isit.mooo.com for daily usage and http://hnapp.com for advanced search.