Posted on

Australia Data Retention Scheme Stalled

It’s been reported in the mainstream media that the Australian Data Retention Scheme has been referred to another committee, effectively delaying it to after the next election.  The Scheme was part of a broad review of the various security agencies powers and how to streamline them.  The initial paper originally stated that retention would be for up to 2 years for parts of the data set, without really specifying what the data was.

There has been various ideas of what this data is, depending who you ask and when.  Some documents state it is only the accounting data; that user X used IP address Y at time Z, while others state it is email logs and a third have been the previous two plus web logs.

There are many problems with a scheme such as this.  2 years of everyones web-browsing history is a desirable target for both legitimate and illegitimate access to that data.  Leaving aside would the access to the agencies get the right level of access; who else would want this data?  I’m sure that AFACT (Australia’s MPAA effectively) would like this data to go trawling.  The recent exposure of AAPT‘s data by Anonymous shows that there may be some other means of obtaining this data.

I actually wonder, if the scheme was in, what they would find?  Take email for example; my email leaves my computer and directly communicates with the destination mail server. If someone pulled my email records they’d show very little information.  If it is too hard to run your own mailserver, I’m sure the enterprising no-gooders that they are so interested in finding can work out how to buy a remote mailserver somewhere.

If that’s too hard, there’s always gmail with https, or VPNs, or TOR, or.. well there are plenty of options.  It probably comes down to how resourceful (if thats the word) people are.  By the way, mentioning https reminded me of the great little plug-in called HTTPS Everywhere by EFF.

I’m glad to see that this legislation is stalled. To me the paperwork I saw appeared to be saying that they got some bad guys with what powers they have so they will catch more with more powers; therefore more powers are good, OK?  It’s a rather simplistic view of the world.  My only worry is its not stopped, just stalled so it might be re-animated in future.

 

Related articles
Enhanced by Zemanta
Posted on

Context sensitive menus with GtkTreeView

A project I now maintain called GJay uses the GTK+ toolkit and has a GtkTreeView that shows the directories and the songs in them.  I was wanting to add a context sensitive menu on that view so that you could do things to the item you have right-clicked on; generally file specific things like give me information about this song or queue it to play.  My only problem was, how to do it?  A few Google searches showed things that were almost, but not quite, what I was after.  The main problem being either the documentation was incomplete or it assumed I was after the selected field (the row I may of left-clicked on) and not the one I right-clicked on to get this event.

This GtkTreeView uses a store where NAME_COLUMN is defined at 0, meaning it is the first column. The program uses this column to store the filename of the song.

So first I needed to create an event to kick things off, we need to connect the “button-press-event” to our tree_view, which calls a function in this case view_on_button_pressed.

 g_signal_connect(tree_view, "button-press-event",
   G_CALLBACK(view_on_button_pressed), NULL);
gboolean view_on_button_pressed(GtkWidget *tree_view,
                                GdkEventButton *event,
                                gpointer user_data) {
  GtkTreeSelection *selection;
  GtkTreePath *tree_path;
  GtkTreeModel *tree_model;
  GtkTreeIter tree_iter;
  gchar *name;

  if (event->type == GDK_BUTTON_PRESS && event->button == 3) {
    tree_model = gtk_tree_view_get_model(GTK_TREE_VIEW(tree_view));
    if (gtk_tree_view_get_path_at_pos(GTK_TREE_VIEW(tree_view),
          (int)event->x, (int)event->y,
          &tree_path, NULL, NULL, NULL)) {
      if (gtk_tree_model_get_iter(tree_model, &tree_iter, tree_path)) {
        gtk_tree_model_get(tree_model, &tree_iter, NAME_COLUMN, &name, -1);
        g_print("rc name is %sn", name);
      }
    }
  }

So a breakdown of what my callback is doing:

  • Line 1:The callback’s widget is the GtkTreeView widget we connected the signal with
  • Line 10:Checks the event was a button press and button #3 (right button)
  • Line 11: Find the GtkTreeModel from the given GtkTreeView
  • Lines 12-14: Get the GtkTreePath that the right-click was sitting at by using the event coordinates.
  • Line 15: Convert the GtkTreePath into a GtkTreeIter
  • Line 16: Find the actual value we put into this row.

The program, now that it knows the song title, can then go off and generate a menu for that song.

Related articles
Enhanced by Zemanta