Posted
by
EditorDavid
on Sunday February 04, 2018 @11:34AM
from the developing-negatives dept.

An anonymous reader shares an article from the security editor of ZDNet:
A year after photojournalists and filmmakers sent a critical letter to camera makers for failing to add a basic security feature to protect their work from searches and hacking, little progress has been made. The letter, sent in late 2016, called on camera makers to build encryption into their cameras after photojournalists said they face "a variety of threats..." Even when they're out in the field, collecting footage and documenting evidence, reporters have long argued that without encryption, police, the military, and border agents in countries where they work can examine and search their devices. "The consequences can be dire," the letter added.

Although iPhones and Android phones, computers, and instant messengers all come with encryption, camera makers have fallen behind. Not only does encryption protect reported work from prying eyes, it also protects sources -- many of whom put their lives at risk to expose corruption or wrongdoing... The lack of encryption means high-end camera makers are forcing their customers to choose between putting their sources at risk, or relying on encrypted, but less-capable devices, like iPhones.
We asked the same camera manufacturers if they plan to add encryption to their cameras -- and if not, why. The short answer: don't expect much any time soon.

There are SD cards on the market which contain an embedded WiFi chip which creates a portable hotspot to connect to and download pictures directly off the SD card via a built in webserver. They seem like they must be running some sort of embedded *nix OS.

You don't say?The person you replied to, who linked to exactly that, didn't have me convinced such a thing existed. But thankfully an anon came along to reply to that and confirm it!

(Sorry, but I couldn't help myself there)

So it would seem like it should be possible to create an SD card with a similar embedded system which automatically encrypts files as their written to the FS in a write-only fashion. Obviously this wouldn't allow previewing of images, which is sort of the point anyways.

Not "seem like", but that exists too.

There used to be an SD card under the brand and name "Trancend Wifi SD Card" containing a multi core ARM processor, flash, wifi hardware, and RAM - all running Linux, a wifi/tcp stack, hostap, Apache, and Samba.

There is the eyefi SD card [eyefi.com] that includes a wifi implementation, allowing you to shoot photos from your camera to your smartphone without any interaction, turning your smartphone into a secure, encrypted photo vault, which can sync with a cloud data service.

Perhaps a card could have it's functionality oriented in the opposite direction and function based on what it receives. It could self encrypt the data with a resident public key, and play it back so long as it can receive a requested private key via WPA2 connection to an external device (eg your phone). People with phone confiscation worries could use the phone as a fragile conduit to a remote key server.

Sadly not. First - that's not even remotely the point of a write-protect tab, it has nothing to do with read-access at all.

Secondly - unlike floppy drives where the write protection tab prevented the drive from writing to the disc, SD cards use software based write "protection" - i.e. the tab is only a request that the card not be written to, and offers absolutely no protection against faulty or malicious software.

The workaround, for photographers, has to be that if the pictures are sensitive they need to download their pictures to their laptop (or other device) which is encrypted as soon as they leave the photography site.

... then take a lot of pictures of the floor, to overwrite the images on the camera's storage...

The problem is key management. A camera does not have a good way to enter a long password or passphrase, and an SD card is worse. It seems just as feasible to plug the memory card into a laptop (or into an adapter attached to a phone) that can apply whatever encryption the photographer wants.

A country could, of course, outlaw the use of apps to do that -- but they could, and presumably would, do the same for cameras that incorporate strong encryption.

The problem is key management. A camera does not have a good way to enter a long password or passphrase, and an SD card is worse

This seems like a trivial problem. Have the camera look for a my.key file on the sdcard. If it's there, copy it to onboard and overwrite it on the card. All future pictures are encrypted using the key. Have a button which the user can push to wipe the key from onboard memory.

You don't even need to do that - use asymmetric encryption and let the my.key file hold only the public encryption key and you can just leave it on the card - it can't be used for decryption, so it doesn't matter who else gets access to it.

Of course that would mean that you can't review your photos on the camera, but also means that the photos are protected even if someone takes your camera without giving you a chance to push the "wipe" button.

And really, there's very little need for on-camera reviewing in an evidence-collecting situation - at most you just need to be able to review the just-taken photo to be certain it clearly captures what you intended, and a professional photographer should have the skills and familiarity with their camera to make that unnecessary. Film cameras didn't have *any* on-camera review options, and did the job just fine for decades.

Being able to review is a handy feature, though, so it would be a shame to get rid of it completely.

But your suggestion is a good one, and there's no reason why both encryption schemes couldn't be implemented. Then the user would have the option to decide which scheme to use based on what level of usability/security they need.

Encryption could also be built into online photo sync systems like Adobe Creative Cloud, so that encryption would take place when you upload the contents of an SD card to the service using a tablet or phone at the end of a shooting day. By the time you cross a border, all your SD cards can be reformatted in camera (not just erased) and your images are encrypted on a server until you get home. This keeps all of the encryption and decryption off the vulnerable camera.

> Adding encryption to cameras will just slow them downYes, and if this is a problem you need to add enough hardware to the phone to accomplish the encryption within the needed read/write time of the camera. Given how little power this takes relative to modern processing power, and given the specialized solutions available in most modern chips, this is exactly what is being added.

> and cause compatibility problems with photo editing software.No, by the time software sees the files they are unencrypte

The higher end camera's have a significant fast memory buffer from which the pictures are transferred to the slower removable media.
The manufacturers will have to devise a system whereby said buffer will not retain a tell-tale.

Re "Hardware encryption won't slow anything down."
A consumer dslr can do 5 images in a set time before the hardware and media need time to catch up. The camera stops for a while as the buffer of set size and speed fills.
Call it say 30 images with a more expensive dslr. Then the much faster card has to saves the images.
Add encryption and that rate stays the same, gets not as good for that generation given the new encryption.
The competition selects not to offer encryption. Their lack of heat, power, wo

Why? This could be pretty easy.Just load up a small version of gpg that only encrypts.Load in your public certificate, and have it encrypt every picture using that.When you get home you decrypt them.

Except, how will this work if you want to see the photo you just took? Encrypt upon capture with encrypt-only software would prevent the camera user from being able to review the photo they just took until they get to a device that can decrypt them. if you implement encryption such that it is a process the photographer chooses to apply after taking the photo (think of it as a process similar to deleting a photo - you highlight it and select "encrypt", rendering it invisible on the camera), that will leave the photos vulnerable immediately after being taken - you know, like when the soldier grabs your camera right after you snap the photo of the soldier beating up a protester...

Except, how will this work if you want to see the photo you just took?

Who could do photography under those conditions!?;)

