Monday, October 30, 2017

It's time to Firefox again

Understand why now is the best time to start using Firefox again

On a previous post, I listed ways we are being tracked without consent by search engines, browsers, mobile apps, social networks, TVs, games, devices, etc. Hopefully by now, you understand why we all should be concerned with security, ethics and privacy.

But before we discuss privacy and why we should reconsider Firefox, I thought it would be interesting to do a quick recap on web browsers, this omnipresent tool in our lives.

Market Share

Today, Firefox has about 13% market share. A huge decrease if we consider that it originates from Netscape, which had close to 80% of the market two decades ago.


To understand how that happen, let's take a quick look at the browser market history

The First Browser War

Back in 1995, Netscape sailed in calm waters until a Internet Explorer 1.0 was released by Microsoft. That was the beginning of what's called the first browser wars.

According to Wikipedia:
  • By mid-1995, Netscape Navigator was the most widely used web browser and Microsoft had licensed Mosaic to create Internet Explorer 1.0 which it had released as part of the Microsoft Windows 95 Plus! Pack in August.
  • Internet Explorer 2.0 was released as a free download three months later. Unlike Netscape Navigator it was available to all Windows users for free, even commercial companies.
  • Internet Explorer 4 changed the tides of the browser wars. It was integrated into Microsoft Windows, which gave it a large installation base.

Quickly, the Windows-IE integration brought excellent results to Redmond. Now, Microsoft had two advantages in the browser market:
  • Resources - Microsoft had way more financial resources than the relatively small company that essentially had a single product (Netscape Navigator)
  • IE was bundled with Windows - since Windows had over 90% share of the desktop operating system market, IE quickly gained adoption.

Fast dominance, Slow innovation

But the market share dominance certainly was not good for consumers. A period of slow innovation started:
Microsoft was able to dominate the market share easily as customers had it as the default browser. This also brought an end to the rapid innovation in web browsers; until 2006 there was only one new version of Internet Explorer since version 6.0 had been released in 2001.

The market remained stalled for a few years until a new contender entered the market: Google Chrome.

The Second Browser War

The Chrome browser was released on December 11, 2008, using the same WebKit rendering engine as Safari and a faster JavaScript engine called V8. Google replicated Microsoft's aggressive strategy and embedded Chrome in Android. Quickly we saw Chrome surpassing Firefox and IE to reach the top spot:

Chrome Advances

Let's be honest: Chrome indeed brought us many advances. To name some: simple bookmarks and settings synchronization, web standards support, malware blocking, plugins, incognito mode, speed, stability, desktop apps, its web store, extensions, themes, automatic web page translation, release channels, frequent release cycles, etc. That's a lot!

But remember, they weren't the first to create most of these features. Firefox (and Opera) had most of those features way before them:
  • themes;
  • a web store;
  • extension support;
  • plugin support;
  • incognito mode;
  • web standards support;
  • developer tools;
  • do not track;
  • automatic updates;

The Strategy

The history repeated itself: a company with OS dominance embed  their browser and foster it as the best for you on all its channels. Example, if you go to today using Firefox you will see:

Source: (using Firefox)

Because Chrome is embedded in Android (the most popular mobile OS), has tight integration into other Google services and to ads like the above, people keep ditching alternatives and just using Chrome.

The problem

As always, problems begin when you dominate the market share. Impartial practices, disrespect to open standards, privacy concerns and all sorts of other issues happen. Common complaints in the past are now back with Chrome:

The solution

The solution is a more open Web, not a web governed by one or two companies but internet for people, not for profit. It has to include open standards, open formats, strong security and privacy that protect the users.

It's internet for the people, not for profit


Unfortunately, the web today has problems. Security, ethics and privacy are not being respected and we should work together to improve it. And it will start with us, the users. It should start with our search engines and with our browser.


That's why my browser of choice is Firefox. Because I want my privacy respected, because I want a more open web, because I support open-source software, because it has excellent development support and it's super fast!

Enhanced Tracking Protection

To get better, Mozilla has been working on the Enhance Tracking Protection feature. Starting on Firefox 63, users will be able to block all third-party cookies so they are not tracked while browsing the web.

Fast, Lightweight and Private

Bonus: Firefox Focus

I've used many browsers on different mobile devices and honestly, never have been completely satisfied. Lately, I've been using Firefox Focus and if you want speed, privacy in a lightweight browser, you got it there:


