The Blog




The Register on Outlook Express : So, farewell, we've always hated you anyway. And if you ask us, people using this malware magnet want their heads examined.

Social Software : Joi says email is officially broken because 17% of messages are rejected as spam. Never mind the false positives, the point is that your average F500 employee spends 3-4 hours per day using email, almost 50% of email is spam and 30% is occupational spam. Email volume is growing at 30% per year, invading our time and effectiveness. Email is no longer a productivity tool.

Outlook is bleak - Where do you want to go today? Anywhere but Outlook! I got back last night from a two-day vacation to over 2000 emails in my inbox. Over 1300 were spams correctly tagged as such by our server's Spam Assassin. Of the remaining mail, several hundred were" real" messages, and another several hundred were debris resulting from the latest round of Outlook viruses. Outlook is a joke. No sane computer user today should use it.

Kevin says the SoBig virus may be the last straw and We have to confront the reality: either email is broken, Microsoft's email software is broken, or those two statements are the same..


This is all quite sad. Email is so good. And right now it's so broken. I wish I knew what the answer is. But right now I don't have any solutions except to keep fighting the bad side with technology and fighting the bad social side with rants like this. [from: JB Ecademy]

In Animal news today, Giant gerbils infest China A.N.Expert writes, "Up to 16" long, the Giant Gerbil communicates with quick, rapid foot thumping and high pitched whistling". Not unlike your average sysadmin then... [from: JB Ecademy]

Do you run a corporate anti-virus or anti-spam firewall that auto-responds to the apparent sender? Do you have an auto-responder "I'm on holiday" message setup? Does your company auto-respond to all incoming emails with "Thank you for your message, we'll get back to you"? Do you have an auto-responder that says "I've got your email, I'll read it later"?

Do you know anyone who has, uses or manages any of these things?

Well, PLEASE TURN THEM OFF.

They're broken. They send messages to the wrong people. They lie. And they add no meaningful value to communication.

All they do is clog up people's email systems and waste their time.

You've probably guessed by now that the combination of managing a bunch of Ecademy addresses and mailing lists, using a long lived private email address, the holiday season , the SOBIG.f and Blaster viruses means that I'm getting more than my fair share of rubbish, useless emails. And I'm sick of it.

See also this report in the Register. [from: JB Ecademy]

This time it's California - Silicon Valley commuters.

Wi-Fi to ride the rails [from: JB Wifi]

Armed with a Mac running some free tools, this guy tested what it would take to break his own WiFi setup. It starts with an AP with SSID turned off, Mac filtering and WEP enabled. Pretty much everything we would tell somebody to do to secure their network.

Here's the conclusion.

.:[ Security-Protocols ]:. : Post Mortem
I hope this little experiment gives you some idea of what you are up against when relying on the built-in security measures of 802.11b. Using inexpensive hardware and freely available tools, a typical Wi-Fi network can be easily cracked in a mere hour and a half (although it will probably take a bit longer on average, depending on how busy the network is, potentially offset by a bit of luck).

What does this mean for wireless security? Should we run screaming to our system administrators and toss the whole lot into the garbage? Of course not. This whole exercise is presented to drive home this point: If you are concerned about wireless security, you must use strong application-layer encryption and authentication. Much of the rest of this chapter details other freely available tools that you can use to protect your network and your wireless users against these attacks.


So if you're concerned, use SSL for your email and a VPN for any corporate access. [from: JB Wifi]




According to Wireless Rides the Rails, GNER is introduing WiFi on it's London to Scotland trains powered by a Satellite broadband connection. So whether Pierre Danon thinks it's necessary or desirable, it's happening anyway. There's no mention of which WISP will be providing billing and authentication services. [from: JB Wifi]

If you haven't yet discovered reading web news with RSS, head on over to Weblogs Compendium - RSS Readers, and try a couple of programs from the list that suit your PC platform. I can recommend Amphetadesk, Newsgator, Netnewswire. [from: JB Ecademy]