Encrypt-only isn't the solution to everything, but it actually might be a better solution to the problem stated in the summary. If you leave the decryption key at home then you can't decrypt it, even under coercion. Plus, if it's in the card, you just swap cards between regular shots and things you think might be sensitive. Provides some plausible deniability too: yeah, here are the pictures I've taken; oh, haven't used that other card yet.

As for looking at the pictures, you couldn't do that in the field with film either. And documentary photographers might look at quiet times for interest sake, but they don't shoot, check the photo, ask the subjects to stand differently, shoot, rearrange.... At least they're not supposed to.

If you can't decypt it, the you can't take the photos out of the country.

Problem still exists, and now you've got built-in ransomware on your device, because the majority of you customers don't know a thing about encyption. I for one hate encryption of my personal devices, it makes it difficult to make unencrypted backups or to switch vendors.

Better to use encrypted LTE and upload to Dropbox, then delete the photos. That way the photos have already made it out, and there is less risk to the photographer

You are pointing out something that film photographers have dealt with for decades: Did I have my settings right? Was I underexposed/overexposed? etc. When I look at my pictures, I *mostly* look to see that it's an acceptable exposure - my histogram is beside the picture. If that looks reasonable, I move on. The encrypt-immediate process could leave the histogram un-encrypted. You can't surmise what the picture is about based on that, but at least you know you have a decent exposure.

I thought the winky face made the sarcasm clear. Or did you mean to reply to the GP?

You could leave the histogram unencrypted yes. I doubt that would be a big selling feature though. Documentary photographers probably don't look at their images (or histograms) much while they're in the kinds of situations where you'd want to encrypt pictures. And those of us who learned with film often rarely look at the back of the camera any time.

By encrypting everything you could hide the pictures entirely on the car

Encrypt upon capture with encrypt-only software would prevent the camera user from being able to review the photo they just took

Encrypt all the photos on a particular card with the same 128-Bit AES "User Key" that is generated by applying a certain number rounds of Argon2id to a passphrase selected by the user. Save a strong hash of the key on the card alongside each file --- AND keep the key in RAM until the camera is shut off, or the user pushes a 'lock' button to allow picture review.

