BKLTTJYL.RVW   20091207

“Land the Tech Job You Love”, Andy Lester, 2009, 978-1-934356-26-5, U$23.95/C$29.95
%A   Andy Lester andy@theworkinggeek.com
%C   Raleigh, NC
%D   2009
%G   978-1-934356-26-5 1-934356-26-3
%I   Pragmatic Bookshelf
%O   U$23.95/C$29.95 praglife.com
%O  http://www.amazon.com/exec/obidos/ASIN/1934356263/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1934356263/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1934356263/robsladesin03-20
%O   Audience n Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   252 p.
%T   “Land the Tech Job You Love”

It’s a bit hard to keep faith in the instructions contained in a book that starts out, not just on the first page, but inside the print cover, with “Question everything, including this book.”

There is a section, in the introduction, entitled “How This Book Was Born.”  It seems that two guys who hired people started giving talks on how to apply for a job.  (It strikes me, anyway, that this might be rather akin to having a toddler write a book on what to feed children.)  Why this one wrote the book is unclear.

Part one is about the job search.  Chapter one says that you should be honest, in order not to get the wrong job by misrepresenting yourself, but spin yourself in the best possible light.  (How to balance these somewhat contradictory positions is not specified.)   Assessing your wants, needs, and motivation is dealt with in chapter two.  Creating the content of your resume in the most promotional way is covered in chapter three.  Style is substance, says chapter four, and, regardless of what is important to you, follow the tips on fonts and paper colour.  Unsurprisingly, chapter five notes that you should research the job and the company, and use contacts to search for jobs.  Target your resume and cover letter, is the advice in chapter six.

Part two deals with the interview, and subsequently.  Chapter seven says to prepare for the interview.  Eight covers interview basics.  Stock answers to stock “tough” interview questions are given in chapter nine.  Chapter ten notes topics that cannot be discussed in
job interviews in the US.  Post-interview follow-up, reference submission, and accepting or declining a job offer are examined in chapter eleven.  Chapter twelve discusses strategic (social or professional) networking, training, and long term preparation for all of the activities in part one, for the inevitable next time around.

Some appendices cover things you shouldn’t do: cliched phrases in A, resume and letter constructions in B, and interview presentations in C.

The content and advice in this book are quite standard.  If you are looking for a job in Web administration, page creation, or sales, and are new to the applications and interview process, it will probably be useful.  In terms of landing a job you love, probably the main thrust of chapter one is the most significant: be honest, and you’re less likely to become stuck in a job you don’t fancy.  (There is, of course, no guarantee that the job you love actually exists …)

copyright Robert M. Slade, 2009    BKLTTJYL.RVW   20091207

BKMTHSEC.RVW   20091221

“The Myths of Security”, John Viega, 2009, 978-0-596-52302-2, U$29.99/C$37.99
%A   John Viega viega@list.org
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2009
%G   978-0-596-52302-2 0-596-52302-5
%I   O’Reilly & Associates, Inc.
%O   U$29.99/C$37.99 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596523025/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596523025/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596523025/robsladesin03-20
%O   Audience i Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   238 p.
%T   “The Myths of Security”

The foreword states that McAfee does a much, much better job of security than other companies.  The preface states that computer security is difficult, that people, particularly computer users, are uninformed about computer security, and that McAfee does a much better job of security than other companies.  The author also notes that it is much more fun to write a book that is simply a collection of your opinions than one which requires work and technical accuracy.

The are forty-eight “chapters” in the book, most only two or three pages long.  As you read through them, you will start to notice that they are not about information security in general, but concentrate very heavily on the antivirus (AV) field.

After an initial point that most technology has a poor user interface, a few more essays list some online dangers.  Viega goes on to note a number of security tools which he does not use, himself.  He then argues unconvincingly that free antivirus software is not a good
thing, unclearly that Google is evil, and incompletely that AV software doesn’t work.  (I’ve been working in the antivirus research field for a lot longer than the author, and I’m certainly very aware that there are problems with all forms of AV: but there are more forms of AV in heaven and earth than are dreamt of in his philosophy.  By the way, John, Fred Cohen listed all the major forms of AV technology more than twenty-*five* years ago.)  The author subsequently jumps from this careless technical assessment to a very deeply technical discussion of the type of hashing or searching algorithms that AV companies should be using.  And thence to semi-technical (but highly opinionated) pieces on how disclosure, or HTTPS, or CAPTCHA, or VPNs have potential problems and therefore should be destroyed.  Eventually all pretence at analysis runs out, and some of the items dwindle down to three or four paragraphs of feelings.