I'm usually fairly up beat but On our oncoming future dystopia is quite the most depressing piece I've read in a long while. Tell me the view through the looking glass isn't really like this.

"the former Soviet Union proceeded in the last twenty years from totalitarianism, through a period of kleptocracy and into a semblance of democracy. The US seems to be going in an exact reverse progression. If the Administration's program to concentrate corporate power and rape our natural resources isn't soon reversed, the US will be a kleptocracy." [from: JB Ecademy]




If you're wondering what is RSS, or you've seen the little XML gifs on Ecademy and wondering what they're for, check out Lockergnome's RSS Resource

There's a full list of known RSS readers and lots of other info. Needless to say the news on the site is available in RSS. [from: JB Ecademy]

A couple of people expressed surprise that their profile is showing up in Google. Some clarification is in order.

1. Anyone can hide their profile. It is then never viewable.

2. The main part of your profile is visible to anyone including guests who are not logged in. Which means including Google.

3. Contact information (phone, mobile, email, first line of address) is under user control. Even if these are set to visible they are still only visible to logged in Power networkers (including green star)

4. Some of this information is also available as machine readable FOAF RDF-XML. This is under user control. This also includes links to people in your network who have enabled FOAF. These links never show email address but do include a cryptographic SHA1 hash of the email address. FOAF data respects the settings in 1,2,3 for both the main person and any links to others.

I think this achieves a good balance between exposing data and privacy.

I'd like to propose a single change which is to make the FOAF default on rather than off. Since there is exactly the same data viewable in html as in XML, I don't see any problem with this. However at Christmas when I started this, it kicked up a small storm.

All of this (with the exception of FOAF) is broadly similar to the approach taken by the other sites such as Ryze.

Comments please.
[from: JB Ecademy]




Results from the Defcon Wireless Shootout

35 miles from a mountain down the Great Basin Highway. "On Friday, August 1, the antenna was built completely from scratch in the desert, on the side of the mountain, in the rain. The large horn was comprised of metal pipes and window screen wire mesh. It had a transmitting element made from cardboard, duct tape and aluminum foil -- and both components worked spectacularly. A bath towel was used to provide shade over the laptop screen, which was otherwise unreadable in the glare of the desert, even with the clouds overhead."

And 5 miles with a pair of cantennas. [from: JB Wifi]

The Register : Some 20 respondents said a 'Wi-Fi hot-spot' is something that has been left out in the sun too long and gone a bit rank.

But at least 30% got it right.

Methinks the Hotspot operators could do with a little marketing in the name of basic education. If the customer doesn't know about what your selling or even what the product is, then they won't buy it. [from: JB Wifi]




Google News Alerts breaks cover from the labs.

But come on Google, where's the XML or RSS version of Google News and News Search? We know you're thinking about it. [from: JB Ecademy]




Richard Allan's Weblog is from another UK MP. Who's next? [from: JB Ecademy]

Now this I like. Stupid Security: Exposing Fake Security Since 2003 Does exactly what it says on the tin. I hate security, it just gets in the way. And there's always a way round it. [from: JB Ecademy]

One of those re-installing Windows horror stories. dive into mark tells it with humour. [from: JB Ecademy]




The XML specs say that you must reject a file that is bad XML. This is good for XML because it encourages people to produce good well formed XML. But our goal is the data not the spec. We're also likely to be collecting embedded rdf in web pages among other things, where the overall file may not be XML at all. So there's a need here for an "Ultra- Liberal RDF parser" like the one Mark Pilgrim has produced for RSS. see http://diveintomark.org/projects/rss_parser/ Most current RDF parsers are built on top of XML parsers which will reject bad XML so you'll never see the data.

If you find bad XML or bad RDF then tell the author. Don't just ignore it or dump it. They will probably be very thankful. And if you're generating RDF then check it with the W3C validator http://www.w3.org/RDF/Validator/

