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!

Rubymotion effort

I wrote the following on a Rubymotion Google Group thread about the disappointment that some are having with Rubymotion. I thought I would place it here. For those who don't know Rubymotion is a proprietary code library (cost $200/year) that enables the use of the Ruby programming language for iOS program development, which is entrenched in Objective-C, and just recently released Android support.

I'm not so disillusioned with Rubymotion, yet. But there are strange memory errors, and stuff that just doesn't work, or I haven't figured out "how it's supposed to work," yet.

I am more disillusioned with iPhone development in general. It's like a trip back to the 1980s, and the nineties are more than over, man! As some would have it, Ruby may be "friendly" to some. It's a nightmare to others like me, who are advocates for type safe languages and a guy who worked on functional languages, like Haskell, back in the day.

Originally, we embarked on type safety to get attain efficiency of execution from the languages in which we wrote code. In all, that was a good goal, but the ultimate benefit of that effort is now the ease with which the development process has improved. The development tools, e.g. Eclipse, are excellent at analyzing the code on the fly, good at making suggestions of method names you desire, and proper argument matching by type, and leads to much faster development process, eliminating stupid errors as a result of the dynamic compiling the IDE employs. And refactoring the code is just a few mouse clicks away, brilliant!

Ruby throws most of that progress into the trash can, and you end up with typeOs and argument mismatches so far down the line that you have write test for everything, just to make sure you typed it correctly. And you can still get burned way down in the process when you fire up the app, because your development tools don't have a friggin clue about what is to transpire. That process is ridiculously long.

I started on this project with Rubymotion because I have an Android App that I did in Java, as one does. It took me a week to learn enough intricacies about the process, and with the help of a good IDE and its integration with excellent documentation, I had a functioning Android app with maps in about a week. It was a relative breeze. 

My app contains a lot of non-ui logic, so after a failure of trying to convert the Java to Objective-C (you can read about that here), I decided to go with RubyMotion, based on the fact that I could get a common base of code that will work for both the Android and iOS. 

I've been at this Ruby crap for months, converting my Java code to Ruby. The IDE I'm using is RubyMine, which is good, but it's Ruby, so it can only be so good, and that's just not Eclipse and Java. It's been a trying experience. As a result, I have Rspecs for everything, basically which is the result of just trying to clear the typeOs and the type mismatches that the IDE can't do anything about before I get into the arduous iPhone/Rubymotion process.

Objective-C is the most inelegant language I've ever come across. Anyway, I bought Rubymotion, and it's just been a frustrating experience. Rubymine just doesn't play well with it. The debugger sucks, and is basically useless. However, its consolation is that it's better than Xcode and Obj-C. And the REPL, which is a dynamic Ruby expression evaluator in the context of the running app, is somewhat useful, except that I have so many "puts" statements in my code for debugging purposes, trying to read the result of an evaluated expression in REPL is like trying to catch chickens in the yard if you can't stop the scrolling fast enough. Also, REPL tries to print out the resulting object and if the object is large the whole thing crashes with a malloc_error, which is some throwback from the 1970s, but I digress.

The whole write code, compile, fire up the simulator, fire up the app, crash sometimes with or without an assembler dump reminds me of a time when I would accidentally drop a boxed program of punch cards on the floor, or when the card reader would chew your cards like a mad dog. Alas, you guys are probably too young to remember that, and some of you'll probably say I'm too old to be doing this stuff.

In any case, I'm hoping that some of the problems with Rubymotion can be gotten around and that the Android thing will work. I'm kind of betting on that. I've seen a lot of software come into being and improve, even Microsoft's horrible crap, given enough time. I still have faith. 

Cheers,
Dr. Polar Humenn

Security Gone Awry: Security Practices at NamelessHost

After a debacle with one cloud service provider, I decided to go with NamelessHost, because of an egregiously bad security capability problem at this provider with their API keys. They lost my trust. I'll expand on that issue in another security related blog post and post a link to it here when completed.

I signed up to NamelessHost, primarily for NamelessObjects, which is NamelessHost's storage option that follows Amazon's S3 API. It has this same API as the first cloud provider, something that would make the switch easy in some of my projects. As a result, I did a bit more research on NamelessHost, and ended up setting up a server or two with them, due to a combination of price and performance that was also preferable to me over the first cloud provider.