For those with extensive backgrounds in the security field, this work might have value.  Not that you’ll learn anything, but that the biases presented may run counter to your own, and provide a foil to test your own positions.  However, those who are not professionals in the field might be well to avoid it, lest they become mythinformed.

copyright Robert M. Slade, 2009    BKMTHSEC.RVW   20091221

UAE says privacy is a security risk.

US says openness is a security risk.

A recent Scientific American article does point out that is is getting increasingly difficult to keep our Trusted Computing Base sufficiently small.

For further information on this scenario, see: http://www.imdb.com/title/tt0436339/  [1]

We actually discussed this in the early days of virus research, and sporadically since.  The random aspect (see Dell problems with bad chips) (the stories about malware on the boards is overblown, since the malware was simply stored in unused memory, rather than being in the BIOS or other boot ROM) is definitely a problem, but a deliberate attack is problematic.  The issue lies with hundreds of thousands of hobbyists (as well as some of the hackers) who poke and prod at everything.  True, the chance of discovering the attack is random, but so is the chance of keeping the attack undetected.  It isn’t something that an attacker could rely upon.

Yes, these days there are thousands of components, being manufactured by hundreds of vendors.  However, note various factors that need to be considered.

First of all, somebody has to make it.  Most major chips, like CPUs, are a combined effort.  Nobody would be able to make and manufacture a major chip all by themselves.  And, in these days of tight margins and using every available scrap of chip “real estate,” someone would be bound to notice a section of the chip labeled “this space intentionally left blank.”  The more people who are involved, the more likely someone is going to spill the beans, at the very least about an anomaly on the chip, whether or not they knew what it did.  (Once the word is out that there is an anomaly, the lifespan of that secret is probably about three weeks.)

Secondly, there is the issue of the payload.  What can you make it do?  Remember, we are talking components, here.  This means that, in order to make it do anything, you are generally going to have to rely on whatever else is in the device or system in which your chip has been embedded.  You cannot assume that you will have access to communications, memory, disk space, or pretty much anything else, unless you are on the CPU.  Even if you are on the CPU, you are going to be limited.  Do you know what you are?  Are you a computer? Smartphone?  iPod?  (If the last, you are out of luck, unless you want to try and drive the user slowly insane by refusing to play anything except Barry Manilow.)  If you are a computer, do you know what operating system you are running?  Do you know the format of any disk connected to you?  The more you have to know how to deal with, the more programming has to be built into you, and remember that real estate limitation.  Even if all you are going to do is shut down, you have to have access to communications, and you have to a) be able to watch all the traffic, and b) watch all the traffic, without degrading performance while doing so.  (OK, true, it could just be a timer.  That doesn’t allow the attacker a lot of control.)

Next, you have to get people to use your chips.  That means that your chips have to be as cheap as, or cheaper than, the competition.  And remember, you have to use up chip real estate in order to have your payload on the chip.  That means that, for every 1% of chip space you use up for your programming, you lose 1% of manufacturing capacity.  So you have to have deep pockets to fund this.  Your chip also has to be at least as capable as the competition.  It also has to be as reliable as the competition.  You have to test that the payload you’ve put in place does not adversely affect performance, until you tell it to.  And you have to test it in a variety of situations and applications.  All the while making sure nobody finds out your little secret.

Next, you have to trigger your attack.  The trigger can’t be something that could just happen randomly.  And remember, traffic on the Internet, particularly with people streaming videos out there, can be pretty random.  Also remember that there are hundreds of thousands of kids out there with nothing better to do than try to use their computers, smartphones, music players, radio controlled cars, and blenders in exactly the way they aren’t supposed to.  And several thousand who, as soon as something odd happens, start trying to figure out why.

Bad hardware definitely is a threat.  But the largest part of that threat is simply the fact that cheap manufacturers are taking shortcuts and building unreliable components.  If I was an attacker, I would definitely be able to find easier ways to mess up the infrastructure than by trying to create attack chips.