How do you go about entering a password on a camera? Any virtual keyboard on a camera would be controlled by the arrow keys and Select button, like name entry on the early video games. No photographer would use such a scheme more than once.

I have my iPhone set to automatically Dropbox all pictures I take with it. Even if someone were to grab my phone on the scene I still have my shots.

Let's also point out the obvious flaw here: encryption takes time and writing to a flash memory device takes time.

This thread is turning into another "smart gun" debate. One side wants a technology that has to read minds and violate laws of math or physics in order to work as conceived, and the other side isn't interested in going down a rabbit hole of silly.

How do you go about entering a password on a camera? Any virtual keyboard on a camera would be controlled by the arrow keys and Select button, like name entry on the early video games. No photographer would use such a scheme more than once.

That's how one sets up camera WiFi and radio flashes. So, yes, the camera already has virtual keyboard. Its no worse than navigating such things as FireTV Stick, etc. If you're the 1 in a million photographer trying to get pictures out of North Korea or Burma then you'd be happy to have such a system. The rest of us wouldn't want to encrypt even if it was easy.

Fingerprint scanner? Or change the screen to a touch device and put up a number pad? Hell they could get rid of the arrow keys and shit if they designed a decent on-screen interface. There's plenty of ways they could do it.

They're just being lazy and cheap and relying on the fact that there's only two major brands (Nikon and Canon.) Sure there's plenty of smaller names in the industry as well but there's also an insane amount of brand loyalty holy wars so the smaller brands have a hard time gaining mark

High resolution, more stops of dynamic range, and the ability to use different lenses does. For really high end models, there are a few other things too, like full frame DSLR formats, high frame rates (for shooting sports etc.), the ability to shoot HD video, etc. The vast majority of people shooting with a camera other than the one on their phone (which is already a shrinking market) don't care about encryption (which would slow down their camera even more), so don't expect the Nikons, Canons, and Sonys

How expensive would it be though? Cameras already have the necessary CPU power to do all sorts of image processing, encryption is no more difficult. All they need to do is load a public key from the SD card and, if in "encrypt mode" use it to encrypt the the photo rather than storing it unmodified on the SD card. Maybe that means it takes 5x longer to store each photo if the CPU is especially weak, but so what? If you're taking photos where encryption is important you should be willing to make compromise

Agreed. The number of folks who are interested in using encryption on a camera is a very very small slice of the consumer base.

I've worked as a photographer in a news organization. Even with my time there, never was there any case for encryption. Having the entire camera industry switch to encryption would be having the 1% of actual use cases drive the cost and performance factors for the 99%.

Lets see one company make a single camera that has encryption. If it sells like hotcakes to news organizations, fine. but I'll be willing to bet that it the sales will be minuscule because it's not a feature that needs to exist for realistic situations.

Not only that, but encruption fights those features. Recording more data faster to the card is consisdered a feature (I need to store that higher resolution, extra dnamic range, more frames per second, etc.) Already some cameras require CF cards because SD isn't fast enough. Encryption will invariably slow down the write speed.

If you're a photojournalist leaving a dangerous field assignment then there's a high likelihood you will be stopped and searched. If you hand over your camera and it comes up with a prompt for an encryption password then your camera and its media will be confiscated or destroyed in front of you. There go your photos.

As for protecting sources, why would you photograph them if you didn't intend to publish the photos anyway, which would still put them in danger?

There go your photos... but then the powers that be can't prove you were taking pictures of the super-secret-government-coverup and hopefully would be less likely to send journalists to a dark hole.

Think about it... If you were searched by border patrol in a fscked up country and you were taking pictures of things that "no one is supposed to know about". What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.

Think about it... If you were searched by border patrol in a fscked up country and you were taking pictures of things that "no one is supposed to know about". What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.

There's no win-win scenario here, a lot would be riding on the actual situation on the ground, and on the stakes at risk. This is why having the possibility of encryption would be a good thing.

The reason why we're not having it even on high-end SLRs (after the Nikon encryption fiasco in 2011 and the half-assed attempts years ago by Canon to implement it, along with digital signature) is completely clear: while professionals and their endorsement help to sell a camera (and a brand), they're only a tiny fract

What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.

I'm assuming if you are a journalist with that task then you don't value your safety much in the first place. It's really surprising more don't just end up "missing". Anyhow the best bet in this case is to have a satellite link and dummy photos on your camera. Because I agree with you and xkcd on the security of encryption. [xkcd.com]

