Mass surveillance and the need for more encryption 
Monday, June 24, 2013, 11:03 PM
Posted by Administrator
Once you understand how Internet communications work on the technical level, it becomes obvious that spying is possible. As data flows between computer systems, anyone with full access to the involved computers can potentially read or copy all unprotected information.

For example, a criminal, working as an computer administrator at an Internet Service Provider company, could spy on customers, potentially reading corporate secrets that are exchanged by email, and could secretly sell such information to the customer's competitors.

There are many additional scenarios where it's reasonable to ensure that information remains protected against spying. And the most important scenario is that people have the right of privacy.

With the recent events we (apparently) have learned, that spying isn't limited to those with criminal intentions, but that spying is also performed by secret government agencies, justified as being necessary for providing security to the people.

At the very least, this (apparently) confirms what has been rumoured or anticipated.

However, it depends on the point of view, whether you call such spying legal or criminal. If you have two countries A and B, and each of them spies on the other one, then probably each of them calls their own activities legal, and describes the actions of the other country as criminal.

What happens if you're a citicen of country A, and both countries A and B are technically able to spy on you? Even if you decided that it might be acceptable for your own country to spy on you for the purposes of national safety, neither you nor your government might like the idea that your data is being accessed by country B.

This is one example why it makes sense to protect your information, making it either impossible or very difficult (and requring a targeted effort) to read your information, instead of allowing them to read your data with zero cost.

The above should show why it's in your own interest to invest resources into the protection of your data.

After the existence of the Prism and Tempora systems became known, it triggered the question, whether government agencies should be allowed to do it or not. That's a good question, and in my opinion, in democratic countries, a government should be obligated to inform its citicens about such operations, enabling the people to use their voting powers to acknowledge or resist such operations.

However, there are arguments why it might be irrelevant what the public decides. Even if country A decided that mass surveillance performed by country A is unacceptable, you still risk being spied on by country B. For example, an Internet Provider operator could be controlled by country B, but offering services in country A. Or country B has agents working at an Internet Provider in country A, that help to spy.

We can also look at it from another angle. I don't know how realistic the numbers are, but I've read that several hundert thousand people might have access to the data being processed by the Prism/Tempora systems. In my opinion, it's very likely that at least some of those people are foreign agents. As we have seen, people with high security clearance may become whistleblowers. Essentially, you don't know what people might do, regardless how many background checks you've made. It wouldn't surprise me if a few employees of such agencies secretly query the databases, on demand, selling the information to a different country. Since this action has a much lower risk for detection than becoming a whistleblower, I don't think we can rule out this possibility. I'd conclude, by spying in your own country, you enable foreign agents to benefit from the information, too.

In my opinion, because spying is technically possible, it won't be sufficient to implement laws that forbid it.

The only solution is to make spying impossible, or very difficult. And that's what all of us should be doing, by using encryption technology and, where encryption isn't possible, such as in places dedicated to sharing information with other's, at least following a strategy of data austerity, and only providing as much information as absolutely necessary (or deliberately considered harmless).

You might say, by encouraging people in country A to use encryption technology, you make it more difficult for the secret agency in country A to do their job. Well, I think that's exactly what we should do, and is acceptable, because more difficult doesn't mean impossible.

The state authorities will still have their classic ways of investigation. They still can secretly tap a suspect, for example by secretly entering an apartment and physically installing a keyboard logger on the target's computer system, installing video cameras, etc. However, because of the required effort and because of limited resources, very likely this will only be done to real suspects, not to every citizen.

Since individual people cannot control what the powerful agencies might do, their only chance is to protect themselves.

As a consequence, in my opinion, we should actively teach all Internet users how to use encryption enabled software, and how to avoid centralized service providers, and improve the software used by people, to make it more difficult for agencies or criminals to automatically spy on them.

view entry ( 7723 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 2.9 / 6786 )

Internal Microphone on Lenovo T510 and Linux 
Wednesday, May 29, 2013, 07:50 PM
Posted by Administrator
The internal microphone on my Linux system didn't work. In order to enable it, I had to disable the driver for the internal analogue (classic) modem.

In order to check, if you might potentially be affected from the same issue, open a terminal, and run the following command:
* lsmod |grep snd_hda_codec_conexant

If the above command produces output, then your system has that particular Linux kernel module loaded, and might be blocking the internal microphone.

The solution is to prevent the system from loading the kernel module on startup. You can use the following commands:
* echo "blacklist snd_hda_codec_conexant" > /tmp/modem-blacklist.conf
* sudo cp /tmp/modem-blacklist.conf /etc/modprobe.d/

Now restart your computer and test if your microphone works.

view entry ( 3873 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1261 )