We are being tracked without consent by search engines, browsers, mobile apps, social networks, TVs, games, devices, etc. Hopefully by now, you understand why we all should be concerned with security, ethics and privacy.

There are alternative search engines and browsers that respect your privacy. Why not try and spread the word?


See Also

Monday, October 23, 2017

Creating private git repos using Azure DevOps

GitHub's also offering free repos now! As it's the world's most popular development platform, I'd recommend using it instead of Azure DevOps.

GitHub is awesome. It dramatically changed how we share and contribute to open source sofware in the work. But, one of its limitations, especially for startups, companies or even tech professionals is that it doesn't allow private repos for free.

Fair enough, they are a company and need to pay for infrastructure, their employees and support all the amazing work that they do and all the traffic that they get. But since startups usually can't have upfront costs what's the alternative?

Introducing Azure DevOps

Azure DevOps is a private (up to 5) service that has a bunch of cool stuff for developers and startups.

I'm a big fan of Visual Studio Team Services because:
  • as, this post explains, offers private git repos for free;
  • allows us to do view repos, code, pull requests/merges online;
  • automate Azure deployment;
  • run automated tests;
  • do continuous integration;
  • do relelease management;
  • have multi branches for your baseline;
  • install extensions;
  • host your private wiki;
  • and more, way more.

Creating your Repo

But back to the repos. Being free, once you register, you can create a new project like:
Azure DevOps - Creating a new private repo

Once your project is created, you should see your Git url from which you're able to pull privately using the credentials for the account you just created.

VSTS - Your Git Url

After your first push, you should see your files there. Other nice features already mentioned above, are available in the blue bar above and I plan to review them in the future.

Personal Git Repo

One thing that was not much explored is, the benefit developers and people who produce digital content in general is using VSTS to host your personal files. Instead of using GDrive, DropBox or OneDrive, why not host all your files there? Plus, you get all the benefits already provided by git and the cloud:
  • security
  • confidentiality
  • intergrity
  • version control
  • hosted on the cloud

So, you could store your portfolio, your projects, all those txt files that are never archived and always lost =) in git, access and modify them from multiple machines and let git manage it for you - for example, rejecting one modification because you are not up to date with the repo.


So there you have it. VSTS is a very friendly, powerful and free (up to 5 users) that you can use to host your personal and professional projects. Definitely it's worth trying.

GitHub's also offering free repos now! As it's the world's most popular development platform, I'd recommend using it instead of Azure DevOps.


See Also

Monday, October 16, 2017

Securing your front-end

How secure is your front-end and how much could it be? Let's discuss it on this post.

An extremely common and dangerous flaw in web apps security is relying solely in client side security as we already discussed on this blog here and here. On this post we’ll examine the most frequent mistakes developers make and how to protect from them. But before we proceed, check our previous discussions on web application security. For all the topics on security, please click here.

Law of Security #4

We already reviewed the 10 laws of security on this blog. So, you may recall our Law #4:
If you allow a bad guy to upload programs to your Web site, it’s not your website any more.
That's probably, the main (but not the only) reason why web applications are so insecure: users are constantly submitting data to your application and changing data state. So what should we do? 
Should you trust all data being submitted to you?

Can you trust data from cookies sent to you?

Can you trust everything that you are getting in your web application layer?
Of course not.

You cannot trust client side security

Because you don’t have control of what runs on your client or how that information is being submitted - if it was manipulated or came from a different source than you expect - you should never trust the data you are getting in a request. That's why you should always re-validate in your server data sent to you. The only actual info you should trust is the session, stored on the server.

So what are the most common mistakes?

In the context of web applications, the most common mistakes web developers make are:
  • Hiding info in hidden fields
  • Relying on Http cookies
  • Relying on Url parameters
  • Using Form action urls for backend logic
  • Using the Referer header for backend logic
  • Trying to be cryptic or to obfuscate info
  • Rely purely on the ASP.Net Viewstate
  • Rely only on html form attributes
  • Only run Javascript validation

Mistake #1 - Hiding info in hidden fields

In the past, developers used to hide essential information in hidden form fields as:
<input type=”hidden” name=”price” value=”45”>
So when a post was submitted to the server, something like the below would be sent:
POST /page.aspx HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
Hacking this application is as simple as:
  1. changing the price value using devtools and resubmitting the form;
  2. issuing a post from a different tool to the server.