We've learnt a lot from RSS about how to play nicely if you're writing aggregators, spiders and scutters. All this is relevant to FOAF along with some other issues.

Bandwidth
The first thing to be aware of is bandwidth. Both yours and the sites your collecting FOAF from. The simplest tweak is to support gzip encoding. foaf, rdf and xml files are essentially text so they compress well. And most web servers out there support gzip encoding if the client tells them that it understands gzip. This should be completely transparent to your code, but make sure your http collection toolkit supports gzip and uses it.
See Mark Pilgrim's page about this.

There are two standards for applications to make known to a client that data hasn't changed. etag and last-modified. Your scutter should store these against the feed data and put them back into the headers when requesting data. If the server is properly setup it should use these to return a 304 not modified header rather than the full file. See this tutorial on using them

Even if you don't get these headers, it's useful to know if a feed has changed. One way is to generate an MD5 hash and store it. Then compare it next time you visit.

Use HTTP Codes
There are a set of well specified HTTP codes that servers generate. Use them. Particularly important are 301 Permenanent redirect and 404 not found. If the server is telling you that the data has permanently moved, use that fact. And if the file is no longer there, don't go on asking for it repeatedly.
Mark Pilgirm has a set of test files for all the different codes.

Play Nicely
You're writing a robot. So pay attention to robots.txt

Some sites, like Ecademy serve large numbers of foaf files. It's not fair on the server to hammer requests at them as fast as you can. This is effectively a denial of service attack and webmasters who notice this may well band you permanently. It's good practice to wait a second or two between successive requests to the same host. Note that some hosts use sub-domains like mine.domain.com, your.domain.com. So Wait 1 between calls to domain.com

Refresh times
RSS can change quite quickly whereas FOAF probably won't. So a refresh strategy is less important. One good approach is to start with a refresh of say 6 hours. If the data hasn't changed (see etag, last-modified) then double the refresh to 12 hours up to a maximum of a few days. If the data does change go back to your minimum refresh period.

There's an RSS problem where lots of client aggregators all collect feeds at :00:00 after each hour. If they're clocks are reasonably well synced, popular sites will get hit by large numbers of requests at :00:00 So when you set up your cron job pick a random(ish) time in the hour to start.

Caching the data and default pages
I think a lot of FOAF applications are going to collect the data on the fly. This means that every hit on your application is going to generate a hit on the data source. Now given that you probably have lots of alternate pages to look at I don't think this is going to be that much of a problem. But think carefully about the bandwidth implications for the source. If you get slashdotted and you,ve coded well to withstand it, you don't want to slashdot the source in turn. Probably the most obvious danger is having a default page with a link to a default source.

The alternative to this is to cache the data locally. On the surface this looks like a good approach for several reasons. But it leads you into a set of issue to do with how current the data is. And these issues are still being worked out. Take an example. Say you collect data that says that A knows B. A week later A falls out with B and they both remove the foaf:knows statement. Your data is now wrong.

Mirrored from the Ecademy FOAF club




TypePad News: TypePad Features and Pricing Note the auto-FOAF support. [from: JB Ecademy]

Here's one to worry about. What legal responsibilities do hotspot owners have for activity conducted by their customers?

This is prompted by the discovery that Wayport run an open email server for their customers and T-Mobile intercept email destined for other servers and route it via their own email server (I think). Both of these are reactions to a real need for their hotspot customers to send email. But both are effectively open relays with no authentication. How much information and logging do they really have in place to positively identify the customer?

The real answer here is for the mainstream ISPs to support SSL and STMP-AUTH so that their paid up customers have access to email services no matter how or where they connect to the internet. At home, work or from a hotspot. Until then hotspot providers need to provide some solution so that hotspot users can send email. But just giving blanket access to anyone using the hotspot is not the answer. [from: JB Wifi]

1 to 20 of 3860