[1] Get it some night when you can borrow it, for free, from your local library DVD collection.  On an evening when you don’t want to think too much.  Or at all.  WARNING: contains jokes that six year olds, and most guys, find funny.

BKDRJNDL.RVW   20091129

“The Design of Rijndael”, Joan Daemen/Vincent Rijmen, 2002, 3-540-42580-2
%A   Joan Daemen
%A   Vincent Rijmen
%C   233 Spring St., New York, NY   10013
%D   2002
%G   3-540-42580-2
%I   Springer-Verlag
%O   212-460-1500 800-777-4643 service-ny@springer-sbm.com
%O  http://www.amazon.com/exec/obidos/ASIN/3540425802/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/3540425802/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/3540425802/robsladesin03-20
%O   Audience s- Tech 3 Writing 1 (see revfaq.htm for explanation)
%P   238 p.
%T   “The Design of Rijndael: AES - The Advanced Encryption Standard”

This book, written by the authors of the Rijndael encryption algorithm, (the engine underlying the Advanced Encryption Standard) explains how Rijndael works, discusses some implementation factors, and presents the approach to its design.  Daemen and Rijmen note the linear and differential cryptanalytic attacks to which DES (the Data Encryption Standard) was subject, the design strategy that resulted from their analysis, the possibilities of reduce round attacks, and the details of related ciphers.

Chapter one is a history of the AES assessment and decision process.  It is interesting to note the requirements specified, particularly the fact that AES was intended to protect “sensitive but unclassified” material.  Background in regard to mathematical and block cipher concepts is given in chapter two.  The specifications of Rijndael sub-functions and rounds are detailed in chapter three.  Chapter four notes implementation considerations in small platforms and dedicated hardware.  The design philosophy underlying the work is outlined in chapter five: much of it concentrates on simplicity and symmetry.
Differential and linear cryptanalysis mounted against DES is examined in chapter six.  Chapter seven reviews the use of correlation matrices in cryptanalysis.  If differences between pairs of plaintext can be calculated as they propagate through the boolean functions used for intermediate and resultant ciphertext, then chapter eight shows how this can be used as the basis of differential cryptanalysis.  Using the concepts from these two chapters, chapter nine examines how the wide trail design diffuses cipher operations and data to prevent strong linear correlations or differential propagation.  There is also formal proof of Rijndael’s resistant construction.  Chapter ten looks at a number of cryptanalytic attacks and problems (including the infamous weak and semi-weak keys of DES) and notes the protections provided in the design of Rijndael.  Cryptographic algorithms that made a contribution to, or are descended from, Rijndael are described in chapter eleven.

This book is intended for serious students of cryptographic algorithm design: it is highly demanding text, and requires a background in the formal study of number theory and logic.  Given that, it does provide some fascinating examination of both the advanced cryptanalytic attacks, and the design of algorithms to resist them.

copyright Robert M. Slade, 2009    BKDRJNDL.RVW   20091129

The recently discovered LNK exploit; using the way Microsoft parses link or shortcut icons for display in order to get something else executed; may be a tempest in a teapot.  It is technically sophisticated, but so far we don’t appear to have seen it used widely.

Probably a good thing.

This exploit could be used in a wide variety of ways.  You can use it in removeable media, so that any time you shove a CD in a drive, or connect a USB stick/thumb drive (or any other USB device, for that matter) to a computer, it results in an infection or some malicious payload.

And remember that OLE stands for object *LINKING* and embedding.  Since it is trivially easy to embed a virus in any Windows OLE format data file, it should be just as easy to create malicious links in any such files.

Microsoft’s own information on the issue seems to indicate that there is a related, but separate, issue with Microsoft Office components, related to Web based activities.  (By the way, when accessing that site, the information about how to protect against the exploit is hidden under the “Workarounds” link, rather than being explicit on the page.)

Some of the potential effects are discussed by Randy Abrams at http://blog.eset.com/2010/07/19/it-wasn%E2%80%99t-an-army

This is depressing, but probably true.  Ethan Zuckerman, at the current TED, notes that the Internet makes us think we being exposed to, and learning from, differing world views, but that, particularly in relation to social networking, we are usually simply seeking out similar views to our own, and reinforcing our existing viewpoints.

