DMail And The False Sense Of Security

Email is around  since several decades. Nevertheless, it is still one of the most used form of communication, especially in business. Therefore the security of an email message is really important.

Over the years, different methods have been implemented. Lately also the guys behind Delicious have implemented their solution, starting a new service called DMail. The claim is:

Self-Destructing Email
Finally, sent email has a delete button

At present, the service is in Beta version, and it's free, so I've tried it to understand how it works.

I have to admit it: I was pretty skeptical... and I was right. But first things first.

How It Works

Let's start by saying that it works only on top of GMail (not even Inbox) and only with Google Chrome/Chromium. In fact, by clicking on the button "Try it now!", you are redirected to the extension page in the Chrome Web Store.

Once installed, you can see the DMail logo on the top-right part of the GMail screen. The same logo appear in the compose window near the enable slider and the combo to choose the expiring time.

You can write your email and send it like you normally do, but what happens is that the message is not sent to the recipient but it's stored in a DMail server in a encrypted form (or so they say).

The addressee receives an email with a link to the message that is unencrypted on the fly just for him. When the time expires or if the sender decides to destroy the message, the link will show the following message:

Message Unavailable
This message is no longer available for viewing..

It seems cool, right? Uhm, not so sure...

Security?

Let's see where the pitfalls are. First, the mail with the link to the encrypted message is (obviously) unencrypted and it contains the codes (KEY and CLIENT) that I suppose are used to decode the message. This means that, if the email is transmitted over an insecure connection, the message should be considered compromised.

Moreover, the email can be forwarded - and also from the forwarded email is possible to access the message.

You can argue that once the message has expired, no one is able to see it. This is also what Snapchat promised, right? The countermeasures are quite simple. You can save the page with the message from your web browser or take a screenshot or a photo. And make the destroyed message live forever.

Besides, you must remember that you messages lay on someone else's computer that can be compromised and your data be stolen.

Conclusions

To me, this service is pretty useless. The idea is good but, at present, I don't think the right technology exists to provide what they promise in a really secure way.

DMail, email, security Friday, July 31, 2015 No comments

Recursion And Stack Overflow

 
Few days ago, the Twitter account of StackOverflow (the famous site of technical questions and answers) has published the following tweet:

int main() { return main(); } pic.twitter.com/SfQv6E8wht

— Stack Overflow (@StackOverflow) 22 Luglio 2015

The intention was to recall the name of the site by presenting a situation that every developer has been warned about.

Of course I got the pun but a light bulb has turned on in my mind: tail calls. Some years ago I've read something about it on the blog of Gustavo Duarte: Tail Calls, Optimization, and ES6.

Do It Yourself

It's not that I don't trust Gustavo, but I've tried to do my own test (on x86-64bits with gcc 4.8):

#include <stdio.h>

int main()
{
        fprintf(stderr, "Go!\n");
        return main();
}

Compiled with the optimization enabled:

gcc -O2 -o so so.c

Launching the executable so (that stands for stack overflow), it prints a never ending series of "Go!", without crashing. The explanation is exactly the same Gustavo presented in his old post: the compiler optimizes this call with a jump. So basically it transforms a recursion in a loop. This is clear looking at the disassembled code, with the following command:

objdump -d so

This is the result (leaving only the interesting part):

0000000000400480 <main>:
  400480:   48 83 ec 08            sub    $0x8,%rsp
  400484:   0f 1f 40 00            nopl   0x0(%rax)
  400488:   48 8b 0d b1 0b 20 00   mov    0x200bb1(%rip),%rcx   # 601040 <__TMC_END__>
  40048f:   ba 04 00 00 00         mov    $0x4,%edx
  400494:   be 01 00 00 00         mov    $0x1,%esi
  400499:   bf 14 06 40 00         mov    $0x400614,%edi
  40049e:   e8 cd ff ff ff         callq  400470 <fwrite@plt>
  4004a3:   eb e3                  jmp    400488 <main+0x8>

As you can see, fprintf is mapped with a callq to fwrite, while the recursion is made by the instruction jmp

Conclusions

Basically there are three considerations that can be done:

1. Gustavo was right;
2. compilers are smarter than you think;
3. the same thing I've wrote about goto and do-while loops apply also for recursion.

Image taken from Wikimedia Commons (public domain).

