Device privacy and application permissions.Éibhear, 2014-12-17 19:42:00 GMT I own a Google Nexus 7, on which I have CyanogenMod installed. I use Google Play for apps. By and large, the permissions that an app 'requires' can make sense. However, sometimes they don't: So, an app for getting news wants information on my identity, my location, my personal files, my camera and microphone, the wifi connections my tablet records and what uniquely identifies my tablet. What could RTÉ want with this information? I asked them: I didn't get an answer. Not really surprising. In the meantime, I still haven't updated the app, and will probably remove it: I can see no good reason for a news-broadcasting app to have access to those private resources on my device. Here are two changes to the app-permissions architecture that I think should be implemented: Require apps to state what the resource access will be used for, and allow reporting of abuse. Apps should be required to provide a specific reason related to the functionality of the app for requiring a 'permission'. Examples would include… "Camera and microphone access required for capturing videos" "Access to personal files required to upload photos" "Location access required to identify relevant service providers near to you" and so on. This would allow users to decide whether these are valid functions for the app they're installing (e.g. I can't think of a valid use a news app would have for access to my location). This would also be backed up by a "Report Abuse" mechanism, which would have at least two purposes: To allow users to report apps to the relevant app store that don't provide sufficient information on what the "permission" is required for. To allow users to report apps to the app store that make use of the permissions that were not flagged to the user (e.g. requesting location information to identify shops close by, which the user knows about, but also to track the user's location on an ongoing basis (a la Whisper), which the user is not informed about). Allow users to decide which permissions to grant and which to deny For some reason, access to the device's location information can be denied independently – you can install apps that claim to "require" this resource, but still turn it off separately, and grant the access on an ad-hoc basis. This seems not to be something you can do with the other resources. So, if an app claims to want access to my contacts list on my device, I can't install it and then turn off that access at the device level. App stores should require applications to allow users to decide, on an ad-hoc basis, what resources on the device the app can use. In the example of the RTÉ News Now app above, I would like to install the app, and then control what it can access on my device. It's true that not allowing access to certain resources on the device would result in certain functions of the app not performing well – or at all – but if the above requirement for the app to state the specific purpose of the "permission" is implemented, then the user is fully informed of this. Some app developers would complain that they can't predict how their app would behave if not all of the "permissions" it requires have been granted. I don't accept this for two reasons. Firstly, most apps that require location information are aware of this resource being denied to them and can behave accordingly (e.g. with a message like "Your device does not permit access to its location information. As a result, we cannot provide the following functionality…"). Secondly, app developers are required to set certain configurations on the app in order to access the device's APIs. When setting these configurations, it's not a great step to require the developer to implement exception handlers for those occasions when the resources are not available. Finally, a step to join these two features would be to allow the user to decide a the time of installation which permissions to grant and which to deny. I'm looking for workÉibhear, 2014-12-16 13:08:00 GMT I am currently in the market for a job. You can find my details on this page. Please see my CV or my PGP Key page for how to contact me via e-mail. Please send me encrypted e-mailsÉibhear, 2014-10-20 09:51:00 IST I'm not a terrorist (though, I would say that, wouldn't I?). I'm not a member of a criminal gang (that too!). In fact, insofar as I can, I obey the laws of the land and any other land I happen to find myself in. Despite that, I ask that you send me encrypted e-mails, using my PGP key. I also ask the you generate a PGP key-pair so that I can send you encrypted e-mails. Let's make the spies pay real money to access our mundane conversations. If you would like assistance setting up PGP, please let me know. See an earlier post for why this is acceptable in a modern democracy. See, also, another earlier post for why encryption is important. Assumption of innocence in a democracy.Éibhear, 2014-10-20 09:49:00 IST In a proper, functioning democracy it is assumed that we all obey the law. We are all presumed to be innocent, not just "until proven guilty" of an offence, but – more mundanely – in everything that we do. In the absence of supporting evidence, the authorities are not permitted to regard anyone with suspicion. This is why the police must get warrants to spy on someone. All of this is logical, of course: in a democracy, the police ultimately work for the people. For example, through the democratic process, the people can decide to disband the police. Right now, it doesn't work that way. Many "western" governments view everyone with suspicion. They collect and share, in bulk, data on all our internet activities (the 5 eyes group, the Nine Eyes and 14 Eyes alliances). They say that access to these data is controlled by laws that respect our freedoms. But this is not valid – the mere collection of the data, to be accessed at some point in the future, is a gross invasion in and of itself. Also, it's worth noting that the laws and controls in place don't sufficiently prevent inappropriate access to these data (of, overwhelmingly, innocent people going about innocent activities!). It turns out, though, that they're finding it hard to break strong encryption. Encryption protects your privacy. And mine.Éibhear, 2014-10-20 09:47:00 IST Edward Snowden said that "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on."1 The US government still can't break good encryption. Its efforts to corrupt encryption algorithms have recently been exposed, making it completely untrustworthy on that score also. On the 12th August, 2012, the NSA collected 33,967 address books from GMail users, and 444,743 address books from Yahoo! Mail users. This difference is more than remarkable given that there were so many more users of GMail than of Yahoo! Mail. Google configured GMail to encrypt traffic by default in 2010. Yahoo! didn't do this until January of 2014. Since March of 2014, Google transmits GMail data only over encrypted connections, which will bring this snarfed-address-book figure down to 0. It's costly to collect all these data. However, storage is getting cheaper all the time. If all these data are unencrypted, retrieval is also very cheap: once all of everyone's data has been collected, it's very inexpensive to spy on someone. To get access to encrypted data is costly: as it can't decrypt the data, the NSA has to target one or another of the end-points of the communication. This is something that still can't be done indiscriminately and in bulk, like the data collection: it requires specific interference with an individual's internet activities. If everyone used encryption all the time, then the likely cost of data retrieval (requiring decryption or targeted, warrant-supported, suspect surveillance) becomes much higher. This would reduce the already infinitesimal benefit the bulk collection might provide, thereby making it harder to justify the cost of bulk collection. This may result in these programmes being discontinued. If not, at least you're actively protecting your privacy all the same. Finally, if everyone encrypts, the assumption that using encryption implies doing bad things becomes harder to justify. Footnotes: 1 He did, however, go on to make the point that "[u]nfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it." The technologies I have experience withÉibhear, 2014-04-01 22:21:00 IST For reference purposes, I'm putting my current CV's technology experiences here: Operating systems GNU/Linux (14 years); Sun Solaris, SunOS (17 years); cygwin; MS Windows; HP-UX; IBM AIX; SGI IRIX; MIPS ABI platforms; Fujitsu ICL/NX SPARC; Apple Mac OS X, 8.x. Development languages SQL, PL/SQL (20 years); Shell scripting (ksh, bash, sh, zsh) (20 years); Java (16 years); HTML/CSS (18 years); C (6 years); PHP (2 years); lisp (18 years); Oracle Pro*C (4 years); Oracle Forms (20 years); UML (3 year) Development tools and environments Java: Oracle JDeveloper 10g/11g (5 years), 9i (1 year); Eclipse (1 year); forte4j; Borland Jbuilder Oracle: Oracle SQL Developer (6 years); Oracle Developer (Forms and Reports) Release 6i, 6.0, 2.1 (19 years); TOAD (5 years); Oracle Procedure Builder (4 years); Oracle Designer 6i, 6.0, CASEStudio (1 year); Oracle Discoverer 3.1 (1 year) Others: vi (20 years); GNU Emacs (17 years); PuTTY (9 years); ArgoUML (1 year) Development technologies Oracle Database: 11g (3 years), 10g (3 years), 9i (7 years), 8i, 8.0.x, 7.0.x, 6.0.x Application Server: httpd (18 years); Oracle WebLogic 11g (3 years); Oracle AS 10g (3 years); Oracle 9i AS. Others: MS SQL Server; MySQL Revision/Source control subversion (9 years); rcs (20 years); IBM ClearCase (4 years); Microsoft VSS; CVS Other tech PGP/GnuPG (14 years); ssh (14 years); autosys (9 years); Dollar Universe Bugging of conversations by An Garda Síochána (Updated).Éibhear, 2014-03-31 22:49:00 IST When the news of the Garda Commissioner's "retirement" was revealed, it was reported to be related to the co-incidental news that some 'phone conversations into and out of garda stations were recorded, had been since the '80s, and had been stopped last November following consultations between the Commissioner and the Attorney General. There has been some concern expressed about whether conversations between prisoners and their lawyers had been recorded: a gross violation of a citizen's rights. This is unlikely. An article detailing evidence given in a criminal trial on the details of the recording. Another article on statements of the "Garda Representative Association" (the GRA) detailing the knowledge of its members on the system. It is asserted that the system was initially installed in the early 1980s to record inbound emergency calls and bomb threats. At the time in Ireland there were many bomb threats, and some actual bombings. This system was upgraded in the 1990s, and again in the late 2000s, when the storage of the recordings were digitised and centralised. It is also asserted that only designated lines were attached to the recording system, and that not all stations were involved. An article in the Guardian, for example, confirms that there's concern that legally-privileged conversations were recorded, but it doesn't refer to any specific allegation, as there haven't been any specific allegations. There are two high-profile cases where these recordings are under consideration: The first is where conversations between gardaí and witnesses in a murder investigation were recorded and are now being sought by the man accused of the murder (but never charged!) in his civil case against the state. The second is where conversations between gardaí accused of (and tried for) assault were recorded, and an attempt to present these recordings as evidence against them was denied at trial. Personally, I believe that there was no intention to record conversations between prisoners and their counsels. It would not be a surprise if such recordings had happened, and if these incidents were covered-up, but – at the moment – it would surprise me if it happened in a systematic way. Some context: The Garda Commissioner claimed not to be aware of these recordings or of the recording system until late last year. The representative body of the more senior-ranking gardaí, the AGSI, asserted last week not to have known of this system. However, the representative body of the lower-ranked gardaí claimed last week that it was known to its members, and that the lines attached to the system were marked as such, and that the lines used by prisoners were not attached. It is not logical to me that the most senior-ranking garda, who would have had to have been aware of the tender process for replacing the system in the late 2000s, and would probably have had to sign off on the budget, did not know about the system. Surely the Commissioner, regardless who it was, would have been aware of such a significant project. Given that the Garda Síochána requires it's officers to start at the bottom and work their ways up, it also doesn't seem logical to me that none of the AGSI members was aware of the system, as they would have been aware of it (according to the GRA) prior to being promoted to the senior ranks. So, assuming that one of the three assertions (the Commissioner's, the AGSI's and the GRA's) tends towards the truth, I'm inclined to accept the GRA's, which contradicts the other two. I don't for a second believe that the practice of recording conversations in this way was legal. What would be interesting to know is if it was illegal from the start, or if it became illegal since it was first installed. It appears, however, that no-one asked about its legality when it was last considered for upgrade around 6 years ago. This is likely, in my opinion, to have been an oversight, rather than deliberate. Convenient, to-boot. The whole thing is political. The government was acutely embarrassed by both the Commissioner's and Alan Shatter's rejection of the two whistle-blowers information, both its content and its implications. As the government had so steadfastly supported the Commissioner on this issue, I believe that when a completely different matter presented itself – the recording of conversations in garda stations – the government took the political opportunity to have the Commissioner removed. The concern around whether privileged conversations were recorded is, I think, political spin designed to deflect examination away from the minister and towards the Garda. Finally, I personally believe that the recently-departed Garda Commissioner behaved disgracefully as regards the whistle-blowers. It's right, and overdue, that he is gone. Similarly, I am delighted that there are moves being initiated to reform the Garda – also long overdue. However, I think it's unfortunate that he had to resign on an issue that he was in the process of setting right, an issue where the political establishment is more at fault in its neglect than that one individual. Afterword The above is an edited version of an e-mail that I had sent to Richard Stallman by way of background explanation of what was going on. Following his suggestion, I'm posting it here. Out of the office and still having funÉibhear, 2014-03-12 23:38:00 GMT When working for Oracle Corporation I was signed up for any mailing list that suggested a hint of a topic that I might have been interested in. Consequently, I would have received e-mails from anywhere, and e-mails that would have been received by any one in the then-40,000 staffed company. As is expected, too, I subscribed to the convention of setting up automatic replies for when I was out of the office. In September of 1999, I went on a trip to the U.S., leaving behind the following out-of-office automatic reply. Subject: Oh well... Hi, It is with a sense of great sadness and regret that I say now that I am unable to respond to your mail immediately. It is with greater sadness, etc. that I tell you I'm on holiday until the 22nd of September. And it is with the greatest bla, bla, that I ask you to contact my manager [Name omitted] at [e-mail address omitted] if you require urgent assistance. Go raibh maith agat, Éibhear =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Éibher Ó hAnluain, SGI/MIPS Tools PLD, Tel: +353 1 8033xxx Oracle Corporation, Fax: +353 1 8033xxx European Porting Centre, Block C, Maretimo Court, Temple Road, Blackrock, All mammals have hair. Co. Dublin, IRELAND. Whales are mammals. Therefore, whales have hair. E-mail: firstname.lastname@example.org Shave the whales. http://sulla.ie.oracle.com/ -Dogbert =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Of course, I didn't redact the names and numbers in the original]. [And, of course, respect to Scott Adams for the Dogbert quote, coming from a very old Dilbert cartoon.] [Finally, "Go raibh math agat" is Irish for "Thank you".] I'm particularly proud of that one, even though I haven't used it since. Anyway. I came back to the office on the 22nd September, and – if memory serves me well – nothing special was waiting for me until I came across an e-mail from my manager (the above-redacted) with the following: good man, this is profiling at the right level!. "What?!" I was saying. So I looked back through the thread. The original e-mail was a request for assistance in setting up an application web server to support 128bit SSL, and was Cc'd to one of mailing list I was on. There was a reply from the Vice President of Corporate Affairs, Cc'ing the Director of Global Trade Compliance and, as well as the same mailing list, regarding export restrictions on crypto technologies and how the latter needs to be consulted. Of course, she got my auto-reply. Forwarding it on to the Directory of Global Trade Compliance, she says… This is the most different "I'm on vacation" auto reply that I've ever received Also note the note on the whales at the bottom His response to her: What do you think "Go raibh maith agat" means? So, she e-mails my manager with What does Go raibh maith agat, > Éibhear mean? Which is how it came to me. I forwarded it on to my then girlfriend (now wife!) and it seriously did the rounds. It gain such notoriety that when I was leaving Oracle (on the 7th January 2000), it was read out to the company at the "ceremony" for my departure. The main reason I so like my original message is the combination of the increasing intensity of my regret as I make the three various points while the care and "professionalism" with which I make the points decreases. I still view it as my best piece of flippancy. It's nearly like grieving...Éibhear, 2014-02-02 22:38:00 GMT There must be five stages for the religious right to lose a policy that used to belong to it: "That's blasphemy!" "It's unnatural!" "Society will completely break down!" "It's just my opinion, but if you disagree with it you're being mean." "La la la la! I can't hear you!" The main 2 differences between this and the 5 stages of grief are that there's hardly ever any acceptance, and it's nearly always denial. Transferring your secret PGP key from one device to another.Éibhear, 2014-01-26 21:15:00 GMT I use PGP a lot, primarily for encrypting files or file-portions that I might want not to slip into the wrong hands. I also use many different devices (3 personal laptops, 1 Nokia N900, 1 Nexus 7 tablet, and so on), and I like to access the data I'm looking for from the device I may currently be on. This means I need my PGP secret key available to me locally: it's unwise to access a secret key across a network. If you're copying the key from one device to another across a network only you have control over, then export; scp; import may be sufficient. However, if you're not certain about the security of the pipes between your two devices, you need to take a bit more care. Here's how I do it, which involves a little more work, but is a lot more secure. The steps below use GNU Privacy Guard (a.k.a. GnuPG), but the actions are rather fundamental to a mature PGP tool, and should be easy to perform with what you're using. Install a PGP tool onto your device. Generate a new private/public key pair using this tool. Set the expiry date for this new key to tomorrow: you won't need this key again once all of this is done. eibhear@bondi:~$ gpg --gen-key gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 1 Key expires at Mon 27 Jan 2014 14:41:38 GMT Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <email@example.com>" Real name: Temp Transfer Email address: firstname.lastname@example.org Comment: Temp to get real key across You selected this USER-ID: "Temp Transfer (Temp to get real key across) <email@example.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. <<key-generation guff about entropy and all that.>> gpg: key AD26C065 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2014-01-27 pub 4096R/AD26C065 2014-01-26 [expires: 2014-01-27] Key fingerprint = A3CF 353E F184 AE8A 2F7A D2E5 51E3 EB22 AD26 C065 uid Temp Transfer (Temp to get real key across) <firstname.lastname@example.org> sub 4096R/BA51E94A 2014-01-26 [expires: 2014-01-27] eibhear@bondi:~$ Export your new public into a file (I generally us the ASCII format for ease of handling). gpg --export -a email@example.com > tmpPublic.asc E-mail key new public key to an address whose account you can access from the device with your secret key. E-mail is the easiest for me, but all you want to achieve is to get this public key across. From the device with the secret key you want to get, download and import this new public key. eibhear@rome:~$ gpg --import ~/tmp/tmpPublic.asc gpg: key AD26C065: public key "Temp Transfer (Temp to get real key across) <firstname.lastname@example.org>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) eibhear@rome:~$ Now, export your secret and encrypt it using the newly-imported public key. Using the gpg tool, I export it to stdout and encrypt that stream. That way, the data aren't stored on the filesystem, even temporarily. If you can't do these in one step, it's probably safe to export your key to a file and to encrypt the file and then to remove the original file (as long as you're confident you have full control over the device, and as long as you use a strong passphrase to protect your secret key!) eibhear@rome:~$ gpg -a --export-secret-key GMail | gpg -ea -r email@example.com > ~/tmp/secretKeyEnc.asc gpg: BA51E94A: There is no assurance this key belongs to the named user pub 4096R/BA51E94A 2014-01-26 Temp Transfer (Temp to get real key across) <firstname.lastname@example.org> Primary key fingerprint: A3CF 353E F184 AE8A 2F7A D2E5 51E3 EB22 AD26 C065 Subkey fingerprint: A526 1366 B691 CF65 C317 88F0 C29C ABE5 BA51 E94A It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y eibhear@rome:~$ Send this newly encryped file to your new device (an e-mailed attachment is normally what I use). Go back to your new device now, and download the file. Decrypt the file, using the temporary secret key, and then import the decrypted key data. Again, if you're using gpg, these two steps can be combined into one. eibhear@bondi:~$ gpg -d ~/tmp/secretKeyEnc.asc | gpg --import You need a passphrase to unlock the secret key for user: "Temp Transfer (Temp to get real key across) <email@example.com>" 4096-bit RSA key, ID BA51E94A, created 2014-01-26 (main key ID AD26C065) gpg: encrypted with 4096-bit RSA key, ID BA51E94A, created 2014-01-26 "Temp Transfer (Temp to get real key across) <firstname.lastname@example.org>" gpg: key F2177106: secret key imported gpg: key F2177106: public key "�ibhear � hAnluain (GMail) <eibhearDOTgeoATgmailDOTcom>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 eibhear@bondi:~$ Confirm that the key has been imported. eibhear@bondi:~$ gpg --list-secret-keys /home/eibhear/.gnupg/secring.gpg -------------------------------- sec 4096R/AD26C065 2014-01-26 [expires: 2014-01-27] uid Temp Transfer (Temp to get real key across) <email@example.com> ssb 4096R/BA51E94A 2014-01-26 sec 1024D/F2177106 2003-08-26 uid �ibhear � hAnluain (Gibiris) <XXXXXXXXXXXX> uid �ibhear � hAnluain (GMail) <eibhearDOTgeoATgmailDOTcom> ssb 2048g/532B1905 2003-08-26 eibhear@bondi:~$ Lastly, delete the temporary secret key. eibhear@bondi:~$ gpg --delete-secret-and-public-key firstname.lastname@example.org gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. sec 4096R/AD26C065 2014-01-26 Temp Transfer (Temp to get real key across) <email@example.com> Delete this key from the keyring? (y/N) y This is a secret key! - really delete? (y/N) y pub 4096R/AD26C065 2014-01-26 Temp Transfer (Temp to get real key across) <firstname.lastname@example.org> Delete this key from the keyring? (y/N) y eibhear@bondi:~$ You're now ready to use your main secret key from your new device.