Then it happened. After a couple of months with NamelessHost, they offered me a financial incentive to sign up for their "Multi-Factor Authentication." Being a security guy and not passing up some free credit, I decided to take it. 

All that being said by talking to a website over SSL, I've already entrusted a credit card and billing information, and after a couple of billing cycles I was reasonably assured that I was indeed talking to a company called NamelessHost and had no indication that they were misusing my credit card information. They fired up a page with a list of "codes" on it. The page told me that it would be the last I see of them, and that I should write them down. I took a picture with my phone instead. 

Okay, fast forward, a couple of weeks and a couple of business trips later, the micro SD card on my phone dies. I did not back up that picture of the codes, so now logging onto NamelessHost is a problem. I can reset my password, but I need that other code to sign on as well, which I do not have. Of course, one would think, these days, there is a remedy to this situation. There is. They say to contact support. 

I realize that this process may be slow, but what the hey, it was my fault. Nothing critical is happening and everything is working. I can still get to my virtual servers via ssh, my servers can still access NamrelessObjects from the API. All their mulit-factor authentication covers is logging onto the NamelessHost website. In light of the Heartbleed exploit I wanted to change my NamelessHost website password. So, now I can get to the password changing page, but I cannot log onto the website to complete the transaction. So, I contacted support, what ensued was a complete surprise. At an impasse, NamelessHost is now losing my trust as well.

George from support at NamelessHost told me that I had to send them the following information to him in an e-mail:

1) The full name on the account. 

2) The billing address of the account. 

3) The first four, and last four digits of the credit card on file for the account, as well as it's expiration date. 

4) The answer to the account security question: "What was [--deleted--]?"

I was floored! It was not because of the erroneous use of "it's!" How can this procedure be from an organization that wants to provide security to their customers? I sent back an e-mail inquiring to find some other approach as I did not want to fire them off a text document with my financial information in an e-mail. I will discuss the flawed and misguided reasons in the following snippets of what I got back from various back and forth e-mails. First, in response to my question of why I need to send all this account identifying financial information:

Unfortunately any account access issues must be handled over email due to strict documentation requirements.

I had to get a further clarification to the meaning of "strict documentation requirements", and got this statement from George:

In order to gain access to an account we must first confirm the individual that is contacting is the account owner. These documents are needed to cross reference the accounts records. The guidelines that we must follow for providing access requires these pieces of information to match.

For my assurance, George also offers this bit of instruction, should I not trust sending this information to him.

However if you would like you can send this email through our verifications email address(verifications@namelesshost.com), which is only handled by our security team.

So, the phrase "strict documentation requirements" means that they actually require all the account information including the financial information in a single e-mail. There are several things that are wrong with this misguided approach:

1. Sending information in an e-mail is not secure. 
2. Financial information and its verification should not be sent via e-mail.
3. Credit Card numbers, if portions are left out, can still be worked out.
4. The e-mail verifications@namelesshost.com is no safer than support@namelesshost.com, no matter how safe he tells me it is or to where it goes.

Let's discuss these points one by one.

The first point, should be quite obvious to most with some notion of security. However, to some it may not. E-mails are passed around from server to server in a hop to hop fashion known as "store and forward".  The very first word of that term should alarm you, which is "store". Yes, it is stored, whether in memory or on disk, it is stored. Perhaps with the NSA, it may be stored for a long period of time.  This storage happens on e-mail relays and servers, and can be anywhere.

Furthermore, lower levels are not secure. Packets that comprise the e-mail are sent over wireless, switches, and routers. Those packets can be intercepted and reassembled easily enough. E-mail relays usually have the entire assembled e-mail stored somewhere before it is sent out again to its next hop. Basically, you have no idea where an e-mail has traveled, let alone even if it gets to its final destination. One could encrypt the e-mail, but still it could be saved somewhere, worked on for a period of time, and eventually cracked. Furthermore, even in this day an age when the patent has run out on RSA encryption, most likely both parties do not have the expertise and the software set up to send a signed and encrypted e-mail.