You can read a report from the BBC or see the actual talk at TED.

(I like the “imaginary cosmopolitanism” phrase.  It reminds me of being in NYC.)

(If you can’t see the security implication in broadening your outlook, there is no hope for you.)

It’s easy to spoof caller-ID with some VoIP systems.  There are a few Websites that specifically allow it.  It’s a little harder, but geekier, to spoof or overflow caller-ID with a simple Bell 212A modem: it’s transmitted with that tech between the first and second rings of the phone.  (Since most people have caller-ID these days, many telcos don’t play you the first ring.  Since we don’t have caller-ID, we often get accused of answering the phone before it rings.)  (Of course, the rings you hear on the calling side aren’t necessarily the rings heard on the other end, but …)

Apparently AT&T allows immediate access to voicemail on the basis of caller-ID.

Apparently, with Android phones, it’s also gotten even easier to spoof caller-ID.

BKEAUTZF.RVW   20091107

“Enterprise Architecture Using the Zachman Framework”, Carol O’Rourke/Neal Fishman/Warren Selkow, 2003, 0-619-06446-3
%A   Carol O’Rourke carol@eabook.info
%A   Neal Fishman neal@eabook.info
%A   Warren Selkow warren@eabook.info
%C   25 Thomson Place, Boston, MA   02210
%D   2003
%G   0-619-06446-3
%I   Thomson Learning Inc.
%O   www.course.com
%O  http://www.amazon.com/exec/obidos/ASIN/0619064463/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0619064463/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0619064463/robsladesin03-20
%O   Audience i Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   716 p. + CD-ROM
%T   “Enterprise Architecture Using the Zachman Framework”

The preface states that this is a text for various courses in business management and information systems, and a guide for business and education professionals.  There is also a quick and dirty introduction to the framework, mentioning the perspectives (rows of the framework) and aspects (columns), but not describing what they are.  (For those who want to understand the framework itself, the book does provide, as an appendix, Zachman’s original paper from the “IBM Systems Journal.”  It is clearer and gives a much better idea of the intent and use of the framework.  For those who have not used it before, the framework is a two-dimensional breakdown model, with the stages of project
management as the vertical axis, and the W5+H interrogatives [what, how, where, who, when, and why] as the columns, also labelled data, function, network, people, time, and motivation.)

Part one of the book, consisting only of chapter one, supposedly provides the reasons for the framework.  This consists of another brief outline, and a great deal of promotional material.  “Examples,” ranging from the alphabet to religion purport to illustrate the
structure, but are, instead, confusing and distracting.  The sporadic outbursts of humour also divert attention from the central themes, rather than supporting them.

Part two outlines the organization of the Zachman Framework’s rows, or perspectives.  Chapter two examines the concept (which may also be referred to in different versions of the Zachman model as scope or context) or planning stage, and the six examples follow the interrogative aspects.  The owner (aka business model/concept) or requirements phase is dealt with in chapter three, but the generic material on business, and shorter case studies on the topic, are not as clear in terms of the framework.  Things become even more confusing in chapter four, where the idea of the design phase (system
model/logical) is surrounded by miscellaneous examples seemingly related to psychology.  Stories that appear to be even more randomly chosen comprise the content on the builder (technology model/physical) or implementation stage, in chapter five.  Chapter six is entitled “Systems Development,” which deals with the subcontractor (detailed representations/out-of-context) or implementation stage.  Although there are interesting points about management, the material is, again, unstructured and confusing.

Chapter seven finally attempts to describe the framework in detail and context, and to provide a rationale for using it.

Part three consists of chapter eight, ostensibly about implementing (I suppose this means using) the framework.  There are lots of management tips and points, but no real structure, or indication of how the framework is to be applied.  (There is also an apparent attempt to add a third dimension to the Zachman grid, but this is not defined.)

If you want to get a good idea of the Zachman framework, you are probably best to go to Zachman’s original paper.  The intent and structure of the Zachman’s article, and the explanation of the model, is much clearer than this mass of verbiage and examples.  As noted, the paper is available as appendix E, but it is also available on the Internet, such as at
http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf

copyright Robert M. Slade, 2009    BKEAUTZF.RVW   20091107

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   “SSL and TLS: Theory and Practice”

The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

