Google’s Street View cars collected whole emails – so what?

In May of this year Google announced that their Street View cars, who also collected WiFi data to assist in positioning your smart phone etc., had captured some of the unencrypted data that was received. In that announcement they stated that they only received fragments of data. Last week, they announced that in some cases whole emails were captured.

Of course, their official reaction has to be “we’re very sorry, we shouldn’t have done this, and we’ll get rid of it immediately.” But remember what they captured – unencrypted data, being broadcast by people who probably didn’t even know they did it. In fact, I think Google did them a service, by pointing out that their “private” data was being broadcast in the clear in a radius of about a city block. And apart from that, think of the data that an ISP sees and can capture (or allow to be captured), even if you use encrypted WiFi: all the data that Google has captured, emails, URLS, etc. and then some.

We still watching you! – junicks

It seems to me the same knee-jerk reaction that happens with Street View pictures, especially in Germany. Although all the information Google collects with Street View is publicly available for anyone at the same position, it suddenly becomes a major issue when Google collects it. Oh, and the “opt out” where Germans can tell Google not to show their house in detail on Street View – another knee-jerk. Have all these people removed their address from the phone book, so they can’t be identified in that way? Did they smudge their license plates, so no one can trace them that way?

So, how can you prevent Google Street View from capturing your data? Two ways:

  • Enable encryption on your WiFi network
  • Use a secure web protocol to communicate with the network

Enabling encryption on your WiFi network has to be done on all devices. Your router determines the level of encryption, and all devices connecting through WiFi have to support that encryption level. Don’t use WEP, but opt for WPA2 without TKIP (AES only).

Using a secure web protocol is simply using https where possible. Sites like Google Mail support this, and even Google Search can be run over https.

I’m not a Google Fanboy, although I use several Google products daily. But this seems like singling out Google for things that are common occurrences, or for things that can be easily prevented.

ICVerify: encrypt request and answer files using EncryptionManager

To increase the security when dealing with credit card processing via ICVerify’s request/answer methodology, it is possible to encrypt and decrypt this information. However, the documentation is fairly sketchy on this subject, especially when you’re not working in one of the languages used in the examples in the SDK.

After some hair-pulling on why it doesn’t work, I think I’ve got it figured out now. Here are the steps I used to get it working:

  1. EncryptionManager.DLL is not a normal DLL, it is a .NET assembly. Trying to register it with regsrv32 will result in an error message, saying that it doesn’t have a DLLRegisterServer entry point. The trick is to use either the .NET gacutl.exe or the icvgacutil.exe supplied on the ICVerify SDK CD.
    UPDATE:You also have to use regasm to register the assembly!
  2. Once registered at the Global Assembly Cache (GAC), the name of the DLL is not EncryptionManager. To make things more interesting, I had to link to the name FirstData.Encryption.Facade.EncryptionManager. The only way to figure this out is to dig through the registry after registering the DLL, or to use the option on the GAC utility to write out a registry modification file.
  3. In Progress, you can use the COM viewer to access EncryptionManager.tlb, and see the different methods defined in the DLL. You’re only going to be using 2 of them most likely: EncryptThirdPartyMessage and DecryptThirdPartyMessage. Both use the creation date of the file you’re working with, so be careful not to copy this file or move it across file systems.
The Progress code I used to encrypt a request file is as follows:

DEFINE VARIABLE vhEncryption AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcPrepFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.prep”.

DEFINE VARIABLE vcReqFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.req”.

DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcRequest AS CHARACTER NO-UNDO.
DEFINE STREAM sOutput.

UPDATE vcRequest FORMAT “x(60)”.
CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
OUTPUT STREAM sOutput TO VALUE(vcPrepFilename).
vcEncrypted = vhEncryption:EncryptThirdPartyMessage(vcPrepFilename,vcRequest).
PUT STREAM sOutput UNFORMATTED vcEncrypted.
OUTPUT STREAM sOutput CLOSE.
OS-RENAME VALUE(vcPrepFilename) VALUE(vcReqFilename).

The decryption routine is somewhat simpler, since we don’t have to move files around so much:

DEFINE VARIABLE vhEncryption     AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcAnswerFilename AS CHARACTER NO-UNDO

INITIAL “C:TEMPicver001.ans”.

DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcDecrypted AS CHARACTER NO-UNDO.
DEFINE STREAM sInput.

CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
INPUT STREAM sInput FROM VALUE(vcAnswerFilename).
IMPORT STREAM sInput UNFORMATTED vcEncrypted.
vcDecrypted = vhEncryption:DecryptThirdPartyMessage(vcAnswerFilename,vcEncrypted).
INPUT STREAM sInput CLOSE.

These code snippets should have some more error checking. Also, the request can be more than one line, depending on the version of ICVerify and the answer file settings in the configuration.