Based on the first point, you should never send financial or authentication information in an e-mail. Even if you send it in several e-mails in a piecemeal fashion, it is just a matter of collecting e-mails from and/or to a single source and assembling them for the whole picture.

In contrast, on company websites, you enter financial information. However, due to the SSL connection, you have an assurance, albeit not a very good one, but some assurance, that you are entering your information to the desired destination, and it is encrypted along the way. Now, there is a different question on whether you trust the other organization with that information, but we'll save that for a later time. With an e-mail, you have no such assurance. Therefore, never send identifying financial information and its verifying components in e-mail.

The third point is not well understood, but extremely important. Leaving portions of a credit card out is not secure. The format for credit card numbers was made along time ago, and they were built with the intent that they could be somewhat "verified" off-line using a formula for the digits. For an example of this procedure, please see Anatomy of CreditCard Number. What this procedure does is effectively cut down the search space of the missing numbers that may be tried. It actually makes it easier to discover your actual credit card number from the given parts. In NamelessHost's request, they are asking for half the number, 8 digits and their positions, which is quite enough information for discovery. Now, combine that with all the other information associated with that number, such as the full name, billing address, expiration date, you've just given anybody who can pick up this e-mail a blank check.

The forth point is also not well understood. First of all, let us say that with points 1 and 2 we have already established that sending sensitive information over e-mail is just not a good idea. Why would sending it to a different place be any better? George may know that e-mail goes to his "security team" on a separate server, as he elaborated in response to my question about it:

I only offer this alternate email address, as only a select handful of people have access to this server. Only our Security/Abuse team have access to this server, and not our general technical support team.

George may certainly try to assure me of that, but he cannot assure me how it got to that server and to his "trusted" people. He seems misinformed at best, and demonstrates it with the following claim that if I faxed the information, it is actually less secure:

If you prefer you can send this information via Fax or Postal Mail(However I would admit that this would be less secure, as any office staff walking by can pick it up, while with Email only those staffers vetted for access to such info can see it).

His "admission" doesn't give me much trust in his organization if he doesn't trust his staffers with such information in their own offices once it gets there. Nonetheless, the point is moot. Fax is no more or less secure than e-mail, and using the post office is only marginally better. I say marginally better, only because somebody at NamelessHost may be able to ascertain that the envelope has been opened in transit and alert me that my information may have been compromised so that I may take appropriate action. With an e-mail, unless there is encryption and signature, there isn't even that assurance. You might as well write the financial information on a post card with large font, and then, mail it.

The intent at NamelessHost was that if I signed up for multi-factor authentication at their request, it was to make my experience more secure. Yet, the rectification of my current situation is tantamount to publishing all the requested information on an obscure website, most likely picked up and cached by Google and to live on in perpetuity. This situation, in the very least, results in a contradiction of purpose.

One possible approach and a STRONG SUGGESTION  for NamelessHost, and any other organization, is to eliminate the need for the financial information associated with the account for authentication purposes. They do not own this information, and it is entrusted to them solely for the purpose of charging their customers for services rendered. NamelessHost should devise other ways to authenticate their customers such that they do not expose their customers financial information. And, although it can be considered a bit misinformed on their part, forcing their customers to expose their information is an egregious act, as at that point the blame can be laid squarely on the transmitter of the information, the customer.

Since I signed up for Multi-factor authentication, unless, they change their security practices, there are only two approaches that I can take.  Create another account on NamelessHost, or go with another service. Both are undesirable and both approaches require shutting down my credit card. That's not really good for business, on their end or mine.

Why? I will not be able to unlock my account on NamelessHost. That means logically and technically that I cannot even cancel  my account, if they are following their policies. I cannot remove any servers or objects I may have. I cannot remove my credit card from their charging scheme. Given that, I will incur monthly charges for an account I cannot shut down. I must shut down my credit card so that I will no longer be charged.

I'm happy with NamelessHost as I have used it, and I still need this kind of service from some provider.  I could create another NamelessHost account. Alas I would need a different e-mail, because my current one is already in use for an "active" account. Of course, I would need to get a different credit card, which is a hassle that affects much more than my relationship with NamelessHost.

