This process must stop! Email Verification of Credit Cards with Government Issued IDs.

It has come to my attention lately that some merchants have gotten into the habit of issuing verification requests for purchases made by credit card on line.

In these requests, they ask specifically for information to be delivered to them by E-mail so that their Fraud department can verify who you are.   For instance, here is a recent email request from eHost.com:

We will need a scanned copy or photograph of the credit card owner's government-issued photo id, such as a drivers license or passport. We will also need a scanned copy or photograph of the credit card used for purchase. Please make sure all of the edges of the credit card are visible, and that we can clearly see the card holder name, expiration, and last four digits of the card number. Please block the first 12 digits of the card number, leaving only the last 4 digits visible. If the attachment does not meet these requirements we will request that you send this information again.

It is also further stipulated in their support page here.

First off, if this sounds like a Phishing scam, it should. Second of all, if you comply with this procedure you are opening yourself up to Identity Theft, facilitated by this company, but you'll be at fault, and they will not. Here is why:

E-mail is not a secure form of communication. You may have a secure connection to your email provider, but once that email leaves the provider, it will hit many email servers and relay points, being copied by everybody along the way, until finally it reaches its destination at eHost.com.

Anybody along the line can scoop that information and use it for any number of purposes. And here is why YOU ARE AT FAULT -- Simply, because YOU sent it. If somebody picked it up along the way before it got to eHost.com, that is not their concern, nor their fault, or so they would say in court. You sent it, even if they requested it to get the services or products you so desire.

Sending a picture of your credit card just bizarre. They already have the credit card number, expiration date, CCV code, everything that they desired to verify that you have the card. In our case, eHost.com already successfully charged the credit card! So, that information is and has been verified. And is now asking for verification information? This process leaves me a little beleaguered in that you'd think they'd ask for verification before they actually charged you.

Sending anybody reproducible pictures of a government issued id, such as a Passport, should be downright illegal. Although I haven't done extensive research on this topic, a cursory scan of the topic yields that it is indeed illegal, at least for most government issued IDs. Please have a look at this link that cites the specific law text:  http://www.weltman.com/?t=40&an=40053&format=xml&p=7735

In any case, even if you block out certain parts of the ID, you end up giving away numbers and other information that can be used to recreate your identity online. There are some requests to block out certain numbers from your credit card number. However, we already know that this is not quite sufficient as it is all the data that verifies the card. They ask that you not black out the very bits needed to identify you. Duh. The parts they want you to black out gives you a false sense of security, as those parts probably name the card, MasterCard, Visa, etc, and the bank. All of which are publicly available and a mere brute force matching scheme to complete the credit card will not be that hard. Please see this post of mine, where a company called Dreamhost.com asks for all my credit card and billing information to be delivered to them in an email to unlock my account.

Why is this process rearing its ugly head? Apparently,  the companies are already subject to so much fraud. Here is a recent article with some statistics. http://www.nasdaq.com/article/credit-card-fraud-and-id-theft-statistics-cm520388

They are scrambling for solutions. On-line payment gateways provide services that may flag transactions as fraudulent. A terse summary may be found here.

In my case, with eHost.com, the transaction was for an American friend of mine who lives and banks in Ontario, Canada. Performing the transaction at my house, probably triggered an Advanced Address Verification Service Filter based on the fact that the IP address given to my modem by my Internet Provider didn't match the address of the bank and billing address in Canada. Therefore the gateway flagged the transaction and forwarded the incident to their "Fraud Department", albeit after charging his credit card.  This type of issue happened several times before I could surmise what is going on.

The payment gateways seem to be able to flag the transactions based on several configurable filters. However, there isn't yet a third party company that handles the outliers, so, the response varies from different merchants. Yet, some seem to follow in the path of others. Some just deny the transaction. Others look for extra information to try to verify your identity, address, presence of card,  and do this by asking you to send such things as a picture of the credit card and your government issued id. Many of them, lacking the web development or a canned web based solution to deal with it, simply ask you to email the pictures to their anti-fraud department.

I had one conversation with a seemingly more knowledgeable attendant at Credit Card Companies trying to rectify the eHost.com charge, as we were NOT going to Email pictures of passports, drivers licences, and credit cards to eHost.com. The attendant said that this procedure is becoming much more prominent, and cited it as compliance to "Know Your Customer" (KYC) rules.