BKCLSEPR.RVW   20091113

“Cloud Security and Privacy”, Tim Mather/Subra Kumaraswamy/Shahed Latif, 2009, 978-0-596-802769, U$34.99/C$43.99
%A   Tim Mather
%A   Subra Kumaraswamy
%A   Shahed Latif
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2009
%G   978-0-596-802769 0-596-802765
%I   O’Reilly & Associates, Inc.
%O   U$34.99/C$43.99 800-998-9938 707-829-0515 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596802765/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596802765/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596802765/robsladesin03-20
%O   Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   312 p.
%T   “Cloud Security and Privacy”

The preface tells how the authors met, and that they were interested in writing a book on clouds and security.  It provides no definition of cloud computing.  (It also emphasizes an interest in being “first to market” with a work on this topic.)

Chapter one is supposed to be an introduction.  It is very brief, and, yet again, doesn’t say what a cloud is.  (The authors aren’t very careful about building background information: the acronym SPI is widely used and important to the book, but is used before it is defined.  It stands for Saas/Paas/Iaas, or software-as-a-service, platform-as-a-service, and infrastructure-as-a-service.  More simply, this refers to applications, management/development utilities, and storage.)  A delineation of cloud computing is finally given in chapter two, stating that it is characterized by multitenancy, scalability, elasticity, pay-as-you-go options, and self-provisioning.  (As these aspects are expanded, it becomes clear that the scalability, elasticity, and self-provisioning characteristics the authors describe are essentially the same thing: the ability of the user or client to manage the increase or decrease in services used.)  The fact that the authors do not define the term “cloud” becomes important as the guide starts to examine security considerations.  Interoperability is listed as a benefit of the cloud, whereas one of the risks is identified as
vendor lock-in: these two factors are inherently mutually exclusive.

Chapter three talks about infrastructure security, but the advice seems to reduce to a recommendation to review the security of the individual components, including Saas, Paas, and network elements, which seems to ignore the emergent risks arising from any complex environment.  Encryption is said to be only a small part of data security in storage, as addressed in chapter four, but most of the material discusses encryption.  The deliberation on cryptography is superficial: the authors have managed to include the very recent research on homomorphic encryption, and note that the field will advance rapidly, but do not mention that homomorphic encryption is only useful for a very specific subset of data representations.  The identity management problem is outlined in chapter five, and protocols for managing new systems are reviewed, but the issue of integrating these protocols with existing systems is not.  “Security management in the Cloud,” as examined in chapter six, is a melange of general security management and operations management, with responsibility flipping back and forth between the customer and the provider.  Chapter seven provides a very good overview of privacy, but with almost no relation to the cloud as such.  Audit and compliance standards are described in chapter eight: only one is directed at the cloud.  Various cloud service providers (CSP) are listed in chapter
nine.  The terse description of security-as-a-service (confusingly also listed as Saas), in chapter ten, is almost entirely restricted to spam and Web filtering.  The impact of the use of cloud technology is dealt with in chapter eleven.  It lists the pros and cons, but again,
some of the points are presented without noting that they are mutually exclusive.  Chapter twelve finishes off the book with a precis of the foregoing chapters.

The authors do raise a wide variety of the security problems and concerns related to cloud computing.  However, since these are the same issues that need to be examined in any information security scenario it is hard to say that any cloud-specific topics are addressed.  Stripped of excessive verbiage, the advice seems to reduce to a) know what you want, b) don’t make assumptions about what the provider provides, and c) audit the provider.

copyright Robert M. Slade, 2009    BKCLSEPR.RVW   20091113

Like freedom of the press, ultimately, net neutrality is going to be reserved for those who own one.

Well, we’re getting closer.

Consider the case of cell/mobile phones.  The device is basically useless for communications, unless you have service through a provider.  They have the cell towers, and link through to the public telephone network.  You have to pay them, and they get to manage how calls are made.

(Just as a side issue, the more people who are subscribers in a given location, the worse chance you have of getting to make a call.  You get to be a victim of their [the telco’s] success.)

Now, consider.  Cell phones are getting smarter all the time.  Already they can connect with (and via) wifi.  And we can build applications for them.  Recently I didn’t have Internet access for my laptop, and someone with an Android phone was able to set up a wireless access point for me, through his phone, and give me that connection.

