What’s the cause of the data anxiety? That others may look past their public physical presence and judge them based on the blinkenlights? Or, more likely, that they’re intimidated by the numbers themselves.

I understand why the information can have that effect. Things like time, distance, even kcal burned, that’s all fine. The one that’s always a little scary is heart rate (which gets displayed by the machines with electrodes in the handles, or picked up from transmitter units). I’ve always just mentally filtered it out. I’ve never felt the need to know about my heart rate. It’s icky scary of-the-body stuff. Until I looked it up recently I wouldn’t have know what a normal, resting, heart rate would be. I’ve somehow never even taken my own pulse.

This bugged me for a while. I decided I wanted to develop some kind of familiarity with my heart rate. The idea was, I’d buy a heart rate monitor and try to cultivate a checking reflex – not just during exercise, but any time. Like how you might occasionally check the time, or an unread message count.

So I broke my personal rule about not buying new tech that wasn’t a replacement for something else (it’s not replacing a watch – I haven’t owned one since my Pop Swatch popped off over a decade ago). I poured over the specs of various products and eventually got into the tech buying trap of attempting rationalise paying more for features I previously didn’t care about (GPS, computer-downloads, etc).

Eventually I decided it hold off, for now, on anything too sophisticated and went for a Polar FS3c. And maybe I was a little swayed in my choice by the fact that it’s one of the heart rate monitors sported by Edward Norton in the 2008 movie The Incredible Hulk.

The Incredible Hulk was one of my favourite movies of last year. Mainly because, by focusing on the fugitive story that drove the 70s TV series, it positioned itself as a geek Bourne Identity. Instead of a trained assassin, Banner is a renegade scientist able to somehow evade a Special Forces snatch-squad (even before his involuntary green ríastrad, a transformation only triggered after local bullies mess with his PC).

A fairly close embodiment of hacker nomad of net-lore. Have encrypted laptop and network radio equipment will travel. He can jury-rig a centrifuge in the favela for grinder-style self experimentation whenever needed. While the Hulk represents the fear of our bodies betraying us, Banner becomes someone taking steps to overcome that fear. (Like the movie hard-men able to perform surgery on themselves.)

It even has a little fun with the current conventions of the genre. Bruce empties the contents of Betty’s handbag on to a motel bed: “Basically we can’t use any of this because they can track all of it.” “My lipgloss – can they track that?”

If there’s any complaint I have about the movie it was that there was too much Hulk. I do appreciate the artistry of CGI monsters hitting each other, but the final half hour takes it a little too far. Apparently sci-fi movie budgets are such that multi-million dollar recreations of the alley-fight from They Live now seem like a good idea.

There’s no word of a sequel yet, but the tying of Hulk into the Captain America origin-story, along with the Tony Stark cameo, firmly establishes it as part of Marvel’s Avengers remscéla – perhaps as hero, perhaps villain.

The heart-rate monitor itself is used cleverly in the movie. It takes the role of a sinister countdown clock. The beeping of the watch heralding the potential for disaster. And while the watch performs as it would in reality, the movie does lie a little.

We see Norton bare-chested (a clear requirement for the role) on several occasions when using the heart-rate monitor. I assumed that the elecrodes were embedded into the strap, but a little research shows that the Polar devices use a chest strap – something I assume has been finessed away from the movie’s world for aesthetic reasons, even though strapless HRMs actually exist.

2002′s Panic Room is another movie that uses medical monitoring in this way. A diabetic’s watch shows their current blood glucose level – it’s suggested that below a certain point and hypoglycaemia kicks in. The watch is a movie fiction – we just have to assume there are wires in the body, either connected to the watch, or relayed from a sensor elsewhere.

The current, real life, version of this continuous blood glucose monitoring is something like the Dexcom system in which a cool little cyborg wart is stuck to your body and is relayed to a hideous tamagotchi-looking receiver unit (that would have looked odd even back when people still carried pagers).

