Fiddler: capture Android traffic

This post notes the steps required in December 2020 to get Fiddler Everywhere to capture traffic coming from an Android phone (on the same network).

Computer: Windows 10, IP:
Phone: Nexus 5X (Android 8.1.0), IP:

On the computer:

  1. Install Fiddler Everywhere on the computer
  2. Enable remote connections in Fiddler
    • Go to Settings > Connections > Allow remote computers to connect
  3. Show Client IP column and set a Contains filter:
  4. Enable HTTPS tracing:
    • Go to Settings > HTTPS > Click Trust root certificate
    • Press [Yes] in the Windows Security Warning pop-up
    • Check the Capture HTTPS traffic checkbox

On the phone:

  1. Set the phone to use Fiddler as a proxy:
    • Go to Wi-Fi > Modify Network > Advanced options > Proxy > Manual
    • Proxy hostname:
    • Proxy port: 8866
  2. Install the Fiddler CA certificate:
    • Use a browser to go to: http://ipv4.fiddler:8866
    • Download the certificate
    • Enter a certificate name (e.g. Fiddler) and press Save
  3. Test the setup by visiting https://wikipedia.org
    • Confirm the Fiddler certificate is being used (as below)
Visiting Wikipedia using the Fiddler certificate

Reference: https://docs.telerik.com/fiddler-everywhere/get-started/mobile-traffic/configure-android


Blockchain Voting

In his latest blog post, Bruce Schneier uses a new paper published by MIT to further reiterate his position of general diffidence towards blockchain technologies, this time applied to voting in political election. The paper, concludes that: not only do these risks persist in blockchain-based voting systems, but blockchains may introduce additional problems for voting systems. It is titled “Going from Bad to Worse: From Internet Voting to Blockchain Voting” by Sunoo Park, Michael Specter, Neha Narula, and Ronald L. Rivest and can be downloaded using this link: https://people.csail.mit.edu/rivest/pubs/PSNR20.pdf.

Schneier also links to this XKCD cartoon as a bonus!

Photo by Element5 Digital from Pexels

What makes good code?

Photo by Christina Morillo on Pexels.com

Excerpt from an interview with David Heinemeier Hansson, full interview can be found at: https://evrone.com/dhh-interview

Question: What makes code good or shitty? Anything that is obvious for you at first glance?

David: If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code, is a life long pursuit. As I said in my RailsConf 2014 keynote, we’re not software engineers, we’re software writers. “Writing” is a much more suitable metaphor for what we do most of the time than “engineering” is. Writing is about clarity and presenting information in a clear-to-follow manner so that anybody can understand it

There’s no list of principles and practices that somebody can be taught and then they will automatically produce clear writing every time. If you want to be a good writer, it’s not enough just to memorize the dictionary. Just knowing the words available to you, knowing the patterns of development is not going to make you a good developer. You have to develop an eye. You have to decide that the most important thing for your system is clarity. When you do decide that, you can start developing an eye.

PingFIN 9 is here

The PingFIN 9 workshop is an international e-payments workshop taking place from the 12th-15th March concurrently in 6 Universities: Colchester Institute, Faculty of Organization and Informatics, FH SalzburgOdisee, Westerdals and MCAST.

The workshop in Malta, held at the MITA Innovation Hub, is sponsored by MITA, MITA Innovation Hub, eSkills Malta Foundation and RS2 Software plc.

For more information see: facebook.com/pingfinmalta

DZone: You Are Not a Compiler!

It is common practice at conferences, interviews and certifications in general to assume that the candidate can process the code and find the subtle mistakes in it. As the article clearly says “there is no single proof of correlation between correctly answering any of the above questions and real-world proficiency of applying the skills they are meant to assess.”

Doing it right requires more time to prepare the material and analyse it afterwords but unless one needs to asses thousands of candidates, that investment is well worth it

Original article: https://dzone.com/articles/youre-not-a-compiler

On passwords

Almost all websites covering technology had an article this week about an interview by the Wall Street Journal with Bill Burr (the man behind the password complexity rules we are forced to use). In the interview Burr says that he might have been was ‘barking up the wrong tree’ in his 2003 manual NIST Special Publication 800-63. Appendix A

This was big news since many organisations follow these guidelines religiously, to the detriment of their users and possible security. Changing your passwords every 3 months and using long and complex combinations makes using a password-per-site impossible to remember. The advent of password managers and 2FA are a sign that the traditional username+password system is not good enough. Maybe someday in the future we will be seeing less passwords…

Reference: Original WSJ Interview and other coverage by BBC and The Verge.

3 security lessons from TDD

The original article Three Lessons From Test-Driven Development that can be found at: https://securityintelligence.com/three-lessons-from-test-driven-development/

“TDD was born out of a collective realization that we needed to change the way software was developed and tested. Similarly, the field of cybersecurity has, in the past decade, brought about a change in the way we think about layered defense in the face of determined attackers. By leveraging these three lessons, we can mirror TDD for software development to create new ways of validating and improving the cyber resilience of our own systems.”