Daily Archives: April 15, 2009

IT Politics, Security, Technology, Web

User data probably for sale

It’s time for a little “doomsday prophesy”.

Already seen happen

As was reported last year in Sweden, mobile operators here sell customer data (Swedish article) to companies who are willing to pay. Even though this might be illegal (Swedish article), all the major Swedish mobile phone operators do this. This second article mentions that the operators think this practice is allowed according to the contract every customer has signed, but that’s far from obvious in everybody else’s eyes and may in fact not be legal.

For the non-Swedes: one mobile phone user found himself surfing to a web site that would display his phone number embedded on the site! This was only possible due to the site buying this info from the operator.

While the focus on what data they sell has been on the phone number itself – and I do find that a pretty good privacy breach in itself – there’s just so much more the imaginative operators just very likely soon will offer companies who just pay enough.

Legislations going the wrong way

There’s this EU “directive” from a few years back:

Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC

It basically says that Internet operators must store information of users’ connections made on the net and keep them around for a certain period. Sweden hasn’t yet ratified this but I hear other EU member states already have it implemented…

(The US also has some similar legislation being suggested.)

It certainly doesn’t help us who believe in maintaining a level of privacy!

What soon could happen

There’s hardly a secret that operators run network supervision equipments on their customer networks and thus they analyze and snoop on network data sent and received by each and every customer. They do this for network management reasons and for such legislations I mentioned above. (Disclaimer: I’ve worked and developed code for a client that makes and sells products for exactly this purpose.)

Anyway, it is thus easy for the operators to for example spot common URLs their users visit. They can spot what services (bittorrent, video sites, Internet radio, banks, porn etc) a user frequents. Given a particular company’s interest, it could certainly be easy to check for specific competitors in users’ visitor logs or whatever and sell that info.

If operators can sell the phone numbers of their individual users, what stops them from selling all this other info – given a proper stash of money from the ones who want to know? I’m convinced this will happen sooner or later, unless we get proper legislation that forbids the operators from doing this… In Sweden this sell of info is mostly likely to get done by the mobile network operators and not the regular Internet providers simply because the mobile ones have this end user contract to lean on that they claim gives them this right. That same style of contract and terminology, is not used for regular Internet subscriptions (I believe).

So here’s my suggestion for Think Geek to expand somewhat on their great shirt:

i-read-your-everything

(yeah, I have one of those boring ones with only the first line on it…)

Development, Open Source

C Code Commandments

3 Comments

I’m an old school C programmers guy and I stay true to some of the older and commonly used rules present in many open source and similar projects. Since I sometimes rant about this to people, I thought I’d amuse my surrounding by stating them here for public use/ridicule. Of course heavily inspired by the great and superior The Ten Commandments for C Programmers. My commandments are not necessarily in any prio order.

Thy Code Shall Be Narrow

Only in very rare situations should code be allowed to be wider than 80 columns. I want my two or three windows next to each other horizontally and still see the code fine. Not to mention the occasional loading up in an editor in a 80 columns terminal and that is should be possibly print nicely (for reviews etc). Wide code is also harder to read I think, quite similarly to how very wide texts in web pages etc aren’t kind to your eyes either.

Thou Shall Not Use Long Symbol Names

To be able to keep the code easily readable by human eyes so that you quickly get an overview and understand things, you simply need to keep the function and variable names fairly short. Not to mention that the code gets harder to keep within 80 columns if you use ridiculously long names.

Comments Shall Be Plenty

Yes, this is something we know everyone says and few live up to. In statistical analyzes of my own C code I usually reach around 25-27% comments and I’m usually happy with that amount. Comments should explain what is otherwise not obvious in the code.

No Hiding What’s Really Happening

I’m not a fan of overloaded operators or snazzy macros that do fancy stuff without it being noticeable in the code. It should be clear when reading the code what it does. That’s also one of the reasons you don’t catch me doing a lot of C++ work…

Thou Shalt Hunt Down and Kill Compiler Warnings

Compiler warnings may be significant and in some cases they are not. Either way, it is our duty to silence them at all times. Firstly because it is often simpler to fix the code to not warn than to figure out if the warning is indeed right or not, but perhaps primarily because it makes it harder to see new warnings appearing if the old ones have been left there.

Write Portable Code Unless Forced by Evil

You may first believe that your code will live on forever on this single platform with this single compiler, but soon and very soon you will learn otherwise. Then you will cheer this rule as it makes you consider unaligned memory accesses, assuming byte-order of binary data or the size of your ‘long’ variable type.

Repeat Not, Use Functions

I see a lot of “copy and paste” programming in my daily life and I’ve learned that sooner or later such practices lead to sorrow. If you paste the same code on multiple places it not only makes it repetitive and boring to update it when an API or something changes, more seriously it increases the risk that you address bugs only on one out of many places or that the fix differ etc. It also makes the code larger and thus harder to follow and understand.

Thou Shalt Not Typedef Away Pointers

A really nasty habit to be seen in some source codes is when people use typedefs to define their own types that is simply a pointer to something. Like with ‘typedef struct whatever * whatever_t’. While I’m in general against excessive typedefing, I’m fine with them in many cases but not when used to hide pointers to look like “ordinary” types. It makes code harder to follow.

Defines, no fixed numbers

Code that relies on zero and non-zero can get away without this, but as soon as you start relying on more numbers in the code you must start using #defines or possibly enums to make them appear with names in the code. Using names is more clever than hardcoded numbers since you can avoid having to explain the number in a comment, and of course it’ll be easier to change the actual number in the code at a later point without it being a painful search-and-replace operation.