In conclusion, I signed up for Multi-factor authentication for more security with NamelessHost, and it appears that I have gotten much less.

Android to iOS: Into bloody hell!

I've been working pretty extensively for the last year on an Android Mobile app for Busme! and to hook into my backend Ruby on Rails servers.The app is GIS based and runs over a scrolling map. It's pretty simple for the most part. The complex stuff lies within the logical bits of dealing with the backend and various user interactions.

The Android app has gone through a couple transitions during its time. The big one was a switch to Open Street Maps from Google Maps, mainly because of the $10K "gotcha", and because I'm a big fan of open data. With the use of OSMDroid and the availability of its source code, that transition was fairly straight forward. I am now using MapQuest's generous serving up OSM map tiles, thank you. Most of the other ongoing developments are conceptual in the user interface and interfacing with the back end. The Ruby on Rails side is a wholenuther story, which I will probably leave for a later date. But for the App, it's pretty much a couple of Overlays onto a scrolling map application. Pretty damn simple.

So, back to reality. For this company to go anywhere, I've been emphatically told that I need to have an iPhone app or it won't fly, and "nobody will use it". I happen to think there are a lot of Android users out there, but I like to be inclusive, so what the hell, I gave into the pressure to investigate.

The following experiment took a week and will be condemned as a complete failure. Although I wouldn't call it a *complete* waste of time, it was close to not being worth the stress and the strife, and, my (now X) girlfriend is amazed, disgusted, and flabbergasted at how much time I put into this project subsequently ignoring her for the most part. Call me a little OCD when it comes to architecture, development and programming.

So, I first thought, "Hey, how hard could it be?" Yep, I thought the job would be hard. I thought it hard in the sense that I had to carry tons of bricks from one side of the yard to another by hand -- simple job, just ominous. The Android is written in Java and the iPhone app needs to be written in Objective-C. I had thought, the two languages somewhat similar since they were both "object-oriented" and it might be straight forward. I'd just have to block out a bit of time to carry the bricks.

 My conclusion? F8cking ridiculous!  My first conclusion was that I should hire some immigrant to do this work, just for the shear tenacity it would take. But I don't have any money, so that won't fly.

First I thought, I'd like to reuse the same code I had in Java for the Android. A lot of the code deals with the server and internal data structures that in a MVC sort of pattern really have not a lot to do with the UI.

Now, I've done a lot of compilers in my time, and figured I could probably get somewhat of a good translator going. But how much time do I have really? My ambition started to wain. Then, one day, there it was!  Like playing the barn hay bales with bare feet, I caught the needle in a callus, I came across a Google project called j2objc, and I thought my life would change. These guys used the Eclipse parsers to generate abstract syntactic trees and already had several generations of it. It did translations of Java into some wacked version of Objective-C. They just didn't do any UI stuff, and rightfully so, because the respective UI components can really be different. Anyway, this was the boost I needed. I put everything else on hold to concentrate.

In hind sight of more grey hairs and further withering eyesight, the only thing that I can say about this project is that it helped me clean up my Android code. Just to even *think* about using j2objc, I had to refactor the Android code so that I separated most of the UI code to the "front" end and factor out the communication (HTTP, cough, cough) backend and I'd be set!

I couldn't be further from the truth.

Refactoring the Java code was actually fun. I was using Eclipse for my IDE mainly because it seemed to work well with the Android SDK. All I can say, is that I spent a lot of my academic life studying type systems. Type strict languages are shunned by students today and barely get taught at all any more, but the benefits are so completely obvious. Originally meant to help compilers squeeze as much efficiency out of your code, they are most beneficial especially in *mostly* strictly typed languages in the tools that help us code. The beauty of this Eclipse for Java IDE are the code generation and translation tools, and they are simply fantastic! I mean, gone are the days of that *unfortunate* method or variable name. Just a mouse click an a few keystrokes away, and it's renamed. Whether for better or for worse, but insurmountably so, it is correct and complete! Imagine trying to do that with C or some dynamically typed language, like Ruby (grrrr) for instance.