C, compilers, development, stackoverflow Sunday, July 26, 2015 No comments

You Need A Bug Tracker

For some years I've worked without the support of any bug tracking system (BT for short) but now it's hard to do without. I think that its standard usage is clear enough, otherwise Wikipedia has a good explanatory page. In this post I want to cover some more things you may find it useful for.

Your Historical Memory

Sometimes bugs tend to represent over time. In this case they are called regressions. A good starting place when you want to create regression tests is your bug tracker. All the bugs with steps to reproduce and support files are stored in a single place. The QA Team just needs to take the information from there and put them into the automatic test suite (because you use it, right?).

Besides, sometimes you choose to not fix some bugs for a variety of reasons. If there is some sort of workaround to get rid of them, it must be registered in your BT for future reference.

Not Only For Bugs

Nobody said that you cannot use it for keeping track of the development of new features. Many BTs provide separated categories for bugs and new implementations. In this way it's easier to filter them and make statistics to be shown to your manager.

Decent Bug Trackers give you the possibility to set the priority for each entry. Using this feature, you can easily manage the work of your team.

And why not using it also for something unrelated to programming, such as the documentation?

Make It Public

Warning! This suggestion should be carefully evaluated by the highest levels of your company because it can be potentially dangerous.

Generally speaking, letting your users signal bugs and requiring new features may increase the level of loyalty. On the other hand, your company must be well organized in order to quickly answer every request in a proper manner. And sometime the proper manner may be "we won't do that". Of course, too many "no" may give a bad idea of your company to potential customers.

Another issue is that one of your customers may feel like you are taking more care in resolving issues signaled by other customers.

However, if your company agrees on this point, it's better to have separated bug trackers for users and developers.

Conclusions

A bug tracking system is one of the most useful things that your company can adopt to manage defects and the project workflow.


Image by Messer Woland from Wikimedia Commons licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.

bugs, management Tuesday, July 21, 2015 No comments

About Projects Driven By Users

I do believe that users are the most important part of a project. Really. They can provide you useful feedback, great ideas and suggestions on what can make your product better. Unfortunately the previous sentence only apply to few users.

In my experience, users are only interested to their own small needs. They don't care about your product but just to solve the problem they have today. More than once it happened to me that a customer asked me a change on a software to solve an urgent issue and few days later he wanted me to roll back the modification.

Having the development of your product driven only by users' requests is the fastest way to go crazy.

Feedback and hints are important but must be taken with a grain of salt. Don't abdicate the development of your product to users and customers.

A similar situation apply to tests. I've heard sometimes "The customer will do the tests." It may be OK if we are speaking about a small customization. But in all other cases, the result will be terrible. A user will test only the three or four functions that uses the most and, if something is not working properly, it's probable that he will find a quick workaround instead of spending half of an hour on the phone with your customer service. And even if they spend some time to report the issues to you, it's very likely that most of the messages would be like those reported in this page.

Again, users are not interested in your product. They only want a tool to solve their own problems and you should just thank them because your software has been elected. But don't ask them to do your job.

working life Monday, July 06, 2015 No comments

Code Review

During past few weeks, I've been reviewing an old codebase. Some functions were in place since 2008. You may think that those functions are bug-free. After seven years of usage, every issue should have emerged.

But the story is different. The number of errors I've found is impressive. Memory leaks, files left open, checks on conditions that can never be true (see also the last Horror Code), and, worst of all, logical errors. What do I mean with logical errors? Let me give you an example.

A Logical Error

There is a file descriptor declared as a global variable (OK, this could be considered a logical error too, but please keep reading) and a function that does some elaborations and then writes the result in a file descriptor. Among the parameters of this function there is a file descriptor... unfortunately it is never used. The writing is done on the global variable.

Everything works fine just because the global fd is the only one used in that program. What if in the future someone would have used that function passing a different fd? How long it would have take to find the bug?

By the way, the compiler has signaled with a warning that a parameter of the function was not used but nobody cared. You should always take care of warnings!

Conclusions

A code review is always a good thing to do. Probably you won't find big bugs but surely the stability and the quality of your software will be improved. And maybe that strange situation so difficult to reproduce will never be reported again.

Image by Randall Munroe licensed under a Creative Commons Attribution-NonCommercial 2.5 License.

personal, working life Friday, June 26, 2015 No comments