Microcode, Clonezilla, SVG, E2EE, Auth, LEP

I guess my friends are too nerdy. Most of them have updated today Intel Microcode updates for their CPUs. All of my friends got i7 CPUs. Lulz, etc. Interesting profiling. Should I be worried?
Had to explain thoroughly in one project why things like: 1) Do not repeat yourself 2) Reinvent the wheel 3) Code reuse. Approaches are very important to follow. It doesn't make any sense to reinvent the wheel and re-implementing some code in very hasty and brittle way, just to make a few workarounds which are missing from the original code. I've done that way too many times, and I'll refuse to do it again. - Even if I do it sometimes with my study projects, just to lean the required implementation details of something, which is already implemented by someone and working well.
With Clonezilla is is for some strange reason impossible to clone some Fujitsu SSDs with Clonezilla / PartClone, but when using NTFS clone everything works perfectly. Error message is just generic I/O error, which doesn't help much solving what's the true cause of this problem. Anyway, if disk is cloned with dd, it works. So that should pretty much make it clear, there's no I/O error in reality. Something else goes wrong for some other reason. Interestingly and unfortunately this problem has been very persistent.
Started a project where many graphics object images on specific websites are being replaced with SVG vector graphics. That's because high resolution PNGs are quite large, and the SVG is finally better option. Sure, it's nice to have huge PNG images on a website to provide crisp user experience, but users with lower end devices and slower network surely aren't going to appreciate that. So what if our background graphics for web page is 50 megs?
More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema - Nothing new really. If you give control to outsiders, well, there's no way to reclaim it. This also means that the group functionality is obvious implemented incorrectly from security standpoint. But that's totally obvious, no need to do research for it. Either you control something, or you don't and in this case, control is handed over. Only correct way would be keeping the group encryption key control in the application sending the messages. Or doing it like others do, encrypt every message with new random key and then just encrypt that key with public key encryption to the intended recipients. Just like PGP ang GnuPG (GPG) have done it for decades. Because this step is done in the device, it should be at least in theory secure. But this is another point which I've been complaining about. Where are the open source WhatsApp clients, where the application can be properly audited? It doesn't matter at all, even if everything is secure, if you can sidestep the whole encryption whenever required. This is exactly what I've been warning about the automatic updates. Yep, the version you used yesterday is secure. But the version just your and your friends are using today, btw, is totally insecure. Because we delivered you a special update. Problem is that auditing software is useless, unless every single update is audited before release and installation. Well, we know that's not going to happen so. Just get used to insecure stuff.
Originally there weren't any mobile strong authentication apps, but now I'm using several. it's nice to compare which are pros and cons of specific solutions. It's also a good question if these methods are defined as "different" in security terms. At least implementations are really different. But because all of these are defined equally strong officially, question is does it matter? If any of the strong authentication methods is vulnerable, it allows attacking same systems.
Law Enforcement Portal (LEP) - Official way to access private information for law enforcement. If you go and search, you'll find that most of major Internet businesses got one and have had for over and decade.
At first the Scalable Vector Graphics (SVG) file might seem bigger. But it's good to remember that the SVG file isn't compressed. After compression, it's for simple logos much smaller than any PNG / JPG presentation. Also high compression JPG images always suck, so fair comparison is only PNG vs SVG. And in most of cases, unless talking really small PNG the SVG wins hands down.

2019-04-28