Home › Posts tagged outlook

outlook

internet e-mail is not secure

Posted on by — 1 Comment ↓

From time to time I have moaned and groaned about the lack of security regarding e-mail. Oddly enough, many people who use e-mail on a daily basis for sensitive business communications don’t realize that, generally speaking, e-mail is, by default, not secure. Nothing is magically encrypted when you send or receive e-mails and, to the extent someone can intercept an e-mail, it can be read very easily. I don’t recall who said it, but I do remember the phrase that e-mail should be considered no different than sending a postcard – anyone along the way will be able to read it.

Oddly enough, for some reason, most folks in the business world – including lawyers, bankers, VCs, as well as very smart technology folks – either are not aware of this issue or, if they are, don’t consider it to be much of a risk. To illustrate – I was talking with someone the other day about the marvels of Blackberries. One reason, I was told, that Blackberries have gained such widespread acceptance is their bulletproof security. From what I understand, transmissions to and from the devices is encrypted using some very serious, very heavy duty technology. I pointed out, however, that the encrypted communication was only between the Enterprise Server and the device. So, while it was great that no one could pick up the wireles signal and eavesdrop that way, it would be quite possible once the e-mail made it back on to their mail server and was transmitted via SMTP, at which point it would no longer be encrypted at all (unless other measures had been taken) between their mail server and to the recipients mail server. So although it might be quite secure for e-mails within the organization, for external e-mails, not so much. That being the case, I questioned the value of a partial encryption path for external e-mails. To me, it seemed like armor plating your body, except for your head and chest. I ruminated that it is a question of when, not if, lawsuit or some other form of liability would attach due to someone exploiting this lack of security.

So I read with interest an article on reportonbusiness.com about insider trading as a result of IT folks hacking e-mail:

Regulators revealed yesterday that an information technology analyst working at TD Securities Inc. in Calgary was reading the personal e-mails of investment bankers working on the deal, and bought Synenco securities using undisclosed information about a pending offer from French energy giant Total SA.

…

While it appears no senior officials involved in any of the recent cases knew their companies’ confidential information had been breached, regulators say firms are responsible for ensuring critical e-mail is not intercepted.

I didn’t see anything in the article about the consequences for the companies. It will be interesting to see what happens. Then again, according to the article, this isn’t the first time this sort of thing happens.

All that being said, there are tools to ensure that e-mails and other communications are made security. There are built-in encryption tools in Outlook. There is PGP. There are services offering encrypted e-mail and other communications through access to secure websites. The fact of the matter, however, is that they’re all an incredible pain in the ass to use. You need to securely exchange public keys. You need to sign up for the web service. You need to go to the website to read and reply. And so on. So, in the meantime, not much is done and millions of unencrypted, easily read e-mails with highly sensitive and confidential information continue to flow through the ether. I imagine at some point something on a much larger scale will occur, and at that point, the imperative will be much stronger to implement security measures for e-mail (at least sensitive/confidential e-mails) or to replace it with something stronger altogether. My suggestion would be that firms exchanging sensitive information by e-mail seriously think about adopting such measures before that. Or run the risk of being the poster-boy for that imperative.

Changes in Daylight Savings Time

Posted on by — No Comments ↓

Most of you are probably already aware of the legislative change affecting daylight savings in North America. In any event, the nub from an internal note:

The U.S. Energy Policy Act of 2005, passed by the U.S. Congress July, 2005, extended Daylight Saving Time (DST) in the U.S. by approximately four weeks. This change was similarly adopted by the Government of Canada in order to harmonize time zones across North America. As a result, beginning in 2007, DST will start three weeks earlier on March 11, 2007, and end one week later on November 4, 2007, resulting in a new DST period that is four weeks longer than previously observed.

(slight correction by the way – time is governed by the provinces in Canada – see for example the relevant Ontario regulation).

Apart from changing your clocks, you should make a note of whether any patches or updates to your computer systems are required. I know I’ve already seem some traffic on how MS Outlook and Blackberry stuff might need patches as a result of the change. You might also want to highlight this when making appointments during the changed period.

In addition to that, there are also some articles, such as the one in Technology Review, that warn of other potential glitches:

Cameron Haight, a Gartner Inc. analyst who has studied the potential effects of the daylight-saving bug, said it might force transactions occurring within one hour of midnight to be recorded on the wrong day. Computers might serve up erroneous information about multinational teleconference times and physical-world appointments.

”Organizations could face significant losses if they are not prepared,” the Information Technology Association of America cautioned this week.

Dave Thewlis, who directs CalConnect, a consortium that develops technology standards for calendar and scheduling software, said it is hard to know how widespread the problem will be.

That’s because the world is full of computer systems that have particular methods for accounting for time of day. In many, changing the rules around daylight saving is a snap, but in others, it may be more complex.

”There’s no rule that says you have to represent time in a certain way if you write a program,” Thewlis said. ”How complicated it is to implement the change has to do with the original design, where code is located.”

…and don’t forget international stuff:

Also, the change originated in the United States and is being followed in Canada, but not most other nations. That could befuddle conferencing systems and other applications that run in multiple countries at once.

Update: A great and concise article on slaw with more details and better links on the changes in DST.