Anyway, I got the code refactored in about a day and made sure it still ran on the phone. I thought I was halfway there. I had to implement a good portion of the front end thingys like some alert dialogs, a few list UIs, and some text based things. On the other end, I had a couple of methods I needed to do HTTP gets and posts to the server. The process left me with a neat TODO list that manifested itself in the form of abstract method definitions in two classes, one for each end. Okay, I thought. I just put the bricks in a nicely separated pile ready for me to borrow that motorized j2obc wheel barrow and take them to the other side of the yard.

My first problem, I don't own a Mac OSX. Oh I did at one time, but the upsale tactics on the thing got me pissed off, and when my last one died for the second time, it got relegated to the bone yard in the attic. So, I borrowed my girl friend's. Now, talk about pressure, as she actually uses the thing, so time is of the essence. And, she was going away for the Memday weekend for a graduation and was leaving it here. Score! so, I thought.

First problem is that it has OSX 6 Snow Leopard. Nothing iOS on this thing actually worked. I had the biggest problem finding Xcode for it. My gawd, this thing is only a couple years old! I couldn't get Xcode 4, so this thing has got Xcode 3.2, but I went through about 30 blog posts to try to find out how to get a new enough version of the iOS SDK. The highest I could get was iOS4.3, and that wasn't easy. I wasn't shelling out some $120 for Mountain Lion especially on a machine that is working fine for its owner, who isn't a geek like me.

Next, j2objc. Requirements: Xcode 4+, iOS5+, clang 2+, and a few other things. I tried numerous things to get j2objc to compile, from jumping back and forth to Linux, etc. Finally after a couple of days. Remember, this is the tool that is going to do most of the work for me, and there was a slowly developing crevasse in the yard. I installed llvm 3.2 on the Mac, and what some of the kids call today "monkey patched" Xcode into believing it existed and to use it. None of that effort was obvious and easy either. Remember, I don't have any money, or time since the girlfriend will be back on Tuesday, and I'm heading out on a marketing trip (of which I did nothing for) and a kayaking vacation out in Idaho for 10 days. So, there is no time.

I was able to do the j2objc translations on Linux, because that is an all Java implementation. However when it came to linking the results together, it had to be on the Mac Box. I just could not get j2objc's JRE emulator to compile and link on the Mac. For one thing it needed NSRegularExpression, which apparently wasn't introduced until OSX7. I'd though, okay so I won't use them and I'll just cut them out. However, their implementation of other Java classes depended on it heavily. So, in the end, I took the already compiled binary from their site, and with the new LLVM compiler I got one link error, which I solved by creating the following:

void obj_setProperty_nonatomic() {
}

This resolved an unkown symbol of the same name, and no matter if it would make the whole thing crash, I just wanted the project to compile, and it did. We are nowhere near execution.

Then, began my foray into the land of Objective-C. All I can say, is WTFF? This has got to be one of the most hideous, heinous, horrible languages I've ever seen and laid my fingers on! How do people code in this monstrosity? Okay, being a *weakly* typed language, it has some hope with Xcode, but nowhere near the effort you get with Eclipse on Java. And the problem is you can get away without it in Java, in OBJC you need help. WTF? I mean, what caused some language designer to split the method name up among the arguments, as if that were some clever thought that somebody probably awarded with a PhD. I mean, really? I've dealt with some pretty horrible languages, like BCPL, and a few others, but none of them come close to this monstrosity. Who the hell wants to type out names like:

[self eatMyLunchWith:@"Joe" atPlace:@"Chatterbox" atTime:@"12:30" andSubject:@"Life"];

I mean, can you really read that? In most understandable languages that would be something like:

this.eatMyLunch("Joe", "Chatterbox", "12:30", "Life");

or

(eatMyLunch "Joe" "Chatterbox" "12:30" "Life")

The only language that comes close to this is Smalltalk, which would be

self eatMyLunch  with: "Joe" place:"Chatterbox" time:"12:30" subject: "life"

However, in cases where it didn't matter those arguments could appear in any order. Not so in the Objective-C case. The above expression is effectively the following in a language that accepts a colon (:) as a literal character:

