Blog‎ > ‎

NFC loyalty / payment card, Telegram Data Retention Policy, Bad Code(?), Skype, Tosibox

posted Jul 22, 2016, 1:20 AM by Sami Lehtinen   [ updated Jul 22, 2016, 1:20 AM ]
  • I'm just wondering why the NFC credit card with loyalty features needs to be read twice when paying, even if the loyalty information has been registered earlier in the transaction. That's about it, I wonder what kind of engineers write this software. A) I register my loyalty identity using the card. B) Then it comes time to pay. I show the card, it says, loyalty information registered. C) Then I'll show the card again, and now the payment is accepted. Why why why, those fail guys got the step B? It's just repetition of the step A. It doesn't make any sense, and makes the the process suck. - Thank you engineers, once again.
  • I asked about Telegram chat history retention policy. It's just as it says on their page, but it's written in bit confusing style. So to make it clear. Telegram chat history is kept forever on Telegram servers / cloud / database. Unless, all parties of the chat delete it. Which basically means that most of chats are kept forever. And that's good to remember. If you delete something from chat, you'll only remove it from your personal view. It's still maintained in cloud for everyone else. Just as they say, you can send stuff to cloud and 'delete it', but it actually doesn't mean anything at all. When it's out there, it's there forever. kw: Telegram, chat, message, history, data, retention, deletion, removal, policy, IM, instant messaging, privacy, security.
  • To continue about crappy code. In one project there's integration (not written by me) which has option to write output as UTF-16 or CP1252. If you enable the option to write out CP1252 files, the data export gets just much slower. I wondered what the option was actually doing. It was pretty clear. If cp1252 option is enabled, add '.tmp' to export filename. Then run the export code as usual. After that open the temp file and read it into memory as one large string. Then remove every second byte from the string and then write it back to disk. - That's marvellous. First of all, it doesn't give a damn about character encodings actually. It'll basically work with < 128 ASCII by design. As well as it's phenomenally slow, because it modified the string in memory over and over again. - But as being said, it still works. And for exports which aren't too big, the time is only a few minutes, so it doesn't matter either when it's run in nighly batch run. Why bother doing things in a complex way, when a simple way works? Ehh... This code has been in production for over 10 years and works well. So there's nothing to complain about it actually. Maybe just a few core weeks or months wasted, but nobody really cares about that. I'm not sure if this works in category, acceptably bad, good enough. But based on the fact that it has been used for so long, I think it does. Yes, it could be in some cases a problem, but in this case it wasn't. So what's the problem? I've seen similar implementations of \r\n to \n conversion. Horrible, but it just works.
  • Microsoft kills Skype for Linux no more P2P the cloud will be only option. So much about 'distributed' or 'P2P' IM systems. They want full control.
  • Checked out Tosibox - It's a box designed to provide secure network for systems which require security. Yet when checking the list, the first question is that if some of the systems should be connected to the Internet at all. That's the question which has been asked in many cases when something bad has happened. Their use cases list businesses like: Water & Wastewater, Security, Robotics, Lightning, Industry Automation & AMchiner, Home Automation, Food & Beverage, Energy Sector and Building Automation. Ahem, some of these sectors are guaranteed to gather interest from extremely competent attackers. Just makes me wonder. Nothing, nothing at all against Tosibox, their products seem great and well. It's much better that there's a proper attempt to secure systems. But the question remains if it's enough. Based on what we've seen in other cases, the answer most likely is, no, it doesn't actually help. But it makes things bit harder for attackers.