Detecting the Cinnamon Desktop using a D-Bus property and Vala 
Saturday, March 16, 2013, 11:45 AM
Posted by Administrator
Gnome-Shell and Cinnamon behave differently, which includes how tray notification icons are being treated. While Cinnamon uses the classic approach of showing them, the Gnome-Shell developers would like to see them avoided.

Therefore it's currently the application's job to figure out what to do. Unfortunately Gnome-Shell and Cinnamon have many similar properties from an application's point of view, so it's necessary to find a way to distinguish them from within the code.

Thanks to Bastien Nocera and Shaun McCance for suggesting the use of D-Bus to distinguish between Gnome-Shell and Cinnamon.

As I was driven to fix the deja-dup backup tool, I was looking for a solution in the Vala programming language, and below is some code to detect a running Cinnamon desktop environment. I tested that the code works in Cinnamon version 1.4.0 and 1.6.7.

[DBus (name = "org.Cinnamon")]

public interface cinna : GLib.Object {
public abstract string CinnamonVersion { owned get; }

int main (string[] args) {
string cv;

try {
cinna c = GLib.Bus.get_proxy_sync (BusType.SESSION, "org.Cinnamon", "/org/Cinnamon");
cv = c.CinnamonVersion;
} catch (Error e) {
stderr.printf ("%s\n", e.message);
return 1;

if (cv == null) {
stdout.printf ("not running cinnamon\n");
else {
stdout.printf ("running cinnamon version %s\n", cv);

return 0;

I'd like to thank Evan Nemerson who helped me understand the correct syntax to access a D-Bus property using Vala.

Update March 18
Below is a reverse test, which tests for a property found in Gnome-Shell:

[DBus (name = "org.gnome.Shell")]
public interface GnomeShell : GLib.Object {
public abstract string ShellVersion { owned get; }

int main (string[] args) {
string gsv = null;

try {
GnomeShell gs = GLib.Bus.get_proxy_sync (BusType.SESSION, "org.gnome.Shell", "/org/gnome/Shell");
gsv = gs.ShellVersion;
} catch (Error e) {
stderr.printf ("%s\n", e.message);
return 1;

if (gsv == null) {
stdout.printf ("not running gnome-shell\n");
else {
stdout.printf ("running gnome-shell version %s\n", gsv);

return 0;

view entry ( 4612 views )   |  permalink   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1233 )

Fix empty list of RSS feeds in Evolution 3.6 
Monday, January 28, 2013, 02:59 PM
Posted by Administrator
I recently upgraded my system from Fedora 17 to Fedora 18, and afterwards Evolution 3.6 (using the evolution-rss plugin) had an empty list of feeds in edit/preferences/news+blogs.

Thanks to Lucian Langa who pointed me to a manual migration script, which fixed the issue for me.

In order to compile and use it:
- download and save the migration script

- make sure you have packages gcc, GConf2-devel and gtk2-devel installed (you might need additional packages to compile it)

- open a terminal and change to the directory where you saved the .c file and run the following command:
gcc `pkg-config --cflags gtk+-2.0` `pkg-config --cflags gconf-2.0` `pkg-config --libs gtk+-2.0` `pkg-config --libs gconf-2.0` -o evolution-rss-migrate-feeds evolution-rss-migrate-feeds.c

- if no errors are shown, you should now have the executable. Check using
ls -l evolution-rss-migrate-feeds

- quit evolution. Now run the migration script

(no output will be printed)

- Start evolution, go to edit/preferences/news+blogs, and you should now see the feeds that you had configured in evolution 3.4.x prior to the upgrade

view entry ( 4433 views )   |  permalink   |  related link   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1185 )

Gnome 3.6 scrollbar behavior 
Saturday, January 19, 2013, 03:39 PM
Posted by Administrator
Gnome 3.6 has changed the default behavior of scrollbars.

For as long as I can think, since I've started to use computers with graphical user interfaces, I've been used to clicking the empty space below (or above) a scrollbar's position indicator, in order to scroll down (or up) exactly one page.

That classic behavior has been changed in Gnome/Gtk, the new behavior is to jump to an absolute position, based on exactly where you click.

I don't like the new behavior, I believe changing the default was an unfortunate decision. I'm using multiple computers, and in my opinion, if I cannot predict the way the computer will react to clicks, because each computer might have a different default, that's a serious regression in usability.

I'm documenting how the classic behavior can be configured, thanks to Ray Strode for telling me how to:

Edit file ~/.config/gtk-3.0/settings.ini and add the following:

gtk-primary-button-warps-slider = false

view entry ( 4041 views )   |  permalink   |  related link   |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1747 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | Next> Last>>