The KYC rules are more situated to hamper money laundering in investment markets than spending $50 on a website, but there you have it. One would think that the credit card companies would be adverse to this procedure as it opens them up to a lot more fraud should these emails get loose.

Think of it. You send and email with pictures of your passport, picture of your credit card, perhaps your drivers license, and then there is a whole Identity Theft Package sitting on multiple Email Servers that could be anywhere in the world. Aside from outright publishing your credit card data and verification, if a perpetrator makes a purchase with that information and the merchant requires this extra information, he already has it. Furthermore, sending a picture of your passport opens you up to passport duplication and fraud, quite possibly to be used by terrorists.

This practice must stop. People should stop and say no to products and services that request this information in this matter, especially over Email. These companies should be held liable just as much as companies like Target in their recent breaches. Sadly, it will take a few egregious acts of identity theft, some people who are hurt by this procedure, and then finally a government regulation stopping the practice all together.

The iOS Deallocation Nightmare Heap

So, well into my failed foray iPhone app development with Rubymotion, I said the hell with having one code base (Ruby) between iPhone and Android and started developing my iPhone app with Swift. It required a lot of typing translating my Java (now Ruby) code into Swift. Uggg.

Unfortunately, the iPhone system, the Objective-C base is hopelessly stuck in the early 80s and doesn't have a garbage collector. It has something called Automatic Reference Counting(ARC). The ARC came about a couple of years ago and was hailed as a major break through. Really? We really are in the 80s.

So, what is ARC? Before ARC you used to have to do RC, i.e. reference counting, which was a tool to handle deallocations in the heap. If you allocated an object you could deallocate it when you didn't need it anymore, by calling .release() on it. Conversely, if you needed it held onto in multiple places you could call .retain() on it. These calls would lower and increase the reference count on that object respectively. When the count would hit zero, then magically, the space the object was taking up would be given back to the heap. In order to deallocate space that the object may have references to, you would have to override a function called dealloc() and call .release() on some references, or you used some other strategy. Some strange strategies did emerge, but that is not the subject here.

Apple discovered, or worked hard at, noticing that the approach developers were doing was pretty boilerplate for deallocating objects. At least that what I surmise, since that is the way garbage collectors have been working for decades. Seriously, we tackled the issue of garbage collection a long time ago in the 70s with LISP and probably before, seriously enhancing garbage collection in the 80s and 90s to be really efficient and effective, yielding smarter, and also less stressed programming.

Enter ARC, that is "Automatic Reference Counting". Voila, It's much like not having to manually shift gears in your car, which is something we developed in the 40s, but I digress. You get my point. The 90s are over.

So, now with the ARC, Apple will take care of this reference counting for you. Apparently, the compiler would be able to notice when ".retain()" or ".release()" needed to be called, based on syntax. Also, at deallocation, much like my 'dealloc()" override strategy mentioned above, one would assume that it would "automatically" reduce all the reference counts of space which was being held by the object being deallocated. So, one would think. Think again Einstein.

One other supreme <sarcasm> benefit </sarcasm> with ARC is that it is NOT a garbage collector. "It's much more efficient than a garbage collector," they say. So, unlike a garbage collector, you cannot just ditch the top pointer of an object graph and have the whole object graph go away. No, uhh unnh. no nada, no god damn way. If you have any reference cycles in the object graph, you are hosed because a cycle chain will never reduce its reference counts to zero, and therefore will never be freed. I'll leave that thesis to the reader as an exercise.

So, Apple developed, at least in Swift, two different types of references, "weak" and "unowned". Pointers to objects declared with these keywords are said not to increment or decrement reference counts on the object for which they are references. For example, the following declarations:

class A {
   var myChild : B
}

class B {
   weak var myParent : A?
}

var a : A? = A()
var b : B? = B()

b.myParent = a!
a.myChild = b!

Now, if you got rid of the reference "a" by the following:

a = nil

Then, both objects would automatically get deallocated. Magic, eh? My god, what an accomplishment!!! If myParent were not a "weak" reference to A, then none of it would get deallocated. Okay, you say. That seems logical.

So, what is the problem with this approach?

