Vacation, Masterpass, PSD2 / e-Receipt, RFC8021, Outlook & Thunderbird mail move

Post date: Aug 26, 2018 4:11:35 AM

• Summer vacation, wonderful time to study stuff. While take care just of the most urgent work projects and incidents.
• Checked out yet another mobile payment method. Masterpass by Mastercard in co-operation with Nordea. Payment method fragmentation has been lately quite massive. Internet makes payments so easy, and providing payment services so easy, that we're going to see many more payment methods in near future. Yet many of the new payment methods actually aren't that handy or secure after all. But future will tell which ones will prevail.
• Electronic receipts, just a few quotes from my email to someone. - There are different digital receipts implementations. Many of those are 'proprietary'. The generic electronic receipt exchange project isn't unfortunately fully functional yet. But I'm pretty sure it will be in future. PSD2 will change so much in Europe. As well as electronic invoicing using national standard has been running in production strongly for a long time. I'm pretty sure this will happen with receipts too. - Some details I won't quote. But listed several chains issuing electronic receipts in Finland. How those are linked to loyalty, customer identification, benefits, data mining, campaigns, etc. Identifying customers, getting extra value about that at retailer, etc. Checking purchases for allergies. Integrated shopping lists. All the stuff, which is utterly obvious. Collecting anonymous statistics, making price comparisons, selling that data, to whom ever is ready to pay for it. What about privacy, and so on? It remains to be seen. What will be the killer solution, and who will get the market dominance? Currently there are just more and more companies and solutions popping up, and it's clear that the market hasn't been shared yet.
• Global positioning, navigation and timing (GPS / PNT) and alternative solutions (APNT), like Galileo, BeiDou, GLONASS. Now it's all about the receivers supporting these. Of course in Europe EGNOS data is also available.
• Tested some old Android platforms. For fun. Some of those work really well, if you just install the applications directly as APK files. If you enable Google Play, it's quite likely that Google play fills your devices memory with junk, and that's really hard to fix. So it's better to just use the Android device without any connection to Google using latest required APKs.
• RFC8021 - Studied IPv6 ICMP fragmentation attack called 'atomic fragments'. Which mostly affected at least Juniper core routers. I'm pretty sure this is not first nor last attack vector to be found. It just requires combining some things and an implementation which does work bit differently than some others. That's the problem with different implementations. Yet diversity is generally good, if there is some important key system, and it's possible to run it using two different implementations. That's what I would prefer. Yes, it might be that it adds extra vulnerabilities, but also if there's vulnerability which causes DoS or downtime / crash, the backup can take over. These things are sometimes hard to balance. Put everything in one armored and gel filled egg basket, or try to diversify and distribute eggs out in separate not so hard core baskets.
• That Outlook / Thunderbird mail copy issue might be seen as generic transactional issue. Transaction contains moving 10k mails from A to B. 1000 mails get copied, and then it hangs. Due to rate limit, operation count limit, or something else Outlook IMAP server is causing. Because each copy is independent operation. Transaction isn't rolled back but next time it's attempted the 1000 mails are copied again. And this ends forming a loop which just generates more and more junk. Btw. I was unable to locate the potential IMAP operation queue from Thunderbird quickly. Does someone know where that's stored? Probably clearing it could have helped. Nothing new, just so common fail. In one API which I implemented, I requested TXID to prevent this kind of problems. But the other party refused. Now it's possible that TX is initiated, and it fails for some unknown reason. Most likely network timeout / or other error. The TX got completed, but the acknowledgement message wasn't ever received. Next time they'll retry, the transaction is redone. In this particular case, it's quite bad, but it's not yet catastrophically bad. Yet, the issue is so serious, I'm not feeling quite comfortable about it. So there's pre-known exploitable flaw in the system, in certain conditions. Which hopefully are rare enough. With TXID I could have just confirmed that this transaction has already been processed, and not to redo whatever it's doing. Sorry can't go into details, due the possibility of exploitation.