For those who are tuning in a bit late, Blaise Pascal came up with the believer’s so-called ‘rational’ argument for believing (or trying to believe) in a god. The argument goes something like :-
God is, or God is not. Reason cannot decide between the two alternatives
A Game is being played… where heads or tails will turn up
You must wager (it is not optional)
Let us weigh the gain and the loss in wagering that God is. Let us estimate these two chances. If you gain, you gain all; if you lose, you lose nothing
Wager, then, without hesitation that He is. (…) There is here an infinity of an infinitely happy life to gain, a chance of gain against a finite number of chances of loss, and what you stake is finite. And so our proposition is of infinite force when there is the finite to stake in a game where there are equal risks of gain and of loss, and the infinite to gain.
But some cannot believe. They should then ‘at least learn your inability to believe…’ and ‘Endeavour then to convince’ themselves.
Sounds reasonable doesn’t it? Of course it does – Pascal has used logic here even though he is coming to an irrational conclusion; the key is logic.
However there is only one small area where Pascal’s wager makes any kind of sense – if believers burn atheists at the stake (which did happen during Pascal’s lifetime) then it makes perfect sense to pretend to believe to protect oneself.
However it does make two rather large assumptions :-
That this god isn’t able to determine the difference between believing and pretending to believe. Which kind of invalidates the notion of an omniscient god.
Which god? Given the childish jealousy that most gods exhibit, pick the wrong one and you’re in just a bad a position as someone who doesn’t pick at all.
And the very first statement – that reason cannot determine whether god exists or not, is completely wrong. Reason requires evidence for the existence of something, and the best evidence for the existence of god is the belief of the believers which isn’t evidence at all.
This question popped on Twitter just now; I’m not sure the question was a serious one, but as it happens I can answer the question as if it were serious. I’ve been running relatively small mail servers for nearly 30 years, so do know a litle bit about it.
This of course does not cover lots of “bolt ons” to email such as SPF, DKIM, DMARC, and that’s just the simple stuff.
To keep things relatively sane, I’m going to gloss over an awful lot of details – for example, there are all sorts of ways of composing and sending emails, but I will assume you’re using some sort of web interface such as Google Mail.
So you compose an email with an interesting picture or two, and click “Send”.
Hang on a bit! You also did some technical stuff when you entered an email address into the “To” field (if you just enter someone’s name, something somewhere is changing that to an email address) and possibly something summarising the email (or trying to get attention) into the “Subject” field.
Those two headers you have filled in – ‘To’ and ‘Subject’ – are just two of a whole collection of headers that are usually invisible. They are invisible because your mail client is hiding them from you; for good reasons as they’re almost always an unnecessary distraction.
But when you have to diagnose an email problem, seeing the full set of raw headers is kind of essential even if it is dead simple (for the relatively technically sophisticated) to forge headers.
For example, if you set up a dedicated mail client rather than use your mail provider’s web-based mail client, you will have to fill out your own email address (to go into the “From” field). You can fill anything you like into that field although you are unlikely to get a reply
If you fiddle with your mail client enough, you will realise that the “To” field can be changed to a “Cc” field or a “BCc” field. All three take email addresses, and can be used to send an email to someone but they operate in very slightly different ways.
The “To” header is for the main audience of a message.
The “Cc” header is for an audience who should also see the message, but perhaps don’t need to take any action based on the email.
The “Bcc” header is a bit special because it isn’t added to the raw mail message as a header, but is instead used to compose the envelope listing who should receive the email. If you need (or should) keep the list of people receiving an email secret, or just want to avoid an inconveniently long header for people to read then use the “Bcc” header.
Although your mail client may hide the details, email addresses look like :-
email@example.com (a “pure” email address)
“Some Name <firstname.lastname@example.org” (as normally formatted)
The Message Submission Server
So you click on “send”. What happens then?
The first thing that happens is that your mail client converts your email (attachments, rich formatting, etc.) into plain text which is why a file attachment just under your ISP’s limit on mail sizes can exceed that maximum.
To the top of that plain text version of your message, your mail client attaches some headers (again in plain text). In addition your mail client will prepare an “invisible” envelope independent of the headers – it contains just the address(es) you want to send to, and your own address.
Finally the mail client is ready to talk to the “mail submission server”. It will login (usually) with your credentials, and sends the message to the server using the “Simple Mail Transport Protocol” (SMTP).
The mail server adds your message to a queue and before it says to your mail client “Okay, I have it”, it will make sure that the message is safe on disk. Mail servers go to a lot of effort to make sure your messages don’t get “dropped on the floor” even when the operating system they are running on crashes.
After you have submitted a mail message to the message submission server, the message is held in a queue. This is significant because email is a store and forward messaging solution, so every server your message journeys through will make sure it is stored on disk before saying to the server sending the message “Yep. Got it.”.
In theory this should mean that messages never get lost “in the system” (although practice is often different to theory). The store and forward style of architecture suits the era that email is from – back in the 1970s when email could (and did) traverse many different kinds of network rather than “the Internet” that we have today.
What does that mean today? Amongst other things, it means that whilst you may think that your message only visits two mail servers – the one belonging to your ISP and the one belonging to the recipient’s ISP – and that is certainly a valid architecture for very small organisations.
But it does not work so well for larger organisations that may handle millions, or hundreds of millions of message a day. Summing up a large architecture without actually seeing an architecture diagram for every single ISP and large organisation on the Internet is going to be a bit hit and miss, but I’ll give it a go.
Your message submission server will probably simply hand your message off to a server responsible for sending email messages across the Internet. If it cannot send to the recipient’s receiving mail server on the first run through the queue, it may well just hand the message off to a “slow message server” (processing large queues is a bit of a drag).
In either case, the recipient’s server will accept the message and then hand it over to a “mailbox server” that the recipient will connect to.
And the journey is over. At every stage, reliability is favoured over speed.
How do servers send your message to each other? Using that SMTP standard I mentioned earlier.
The speed of email is a good topic to cover here. Speed is not what email is about in the same way that the postal service for physical letters is not about speed. It’s about reliability
Your messages may be readable by the recipient within 5 minutes 99 times out of 100, but that 1 time may take a day or two. That’s just the way that email works – if you want instant messaging, use an instant messaging client.
At no point have I mentioned encryption, and that is intentional. At no point is encryption required; email was designed in an era when computers were far slower and encryption was expensive (even though it was far weaker).
At every point, servers are trusting that the senders are not lying and the original sender is trusting that nobody is snooping on their emails.
To correct that there are a whole bunch of optional add-ons to the email standard to deal with that. But that is a story for another day.
Liam Fox has claimed that Trump protesters have “embarassed” themselves by protesting Trump’s visit to the UK. He claims that we have a tradition of being polite to guests (at least until they throw up on the carpet, piss in the wine, and try to have sex with the host).
Well, I didn’t invite that jumped up rancid little toad who is Putin’s lickspittle and quite possibly the closest thing we’ve seen to a major free world leader being a Nazi. So I am under no obligation to be polite to the bankrupt crook.
Besides which, with his unreasonable and unhinged attack on NATO, Trump has been pissing in the wine, so it would not be unreasonable to slam the door in his face. Of course I’m not being “diplomatic” but I’m not a politician so I’m not being paid to be polite to the kind of person resembling that which you instinctively scrape off your shoe.
To USians who might feel a bit insulted by how their president is being treated; well if you did your job properly and didn’t elect someone with the brains of a pea-sized petrified panda turd who separates children and puts them in concentration camps then we might treat them with a bit more respect.
During a recently on-line rant about anti-abortion terrorists, I happened to trip over some statistics on the rate of mortality during childbirth (the “Maternity Mortality Rate”) from the WHO. And being the kind of person that statistics interest, I spent some time looking into them; indeed I got so interested I transcribed some of the raw figures to generate a pretty graph :-
This obviously excludes many countries – what we could call the developing countries. The countries included (which you’ll have to peer closely in order to see – sorry about that) are all rich. At least relatively speaking.
Just look at the USA! Down with the also-rans amongst what could be called the relatively dysfunctional countries at the fringes of being considered “developed”. Now you could argue that there is something special about the reason why the USA doesn’t have a single-digit MMR like the overwhelming majority of developed countries. I can think of a few possibilities myself :-
Perhaps the USA is the only country in the world to tell the truth about it’s actual MMR and all the other countries are lying. Perhaps. I am not going to argue there isn’t a bit of shady practices going on with the figures in some cases, but these figures are produced by statisticians and as an overall group statisticians don’t like lying about numbers. Yes there is the old saw about “lies, dammed lies, and statistics”, but the source of that distrust is the twisting that politicians apply to statistics to support their lies.
Perhaps the USA didn’t read the instructions from the WHO properly about what kind of deaths to include in their returns and they’re including deaths that other countries wouldn’t include. But whilst I’ve not read the instructions from the WHO about this, I have read other instructions on statistics and they usually go into excruciating detail about what should and should not be included. It’s possible that the USA handed this little job over to a complete dumb-arse, but it doesn’t seem very likely.
The WHO is anti-American and decided to inflate the figures. This is just laughable – the WHO isn’t going to risk getting called out by doing something so obvious even if it really was anti-American.
Sometimes the most obvious reason is the real reason – and here the most obvious reason is that the US health care system sucks.
There is additional evidence to show that – the WHO figures cover years other that 2013, and the US figures are consistently bad and getting worse.
But how can this be? The USA is one of the wealthiest countries in the world that spends a ridiculous percentage of it’s annual GDP on health care. It also produces many healthcare innovations and undoubtedly has improved maternal care at some point with some new technique. The really rather obvious (although it really needs to be tested) is that healthcare in the USA is divided into three.
There are those who have full insurance, and this group probably gets pretty good healthcare.
There are those who are covered by government schemes and this group probably gets reasonable healthcare.
And there are those who fall between the cracks – they’re not covered for various reasons – and their care is abysmal and probably limited to emergency care only. Which can sometimes be too late.
But when you come down to it, if you are pregnant it may be worth avoiding the USA until you’ve given birth. And if you’re already in the USA, it may be worth thinking about a long break somewhere where they have a healthcare system that doesn’t suck.
One of the interesting aspects of Heartbleed are some of the criticisms of OpenSSL, the relevant developers, and open source.
Isn’t this the fault of the OpenSSL developers?
Yes, but …
Whilst it is very easy to blame the OpenSSL developers, and ultimately they were the ones who made the mistake of introducing this vulnerability, it is not quite that simple.
What has become clear is that the OpenSSL is chronically underfunded with less than four active developers (only one of whom is full time). This is despite the fact that OpenSSL is probably in roughly 1/2 of all software products including products from technology giants such as Cisco, IBM, HP, Lenovo, etc.
If OpenSSL is underfunded, everyone who makes use of the library in their products should look into why they should not be contributing towards the product. Surely every one of the technology giants could afford to contribute the cost of one developer each towards the project?
Isn’t this the fault of the open source methodology?
Every time a vulnerability crops up, someone blames the development model for the vulnerability. But when you come down to it, both open source and closed source projects contain vulnerabilities.
In theory it is possible for open source to be more secure. Because the source code is publicly available, it can be audited by independent researchers. And that is effectively what seems to have happened – a Google researcher found the vulnerability and informed the OpenSSL developers of the problem.
What went wrong is that the audit happened after the release of the code. To be more secure than closed source, open source needs to be audited before the code is released. Perhaps some automated system that checks every code check in.
Is it the fault of the C programming language?
No, it’s the programmer’s mistake.
But C does make it easy to make mistakes with memory handling although we have to remember that half of this bug was a different sort of mistake – trusting user supplied data. And no matter what kind of language you are using, if you trust user supplied data then attackers everywhere will be chortling.
Back to C’s memory handling. C is a very old programming language and expects the programmer to safely deal with memory management. The best programmers can do this safely, but even those programmers have the occasional Friday afternoon and most programmers are not that good.
A more modern system programming language such as Go or Rust would be very helpful in reducing the possibility of certain types of errors, and there’s a great deal to be said for switching to one or other.
But OpenSSL is written in C, and switching now would be very difficult especially as the OpenSSL library needs to maintain compatibility with hundreds or thousands of programs written to call functions within a C library. Even if that compatibility problem were overcome, rewriting OpenSSL in some other language is an enormous amount of work which is hard to do with just four developers.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.