Journalists have been aware of this problem since glass-plate cameras: they look for ways to hide their images from passing police, and only have harmless ones to display. Once they get home, they can crop and mask out persons at risk and still show, for example, the violent breakup of a protest by the military.

If they destroy your camera rather than killing you, that's a win. As for protecting sources: sometimes you take pictures with the intention of publishing some of the picture, and redacting the rest. It's very common to blur peoples' faces.

Why would the camera ask for an encryption password? Store the public key used to encrypt the photos on the card, and then just completely ignore any encrypted photos when browsing, since it can't decrypt them anyway.

A professional photographer has no particular need to look at the photos they just took - they didn't even have the option in the film days. It may be convenient for many things, but it's a small convenience to sacrifice to ensure their sources remain safe. Once they get back home, then they

Interesting. But it should be pointed out that the implementation is very badly done from a security perspective. I only spent a few minutes looking at it and found several showstoppers in both design and implementation. Among them:

1. The basic file encryption algorithm is a stream cipher construction using a simple LFSR as the stream generator. This is almost certainly trivial to break; standard LFSRs are in no way designed for cryptographic security. I suspect the LFSR was used for performance, and I'm sure it does in fact perform much better than, say, AES in CTR mode (where AES is used to generate a bitstream XORed with the plaintext in the same way the LFSR output is). While no good stream cipher is likely to match the LFSR performance, there are several that would provide moderate performance and high security, such as ChaCha20 -- or perhaps even a reduced-round variant like ChaCha12 or even Salsa20/12.

Note that someone has contributed an XTEA implementation which is much better, security-wise, than the LFSR but actually slower than AES. If you're going to do that, just use AES.

2. Even if the LFSR-based encryption algorithm were good, it uses 64-bit keys, which is just too small. Oddly enough, when you use the provided RSA mode for asymmetric write-only encryption (decryption can only be done on your PC), the author seems to recommend a 4096-bit RSA key size, which is roughly equivalent to a ~160-bit symmetric encryption key, and which is quite slow. It makes no sense to use such a huge, slow RSA key to protect small symmetric keys.

3. Password hashing uses the same LFSR plus some shifting and masking. Almost certainly insecure, and there's really no reason at all not to use a good password hashing algorithm like Argon2, or at least scrypt.

4. In asymmetric mode, the code appears to use random padding for RSA operations. There are really good reasons for the PKCS#1 v1.5 and RSA-OAEP padding modes that are normally used. It's possible that a very careful analysis of this implementation may show that under certain operational assumptions random padding is okay... but I seriously doubt that any such careful analysis has been done. I would never bother doing anything of the sort and would simply use OAEP. (Or, better yet, avoid RSA and instead use an elliptic curve algorithm -- less tricky to use correctly, faster, smaller keys and even the provides possibility to derive keys from passwords. There's really no reason to use RSA for anything anymore unless you have to interoperate with legacy infrastructure that already uses it.)

5. RSA key generation is done on-device, with the private key written to the SD card, then later deleted. You can't actually delete things from SD cards, not with any confidence. Much better to do keygen off device so only the public key ever exists on the SD.

6. A glance at the RSA key generation code throws up a number of red flags. I suspect the key generation is buggy.

7. I didn't find the random number generator, but given all of the above, I'd be shocked to find that it's actually good. A bad RNG can easily destroy the security of the best cryptographic design.

When I get some time (ha!) I'm going to see if I can get ML running on my 70D and hack together a better version, using Curve25519 ECDH and ChaCha20 with 128-bit keys, with asymmetric keygen done off-device, and a decent PRNG plus the best seeding mechanism available. To make it more usable, I'll see if I can keep the last few dozen per-file keys in RAM, which will allow the photographer to look at the images on the camera, until the camera is turned off. More paranoid users should be able to disable the retention of keys in RAM.

Sounds like a fun project. One which I may or may not get to before 2025 or so...

Sure, it'd be a useful feature for a small number of people, but the vast majority of users of high end cameras (and there aren't that many) wouldn't need it. And doing it this would either require a special encryption chip, increasing the cost for all users, or would be so terribly so that it would make the camera effectively unusable.

This would not require a special encryption chip. Most high-end cameras are built with ASICs that are designed by the manufacturer. There is an extensive market of reusable logic cores, including ones that perform encryption and decryption, that can be integrated into an ASIC. Most modern encryption algorithms are designed to need very little in terms of hardware resources, so it should not significantly increase the size of the ASICs in question.