YOU HAVE NO FUCKING CLUE whether any 3rd party software actually declared myParent a weak or unowned reference. 

In fact, the above example is quite simple for illustration, but if the object graph is complicated you have to do a whole bunch of this stuff, just to MANAGE the GARBAGE! You have to MANAGE the GARBAGE.

Let me say that one more fucking time.

YOU have to MANAGE the FUCKING GARBAGE!!!!!

So, back to my point. My problem arose from doing this:

class MapViewController : UIViewController, MKMapViewDelegate {
    init() {
       mapView = MKMapView()
       mapView.delegate = self
       .....
       mapView.addOverlay(MYOverlay())
   }

   func mapView(mapView: MapView, rendererForOverlay: MKOverlay) -> MKOverlayRenderer {
     return MyOverlayView(rendererForOverlay as MyOverlay)
   }
}

MyOverlay would get a MyOverLayView and go on with its business. So, one would think that when MapViewController got deallocated, it would also deallocate the MyOverlayView, which it does. One would also think that the mapView would in turn deallocate the overlay, or at least reduce its reference count. Apparently, after painstaking investigation, that is NOT the logical case. WTF?

It took me more than a fucking week with debug statements and the almost usless Xcode debugger to figure out what I now call an undocumented requirement. It's not documented anywhere probably because, why would you want to deallocate a mapView? Fuck me.

So, as I labored for weeks, I find this solution. You have to keep a reference to the overlay you added, and also remove it from the mapView when the ViewController is getting deallocated, Otherwise, I can only surmise that it is holding onto a lot of closures, or something that isn't even referenced in the overlay object itself, but to things in the MyOverlayView.

This was the hard part. The matching MyOverlayView was getting deallocated, however, a lot of stuff that was actually referenced in the MyOverlayView was not. The MyOverlay was NOT getting deallocated, and it actually contained references to anything that was still being held. But that stuff in question did have some indirect references in the MyOverlayView. But let me say this again. the MYOverlayView object was deallocated. So, that lead me to look for something else, possibly stupid, that *I* was doing. Think again Einstein.

After trying everything else that was related to the objects/memory that should have been getting released and was not,  this approach magically seemed to do the trick:

class MapViewController : UIController, MKMapViewDelegate {
    var myOverlay : MyOverlay?
    init() {
       mapView = MKMapView()
       mapView.delegate = self
       .....
       myOverlay = MyOverlay()
       mapView.addOverlay(myOverlay)
   }
   deinit {
      mapView.removeOverlay(myOverlay)
   }
}

Then, BINGO, WTF? Really? My memory leak from releasing and creating difference instances of the MapViewController disappeared, well, as far as I can tell.

One would think, that if the MapViewController only carries a reference to the MapView that when it gets deallocated, it should also deallocate the MapView object, and therefore AUTOMATICALLY remove the overlays. Obviously,  that is not the case, and that is not documented anywhere.

I am kind of thinking that the MKOverlay class actually holds an undocumented non-weak reference to the MKMapView object, and the MKMapView object obviously holds a reference to the MKOverlay in a list somewhere. So, neither the mapView nor overlay object get deallocated due to their reference cycle. I'm still at a loss for why all the rest of the stuff was being held onto as they never had references to the mapview except within executed function through the MyOverlayView, which had been deallocated. Who the fuck knows?

This situation does not seem to be documented probably because nobody would probably think about deallocating a ViewController containing a mapView. In my app, this situation may occur as much as the user wants it, so I've gotten burned.

Finally, though, I now know how to solve the memory leak with this mapView, and hopefully this blog post helps the next poor schmuck who has to do MapKit shit in iPhone development.

Now maybe I can finish this fucking iPhone App that took a significantly less time (an order of magnitude less time) to implement in Java and Android.

Thanks Apple.

The Rubymotion Failure

A while ago I wrote a post about my foray into using Rubymotion (RM) for iPhone development. RM is a development tool for programming in the Ruby language for the iPhone. The basic reason for this approach was that I had an Android App with a lot of non-ui code and Hipbyte's promise that Rubymotion will support Android. Therefore, I would have a single code base to maintain between the two platforms. The other reason was merely cosmetic in nature. I think Obj-C is one of the more horrendous languages around. This effort was a resounding failure.