I think I’ve assumed that there was some good reason that personal medical tech always had to look a little out of date, but the iPhone 3.0 preview last Tuesday showed a preview of a iPhone fingerstick (rather than continuous) glucose monitoring application.

So what happens when the device that records your medical status is also the device you use to update your social connections?

I can see some crossover with the grinder and personal infomatics (“Quantified Self”) crowd who aren’t afflicted with the specific aliments these technologies are aimed at. Just adopt the tech as cyborg gadgets providing yet another datapoint – especially for non-invasive measurement techniques.

I’m a member of a generation that’s seen the culture of internet personal sharing and disclosure occur only after our own youthful embarrassments were already behind us. Financial and medical information is private – that much is sacrosanct. Which is why I wouldn’t be surprised to see that attitude challenged over the next decade.

Imagine some ambient representation of your friends list which incorporates this information – marrying the medical telemetry of the USCMC in Aliens with the wearable contact list of clatter

It might be a represented by subtle changes in shape, and colour. Or maybe just like the changing face of BJ Blazkowicz. You might learn to tailor any real-time communication to your recipients present physical state.

It doesn’t seem too far fetched. My girlfriend allows me access to her Nike+ data (in an interesting connection, it was Edward Norton’s voice on the commercials). I’m not a runner myself, so it doesn’t ever represent useful actionable information. Yet the access itself has some meaning, some value that I don’t yet have the tools to describe.

Of course I’m still mentally entrenched in the world of risks and nightmare scenarios. You might not want to keep discretionary medical records that can be subject to discovery by insurance claims investigators. Or, in the UK, the many tentacles of the RIPA-enabled state (the current message to banks and benefit claimants alike seems to be: if you ask for support, you consent to surveillance). Maybe stories of spouses demanding an explanation for jump in heart rate for a partner supposedly working late at the office, or the panic of parents when equipment glitches produce aberrant results.

I’m cautious and conservative when it comes to this sort of thing. It can take years for the technologies, especially those encourage new forms of sharing, to find their way through the following mental sluice gates:

• How is this any different or better than X?
• Why do you care?
• Why do you think anyone else would care?
• What are the potential health/privacy/lock-in risks?
• What are the network benefits?
• Do the benefits outweigh the potential health/privacy/lock-in risks?
• Why is my preferred username already taken?

Whenever I hear about someone preserving a moment of chemical idiocy to a social website it’s usually followed by “that’ll come back to haunt them when they run for political office and discover they’ve inadvertently licensed the indiscretions of their youth to a media conglomerate”. But part of me wonders if there’s really that much value in the idea that we need to maintain some kind of plausible deniability about our lives – in the unlikely event we run for political office (…in an future where only paragons are electable).

Indeed, I recently watched an episode of The West Wing on DVD that seemed to suggests that, for high profile politicians, at best the position of well-guarded privacy will result in culture shock when your entire life is suddenly thrown open to the scrutiny by your enemies, and at worst your secrets become the things other use to influence you.

So maybe, when the issue arises, we should just relax.

Current heart rate: 69 bpm.

Maybe that cyber-security review can’t come soon enough…

Return-path: nobody@bluestatedigital.com
Delivery-date: Thu, 12 Feb 2009 16:27:33 +0000
Received: from web11.bluestatedigital.com ([70.42.50.177])
  by [redacted]
  id 1LXePM-0000sS-I9; Thu, 12 Feb 2009 16:27:32 +0000
Received: by web11.bluestatedigital.com (Postfix, from userid 99)
  id 20C3310F3190; Thu, 12 Feb 2009 11:13:00 -0500 (EST)
Received: from phpmailer ([41.210.4.187])
  by www.wecansolveit.org with HTTP (PHPMailer);
Thu, 12 Feb 2009 11:13:00 -0500
Date: Thu, 12 Feb 2009 11:13:00 -0500
To: [redacted]
From: "Mrs. Gloria Cooper" <mrsgloriacooper10@live.com>
Subject: A recommendation from a friend
Message-ID: <36237f8f8ea83d1a9e32627e8e978c15@www.wecansolveit.org>
X-Priority: 3
X-Mailer: PHPMailer [version 1.71-blue_mailer]
X-blue_mailer-http_host: www.wecansolveit.org