It's not just encryption that cameras need, they also need a cryptographic signature to indicate that the image it took is fresh from the camera and has not been edited since the photo was taken. (Obviously this can be defeated by photographing a photoshopped image, but still...)

The lack of encryption means high-end camera makers are forcing their customers to choose between putting their sources at risk, or relying on encrypted, but less-capable devices, like iPhones.

Or, you know, pulling the memory card out of the camera and hiding it.

I've seen wifi SD cards for cameras [eyefi.com], so it should be easy to have your high-end camera send it's pictures to your smart phone, tablet, etc. as soon as you take it, then the photojournalist can simply delete the local copy on the camera. when your camera is searched, no images are found, they are all on your secure, encrypted smartphone, and who knows, maybe the smartphone could sync with a cloud service to get the images out of the region moments after captured?

Given the remoteness of most of these regions, and that RAWs can be upwards of 50MB each, I don't think a phone's data connection would cut it.

Syncing via WiFi to another device could be an option, depending on the scenario, but it's relatively battery intensive so it requires preparation & knowledge of exactly when you're going to shoot. Not so great for journalists travelling in remote regions, often off-the-grid, who need to be able to whip out their camera at a moment's notice.

I can easily imagine a program that detects a new photo on the SD card, transmits the message to the linked-to device (smartphone), then overwrites every sector the photo occupied with a random bit pattern before deleting the photo entry from the file directory on the device.

Sure, a curious regime could send the SD card out for data recovery, but the actual sectors the photo occupied would contain the random bit pattern - a brute-force search of the device would be fruitless.

You'd still need to actually wipe the camera - deleting typically only mangles the filename. And without hardware support, reliably wiping requires completely filling the card with other images - and even that may not do it if the flash storage is over-provisioned so that it can maintain its capacity as flash cells begin to fail (I have no idea if that's common with SD cards, but it's standard procedure for SSDs)

Canon offers a kit that includes an encrypted SD and flash drive. There are also a bunch of hackers around that do anything from running Arkanoid to implementing zlib on their dSLR camera. There are options, a bit of research and/or a knowledgeable it staff would help them more than bitching at the manufacturers.

You want a niche feature that would be detrimental or confusing to most users. An average photographer's nightmare is losing an amazing shot and encryption is likely to screw up any recovery attempts. Others would get in more trouble because of encryption than because of actual photos. Sounds like a good case for a Kickstarter project to make an Android-based camera where you can use a photo app that suits your specific needs. If there is mobile data, you would ideally upload shots to your studio and the se

OK, so you're in a country where they're suspicious of photographers. A cop comes up and asks to see what's in your camera. Sure, you say, and let him download your files. Oh, I see they're encrypted, he says...well, thank you for your time. Right?

The idea is that you load the public key that will be used to encrypt the images on the camera and you leave the private key back home. This is all fully documented by the camera manufacturer so that if the photographer gets challenged to decrypt the images it's easy to establish that they can't actually do that and there's no point in getting out the rubber hose. Ideally there would also be some options for having unencrypted images on the card and simply hiding the encrypted ones from the image review i

Every human endeavor can be used for both good and evil. In this case, those who are arguing for protection against a government agency looking at the contents of the cameras are ignoring the fact that the cameras can be used for illegal purposes.

WTF? If some authority can't browse the photos in your devices, they will simply seize the devices. Encryption isn't going to help you there.

Adding a digital signature, created by the camera before compression, etc.. to an image, would be a much better value add. This could help assure that images aren't tampered with after they are taken. Heck, my name is even on one of those patents, though I wouldn't get any $ from it.

Uhh, Sony camera's make nice pictures but their operation is rather difficult, for one Sony decided to make them too small for many if not most hands.
Even though their price / quality is very good pro photographers need something more substantial.
Luckily the better Nikon camera's use the best Sony sensors.

Talking about ignorants... Journalists weigh personal risks vs. getting the story out since the profession exists and you think it's all a super-easy choice and you always should just obey the authority.

You're presenting a false dichotomy and are apparently completely ignorant of the profession. Journalists reporting from crisis & war zones, on violent crime and from regimes with undue process have always been taking risks, and they have always weighed them against the obligation to report the story. It's part of the job, but only a small number of journalists work in this field and are willing to take the risks. Despite all that, dozens of journalists are killed every year while doing their work, just