Luckily, this anti-pattern is no longer common anymore.


The solution here is simlpy not use hidden fields to pass sensitive information to the client. Use the Id of the product or some other type of identifier instead.

Mistake #2 - Relying on HTTP cookies

This one is less common but is still being used. Developers are still saving sensitive information in cookies, which are stored in the client side and can be easily manipulated. Consider this response from the server:
HTTP/1.1 200 OK
Set-Cookie: Discount=20
Content-Length: 100
Assuming that the Discount value set in the cookie was used to perform some calculation in the server, a malicious user could easily change that information to 100 for example, and get the product for free. Not what we want.
POST /store.aspx HTTP/1.1 
Cookie: Discount=100
Content-Length: 10


The solution here is simlpy not use cookies fields to exchange/store sensitive information to the client. If you need to save, save it on the session, on the server. Upon each request, get the session value and process it from there.

Mistake #3 - Relying on Url parameters

Often, urls are very easily hackeable:
Anyone using a web browser or curl for example could alter that url and, if that property was used to provide the price to the server, alter it and benefit from your security issue. Others can be more obscure but also open to attacks:
 Remember that security trough obscurity does not work flawlessly.


Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #4 - Using Form action urls for backend logic

Similar to mistake #3, hidden but still modifiable, form actions can also be used to pass information :
<form action="/store/submit?discount=10">
Remember, this approach could be easily manipulated.


Avoid using the query string to pass sensitive information. Even if some urls are meant to be hackeable, that's not the objective here.

Mistake #5 - Using the Referer header for backend logic

Less common, the Http Referer header can be used to simulated authentication logic in the server. For example, a request like:
GET /auth/CreateUser.aspx HTTP/1.1
Could be interpreted in the server that the user indeed came from the admin page. While this could be true for non-malicious requests, it could also be manipulated.


Avoid using the Referer for authentication as can be easily manipulated in the client side.

Mistake #6 - Trying to be cryptic or to obfuscate info

We already provided an example in mistake #3. Trying to be cryptic or obfuscating information is not a 100% reliable solution. Yes, it could be used as part of a solution but should not be the sole solution.


Be creative securing your services and avoid security trough obscurity.

Mistake #7 - Rely only on html form attributes

Html form attributes like maxlength and disabled are nice but can be easily circumvented by simply removing them in developer tools or by submitting. Example:


Keep using those components to provide more friendlier applications but never rely only on them to validate your data. Always have similar validation in the server and in the backend if necessary.

Mistake #8 - Only run Javascript validation

As in mistake #8, relying solely on javascript is highly insecure as javascript can be disable or be easily removed, altered or manipulated in the client machine.


Make use of javascript to serve more friendlier applications but never rely only on it to validate your data. Always have similar validation in the server and in the backend if necessary.


So there you are, hope this post has helped you identifying the threats your app may be facing and how you could protect against them. But only for your front end. Remember, security is complicated. Securing your frontend is just another piece in the complex effort towards a good security framework.

See Also

  For more posts about ASP.NET on this blog, please click here.

Monday, October 9, 2017

Privacy and Ethics

Security, Ethics, Privacy and Confidentiality. How's everything related on today's internet.
On a previous post we discussed Security and Ethics. Today we follow up on Ethics and Information Privacy and discuss privacy and ethics.

We're living interesting times. Around 10 years ago, the biggest ad agency of all time started tracking and reading personal information. Now it has expanded from your browser to, basically, everywhere. In case you are not sure what I mean, let's examine where tracking is happening.

Tracking is Everywhere

Tracking today happens on:
  • E-mail providers: Gmail, Outlook, Yahoo! and everyone else is reading your email. What about you? Are you reading your own emails? 
  • Search Engines: where do you think that Google, Bing, Yahoo!, et al get their money from? But wait! We seem to have an option that does not track you. 
  • Social Networks: every social network these days tracks you and reads your data. And they make a lot of money. 
  • Companies:Google, Apple, Microsoft, Facebook, Amazon and everyone else is tracking you not only by using their services but, if you're using their gadgets, you're probably being tracked there too! 
  • TVs: smart TVs like Samsung TVs are spying on viewers. 
  • Smart devices: Smart devices like these, are tracking users:
  • Virtual Assistants are tracking us: virtual assistants are also tracking their users:

Tracking and Privacy

But people are starting to note that privacy invasion is becoming or will become an issue. And that is a good thing!

Maybe this change is happening due to the impacts of the recent very important data leaks on Equifax and Deloitte, or because their personal pictures leaked online or, because their Dropbox, Adobe, LastPass, personal e-mail, mobile operator, and so many other services suffered a leak and they lost confidential information and/or were victim of a scam/phishing/smishing, etc because of those leaks. Who knows? It doesn't matter.

What matters is that the society as a whole needs to be aware of how our privacy is being disrespected and start demanding for a change. Unfortunately, neither governments nor companies are doing their share and remain doing all that's possible to get access to your data - ethically or unethically. But why is that happening?

Remember: If a product is free, you are the product

As we already discussed that on the Security and Ethics post why is this all happening? Why now?

To understand that, we first need to reflect on why would a company give their products for free? Since the majority of them are not charities,  maybe this is happening because, they make tons of money out from your data and ads

For example, here's how Alphabet (Google's parent company) makes money (88% from Ads):


And here's how Facebook makes money (97% from Ads):

US$ 106 Billion / year in revenue from Ads

As show in the previous charts, advertising generates 88% and 97% of their revenues to Google and Facebook respectively. That's USD 106.36 Billion per year from your data. All from "free products" like Facebook, Gmail, YouTube, Instagram, Android, Google Docs, etc That's why they say thatif a given product is free you are the product.

All that said, we should be concerned. Not because we're doing stuff we're not supposed to do or because we're being injected too many adds but because your information is being scanned without consent or further notice.

This is not a financial but an ethical decision. It's not about stock prices or revenue per user.

Privacy concerns have reached a limit and people are starting to realize that. You can see by google searches decreasing (more on that later), or increase in utilization of tools like DuckDuckGo (which I recommend using), even by the increase in adoption of free/open software projects like LibreOffice or Firefox that do not track your data. Not because they are better but because they are safer and more trustworthy - If I can read the code, I can trust it.

Privacy - What are our options?

Then where should we be? What should our companies be doing? This is what would like to see: companies that explicitly care about your privacy and how the internet and our lives will be better if everyone cared about that.

Here are my humble suggestions.


My browser of choice is Firefox. Yes I know there are other options but for my daily use (including development) works very well.

Search Engine

I believe my search engine shouldn't track me. That's why I use and recommend DuckDuckGo.

Operating System

I want privacy in my desktop operating system. That's why I use Fedora Linux.


I wish a modern phone that respects my privacy and runs all the apps I like. Who knows the Librem 5 or the PinePhone one day doesn't happen? I'm closing monitoring their development and it's getting close, real close!

Final Thoughts

Think about it. Think about the necessity of protecting our privacy, our families' privacy. Think about the impact it can have in 20, 30 years from now. Think how can we make the web and our lives safer for ours and future generations.

See Also

Update [Mar 13, 2018]: There is a very nice description on why you should consider migrating from LastPass here. 
Update [Mar 13, 2018]: Good News! Purism just showed some updates on the Librem 5 phone here

Monday, October 2, 2017

Interview questions for QA analysts

Hiring a QA engineer? Here are some ideas.

We were asked to provide feedback on what I would like to see in a potential QA analyst. Apart from the traditional and essential HR screening (which they know way better than us) this post is about what I would like to see in a QA engineer working in my team.

Conceptual / Basic Questions

Before everything, we're interested in knowing if the person has solid understanding on why that work is being done, why it's important and how to get good results out of it. So, we would like to know, for example:
  • In your understanding, what are the benefits of QA?
  • In your opinion, what is the role of a QA analyst in a project development?
  • What is severity and priority of a bug? Give examples;
  • Define bug triage;
  • Expect some sort of calculation using severity, number of tests, dependent tasks, etc;
  • How to Estimate Testing effort;

Define why do we test software?

Expect the answer to include thinks like:
  • the process of assuring that the product being developed is meeting all requirements.
  • the reason to perform testing is to find bugs and make sure that they get fixed.

Why do we do QA?

Expect the answer to include thinks like:
  • to find the bugs before the product is released to customer.
  • to improve the quality of the product
  • to evaluate that the product is according to requirements

When is it the best moment to start QA in a project?