From that post, fast forward a few months, and as of Jan 1st, the start of the new year, I have scrapped the entire Rubymotion project. A total of 5-6 months of development has come to a screeching halt. Rubymotion has been a disaster.

First off, from a old cogger developer that actually likes statically typed languages, Ruby is an atrocity. But with some discipline it could be worked. However, the mere fact that it is Ruby, makes it problematic for smallish platforms because of its memory usage. I found that Rubymotion had bizarre memory problems. Weak Reference exceptions would popup when trying to do NSCoder serializations, where I wasn't using any weak references in the object graph. That lead me to write my own text based externalization library, because the Sugarcube NSCoder strategy kept failing. Sugarcube is a Ruby Gem that makes using Rubymotion a bit more like Ruby and less than Obj-C.

Other memory problems kept creeping up occasionally. One notable one is where somehow a reference to a list of one type of object became a list of another object. Now, Ruby doesn't have any type safety, but if you are disciplined enough, you can be 100% sure that if a variable to be of a certain type, it should be just that.

I had something of the sort:

class A  
  attr_accessor :bList
  def initialize
     self.bList = []
  end
  def add(args)
     self.bList << B.new(args)
  end
  def process
     bList.each do |b|
        b.doit
     end
  end
end 
class B
   def initialize(args)
     ...   
   end
   def doit
     ....
   end
end

 In A#process, the app would crash because bList didn't contain a list of B. That was evident because the error message said that the target object didn't have a method named "doit".  A few puts statements, revealed that it was an object of a different type. WTF? The list of the other object did exist, but should have been in some other object.

To top all that, it wasn't consistent, which probably was a result of the particular memory recovery strategy they were using. Apparently, I got from the community support list that they don't use iPhone Automated Reference Counting and use something else. That is probably due to the dynamic nature of Ruby and what they have to plan on with the crazy bullshit you can do in Ruby.  This error was the most egregious one and with the group not being quite forthcoming with the problems leads to undermine my faith in the product. If you can't trust the fundamentals then what the hell are we doing. Gödel, I digress.

Other memory problems seem to be with the memory collection. I won't call it garbage collection, because the Rubymotion people seemed to vehemently avoid that term. It would seem that at the end of segment of a thread, the app would freeze up, maybe for as much as 10 seconds. One community member confirmed this problem, and could replicated using autorelease_pool.  That seem to fall on deaf ears, and the RM community guy couldn't understand why I was having all these memory problems and doubted my use of mutexes , locks, and semaphores. I'm quite well versed at concurrent programming, thank you, and instead of doing any real investigation, passed it off as a problem that I'm doing something too complicated. Really?

I actually found a problem, and did my best to reduce the problem to a minimal app to demonstrate the problem, put it on Github. The AppDelegate class would illustrate the problem. Even that was too much. Here is a response from the HipByte support site:

Hello Dr. Polar Humenn,     

A good test project usually consist of one file with the minimum amount of code that exposes the error or wrong behaviour. It would really help us if you could create a further reduced test project.     We can take a look at the unreduced test project. But please be advised that won't happen until we have gone through our backlog of support tickets.     

Thank you, 

Mark. 

At this point, I was sorry to  tell them that wasn't going to happen, and I was giving up on Rubymotion. That was Jan 1st. Time to start a new year.

So, now what? I'm using Xcode and Swift, and unfortunately, I will have to maintain two completely different code bases.  And I'm on a fast and furious programming to get it up and running using Swift. Swift is not without its own problems, but the type safety definitely helps, and it's not Obj-C. The problem is that Xcode is not Eclipse, and the syntax evaluator keeps crashing. At least it is resilient that it restarts itself, but the crashing all the time is quite annoying. The code completion, when the syntax evaluator isn't crashing, it works, albeit a bit slow. Documentation is crap. And apparently, as I wrote here, Xcode cannot refactor Swift code, only Obj-C.

I'm a registered  Beta user for RoboVM which is a Java product for the iPhone out of Sweden, but I haven't had the courage to fire it up. Right now due to this failure, time has become critical.

Cheers,
Dr. Polar Humenn

Apple Swift Development

Message from Xcode:

         Can’t refactor Swift code.

         Xcode can only refactor C and Objective-C code.

My Response:

        FUCK YOU APPLE!