Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
It started off early Wednesday as an innocuous request from a North Carolina
businessman to the Homeland Security Department. He was responding to a
daily antiterrorism bulletin by asking that it be sent to another e-mail
address. But by afternoon, a programming flaw involving the REPLY function
transformed that e-mail message into a flood of more than 2.2 million
messages nationwide that clogged the e-mail accounts of government and
private experts on domestic security, including the operators of an Illinois
nuclear power station. .... [Source: Eric Lipton, Security Bulletin Problem
Creates Message Flood, *The New York Times*, 4 Oct 2007]
http://www.nytimes.com/2007/10/04/us/04secure.html
[Who needs a greater-than-3-oz liquid bottle when an e-mail reply will do?
Do we need to get DHS a new broom and bucket to clean up this mess?
Clearly they (or more likely the contractors they hired...) need a senior
sorcerer to watch over the apprentice admins.]
[See also Lauren Weinstein's blog on this topic, Homeland Security Floods
Users With Private E-Mail. PGN]
http://lauren.vortex.com/archive/000305.html
At least 2,000 Long Island Railroad passengers were double-billed for tickets purchased with credit cards at automatic ticket kiosks in early October. The problem occurred on the first business day in October. A record number (over 30,000) of tickets were purchased by credit card via their network of automated kiosks. This triggered a software error (apparently undetected since 2001) which caused the system to bill for the tickets on October 1, and then again on October 2. The vendor is working on the problem. [It's not clear from the article whether the problem is in each of the 269 kiosks, or possibly some central server.] [Source: Michael Amon, *Newsday*, 5 Oct 2007] http://www.newsday.com/news/local/ny-lilirr1006,0,7787106.story
You are responsible for a sub-domain of a large, distributed, and well-known
organization. Your DNS server, maintained by your ISP, gets hacked so that
its entries are pointing to pornographic websites. When your ISP doesn't
resolve the issue after 2 weeks, you switch to another DNS provider and fix
the problem.
In the meantime, someone has discovered the problem, but suspects it is not
just your domain that's been hacked, but your entire organization's, and
complains to your new DNS provider. They, of course, don't recognize your
well-known DNS name, nor try to effectively resolve the issue. As a result,
you and all your sister domains are erased from the net.
And that's how the General Services Administration came to remove
California's ca.gov domain — because your domain tam.ca.gov was hacked.
(That's the Transportation Authority of Marin county.)
http://www.networkworld.com/news/2007/100407-feds-pull-ca-gov-domain.html
Talk about Denial of Service!
[*NYT* item noted by David Lesher.
http://mobile.nytimes.com/2007/10/05/us/05brfs-APOLOGYAFTER_BRF.xml
PGN]
The Air Force destroyed all records from unsuccessful searches for aircraft missing before 1989, which is likely to make it much harder for Nevada investigators to determine the victims of three wrecks found in the recent search for the aviator Steve Fossett ... One resource that had been expected to help in the inquiry was suspended mission files, kept at Tyndall Air Force Base in Panama City, Fla. Those files are the paper trails of all failed searches for missing aircraft by the Civil Air Patrol, a volunteer Air Force auxiliary group, or any other Air Force resources. But in 1994, the Air Force instituted a regulation requiring the destruction of records of noncombat missions after seven years. [Source: Steve Friess, *The New York Times*, 4 Oct 2007; PGN-ed] http://www.nytimes.com/2007/10/04/us/04fossett.html?th&emc=th
A cartoon with a cute exploit: http://xkcd.com/327/ This example may not work in real life due to naming laws, but I would be surprised if there were some systems out there vulnerable to names with exotic letters being interpreted as escape characters. Anders Sandberg, Oxford Uehiro Centre for Practical Ethics, Philosophy Faculty of Oxford University [xkcd is "A webcomic of romance, sarcasm, math, and language". This item was also noted by John Tate. PGN]
Many years ago, I was involved in 'porting' the payroll system of a large British TV company from an ICL 1902S to an ICL 2903 (told you it was a long time ago). We actually rewrote the whole thing in RPG2, from its original Autocoder. We moved the data between the two machines on punched cards. So, come the day of the first parallel run, after months of testing, and the results were different. Not much, a few pennies, but different nonetheless. Huge panic, much headless chicken behaviour until we discovered that ... the old system was the one that was wrong. And had been for years. So, what have we learned in the intervening 30 years? Not a whole lot, it appears.
http://lauren.vortex.com/archive/000313.html
Ready to turn over the keys of your vehicle to the cops, or that clever
hacker in the next lane? How about that creepy guy following you on a
lonely country road?
GM apparently plans to perhaps make this all possible. It's been announced
that they'll be equipping nearly two million of their 2009 model vehicles
(that have OnStar installed), with the capability to be remotely shut down
to idle via OnStar commands at the request of law enforcement (
http://abcnews.go.com/Business/Autos/story?id=3706113 ).
The claim is that owners will have to give permission first for this
capability to be enabled. Bull. I don't care what OnStar's privacy policy
says, if the technical capability for this function is present, OnStar will
have no practical choice but to comply when faced with a law enforcement
demand or court order, whether or not owner "permission" was ever granted.
This new capability will also create an irresistible challenge to the hacker
community — and perhaps criminal organizations — to try find ways into the
OnStar system for triggering this fun — one way or another. It's
impossible to hack OnStar? Would you bet your life on that?
Unfortunately, this is yet another laudable idea that's being "driven" into
the marketplace before all of the negative ramifications have been thought
through or fully understood. And how long will it be before such systems
are mandated, one might wonder?
OnStar has long been the subject of various privacy concerns. This new
capability appears to be the most serious privacy-related issue for OnStar
to date.
Lauren Weinstein lauren@vortex.com or lauren@pfir.org +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
http://lauren.vortex.com/archive/000312.html
It looks as if Microsoft may already have some significant quality problems
with their heavily hyped HealthVault.
I received an e-mail last night from a reader who was disgusted to find that
some completely valid queries to the HealthVault search engine — mentioning
bodily parts or bodily functions — returned extremely high percentages
(sometimes almost 100%) of porn keyword "sucker" pages (porn pages that have
been "seeded" with all manner of likely keywords). I won't offer example
search strings here in the interests of good taste, but I've confirmed this
situation myself.
In fact, this person noted getting masses of porn results starting with
their very first HealthVault search. They were stunned that Microsoft's
quality control and presumed filtering of results for health relevance were
so defective on a highly touted health-specific search engine deployed for
the general public. I agree.
For comparison purposes, a test of the same searches on Google also yielded
a lot of porn hits, but overall more relevant hits were returned, and Google
isn't promoting their main search engine as having a health focus.
There is a potential bright side to this situation. I'm all in favor of
using encryption whenever possible on the Net, and HealthVault uses SSL
crypto for searches in both directions. So finally there's a way to search
for porn on the Net with better privacy!
All Microsoft needs to do now is simply rebrand their service as "PornVault"
-- now that's a winner.
Lauren Weinstein lauren@vortex.com or lauren@pfir.org +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
http://lauren.vortex.com/archive/000310.html
VHS is dead. Its ghost lingers in our homes and in cobweb-filled corners of
electronics retailers, but make no mistake, VHS recording is rapidly going
the way of the dodo. And this passing is being used as an excuse for one of
the biggest consumer ripoffs in technology history — with our friendly
neighborhood cable television services (in their various incarnations)
chuckling mightily at the situation.
When we first started hearing about Digital Rights Management (DRM) systems
planned for digital television, there was a great deal of concern, even
though the planned focus appeared to be on "premium" programming (HBO,
Showtime, Pay Per View - PPV, and so on). Much of this seemed rather
academic anyway, since consumer devices that would be affected by such
systems were still largely vaporware.
But that situation has changed rapidly, and now cable firms (and their
fiber, satellite, IPTV, and other variations — I'm calling them all cable)
have got their subscribers by the you know what, and unless the FCC (fat
chance) or Congress (perhaps a better chance) get moving, consumers will see
their hard won rights to record and save television programming fade into
history. It's happening right now.
The Supreme Court "Betamax" decision decades ago established the fair use
rights of consumers to make copies of television programs, and save them on
videocassettes. But with the demise of VHS, the newly ascendant technology
is Digital Video Recorders (DVRs), such as the TiVo and its various cruder
generic cousins (the latter typically cable company supplied).
DVRs allow saving of programs on their internal hard drives, but there's a
problem. Video takes a lot of bits, and hard drive space is limited. So
the trend now is to find ways for consumers to save programs to external
media and devices (such as DVDs or PCs), much as they could with VHS tapes.
Direct DVD recorders are appearing, as are newer generation TiVos that will
shortly have the capability enabled to move programs to PCs and then write
them to DVDs.
But many cable firms are trying to thwart these capabilities via DRM, trying
to turn back the clock to pre-Betamax days. Their magic wand for this
purpose is the Copy Control Information (CCI) byte, transmitted as part of
digital cable channels, which impacts any modern device that interfaces
directly to a cable system (e.g., through cableCARDS like with the newest
TiVo HD — and many more devices so affected are now appearing).
Set CCI=0x00, and the consumer can dump programs off of their DVRs. Set it
to 0x02, and the programs are locked down. The device manufacturers must
abide by this rule or suffer the wrath of CableLabs — the cable industry's
own version of Dr. Evil's R&D operation.
Given the power that CCI holds over consumers, one would think that there
would be concise standards for how it would be applied to programming.
Buzzz! Wrong! In fact, the significant regulations that apply to CCI
simply require that digital broadcast channels (that is, over-the-air
signals retransmitted as digital cable channels), must set CCI=0x00. Beyond
that, the regs are essentially silent.
Now, logically one wouldn't be surprised to find cable companies setting
CCI=0x02 — blocking program saving to DVDs, etc. — for special event
programming, PPV, and perhaps even the HBO/Showtime class of premium
channels.
What you might not expect to frequently find is cable company ad hoc CCI
blocking of essentially *all* basic digital channels (other than
over-the-air) totally on their own volition — creating unfair recording
capability variations around the country.
For example, Time Warner Cable is generally setting CCI=0x02, and blocking
dumping of programs from DVRs, in this expansive manner. There's no
evidence that all of these programs suppliers have demanded such an action.
Many of these channels run Cable in the Classroom programming that is
specifically licensed to be recorded, saved, and distributed in schools
under various terms. CCI=0x02 can directly block such licensed use.
Similarly, it seems unlikely that the various C-SPAN channels would demand
blocking of program dump functions, yet Time Warner is routinely setting
CCI=0x02 for some or all of these channels as well (which may often appear
only on digital tiers) on many TW systems.
Since nothing requires TW to be taking this broad control freak approach to
DRM on their digital channels, the most likely explanation would seem to be
a CYA mentality run amok, subscribers' rights be damned.
Comcast, on the other hand, has reportedly been trending in the opposite
direction, with their systems moving toward CCI=0x00 settings for most
digital channels, allowing consumer program dumping and external saving.
Question: What possible valid reason can there be for cable subscribers of
one company's systems to have vastly fewer recording rights for the same
channels, compared with subscribers of another company's cable systems?
Answer: There's *no* valid explanation for this disparity. It's wacky,
wrong, and just plain unacceptable. And as more consumer devices affected
by this craziness rapidly deploy in the marketplace, subscribers are going
to go ballistic when they discover that the pricey boxes they've bought have
key functionality cut off at the knees by cable company edict in many
locations.
If the cable industry was smart, they'd collectively start reversing
draconian CCI settings right now, and start universally treating their
subscribers as individuals to be appreciated, not chattel to be abused. But
absent such an enlightened approach from the industry as a whole, it's
likely that we're going to have to make it clear to Congress that when it
comes to this sort of DRM abuse (to paraphrase Howard Beale in the 1976 film
"Network"): "We're as mad as hell and we're not going to take this anymore!"
-- assuming that our cable companies don't try to block this too, of course.
Lauren Weinstein lauren@vortex.com or lauren@pfir.org +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
I've just posted a proposal for a project aimed at moving past the current Network Neutrality impasse, with the deployment of a distributed global Internet traffic measurement system as a major component. http://lauren.vortex.com/archive/000299.html Comments, questions, etc. are welcome. Thanks! Breaking the Internet Network Neutrality Deadlock (HTML) http://www.pfir.org/nn-proposal Breaking the Internet Network Neutrality Deadlock (PDF) http://www.pfir.org/nn-proposal.pdf Lauren Weinstein, +1 (818) 225-2800 http://www.pfir.org/lauren Lauren's Blog: http://lauren.vortex.com
Practical Issues of the Proposed
"Global Internet Measurement Analysis Array"
http://lauren.vortex.com/archive/000303.html
In "Proposal for Breaking the Internet Network Neutrality Deadlock" (
http://lauren.vortex.com/archive/000299.html ), I recently suggested a
project for the gathering and analysis of worldwide Internet traffic data
and characteristics, for Network Neutrality-related and other purposes,
based on a distributed architecture of processes running mainly on end-user
computers.
I've now dubbed this project the "Global Internet Measurement Analysis
Array" (GIMAA).
I'd like to now touch very briefly on a few of the many practical
considerations that such a project would entail, including deployment,
security, and privacy issues.
To be useful, the measurement collection environment requires a very large
number of participating end-user sites. While standalone versions of the
GIMAA programs will of course be needed for a variety of hardware platforms,
deployment could be significantly hastened by including the associated code
into other already widely used end-user packages, e.g. popular browser/OS
toolbars and/or free utility application bundles. It may even prove
possible to primarily use the existing application/toolbar data traffic as
the foundational operational corpus for the measurement system itself,
supplanted as necessary by purpose-generated measurement-related data.
To the extent that the vendors of such toolbar and application packages are
interested in the potential ongoing output of a GIMAA environment, such
"packaging" would seem an attractive possible route for dissemination of the
system, with the goal of reaching a practical deployment level as quickly as
possible.
A range of security and privacy issues accompany a project like GIMAA, some
of which will likely be leveraged by some entities into objections against
the entire project.
Clearly the GIMAA code modules, measurement payload data, and any associated
aggregated data will need to be secure and as protected against manipulation
and tampering as current technology will allow. User data on participating
systems must be protected as a first priority concern.
A more unique issue with the GIMAA methodology is that the techniques
envisioned, if they prove out and are very widely deployed, could be
extremely powerful. As such, concerns are sure to be raised that GIMAA may
publicly reveal network traffic, topological, vulnerability, and other data
that some network participants, and others, might prefer to keep hidden for
business, security, or other reasons.
It can be anticipated, for example, that some firms (including ISPs) would
become concerned that GIMAA node activity could reveal what they consider to
be proprietary aspects of their network topologies, and that attempts to
block GIMAA measurement traffic, and/or the writing of prohibitions against
such measurement techniques into Terms of Service agreements, would be
forthcoming.
Of course, one of the key purposes proposed for GIMAA is to detect
vulnerabilities and abuses so that they can be corrected (through technical
or policy means, as appropriate), and it would be expected that some of
those entities responsible for such conditions would not be enthusiastic
about their being so exposed.
I also consider it likely that GIMAA will be criticized from some quarters
on national security grounds, with the argument being that the Internet
infrastructural data that could be exposed would make attacks on the
Internet and its attached systems more effective.
All of these concerns are real, and considerable effort will be needed to
balance the benefits and risks associated with a project like GIMAA.
But aside from the more obvious cost/benefit analysis that can be applied to
this project, there's another basic reality that renders some of these
concerns relatively moot in important respects.
The categories of measurement methodologies proposed for GIMAA could be
deployed on a clandestine basis by technologically skilled adversaries,
perhaps as part of widely disseminated computer viruses and the like. If
GIMAA does not move forward, that doesn't guarantee that "bad guys" won't
get access to such data via their own GIMAA-like technologies that could
infect systems around the world. Blocking GIMAA would only assure that
honest players wouldn't have access to the same sorts of important
information.
In my book, it's nonsensical and dangerous to block open and honest use of
even potentially sensitive data, while the unscrupulous can likely gain
access to similar data via their own means and for their own purposes.
Sometimes sunlight really is the best disinfectant, and in the case of the
Internet the old paradigm of "security through obscurity" has been widely
discredited.
GIMAA, while not without real risks, will hopefully shed some needed
light on aspects of the operational Internet that have been in the
shadows for far too long, having caused a resulting lack of trust
that only more open availability of data in these respects can likely
ameliorate.
Thanks as always for your consideration.
Lauren Weinstein lauren@vortex.com or lauren@pfir.org +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
http://lauren.vortex.com/archive/000307.html
In response to my discussion of "The Online Medical Records Trap" (
http://lauren.vortex.com/archive/000306.html ), I've been asked what would
happen if a central medical records system were encrypted in the manner I
suggested, where the service provider couldn't access the records even in
the face of an outside demand (like a court order) without the user's
permission, in the case of the person being incapacitated or unconscious.
There are several rather simple answers to this. The most basic is that to
depend on a centralized system as the only location where medical records
are stored would be incredibly foolhardy. If doctors or hospitals needed
access to that data, and their local computers or Internet connections were
down, or if the central servers had been hacked or were having other
problems (including possible connectivity issues) then patients would be
S.O.L. (that is, up the creek without a paddle).
It should be required that doctors and hospitals maintain local copies of
patient records, ideally not only on their local computers (the same level
of encryption and access control that I propose for central medical records
systems would not be necessary nor desirable on these local systems), but
also the records should be kept in hardcopy form as well.
Yes, I said hardcopy. A hassle that devalues the computerized systems?
Yep, but I want my medical records kept locally in a form that doesn't
depend on computers or even electricity. I like those manila folders on the
shelves, especially living in an area where earthquakes and other natural
disasters (with their resulting power outages) are always a possibility.
Most other areas also have their own risks of disasters or problems that
could make computer-based access to patient records impossible just when
they're needed most, especially if those records are centralized and
communications are down.
As far as access to a central system is concerned, nothing says that a user
couldn't provide friends, next-of-kin, etc. with their access key, or even
have it noted on whatever emergency contact information that they hopefully
carry routinely. I have a slip of paper in my wallet with a few contact
names and numbers for emergency use, mainly in case some idiot wipes me out
making a left turn in front of me when I'm riding, but the point is that
while carrying around your passwords isn't a great idea in the general case,
this is one specific situation where it could make sense.
I should add that it's also wise to include on your contact sheet full
information about any allergies or other serious medical conditions that
exist so that responders will know about them in emergencies. To depend on
access to a centralized medical system for such info in these situations
could be disastrous, even if none of the central data were encrypted or
otherwise access controlled — there's no guarantee that the central system
would be reachable when you might need it most.
So what does this all boil down to? A centralized medical records system
should never be depended upon for anything other than secondary access to
medical data, if that. Doctors and hospitals must be required to maintain
local copies of patient data since there is no guarantee that central
systems will be accessible at any given time, particularly in disaster or
other emergency situations.
To help prevent misuse of central medical records systems, all personal
medical data on those central systems should only be accessible with the
permission of the user or their designated contacts, and should be encrypted
in a manner that makes other access impossible. Period. Anything short of
this opens up enormous abuse potential.
Lauren Weinstein lauren@vortex.com or lauren@pfir.org +1 (818) 225-2800
Lauren's Blog: http://lauren.vortex.com PRIVACY Forum: http://www.vortex.com
[In subsequent discussion, Curt Sampson noticed the "beta" tag below the
HealthVault logo doesn't make him very confident about putting all of his
and his family's critical health information into the system. He also
noted a nasty problem with their feedback facility. Lauren noted a cert
inconsistency there. Curt replied "I think I can get some sense of how
well your site is run by clicking on 'feedback', which first gives me:
'Unable to verify the identity of feedback.live.com as a trusted site.'"
PGN]
Please report problems with the web pages to the maintainer