Expect the answer to include thinks like:
  • A good time to start the QA is from the beginning of the project startup.
  • This will lead to plan the process which will make sure that product coming out meets the customer quality expectation.
  • QA also plays a major role in the communication between teams. It gives time to step up the testing environment.
  • The testing phase starts after the test plans are written, reviewed and approved.

What are the key challenges of software testing?

Expect the answer to include thinks like:
  • Application should be stable enough to be tested.
  • Testing always under time constraint
  • Understanding requirements, Domain knowledge and business user perspective understanding
  • Which tests to execute first?
  • Testing the Complete Application
  • Regression testing
  • Lack of skilled testers.
  • Changing requirements
  • Lack of resources, tools and training

Define a testing lifecycle?

There is no standard testing life cycle, but I like to have following phases and would expect some (if not all) of them being mentioned:
  • Test Planning (Test Strategy, Test Plan, Test Bed Creation)
  • Test Development (Test Procedures, Test Scenarios, Test Cases)
  • Test Execution
  • Result Analysis (compare Expected to Actual results)
  • Defect Tracking
  • Reporting

List different types of tests

I expect at least 5 of the following:
  • Manual testing
  • Smoke testing
  • Regression testing
  • Automated testing
  • Stress Test
  • Load Test
  • Performance Test
  • Exploratory Testing

Programming Skills

For me, developers (as sysadmins/devops engineers), would do their job way more efficiently if they knew how to programm. If she knows how to program, then I would ask:
  • to write a simple function that would, for example, write a string backwards;
  • if the person knows html, css? Exercise that a little;
  • does the person know how to hit a restful api to use browserstack, for example;
  • does the person know javascript;
  • does the person know some other scriptting language so he/she would be able to write some automation;

SQL / NoSQL Questions

I would also very interested in knowing if the person knows SQL. Not necessarily super well but well enough to deal with basic sql instructions and be independent. Also, in case you use NoSQl, ability to query your db in your query language like for example, MongoDb's query syntax or Lucene.

Software Automation Questions

In order to maximize the return of a QA in the team, test automation is a must. That said, the person needs to have enough programming skills write reproducible tests using selenium for example. Personally, I would like to know if the person: 
  • thinks automation is important?
  • knows when to automate?
  • knows what are the benefits of automating?
  • knows what are the downsides of automating?
  • have written automated tests?
  • have used selenium?
Having already working selenium is a big advantage for me.

Infrastructure Questions

Expect the answer to include thinks like:
  • What's the difference between a build and a release?
  • Yes, I have used Azure or AWS before;
  • Yes, I know how to use ftp;
  • Yes, I know how to you check if a server is up;
  • have previously used git, github?
  • have previously you/written a wiki?
  • have previously used Firebug / Chrome Dev tools 
  • is able to inspect, communicate js/html issues;

Board/Offline Exercise

While I don't think we should always use the board, it would be interesting to use the board to check how the person would improvise on two scenarios:

Scenario 1 - Write a test document based on a real use case

In this scenario, I would present a simple use case such as how to create an account on my system (please, use a simple enough for your own system):
  1. Navigate to the landing page of my site;
  2. Click on the Register button;
  3. Enter essential information to create account;
Then, ask user to:
  • List what he/she would have validated?
  • What boundary tests could be written?
  • Ask user to write test matrix;

Scenario 2 - Write a bug report

Still on the create account use case, let's assume that the system should email the new user a confirmation token but it didn't. I then would be interested in:
  • How would the person write a report in case the email didn't reach your inbox? 
  • If the person would document simple stuff as:
    • Date of the test, url, browser version, etc;
    • Steps:
      • clicked on button X;
      • Entered the following info...;
      • Clicked submit;
    • Expected result;
    • Actual result;
That is what I, as a developer, would like to see in a basic bug reported: enough information to reproduce and fix the test. Less than that may be insufficient to reproduce it meaning the probably   the candidate is not a good fit.


I consider the following, differential to have:
  • Selenium/Automation experience;
  • Cloud experience;
  • Being able to discuss technical details with the developer
  • Linux/MacOS experience;


So, this is all that came to my mind. There's probably more to it but I think that the list above covers a good, very strong candidate. Note that this is by no means a checklist but how I describe a very strong QA candidate and I would be very happy to have someone with the above skills in my team.

About the Author

Bruno Hildenbrand      
Principal Architect, HildenCo Solutions.