From: Mrs. Gloria Cooper,
Off Ring Road,
Accra Ghana,
West Africa.

Attn:Dear Friend,

I know you will be surprise to receive this mail from me as we do not know each other, nevertheless I am Mrs. Gloria Cooper from Monrovia Liberia presently residing in Accra Ghana.

I would like to apply through this medium for your co-operation to secure an opportunity to invest and to go into joint business partnership with you.
[...]

“We are currently contacting affected customers to help them clean their PCs which, as you can imagine, is a time-consuming task,” it said.

Which, while it needs to be done, is exactly the wrong way to fix this. They may as well have added “and once we’ve contacted all 16,000 of the infected users we imagine nobody on our network will ever be infected with a virus or trojan ever again.”

The proper solution I’ve long supported is blocking outgoing port 25 from dynamically allocated addresses.

Now, in theory, all receiving servers could just refuse to accept mail from these addresses. Unfortunately there’s no simple way to do this. MAPS had an RBL for this purpose the dial-up user list, the “DUL”, I’ve no idea if this still publically usable, or if it’s still maintained. Regional IP registries don’t seem to record this information in a way that’s publically queryable. You might encode it into DNS in some way, but given the pathetic level of reverse DNS deployment by many providers I wouldn’t expect that to be done.

You have to stop the spam from leaving your network. You have to block it, not at the application layer – but at the network layer. Any solution that requires effort on the side of the receiver is already broken.

Today, it seems that blocking port 25 is what the US Federal Trade Commission is advising ISPs to do as part of Operation Spam Zombies.

• block port 25 except for the outbound SMTP requirements of authenticated users of mail servers designed for client traffic. Explore implementing Authenticated SMTP on port 587 for clients who must operate outgoing mail servers.

However, the advice about port 587 seems a little confused to my mind.

The solution for “clients who must operate outgoing mail servers”, presumably those who need to send direct-to-MX mail (operators of mailing list servers, for example), is for those customers to be allocated static IP addresses, with correct and useful reverse DNS records. Just putting machines on static addresses doesn’t make them less susceptible to trojans, of course.
But it does allow for some level of “reputation” heuristics, if only to allow others to adjust their filters and back/whitelists.

Port 587, specified in RFC2476 (back in 1998), concerns how clients submit to an authenticated relay. Not necessarily operating a outgoing mail server from within the ISP’s ranges (which I take to mean a machine that performs direct-to-MX SMTP delivery).

The concept has two major benefits – firstly by separating submission and relay/delivery it should simplify the configurations and operation of mail servers and also firewall configurations. At the client end it allows you to configure the mail software on a network roaming laptop to use the same outgoing mail server without having to worry about port 25 blocking.

And note that in some circumstances it is a requirement that people relay mail though a specific, external, mail server. Some regulations require that all business mail be auditable, and usually this means using the mail server to store a copy.

If you’re already running a mail server that requires SMTP Authentication then you should make it available on port 587 as well as (or instead of) port 25. So in terms of advice – it’s not the network providing ISPs that need to be talked to – it’s the third party providers of mail relaying services, it’s the providers of mail server software, and it’s the providers of mail client software.

The second group isn’t too much of a problem. Sendmail certainly supports port 587 though its MSA (Mail Submission Agent). And, since the only real difference in protocol terms between port 25 and port 587 is that port 587 traffic must require SMTP Auth, you can get away with running another server on the other port (if that’s possible) or, as a hack, just redirect port 587 traffic to port 25 on the same address.

It’s the client software that I’d expect to be problematic. Despite being a Standards Track RFC for six-and-a-half years, I’ve never really encountered much support in mail clients.

