A first comment is that email is not secure anyway. Maybe it "feels" safer, but it actually is not. Nowadays, many mail relay systems will try, opportunistically, to activate some SSL when the mail hops from server to server. However, on a failure to establish the said SSL, the same servers will automatically degrade to non-SSL mode and send the email as cleartext; a consequence is that an attacker intent on eavesdropping on emails as they flow will not find it too hard to do: it just is a matter of sending the right fake packet at the right point to make the SSL fails, and force the machines to fallback to non-SSL mode.
Moreover, when servers exchange emails, they usually store a local copy on a physical medium. That's part of the SMTP protocol. In older days, reliability of emails was taken seriously, so the protocol mandates that a receiving server is not allowed to acknowledge reception of an email until it has committed it to a physical medium which would resist a power shortage (in programming terms, this means that the email was written to a file and a call to fsync() was made to ensure that the data is not merely cached in RAM).
The end result is that an email containing "personal details":
- may be intercepted and spied upon by industrious attackers (rumour has it that intelligence agencies do it on a regular basis, which makes sense because that's what they are paid for -- but they most probably do it by making deals with the mail relay system owners, i.e. ISP);
- will leave traces in many systems that you don't know, ready to be revealed by malice or incompetence of people working in network organizations that you don't know of;
from which we conclude that sending the said details over plain HTTP may be a better deal in the long run. At least, HTTP traffic goes through routers which do not have a legitimate reason to store the packets on hard disks, and indeed honest routers will not indulge in such leaking.
Now a more important point is that HTTP, HTTPS, email... are just for data in transit. If you fear for the privacy of your personal data, then your biggest worry should not be that transfer operation. The real issue is that you are, by definition, sending your CV to some hiring agency that you don't know. You cannot be sure that they will keep it in a secure place and take care of it. Actually, given the average level of security awareness, it is a rather safe bet that your CV will be put on some hackable server, copied into multiple places, exchanged by emails and thus copied into multiple mailboxes of many people, and probably printed two or three times with copies ending up in totally non-secured dumpsters.
In that sense, the lack of HTTPS is not a good reason to abort the sending process, because HTTPS would not noticeably improve the overall picture anyway.
A more practical strategy is to consider that the "personal details" you put in your CV are not, in fact, private data. These will be shared with several (many) prospective employers anyway; a secret which is shared with many people is no longer a secret. Just accept it; review your CV and what you input in the form under the basis that it won't be private. In any case, people who really want to know your name, date of birth and list of diplomas already know them (for instance, it makes no sense for me to hide my birth date, since it appears in at least two places in the Journal Officiel, the official publication place for publishing laws and decrees in France). Also, 500 million people reveal a lot more about their lives on Facebook, and this (to my darwinian dismay) has not proved utterly deleterious to their well-being.
The best that you can hope to achieve is to avoid your personal details to be harvested automatically by mindless Web crawlers. For that, email, HTTP and HTTPS are all good enough -- and irrelevant.
