IM, Tor, Über, Vuvuzela, HTTP2, Lenc, LZHAM, acme-tiny, Webhooks, Productivity

Post date: Dec 25, 2015 7:37:13 AM

  • Carefully studied WhatsApp and Telegram FAQs and documentation. I find Telegram better option than Whatsapp. It's open source, multi-platform, free and clients are technically lighter to run. It's nice that they got ratcheting OTR client - client encryption.
  • Actually Telegram, Whatsapp, and so on, phone number linked services could potentially also be a security problem? Why? Because with burner phones the numbers are reused by the service provider quite quickly. If the data is still in the cloud service, it could pop up when the number is circulated to new user and they start using Telegram / Whatsapp or whatever phone number linked service. So it isn't secure either. Except when using client - client OTR mode. There are reasons why linking identity to email or phone number is actually a very bad idea. I think again that linking it to private key or 'shared secret' negotiated securely is much better alternative. As well as challenge response can be used to verify the shared secret, so there's no need to actually tell out after initial negotiation what it is.
  • Great long article about Dark Web (Tor) got broken, and plans to fix it. Had to read it all. No news there.
  • Über Pool, that's nice. I'm just wondering when we do get that in Helsinki, Finland.
  • Vuvuzela a metadata hiding chat. Finally a project which considers the long known short comings of most chat applications. Worth of checking out. I've written so much about this topic. Many aspects remind me again from Freenet and GNUnet and Freemail. constant-bandwidth protocols, mixnets, and cover traffic. Nothing new there.
  • The most important part and difference to other secure chats is here Quote: "Network traffic. To limit the information that an adversary can learn by watching the network traffic between Vuvuzela clients and Vuvuzela servers, Vuvuzela encrypts all messages. Furthermore, Vuvuzela ensures that message sizes, and the rate at which messages are sent, are independent of user activity (via padding, splitting, etc). Vuvuzela clients also send messages at a fixed rate (queuing messages if the user types too fast, or generating empty messages if the user has not typed anything). One implication of this design is that there’s a fixed number of conversations that a client can participate in per round (in our prototype, we set this to one)." - Only thing I found somewhat interesting was the layering of the server side servers. Yet it's not anything new, it's still a neat security feature. Assuming that he three servers are correctly administered and so on. What I really loved was the server and system performance analysis.
  • Reminded my self about Laplace distribution.
  • Cloudflare added HTTP/2 support.
  • Let's Encrypt Public Beta is here! Awesome. I've been wating for it. Now you can get free SSL / TLS certificates from Let's Encrypt project.
  • Everything you post and do, is and will be analyzed. Are you pro, leader, spreading disinformation, troll or something else? Pheme project addresses speculation, controversy, misinformation and disinformation on social networks utilizing big data analytics. Pheme Computing Veracity.
  • Checked out LZHAM data compression algorithm and LZFSE Data Compression. Yet it all comes down to what and when the data compression is being used and what are the other bottlenecks and performance characteristics of the system and environment. Also read great article about Unexplored areas in data compression.
  • Checked out acme-tiny. Which is a small Python script which renews SSL certificates using Let's Encrypt issuing service. Awesome!
  • Finishing once again one integration, pretty standard SQL / Webhooks stuff. Data mapping is sometimes challenging, especially in cases when nobody knows what there exactly should be. As well as even if data mapping is done correctly are both ends configured correctly is totally another question. It's funny when there are project managers, programmers, customer and consults and more project managers on customers side and more coders on their side and communication is what it is. People look for bugs, or claim something isn't working, even if it's obvious that the production DB just lacks one database key which the data refers to. Of course that key is in test environment. Duh, that's the normal life with this stuff. I personally just love small efficient teams. They can pull of in a few days something which will take weeks or months from larger teams messing up with simple things. Nothing is better than two guys which completely knows their own systems and are also capable coders, say let's get this stuff done and that's it. A few iterations later it's done and working.
  • Had a long discussion about getting stuff done. We found out that most of us which get a lot of stuff done, prefer doing over watching. As example, if you can spend a weekend binge watching some a few seasons of some TV series, versus learning and doing stuff, which option you'll prefer? It's also interesting to notice that the people preferring the doing, usually are always employed, vs the people preferring watching might have very long unemployed episodes or be more or less permanently unemployed. As well as the people which are employed, often receive contacts from startups looking for people actually getting stuff done with some very specific requirements and cases at hand, versus HR departments looking for 'employees'.