At best, I’ve seen clients that allow you to change the port number from a default of 25 – but nothing that acknowledges the “official” status of 587. Just as a test I’ve checked the configuration of Evolution, and it makes no reference to using alternative ports at all (although you can apparently suffix “:587″ to the host name for the same effect.

Ultimately, I guess you could set up some thing locally that listens on localhost port 25 and relays on to the remote server with SMTP Auth.

If blocking port 25 is going to work on a larger scale, people need to be submitting bug reports for the software that they’re using right now.

By August these started increasing in frequency, and included a couple of attempts at guessing the root password, which (even on the unlikely chance it was right wouldn’t have worked while the ssh server was set to “PermitRootLogin no“.

Now, in the last few weeks the frequency and number of attempts has increased. It’s just getting stupid. Now more usernames are being checked – not just the standard accounts, but names that look like normal logins:

Oct  2 18:09:47 foobar sshd[15646]: Illegal user adam from x.23.51.222 
Oct  2 18:09:50 foobar sshd[15648]: Illegal user alan from x.23.51.222
Oct  2 18:09:53 foobar sshd[15650]: Illegal user frank from x.23.51.222
Oct  2 18:09:56 foobar sshd[15652]: Illegal user george from x.23.51.222
Oct  2 18:09:59 foobar sshd[15654]: Illegal user henry from x.23.51.222
[snip]

The cause seems to have been the release of a cracking tool, brutessh2. Normally I wouldn’t link to something like this – but if you run an ssh server you probably want to check the list of passwords it includes. If your password is there (for shame!) there’s a fairly good reason to believe you’ve been compromised. And if you’re running sshd and you aren’t aware of these password brute force attempts, you should probably investigate why that is.

Now, unlike port scanning (which is, in itself, just rude) brute force password guessing is a clear and obvious attempt at unauthorized access. And it’s not a very subtle one – one or two failed logins will usually get overlooked, but I’m seeing 60+ login attempts within the period of several minutes. If I’m getting frequent alerts and forwarding them on to relevent abuse contact addresses, then surely some others are too?

DShield is listing over 300 distinct sources a day for ssh based attacks (it’s not clear if that includes brute force scanning). Based of the frequency I’m being scanned (and the time taken) verses the number of ssh servers out there, there may be may more out there (maybe it’s that North Korean hacker army). Sure, the number will seem like a drop in the ocean of trojaned and worm-infected windows boxes out there, but these aren’t worms doing the scanning – these scans are coming directly from crackers using their own or (more likely) previously compromised systems. So if you spot these in your logs it’s in everybody’s interest to report the intrusion attempt to the whois-listed abuse contact.

If your network uses Snort then the following rule (via BleedingSnort) should highlight the ssh brute force attempts:

#Submitted by Matt Jonkman    
alert tcp any any -> $HOME_NET 22 (
  msg:"BLEEDING-EDGE Potential SSH Brute Force Attack";
  flow:to_server,established; flags:S;
  threshold:type threshold, track by_src, count 5, seconds 60;
  classtype:attempted-dos; sid:2001219; rev:4;
)

Anyway, to repeat the main problem with SPF: SPF validated using envelope sender addresses. This was good because it meant that validation an rejection could happen before accepting the email, but was bad because it meant that traditional mail forwarding (where the envelope sender is preserved) wouldn’t work. I wasn’t a fan of the proposed solution which involved sender rewriting.

I imagine, if this proposal goes through the IETF wringer, we’ll eventually end up with a standard SPF ESMTP extension being advertised and recognised by ”SPF2″ compliant mailservers. This will be the hook to communicate the additional information for dealing with forwards and bounces. Servers that do not advertise or recognise the extension would work as normal, and be candidates for a local whitelist.

Well, that’s similar to the Draft for the SUBMITTER extension which was submitted to the IETF in August.

SenderID, unlike SFP (or “SPF-Classic”) doesn’t validate the envelope sender, but rather attempts to determine the “responsible address” by accepting the email and parsing the header. This means that rejection can’t happen until after the email has been accepted, which is non-optimal. (And given the number of broken mailers out there that refuse to regard post-data rejections as fatal, just asking for trouble.)

The ESMTP extension allows the responsible address to be specified up-front by the submitter during transaction time, allowing for instant rejection (and then a second chance if the approved sender is not listed in the headers). I don’t know if there are any specific IP claims on this proposal, but since it’s just about the simplest and obvious ESMTP extension, I’d be surprised if there were.

Regardless of the SenderID scheme being adopted as a whole, I’d like to see this extension supported by not only the software for receiving mail, but also the software used in sending mail, just so that when the dust of the current disputes finally settle, the bulk of the infrastructure will be there.

I am delighted to announce today that UK industry has taken the lead in building a key component of the emerging global electronic marketplace: Greenwich Electronic Time – the global time standard for e-commerce. The GeT website and software will turn GMT into a user friendly e-commerce tool. Because of the Greenwich connection, it will be clearly branded as a UK service to global business, underlining the leading role UK companies are playing in the online marketplace.

The pitch for new world-wide timezones goes like this: “Co-ordinating
network-based events is hard. If an online discussion takes place between
participants in different continents there’s no concept of what would be
considered ‘local time’, and it’s really messy and difficult working out
timezone offsets. What would really simplify things (wait for it…) is if we used a completely different clock.”

At least that’s the explanation given for schemes such as Swatch .beats (a novelty which may still live on in a few online gaming groups, but I’ve rarely seen in the wild) and the optimistic New Earth Time.

Of course, the usual response to this is “hold on, there are plenty of organisations that have been working with international timezones for a while now.” The military, for example, have been using UTC, or ”Zulu” as it’s often known. I like Zulu as a term for UTC. Not only were those guys in the movie “Zulu” super-badasses, but it’s always cool to drop military slang into everyday conversation. I’ve often thought that the metric system might stand a chance in the US if people habitually referred to distance in “klicks” (km).

So promoting UTC for wider internet and business use seemed like a sensible idea. And, in fact, that was at the core of “GeT”. It’s just that they
couldn’t call it UTC. You’re not taking the lead if you’re just promoting something that’s already been in use for years. So UTC needed to be re-branded, maybe with one of those oh-so-trendy-in-the-mid-90s “e” prefixes…

GMT and UTC are usually be thought of as the same thing. Since the late 19C, Greenwich Mean Time was the universal world time base, and (as it hosted the meridian line) was also the local time zone for the UK. However since UTC is calculated using atomic clocks rather than GMT’s solar method, their values actually differ slightly. However, the “GMT” that we use today, is actually UTC.

When naming a universal trans-geographic time reference standard should
probably avoid having the name of a specific location. Something the namers of UTC specifically set out to do. But in the switch from GMT to the
neutrally named UTC, it might have felt like Britain lost out. That one of its
few victories in international standardisation had been devalued – the reminder that the prime meridian runs through London rather than Paris.

GeT was an unashamed attempt to internationally re-establish the Greenwich name as a UK promotional tool. They might as well have called it “CBT: Cool Britannia Time”.

It wasn’t about establishing a new legal time for the UK (such as removing
BST) or even updating legislation, as attempted by the failed Co-ordinated Universal Time Bill which sought to change the legal time base from GMT. It was just about renaming UTC.

And so what was needed was the magic dotcom pixie dust, the other essential element of turn-of-the-century press release – “software”. This, it would emerge, would consist of a website with a Java
applet that would update the local clock against an acurate time-source.
“Why not use NTP?” asked, well, almost everyone.

LINX managed to slightly spoil the GeT announcement by (coincidence? mis-communication?) issuing an earlier press release announcing Greenwich Network Time. This scheme seemed to consist of installing new Datum NTP servers at several London sites and (because “back-room” stuff always fails to excite journos) a Java-based web clock applet would be provided by Enron. Yes. A java-applet that would show you the correct time in a browser window. From Enron. In Java. Stop the press.

One month later, and GNP was a memory. LINX was on board the GeT bus.

Looking at the minutes of the GeT technical meetings it seems that, despite implying that this was some exciting new technology (and not mentioning NTP) that could overcome the existing software limitations holding back international e-commerce, the system was actually built on good-ol’ NTP all along.

While NTP was well known on Unix systems at the time, I’m not sure if it
was known in the Windows world. SNTP support was available in Windows 2000 (at least), but it wasn’t signposted in the native “Date/Time Preferences” utility until XP. The one thing it doesn’t offer (without a registry hack) is the ability to synchronise more than once a week (I imagine to protect those dial-on-demand users whose metered lines would be kept open. Ironic really, since the only time I’ve configured NTP under Windows was specifically to keep a network connection from closing.) Back in 1999, I believe the NetTime application was available, as well as several commercial and shareware alternatives. I wasn’t using them, so I couldn’t say if they were found lacking.

So perhaps there really was a need for a simple, Windows-based, desktop
time sychronisation app.

But, given it was NTP based, a Java applet was a really bad choice. You’d
be limited to only synchronising with an NTP server running on the same address as the webserver hosting the applet. And it turned out, that wasn’t the biggest problem using Java under Internet Explorer – the security model wouldn’t allow the applet to update the system clock.

All that remains of GeT today, appears to be an unmaintained DNS directory of public NTP servers. A TCP query of gb.public.ntp.get-time.net. (the root record of which apparently last edited almost a year ago) lists 23 NTP servers, of which 14 are still responding. This part of the scheme might actually have been useful had it been widely known about. (A couple of years later a similar round-robin DNS idea took off, now available via pool.ntp.org.)

We still have the UTC we had before, we’ve still got the NTP we had (although with wider client support). GeT is just another ghost-site in the
web archive. A branding exercise, all style and little substance. Something
that people might consider emblematic of the Blair government, of New Labour. But I think of it as the essence of what we used to consider the “new Net”. The marketeers pimping the possibilities of the newer than new, but never around to see in that future themselves. While the old net seems to stumble on as before. A rate of progress that seems to illustrate one of Zeno’s paradoxes.

On the internet, the most curmudgeonly survives. And apparently I’ve reached an age where that’s reassuring rather than disappointing.

From today I’ll be forwarding most of my mail to my gmail.com account. Note that gmail doesn’t support TLS so your mail to me will be sent in the clear. And of course, all our correspondence will be stored in a database with access controlled by a US based company, who (regardless their commitments to “not being evil”) will almost certainly roll on NSLs.

So, just thought I’d give you a courtesy heads up. Gmail has some privacy info at http://gmail.google.com/gmail/help/more.html

I imagine that for every person that informs me they’re storing their correspondence and/or addressbook in a commercial, third-party, US-based computer system, there are several who don’t. The privacy of an email is entrusted to the recipient, but disclosure more often impacts the sender. (e.g. those regrettable email correspondences between London investment bankers on Monday, as far as Hong Kong by Tuesday, and in the London tabloids by Wednesday morning.) Yet people’s choices and compromises are mainly in regards to their own privacy.

Some of the issues we see with the introduction of gmail are similar to the issues resulting from the introduction of DejaNews, a searchable web-based Usenet archive (which later became Google Groups). Advertising linked to postings were a hot topic, as well as people being uneasy with their, once-transitory, drunken missives waiting to be rediscovered.

The solution was to allow an opt-out. A “nuke” function was made available to erase old embarrassments from the archive, and the technical means to opt-out of long-term storage – the famous “X-No-Archive:” header.

Does gmail honour X-No-Archive? Should it? Unlike public Usenet postings, the trustee of the mail should still be the recipient. (Mail forwarding systems could easily not forward mail with that header to gmail, as it is. But that probably wouldn’t go down well with users.) And yet, when I mail an individual (who may have mail forwarding in place) I’m not necessarily cogent to the privacy policies that will be applied to it. I still believe that personal email (even unencypted email) should have the same expectation of privacy that a physical letter would have.

Personally, I think the first step in reassuring people would be to allow for an optional mechanism to allow them to know when their mail is, or isn’t, stored in a third party archive.

My suggestion (and this is from the top of my head, I haven’t researched this, or looked for other proposals) would be to extend the syntax of
RFC3798 - MDNs: “x-archive”. An option only processed by third-party archives such as gmail.

An example of a mail header fragment might be:

From: Joe Example <joe@example.org>
To: Belinda Example <belinda@example.com>
Subject: My confession
Disposition-Notification-To: Joe Example <joe@example.org>
Disposition-Notification-Options: x-archive=optional, stored, purged, policy;

So x-archive would be a non-standard extension (i.e. not registered with
IANA which is what the “x”-prefix denotes. A registered version might be “archive”.) to “Disposition-Notification-Options:”. The importance should be listed as “optional” if a notification request is required from systems that do not understand the x-archive option (as per the RFC, only a “failure” notice will be sent if all options are not understood).

Note that the variables for this option are concerned with an instance of a mail in an archive, and not with the user interaction with the mail. They merely provide a mechanism for informing the sender of the status
of the mail in an archive (and provide a form for promoting the relevent
privacy policy). Examples of variables might be

• “stored”: send an MDN when the mail is stored in the archive
• “policy”: send an MDN when changes are made to the privacy policy
• “purged”: send an MDN when the mail is purged from the archive

There is a difference between “deleted”, a user action (which in MDN terms does not preclude the un-deletion of a mail) and “purged” which is
an indication of an unrecoverable deletion from an archive. Therefore a user deleting mail from an archive may (depending on the configuration) result in two different MDNs – but a mail being automatically purged from the archive without user interaction may just result in one.

These options might not be useful as default headers. For example, a wide use of “policy” may cause a large number of small MDNs to be delivered to the senders of any mail in the archive when a policy change is made. Someone without correct filters in place to interpret them might end up with a flood of mail. Would one “MDN” per email address suffice? Similarly, what if an entire user archive is purged?

Are there any groups looking into this issue?

Apart from the simple fact that if everyone in China went online at the same time, it would bring the whole net down

I like “simple facts” like this. One of those “OK, maybe it’s not accurate, but it serves to illustrate scale… you fucking pedant” sort of “facts”. A technical version of the old “prove me wrong” chestnut about what would happen if everyone in China jumped at the same time.

So, somehow, overnight – without the infrastructure of the worldwide Internet changing, the number of PCs in China goes from about 35 million to one “billion”. One thousand million PCs are switched on, disks and fans spin up, but the power surge is easily handled by the Chinese power network. One billion network connections are established with no contention problems since China’s IAPs are designed precisely for this. Obviously they don’t all have unique IPv4 addresses, so they’re mostly going to be going through NAT gateways (which easily take the strain). Then one billion Chinese users make multiple requests via the national filters – which, naturally, don’t falter under the increased pressure. And by a weird quirk, all of these are from sites outside of China (I’m assuming web traffic here, but who knows). Luckily the external bandwidth out of China is more than enough to support one billion simultaneous requests…

Yet somehow, the servers and the networks of the rest of the world prove to be the weak link in the chain. The Internet is brought down (whatever that means).

The implication here is that the worldwide internet is somehow not decentralised and distributed. That there are some fundamental scaling issues with the net here. Even if everyone in the UK phoned in a gameshow vote, you wouldn’t expect that to cause the phone network in Luxembourg to crash.

I don’t know, maybe there’s some CAIDA data to back up this “everyone in China” fact. The net being “brought down” is seems believable when the fagility of the net is shown by worms and distributed attacks from trojan infected “zombie” PCs. But it’s precisely the distributed nature of these issues (along with the shocking negligence of networks that still don’t employ ingress/egress filtering) that causes problems.

Google.com is not “the net”. Microsoft.com is not “the net”. Hell, “.com” is not “the net”, regardless of the headlines after a NetSol screwup. Even the necessary single-point-of-failure represented by the root servers are more distributed than you might think. 

Not really sure what point I’m trying to make here. But anyway, in about, um, 40 years – when everyone in China has Internet access, and they all log on at the same time to a website that synchronises them all to simultaneously jump of their chairs, and the networks of the US and Europe go down shortly before they are wiped out by massive tidal waves… feel free to rub this in my face.