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…
[Via Dave Farber's IP distribution. PGN] A simple flaw in the coding of Senator Barack Obama's Web site led to a hacking switcheroo of presidential proportions just days before the Pennsylvania primary. Some supporters who tried to visit the community blogs section of Obama's site started noticing late last week they were being redirected to Senator Hillary Rodham Clinton's official campaign site. Security researchers said a hacker exploited a so-called "cross-site scripting" vulnerability in Obama's Web site to engineer the ruse. Netcraft Ltd. said the hacker injected code into certain pages in the section—code that was then executed when subsequent visitors tried to view the community blogs section. The vulnerability has since been fixed. ... [Jordan Robertson, The Associated Press, 23 Apr 2008; PGN-ed] http://www.washingtonpost.com/wp-dyn/content/article/2008/04/23/AR2008042302976.html Joseph Lorenzo Hall, UC Berkeley School of Information http://josephhall.org/
From Reuters via Robert P Schaefer A computer hacker testified on Wednesday that News Corp's NDS unit hired him to develop software to reverse-engineer a rival's smart card. Was the purpose to pirate? http://www.reuters.com/article/technologyNews/idUSN2334980420080424?pageNumber=3D1&virtualBrandChannel=0
[Via Dave Farber's IP distribution. PGN] Owen Bowcott, *The Guardian*, 25 Apr 2008 Face scans for air passengers to begin in UK this summer; Officials say automatic screening more accurate than checks by humans A face recognition system will scan faces and match them to biometric chips on passports. Airline passengers are to be screened with facial recognition technology rather than checks by passport officers, in an attempt to improve security and ease congestion. Unmanned clearance gates will be phased in to scan passengers' faces and match the image to the record on the computer chip in their biometric passports. Border security officials believe the machines can do a better job than humans of screening passports and preventing identity fraud. The pilot project will be open to UK and EU citizens holding new biometric passports. But there is concern that passengers will react badly to being rejected by an automated gate. To ensure no one on a police watch list is incorrectly let through, the technology will err on the side of caution and is likely to generate a small number of "false negatives" - innocent passengers rejected because the machines cannot match their appearance to the records. They may be redirected into conventional passport queues, or officers may be authorised to override automatic gates following additional checks. Ministers are eager to set up trials in time for the summer holiday rush, but have yet to decide how many airports will take part. If successful, the technology will be extended to all UK airports. ... Full story at: http://www.guardian.co.uk/business/2008/apr/25/theairlineindustry.transport School of Computing Science, Newcastle University, Newcastle upon Tyne, NE1 7RU, UK http://www.cs.ncl.ac.uk/people/brian.randell +44 191 222 7923 IP Archives RSS Feed: http://www.listbox.com/member/archive/rss/247/
[Thanks to Mike Hogsett for noting this event, and Brad Templeton for recording it.] What is allegedly the very first spam message was sent roughly 30 years over the ARPANET: http://www.templetons.com/brad/spamreact.html#msg In seeing this, Mike was amused because he works with some of the people it was addressed to, of whom a few are still at SRI: NEUMANN@SRI-KA, GARVEY@SRI-KL, MABREY@SRI-KL, WALDINGER@SRI-KL and some of whom are retired: ENGELBART@SRI-KL, NIELSON@SRI-KL, GOLDBERG@SRI-KL (I am always amused when some of these old ARPANET addresses show up in today's incarnations of spam.) Also somewhat before Mike's time, Geoff Goodfellow, Ron Kunzelman, Dan Lynch, and many others at SRI were instrumental in the evolution of the ARPANET. Also included in the enormous enumerated TO: list (historically interesting in itself by not having been suppressed!) are Bill English (who was the catalyst for much of Doug Engelbart's innovations being transitioned from SRI to PARC), Dave Farber, Irv Jacobs, Bob Metcalfe, Jon Postel (who by then had moved from SRI to ISI), three Sutherlands, and Lauren Weinstein, to name just a few. Happy Birthday, Spam! Sorry I cannot wish you many happy returns. [Error corrected in archive copy. PGN]
Making it a legal offence to reply to the "From:" address of a message one had classified as spam would be disastrous. Many overly-ambitious spam filters classify legitimate email as spam. In particular, there is one spam filter that regularly classifies email from family members as spam, even though the email itself is quite legitimate and contains no evil attachments. Until there are perfect spam classifiers (which is likely never), such a legal requirement would criminalize responding to legitimate, but miss-classified emails. (Yes - I've tried to get the spam filter in question fixed, but it hasn't happened yet.)
> The risks are left as an exercise for the reader... I've been reading RISKS for a looooong time. I'm not quite as paranoid as they come, but I'm close, and I don't see the problem. In fact, this seems like a pretty good idea to me, not so much because it allows bosses to spy on their employees (though that doesn't seem altogether unreasonable) but because this kind of closed loop could put a serious dent in credit card fraud. The source of nearly all credit card fraud is the fact that under the current protocols, the information used in one transaction can be used to conduct a different transaction. Adding a closed loop through a node over which the card holder has actual control (like an email account or a cell phone) eliminates this problem. The only reason IMO the card companies have not done this sooner is that they have been able to fob the problem off on the merchants. Perhaps Mr. Brown would be so kind as to elucidate exactly what he thinks the RISKS are?
How about the following explanation. Both neighbours use the same ISP and power off their networks. when they power up, the ISP assigns Jason's DHCP address to the OP and then the tax site maps that IP address (previously used by Jason) and provides Jason's details to the OP. This would be a really scary ignorance of the way in which the Internet works!
This is easily explainable by server-side IP tracking, so you can rest easy on "Jason" hacking your computer. It's quite likely the server noticed a hit from an IP address that matched a recent login from Jason. (Either an exact match, or similar within a few subnet bits.) So it helpfully preloaded the auto-complete list to speed the login process for Jason. After your reboot, the most recent hit from that IP or subnet was no longer Jason, so Jason's information was no longer preloaded. The privacy risk does exist, but would seem fairly minimal. Name and address are hardly secrets, so the only thing you learned was that he has a computer and used TurboTax online. A View Source on the HTML might have dispelled any further concerns about leaking Jason's info to you or your info to anyone else from the same IP address or subnet.
Last year my Significant Other Martha and I were at the end of a California vacation, driving south from Calistoga to Oakland in our GPS-equipped rental car. All went well until the pleasant female GPS voice told us to take a certain exit. It didn't look right, but I though, "Why not? We have time, and we might see something new." I took the exit, as did the car behind me. I was directed down some very suburban side streets which were clearly not going to be taking us anywhere near the Oakland airport. The car stayed behind me. Finally the car honked because I had slowed to try to figure out where I was, and what might have gone wrong. I pulled over, and as he roared past me, honking again, I could hear the driver shout something about "tourists." I continued on, following the GPS route, which now brought me back to the starting point of the misdirection. "Turn right," said the GPS. To do so would have taken me around the same suburban loop. Just as I turned left (against the advice of the GPS) I noticed that the car which had once been following us, and which had honked and whose driver had shouted, was now sitting curbside, its occupants shouting and waving arms in frustration, arguing about which of them had made this terrible mistake. Though I have no proof, I believe they had the same in-car GPS that we had, and received the same erroneous directions. But we used our heads, and were soon on our way back to Oakland on a road we knew would actually take us there. For all I know, the other car is still looping around that obscure California neighborhood, blindly following the instructions of the GPS.
I've spent the last two years looking at map data from vendors across the world trying to understand if they have decent speed limit data. They don't. Last time I ran the numbers, NAVTEQ provided "observed" speed limit data on less than 10% of the US street segments. TeleAtlas is worse. You don't want to hear how bad the EMEA data are. For the most part, the best you can do is choose a speed limit based on the class of road (limited access, expressway, arterial, etc.) Most US States have speed limits that vary by vehicle type - for example, class A trucks may only drive 55 on freeways even if the road speed limit is listed as 65. That's in California (and many other states), but there are exceptions, sometimes on a per-road basis (the Ohio Turnpike comes to mind, and Texas has even more arcane rules). Real-time conditions aren't even under consideration ... though the infrastructure to deliver the condition information is improving!
> Does the car work if it can't get a GPS fix? Modern car navigation systems (such as the TomTom Go 920) have accelerometers in addition to a GPS receiver. The primary purpose of these accelerometers is to allow the system to function in tunnels and deep valleys, but they should also nullify the effect of a GPS jammer, unless of course the jammer is in a car that's driving on the same road, in the same direction, at the same speed as you are.
> [... SEE 25.12. PGN] With all due respect, this is preposterous. First of all, the speed limit warning is one of a series of safety features that can be enabled and disabled, and last I checked they were all disabled by default. When they were first introduced in a software update some months ago, I deliberately enabled the speed limit warning and the menu restrictions. Second, if you do enable it, there is an audible warning when you go above ~110% of the local speed limit. The default sound is a soft triple chime that repeats at an interval of about 30 seconds (I've never timed it, it just feels that way) Third, there is a hysteresis, so that if you cross from a section with a higher speed limit into a section with a lower speed limit, TomTom will wait a bit for you to reduce your speed before the speed indicator goes red and the audible alarm goes off. Fourth, if you are going more than 10% over the speed limit - which is when it starts blinking - you'd better be watching the road and not your satnav or I wouldn't want to be on the same road as you. In fact, TomTom has another safety feature you can enable that blanks the screen when you go above a certain speed. Fifth, regarding misleading speed limit information, *use your eyes* - how on earth did you cope before you got your satnav? - and use TomTom's map correction feature to report the error. I concede that it doesn't handle variable limits, though, and it is a problem in Oslo, where I live, albeit a minor one - there is only one road where the speed limit varies on a daily or intra-daily basis, and two where it varies on a seasonal basis. Sixth, when you've driven a few miles with your TomTom, you should have a pretty good idea of the magnitude and sign of the error on your car's built-in speedometer (mine is 8%, and unless there is something wrong with your car, it is always positive, i.e. you are going slower than the speedometer indicates), so incorrect speed limit information in your satnav shouldn't be a problem - provided you pay attention to the signage so you know when it's incorrect. Personally, I don't find the blinking annoying at all - once I enabled it, I adapted very quickly so that I now see in my peripheral vision when it's on and when it's off, and I don't have to stare at it to read the speed.
We differ of opinion on a number of points. It starts with an apparent assumption that all TomTom versions are equal, which is not the case. I was talking about Navigator 6 on Symbian (further named N6) - my fault for not clearly identifying it because it alters the discussion somewhat (and it means another risk has been identified, version delta). Further, note that I'm not *relying* on the speed limit feature - it actually gets in my way :-) > I deliberately enabled the speed limit warning and the menu restrictions. I didn't deny the original useful intention. It's especially handy when abroad and when you're in a different system of measurements (miles vs kilometers) - but claiming a feature isn't a problem because you can switch it off misses the point somewhat. And in my version it cannot be disabled. Speed indication comes with limit "feature", like it or not. New risk: different implementation per version. In N6, the speed tolerance in N6 is limit + 5 km, with the disco effect starting at limit + 10 km (where limit = what TomTom derives from the supplied maps). N6 also lacks the audible alarm, but I started this discussion talking about the speed indication and what the alarm "feature" does to it - not that I'm somehow reliant on the limit information (if anything, I'd be happy if I could disable it). > TomTom will wait a bit for you to reduce your speed before the speed > indicator goes red and the audible alarm goes off. And this affects the discussion in which way? > In fact, TomTom has another safety feature you can enable that blanks the > screen when you go above a certain speed. Available in N6. I think we're on the level with road sharing - I would be worried about a driver relying on an external, unaudited and unaccredited piece of equipment with data in need of improvement as primary means to comply with speed limits, instead of using a speedometer that require formal type approval before vehicle use. And let's hope the radio stays off :-) My point is exactly that there is very little time to take in data when driving (side and rear mirror scan, speedo, fuel status, children) so the last thing a device should do is obstruct information. If one insists on blinking then use at least a method that doesn't deny or delay information, especially if this feature isn't optional. [...] I already observed I'm not that interested in the limit data (it presently seems to get in the way :-). The map correction feature is another fun feature. It leads me to suspect it's maybe a good idea to avoid any new road layouts for a while because drivers may be distracted entering map changes, potentially resulting in a higher than usual accident risk.. Joking aside, the only way I can see that work sensibly is if it's a one-button feature which simply sends the current GPS location to the surveyors for review (i.e. uses the traffic link, for example). That would ensure the quality of the input, because the whole map sharing concept has IMHO some entertaining potential too. As a matter of fact, if you file a map issue with TomTom this is exactly what happens. You identify an issue, and they appear to queue a location survey to re-acquire the information, which assures the quality. And sell you a new map :-). I think my reasons for why I want the speed facility are slightly immaterial to the discussion, but FYI, it merely serves as extra calibration data for me as a driver as I use multiple vehicles in various countries, it's not a primary source of information. > Personally, I don't find the blinking annoying at all ... Well, AFAIK blinking fell into programming disrepute (other than for severe alarms and Hollywood movies) somewhere around the times VT100s were introduced. It appears we need to re-chlorinate the gene pool because it keeps popping up. Blinking, as it were.. It's also not a major issue (after all, I'm still using the software :-), merely a fine example of how the best intentions get waylaid by not thinking something through and sufficiently testing it in the field. I see the same issue with map share - I'm sure creative use will appear at some point. I just hope it can be disabled..
When the "restricted menus" feature is enabled and the car is moving, most menu choices - including map correction - are disabled. There is an option to have a button on the screen that you hit to mark the location so you can enter the correction later. I don't like it, as it clutters the screen; instead, I either make a mental note to enter the correction later, or pull over and enter it right away. You get twelve months of free updates for every map you buy. There is also an option to update your map with unverified corrections, in which case you immediately get any correction that has been reported by multiple users. I'm not sure what the cutoff is, and I'm not sure how quickly speed limit corrections are made available; they seem to be processed manually, unlike simpler changes (one-way streets, blocked streets, intersections converted to roundabouts or vice versa...)
Please report problems with the web pages to the maintainer