this.eatMyLunchWith:atPlace:atTime:andSubject:("Joe","Chatterbox","12:30","Life");

So, why not just have that syntax, so it's bloody succinct and understandable? The biggest problem we have here, is that we don't know what the first arugment is, really. Is it "joe", but the definition of that looks like this:

-(id) eatmyLunchWith:(NSString *) person atPlace:(NSString *) place atTime:(NSString *)time andSubject:(NSString *)subject {

};

Anyway, you get my point. I understand the underlying method to the madness is that you are sending messages to the object, but really does the coder really need to know that? Especially when you aren't going at it in a Smalltalk fashion? The only message you can send is 'eatMyLunchWith:atPlace:atTime:atSubject:' You can't split it up, and if you did you'd have to curry it up with brackets, which would make LISP look good. Oh and don't forget the final ":" or you'll get a "Unknown Selector". Sometimes I wonder.

The next thing is Xcode. Granted it is an aging IDE, but it has some serious navigation issues. This may have more to do with my Linux environment is 3 screens wide, and all I have is this lousy Mac laptop, but I couldn't figure out how to use it without getting cluttered really quickly.

Next is the C part of Objective-C. I'd routinely get SIGABRT signals and hardly an indication of where they came from. Back to the days of GDB and reading into the C stack. Gack!  And with the Delegate stuff being thrown around it's just confusing. Apparently, there is some convention where the first argument is always the "sender" if the "message", but that's not always the case. This burns you more than getting hit on by your girlfriend's best friend, more than once.

After a while of pulling teeth, nose hairs, drinking way too much coffee, sitting in a chair until my legs hurt and my eyes bled, and my ass swelled, I gave up. I use RubyMine for my Ruby on Rails projects and during the last update, they mentioned something about RubyMotion, which I had thought was just a Javascript tool for iOS Webkit.

Doing a bit more research on it due to needing a break I found that you use it to develop for iOS in Ruby and you may include Ruby gems. I'm sure there are restrictions, but how cool is that? I don't have to code in Objecitve-C? It actually compiles its result directly into the OBJC framework, either into Objective-C or assembly code. I'll take it, and a beer.

So, that is event that made the definite point at which I, bleary eyed, tired, wigged out, frustrated, downtrodden, and worn out, gave up this project. Well, at least until I get back from the kayak trip.  Although, I'm sure there are obstacles, RubyMotion might make it easier. I'm not a great fan of Ruby, but there is a ton of support out there, and tools like RubyMine make the job a lot easier and almost palatable, and there are a plethora of GitHub junk out there that is somewhat useful, although you spend a lot of time fixing other peoples' code.

The unfortunate reality is still, you have to pay if you want to play in the iOS biosphere. You still need a Mac OSX7, which can be upwards towards $1K-2K and RubyMotion is $200.  They say it's that one price forever. However, if you want updates it's that price per year. Hell, if a Mac goes really goes that obsolete in less than a 2 years, to where nobody will support it, you'll need them. If you want RubyMine, which has support and tools for RubyMotion, *is* worth it  at $70/year. However, RubyMine has nothing to do with a Mac and you can use it on as many machines as you want. Why you would want Windows, I have no idea. I tried that as well, and that's another story. Oh, and if you want to put your app on a iPhone or iPad, even for testing and personal use, you need to pay Apple $100/year.

What gets me, is how do people develop anything for this iOS platform? And if so, I hope they are making lots of money, because, it's f&cking painful. Also, I tried looking around for "widgets" and barely none exist that I could use. The ones I did try wouldn't even compile, and most said they were compatible with all versions, but hey, they were not. And some of the code out there is horrible, even as horrible as Objective-C syntax really is. Did these  people really get Computer Science degrees in a Cracker Jack box? I know, I know, I'm old, I'm typed, I'm structured, I use vi (not vim, vi).

So, it's time to put away the girlfriend's MacBox in preparation for her return. It hasn't seen that kind of use and probably hasn't rocked the fans that much since it came from the factory, all those many *months* ago. It's time to get back into and enjoy real life, and get ready for this drive across the nation in which I may talk to some people about Busme! and the kayak trip. But first today. A BBQ.