Wow... just wow. In every conflict on earth you have a side that opposes covering aspects of the conflict at one time or another. According to your bizarre logic journalists could never get any footage from any war zone anywhere without 'taking sides' and 'no longer being journalists'. The world does not work the way you think it does.

By the way, in many cases war correspondents who miscalculate their risks can be happy if they end up in prison. Often they are killed. But I guess the beheading of James Foley by ISIS was just alright from your point of view, because he was 'taking side'. Retard.

I've always wondered what would happen in such a regime if the password you give them doesn't work for them because it's biometrically keyed to work only for you?

And what would happen if further, the biometric protections utilize mechanisms that go so far as to examine your brain waves to evaluate your emotional state at the time you are attempting to unlock the device, and will not unlock, not even for you, while you are experiencing above average levels of stress or otherwise under any kind of duress t

Wow, I'd think the better approach would be a fingerprint reader that can store two fingerprints - one that operates normally, allowing access to all the images on the device, a second finger that only allow access to a curated area of storage, with pictures of puppies, children, and sunsets. A more aggressive option would be a third-finger that wipes the contents of the card...

An easier option - use asymmetric encryption, and leave your private key at home. You can't give them what you don't have, even if they break you and you really wish you could. Of course, if they break you then you can probably just *tell* them most of what they want to know, but it at least ensures that you are the weakest link.

> I've always wondered what would happen in such a> regime if the password you give them doesn't work> for them because it's biometrically keyed to work> only for you?

Similar issue: A company I used to work for always but ALWAYS required travel with loaner laptops only. (Didn't matter if it was just to LA, or all the way to China. And, by his own decree, the policy included everyone up to and including the CEO.). All of the important data was on an encrypted partition, with just the basic OS unencrypted. Tricky bit was: we used a split-key system where the traveling employee had to:

1) Plug in his USB key, input the PIN on the USB, and its password on the computer to unlock his half of the key.then2) Connect to the company VPN, from which he would fetch the other half of the key, which was only stored in RAM and never swapped to disk.

Only with both parts of the key could the encrypted partition be accessed. And we always suspended VPN access while the employee was en route; making it literally *impossible* for him/her to give up the secured data, even to "rubber hose decryption". If some airport security goon got the notion in his little head that he wanted to see the contents of the laptop, he could go tell it to a real LEO, who could tell it to a judge, who could issue a subpoena or warrant, which our lawyers could fight. The ASG itself could go get bent. That data was OURS, not the employee's, and certainly not the airport's.

It was an issue only once while I worked there. An employee was returning from Singapore & vicinity; and some ASG wanted to see the contents of his laptop. After explaining the situation that the data was privileged and protected to them, our guy actually called up InfoSec, put him on speaker with the airport goon, and reportedly grinned ludicrously as InfoSec told the ASG not just that we wouldn't be unlocking the laptop, but also exactly what we thought of him, his kind, his agency, his "mission", his manhood and the lack thereof, his family and it's canine/porcine pedigree, and so on (Said InfoSec guy had been an army drill instructor in his past. So he had the talent. And I understand that the looks on the faces of the other overhearing travelers was fairly priceless.); with an admonition to not-so-kindly go fuck himself sideways with some rusty farm implements and to call legal if he had a problem and could somehow conjure up the mental wherewithal to operate a telephone himself. The laptop did stay at the airport; but not for long. Legal wrote a nastygram, in blood, on asbestos paper, and delivered by a black raven. And I think it only took about a month or so to get it back.

It wasn't so bad as you might think. Our lawyers were mostly full-time on-staff. While we brought in dedicated specialists from law firms when needed; for routine matters like griefing ASGs, our salaried guys could generally keep the requite steady stream of bile flowing as part of their 9-5. Also, due to the nature of the business, a number of said lawyers in addition to many of our execs, had contacts in the federal government and knew exactly who to go over-their-heads to, so as to expedite the shit r

Biometric security can be "compromised" if you have the hand the fingerprint came from... We're talking repressive regimes here, they would happily put a pistol to your head and tell you to put your thumb on the fingerprint scanner.

In 2000 and at the end of their 25th. independence celebrations I took some pics of the Angolan government plane being boarded by some VIP's.
Within seconds security confiscated my camera.
A good hour later they came back explaining they could not get the film out, indeed they had never seen a digital camera:). (Olympus C-900 Zoom)

So I showed them the photo's and deleted the ones' they objected to.
Little did they know or understand I had already taken more pictures on a different card.
A couple of hour