OK, lets extend the routing a bit.  We’ve developed a lot of good routing protocols from building the Internet.  Let’s extend those to handle hops from phone to phone.  And, using voice over IP, and a few other technologies, pretty soon we can make calls without hitting a cell tower.

(And, bearing in mind technologies such as CDMA2000, note that, in opposition to the cell tower contention model, the *more* cell phones we put into an area under this model, the *better* our coverage and bandwidth is going to be.  The closer the devices are to each other, the faster [more bandwidth] they can talk to each other.)

Latency may be a problem.  Security (in terms of confidentiality) will definitely need to be addressed.  Long distance transmission will be a concern (although it’s rather amazing how many ideas start popping up as soon as those issues are raised).

Basically, any form of communication will follow from the same model.  With a bunch of cell phones where your only cost is the initial cost of the phone itself (no subscription, no usage cost, no long distance charges) it won’t take long for landline phones to be phased out.  Data communications, for any “store and forward” model (basically, anything other than streaming) will be even more efficient.  Maybe there will still be a place for the telcos: if you want faster service for real time streaming of content.  Of course, they’d have to be willing to set the price point for unlimited data low enough to be attractive …

However, we would now seem to be nearer the end than the beginning.  It’s mostly a matter of which platform to start with.  Google has demonstrated that it *can* term off applications, but, in this case, why should it?  Apple might want to jump in on the ground floor, but they turn off a lot more apps, and, in any case, it probably isn’t best to start with a phone where you have to hold your tongue (or your hand) just right to get it to work.

There is no possible way this could potentially go wrong, right?

Doesn’t the phrase “Identity Ecosystem” make you feel all warm and “green”?

It’s a public/private partnership, right?  So there is no possibility of some large corporation taking over the process and imposing *their* management ideas on it?  Like, say, trying to re-introduce the TCPI?

And there couldn’t possibly be any problem that an identity management system is being run out of the US, which has no privacy legislation?

The fact that any PKI has to be complete, and locked down, couldn’t affect the outcome, could it?

There isn’t any possible need for anyone (who wasn’t a vile criminal) to be anonymous, is there?

By the way, in non-Sonne-erous G8/20 news, our government(s) have spent a billions dollars on security for a couple of days of meetings.  Even given the degraded value of the American billion, that’s a lot of money.

Part of it was used to buy sound cannons.  (The police don’t like you saying that: they prefer the term “long range sonic control devices.”)  These sound cannons generate noise at 130 decibels, which the civil liberties folks are concerned will damage human hearing.

That’s the same level of noise a vuvuzela makes.

So, look, why didn’t we save the billion dollars, go down to Canadian Tire, and, for a hundred bucks (possibly in Canadian Tire money) equip the entire riot squad with vuvuzelas?

We’ve got a new law coming up in Canada: C-32, otherwise known as DMCA-lite.

Lemme quote you a section:

29.22 (1) It is not an infringement of copyright for an individual to reproduce a work or other subject-matter or any substantial part of a work or other subject-matter if
[…]
(c) the individual, in order to make the reproduction, did not circumvent, as defined in section 41, a technological protection measure, as defined in that section, or cause one to be circumvented.

Now, of course, if you want to examine a virus, or other malware, you have to make a copy, right?  So, if the virus writer has obfuscated the code, say by doing a little simple encryption, obviously he was trying to use a “technological protection measure, as defined in that section,” right?  So, decrypting the file is illegal.

Of course, it’s been illegal in the US for some years, now …

So I’m in the store with my grandson, preparatory to taking him (and his sister) for ice cream.  We’re buying cheese.  One of the varieties of the cheese we want to buy is wasabi.

“We should get some of that for Grama,” he says.

(His father gave him a wasabi pea, once, and he has never forgotten it.)

“Ha!” says I, “Maybe we should forget this ice cream idea.  We shouldn’t get you ice cream, for you are an evil child!”

Most children of eight would object.  Both to the potential loss of ice cream, and to any insinuation that they are evil.  “I’m not bad!” they would whine.

But not my grandson.  He doesn’t batt an eye.  Without a second’s pause, he fires back with “Ah!  But you haven’t yet heard my plan for taking over the world!”

Maybe he takes after his grandfather too much …