pyodbc, backdoors, RESTful, SaaS, Hexadecimal, Hackers, TinyDB, Buzhug

Post date: Jan 28, 2016 4:31:27 PM

• I've noticed multiple scenarios with pyodbc where something really nasty happens. It's possible to crash the database engine and or the application calling pyodbc. I just wonder if any of those could be escalated into security problems and exploits? Anyway potential DoS is alone bad enough.
• Backdoored backdoor - Really nice analysis. That clearly shows how hard security is.
• I'm still very negatively impressed by so many sales persons. I wonder how they manage to be so full of .... It's amazing. What I want, I want a good product, good price and fast delivery. No matter what it is about. Somehow it reminds me from the pitching talks and start-ups. This is so awesome, cool and does everything you want, now give us 10 millions. What it is about? Well, this is amazing, you'll be surprised, but it's kind of secretive business so... Yawn.
• What RESTful actually means? - Excellent post. I've been also wondering this hype several times. Especially I didn't like that leetness about post, get, put, delete usage. Does it really matter? I've been doing usually as versatile and simple code as possible and I find that separation just restricting. Basically you could get all that easily done with post alone. But we all already know that. Link to this page will clarify this out or maybe not.
• Once again more discussion about software testing, and how often testing lacks proper load testing etc. It's just tested with minimal data set which it seems to work with. But in that case you're probably expecting issues in production. Unless you know your tools very well.
• Analysis of 205 SaaS businesses - Awesome reading. Yet nothing surprising as far as I figured out.
• Why did the guy in Martian movie use hexadecimal? I would surely have implemented more efficient encoding method. Hex for text is utter waste of code space. As well as it requires at least two code points / letter, which is horrible. In most of cases also separating between capital and lowercase letters is huge waste of comm resources if that's not useful for the use case. It's also nice that they'll get near real-time chat over the links, where single letters are being transmitted. That's also huge waste of resources. Haven't they really ever used packet radio? Even most of IM apps do not transmit in real-time because it uses up resources. Yet when chatting with ridiculously slow writers it would be awesome. Because I could reply before they even finish their messages. Ha. That's why I loved HS/Link real-time chat as well as split screen chats with BBS admins / SYSOPs. Limited code space makes also memorization easy. Who doesn't remember something like telephone keypad? It's not perfect, but as T9 has shown, it's reasonably easy to decode with natural language. Yet if hex is being used it's good to remember 0x41 or 65 so you can create the most important mapping table from memory or even do without it. Remembering also basic ciphers and creating required tools for those like Playfair cipher and creating The Vigenère square can be very useful in some case. Yet it might be better in some situations not to get caught using tools like that and preferring in memory mapping. As well as using steganography as primary tool to hide the cipher text. Also having a fixed codebook can be highly beneficial, it helps a little with hiding the content, but even more compressing it working as shared dictionary compression. One important thing is also being able to make a light encryption or which could be called nowadays classic encryption and in modern terms more like obfuscation. Which is trival to crack with right tools and for right people, but it still will easily keep the content for huge majority of population.
• Hackers relaxing during vacations? Nope. As far as I've seen, attack just get much worse during vacations? Why? Well, they know that nobody bothers to fix their systems during vacations. So they might much better peace working with systems, just like any other burglarian would do.
• Checked out and played a little with TinyDB and Buzhug. Yet TinyDB is useful, it's not for me. My basic requirements are indexing and transaction safety. Even if I'm usually dealing with small databases, in range of a few gigabytes and only tens of millions of rows, I still can't accept lack of those two absolutely vital things. It's also likely that if there isn't proper transaction support, data integrity could be also at very real risk. And I'm not just now meaning transaction safety alone, I mean it could get corrupted because the ordered execution of stores might not be throughly thought out. For small data sets which are processed in batches, I still prefer the very old fashioned style, where I read the stuff into memory, process it, and then safely write back to disk and rename back to replace the original data. That's atomic and safe. If it fails, so what, it can be retried later. When the saving is done with proper synchronization then it's pretty safe. I might also save a number of previous verified to be correct data sets if data is so important that it's worth of it.