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…
'improbable' A mechanical failure sent a JetBlue plane like this one careening wildly through the skies, sparking panic among the 155 people aboard the Las Vegas to New York flight, passengers told The Post yesterday. "It was four hours of hell," said Travis McGhie, who described how the plane kept lurching from side to side and going into steep turns when its hydraulic system failed Sunday. ... The side-to-side weaving was likely a sign that the pilots had lost lateral control, said Dave Esser, a professor at Embry-Riddle Aeronautical University in Florida. An Airbus manual describes a double hydraulic failure as "improbable in operation." ... [*NY Post*] http://www.nypost.com/p/news/national/jetblue_hours_of_hell_sKTYyyOCgV9oGLeqnuIWIJ
http://latimesblogs.latimes.com/lanow/2012/06/san-onofre-computer-modeling.html
https://threatpost.com/en_us/blogs/fda-software-failures-responsible-24-all-medical-device-recalls-062012 robert schaefer, Atmospheric Sciences Group, MIT Haystack Observatory Westford, MA 01886 781-981-5767 http://www.haystack.mit.edu
(RISKS-26.85) Baxa also sells a medical compounder using a Microsoft operating system with the gotcha that “any unauthorized programs installed on a Baxa product will void the manufacturer's warranty.'' For instance, the Baxa `Preventing Cyber Attacks' document explicitly cites “OS updates and installation of antivirus software'' as a warranty voiding event. This rather draconian, blanket mandate appears to contradict the FDA's document on `Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software'.
(Fu, RISKS-26.89) Readers contributed a couple updates OOB regarding malware and medical device software. Hat tip to Shawn Merdinger who points out that CareFusion appears to violate the spirit of its own legal disclaimer concerning not to "post or transmit any information or software which contains a virus, trojan horse, worm or other harmful component." It also says, "By using the CareFusion.com web site, including any software and content contained therein, you agree that the use of the Site is entirely at your own risk.... THIS DISCLAIMER OF LIABILITY APPLIES TO DAMAGES OR INJURY CAUSED BY ... COMPUTER VIRUS." This technique reminds me of Riegel vs. Medtronic, but so much more efficient when a manufacturer can simply disclaim malware liability in medical device software. The CLEAN MX realtime database offers further details on the infection. According to CLEAN MX, the web server was infected with the "JS/Redirector.JL.1" virus for 1666.3 hours from March 23, 2012 to May 31, 2012. Also, the Department of Homeland Security wrote to me that according to http://web-sniffer.net/, the site seems to be running an old version of .NET. http://blog.secure-medicine.org/2012/06/click-here-to-download-your-avea.html
If you are at all interested in the issue, I urge you to read the original published article, at http://www.prsa.org/Intelligence/PRJournal/Documents/2012DiStaso.pdf I have done so, and the *Science News* article is a fair summary of the findings. I would paraphrase the original article as "Because the Wikipedia is rightly so well respected, it's important that information about companies should be correct, and our survey shows that PR professionals who try to get factual errors corrected often experience serious difficulty and long delays." The difficulty people experience in getting incorrect computerised information corrected is no new topic in RISKS. The one thing which _is_ misleading is the 60% figure. You would think that someone had taken a sample of Wikipedia pages about companies and discovered that 60% of them contained (possibly minor) errors. The study surveyed a sample of PR professionals. Paraphrasing again, out of those who answered "yes" to "does the company you represent have a Wikipedia entry that you know about", 60% went on to answer "yes" to "does that entry contain factual errors". The error rate in company entries as such remains unknown.
within hours (Mike Flacy) Mike Flacy, Digital Trends, 29 May 2012 As mentioned by the BBC News recently, a 17-year-old girl was visiting her grandmother in Sydney, Australia when she took a picture of a "large sum of cash" while helping her grandmother count her cash savings at the home. The teenager posted the picture on her Facebook feed around 4 p.m. on Thursday May 24. Approximately seven hours later, two masked men armed with a wooden club and a knife entered the girl's family home 75 miles away in the town of Bundanoon. Upon entering the family home, the men found the 47-year-old mother of the girl as well as a 58-year-old man and 14-year-old boy, likely her father and brother. When speaking to the family, the two men wanted to talk to the girl about the sum of money in the picture that was posted on Facebook. ... http://www.digitaltrends.com/social-media/teenage-girl-posts-picture-of-cash-on-facebook-family-robbed-within-hours/ http://www.bbc.co.uk/news/world-asia-18232613
Original source: http://phk.freebsd.dk/sagas/md5crypt_eol.html John Kemp <john@jkemp.net> wrote: > This blog post doesn't tell us anything useful. Actually, it does, and you have missed the main point amongst the fuss over the recent password leaks and the irrelevant problem of MD5 collision attacks. > [MD5 is] probably still mostly just fine for storing passwords, provided > that certain other security measures are taken: > > i) Online password retries must be limited > ii) Passwords should be stored "salted" [...] > iii) Password databases should be stored securely The point of Poul-Henning's announcement is that (ii) is not sufficient in the event that (iii) fails. The reason is that MD5 is optimised for speed, so an attacker is able to use brute force to recover password plaintexts in reasonable time. So as well as salting you need to use many iterations of the hash function in order to slow down a brute-force recovery attack enough to make it infeasible. Recently several people have written good articles to explain this: http://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/ http://www.f-secure.com/weblog/archives/00002095.html http://throwingfire.com/storing-passwords-securely/ Now, PHK's MD5 crypt() uses 1000 iterations, so it is a lot more secure than a naive salted hash. But still, it is not secure enough given the performance of current computers and GPU-optimised MD5 implementations. The articles all mention bcrypt() which is based on Blowfish instead of MD5. It has the advantage (for this purpose) of requiring a large state space, so it is harder to speed it up using GPUs. They also mention scrypt() which is designed to use a fairly large amount of memory, more than fits in the CPU cache, so that its performance is limited by memory speed more than CPU speed - and memory technology does not speed up like CPUs.
Allow me to inject a minimum of fact into the discussion, as someone who has known Poul-Henning for many years and actually took the time to read what he wrote and not just the regurgitation of a journalist who clearly does not understand the issue: Poul-Henning's point has nothing to do with real or imagined inherent weaknesses in MD5. His point is that known-hash attacks against MD5 are too easy because MD5 is fast on modern hardware. Neither did he claim any connection between the LinkedIn breach and his code; he just thought it was a good occasion to remind people that times change. For the record, I don't agree with him - picking a slow algorithm only slows the attack down arithmetically. I believe in increasing the key space, which slows the attack down geometrically. The best long-term solution is probably to switch from passwords to passphrases. > (i) Online password retries must be limited Irrelevant in the case of a known-hash attack, which is the premise for this discussion. > (ii) Passwords should be stored "salted" - i.e.. where the cleartext > is concatenated with a random value. In such a case, the attacker will > have to run an individual dictionary attack for each user's password. Poul-Henning's MD5 algorithm is indeed salted. That doesn't matter for known-hash attacks, since the salt is known to the attacker. LinkedIn's password hashes were not salted, but they are now: It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases. The bit about "members whose passwords have not been compromised" worries me. It implies that they either a) have a copy of the cleartext passwords and are therefore able to rehash them immediately, or b) won't rehash those passwords until the next time the user logs in. I don't much like either option, but I dislike option b) less than option a). > (iii) Password databases should be stored securely Once again, the premise is that the hash is known to the attacker.
In the third paragraph of John Kemp's piece on MD5 (RISKS 26.89), he states that 'When people have said that "MD5 is broken" they mean that MD5 is subject to "collision attacks" in which two different cleartext values can hash to the same value.' This is true but not useful. By definition, a hash is a digest of a message *which is, except for very short messages, shorter than the original message*. So the range space of a hash is much smaller than its domain space, so many different possible (but not necessarily human-intelligible) messages map to the same hash value. This is a property of the hash problem, regardless of the hash algorithm. So MD5, SHA-1, and all past, present and future hash algorithms contain potential collisions. However, if it is possible, given a hash value, to generate a source message (not necessarily the original message) which hashes to that value, then the hash algorithm is truly broken (as it is effectively not reversible). Ironically, password storage is one application where the "messages" (the passwords) are typically very short (i.e. shorter than their hashes); however, designing a hash algorithm to be completely collision-free for very short messages would probably introduce enough "structure" to enable a cryptographer to reverse-engineer the algorithm ... which would break the algorithm.
Cameron Scott, 20 Jun 2012 LinkedIn hit with lawsuit over massive data breach A lawsuit seeking class-action status said the company failed to implement industry standard security measures http://www.itbusiness.ca/IT/client/en/CDN/News.asp?id=68020
Error code 451: an HTTP error for censorship? One would imagine that after legal censorship there would be either a password protected gateway or more simply no page to not return. XML creator Tim Bray has proposed a new HTTP error code: 451, "Legally restricted." The idea is to create an unambiguous code that ISPs can return when a user requests a page that has been censored by a court or government. Note the specific number of the error code. Bray thanks Ray Bradbury in the footnotes." Here's a sample error message: This request may not be serviced in the Roman Province of Judea due to Lex3515, the Legem Ne Subversionem Act of AUC755, which disallows access to resources hosted on servers deemed to be operated by the Judean Liberation Front. http://boingboing.net/2012/06/13/error-code-451-an-http-error.html and https://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00 robert schaefer, Atmospheric Sciences Group, MIT Haystack Observatory Westford, MA 01886, voice: 781-981-5767 www: http://www.haystack.mit.edu
http://j.mp/MfX37L (*The New York Times* via NNSquad) "Just how hard can it be to verify the age of a person online? After all, privacy experts have been complaining for years about how much advertisers know about people who use the Internet. The answer, it turns out, is very hard." And even if you establish a Big Brother database and force everyone to use biometric IDs all the time—people will still find ways to evade the systems, en masse. The bottom line: It may not be immortality, but in key ways and from a practical standpoint we're all ageless on the Internet.
[Relating to CNET Mobile via Dave Farber's IP] http://m.cnet.com/news/fbi-dea-warn-ipv6-could-shield-criminals-from-police/57453738 Relax. This has nothing to do with criminals. It's cop bluster designed to get us to wiretap ourselves "before the cops get Congress to force us to". The actual situation is that the shortage of IPv4 addresses (plus routing constraints) required careful allocation of IPv4 addresses. These needs were addressed through a cumbersome and intrusive global bureaucracy led by ICANN, ARIN, RIPE and APNIC. Those bureaucracies ended up building a big database of who-has-what-addresses, containing every customer of every ISP who had a fixed IP address. All sorts of cops and busybodies around the world got used to having that database, in order to turn arbitrary IP addresses into names to harass, and physical addresses where the honest among those people might be harassed. There's no need for such global databases of IPv6 addresses, which can be allocated in large chunks to ISPs and then allocated locally by the ISPs in any manner that pleases them and their customers. This blather from cops, via Declan who should know better, is solely to encourage the intrusive global bureaucracies (and their ISP customers) to build the same kind of database. Not for the bureaucracies' own convenience; it's endless nitpicking work and always wrong. Nor for the convenience of Internet users nor ISPs, who hate the existing bureaucracy for 'justifying' their need for niggardly dribs of IPv4 addresses. It's all for the convenience of cops. They love systems that collect reams of data about everyone, guilty or innocent. Then they can go trolling through that data without warrants, whenever they feel like it. For example, they get hundreds of thousands of copies of your phone bills every month, without notice to you, just because they can, to see who you were calling, and from where. Tell them where to stick it. Our identities as online communicators are none of the government's business. We are innocent until proven guilty. FBI, DEA, NSA, and RCMP can, and should, stop their totalitarian strategies and tactics. They can "Come back with a warrant", and serve it on an ISP, if there's a real issue about a particular IP address. Under current law, a mere subpoena to an ISP suffices to get all their records about you (an ISP customer), under the dubious legal theory that "you have no 4th Amendment protection for data about you that's held by somebody else" (California Bankers Association v. US, 416 U.S. 21 (1974)). Cops can issue subpoenas themselves, without even asking a judge. So the lack of a big database about all of us is really no problem for police. They're just lazy. "A policeman's job is only easy in a police state", as Orson Welles wrote in 1958.
http://www.bbc.co.uk/news/business-18535060 NatWest said it had failed overnight to solve issues that meant some customers could not access online accounts. "Unfortunately we are once again experiencing technical issues with our systems," NatWest said on Friday. As well as some NatWest customers, others with RBS and Ulster Bank accounts have also been affected. ... NatWest has 7.5 million personal banking customers. The bank did not say how many people had been affected across the group, but Ulster Bank, which along with NatWest is also part of the RBS group, said 100,000 of its customers had been affected by "a major technical issue".
Canada" (Christine Wong) Christine Wong, *IT Business*, 14 Jun 2012 http://www.itbusiness.ca/it/client/en/home/News.asp?id=3D67942 Data lost or breached at 82.5 per cent of government IT systems in Canada A new McAfee study suggests IT managers at all levels of government in Canada may be overly confident about the security of their systems. This overconfidence is one risk, but there is another with statistics. opening text: Government IT managers in Canada are over-confident and reactive rather than proactive when it comes to protecting public data from security threats, a new study suggests. Although 97.5 per cent of government IT security software decision makers say their systems have been exposed to some sort of direct security threat or challenge in the past year =96 and 82.5 per cent have suffered a data loss or breach in the same period—80 per cent of them still feel =93confident=94 or =93very confident=94 about their ability to protect mission critical data. Leger Marketing surveyed 40 randomly selected IT managers responsible for security software decisions at the federal, provincial and municipal government levels. They were polled in February for security software vendor McAfee Canada. Now, it comes out that the sample is only 40. Throughout the article, the results are stated to three significant digits when the result in the sample is odd. This is abuse of statistics.
Robert X. Cringely, *InfoWorld*, 13 Jun 2012 Why we need a code of ethics for the Web? What do you do when you've stolen content from someone else's website? If you're FunnyJunk.com, you sue them for defamation when they call you a thief http://www.infoworld.com/t/cringely/why-we-need-code-of-ethics-the-web-195510 The summary above says it well. One of the comments refers to a writeup of some rather careless/shady reporting.
[This link gives a bit more detail than a link that I sent yesterday.] David Marshall | InfoWorld, 18 Jun 2012 Security issue found in 64-bit virtualization software running on Intel CPUs Vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape http://www.infoworld.com/d/virtualization/security-issue-found-in-64-bit-virtualization-software-running-intel-cpus-195746
Antone Gonsalves, *InfoWorld*, 18 Jun 2012 US-CERT discloses security flaw in Intel chips; Vulnerability could allow hackers to gain control of Windows, other operating systems http://www.infoworld.com/d/security/us-cert-discloses-security-flaw-in-intel-chips-195725
Jeff Vance, *IT Business*, 18 Jun 2012 How secure is the cloud? IT pros speak up http://www.itbusiness.ca/it/client/en/CDN/News.asp?id=67997 What you really need to know about cloud security selected text (There is more interesting stuff.): One troubling trend uncovered in the Sony breach is that hackers view the cloud not necessarily as a target, but as a resource. Hackers used stolen credit cards to rent Amazon EC2 servers and launch the crippling attack on Sony. "Everything the cloud offers to legitimate businesses it offers to criminals as well," says Scott Roberts, senior intelligence specialist at Vigilant, a security monitoring company. "It's becoming common for cyber-criminals to rent cloud infrastructure to set up spambots or to build out a malware command and control infrastructure. At $50 or $60 a month, attackers can take advantage of resources that a few years ago would be too difficult and too expensive to build on their own." Sweet discussed a client CloudPassage worked with (who prefers to remain anonymous) who had development servers in the cloud. A hacker placed a rootkit onto one of the virtual servers. When the developers noticed something was off with their servers, they brought them back behind the corporate firewall to re-image them. Unfortunately, they brought the rootkit in with them, infecting their entire network.
*Technology Review* (via NNSquad) http://j.mp/LC3gv2 "If Facebook were a country, a conceit that founder Mark Zuckerberg has entertained in public, its 900 million members would make it the third largest in the world. It would far outstrip any regime past or present in how intimately it records the lives of its citizens. Private conversations, family photos, and records of road trips, births, marriages, and deaths all stream into the company's servers and lodge there. Facebook has collected the most extensive data set ever assembled on human social behavior. Some of your personal information is probably part of it." And knowing that Mark Zuckerberg has ultimate say over how that data is used gives one such a warm and fuzzy feeling, eh?
Australian retailer applies 6.8% surcharge on orders placed using older versions of Internet Explorer. Security concerns are alleged, but it's really about website support. http://www.maximumpc.com/article/news/aussie_e-tailer_begins_taxing_ie7_holdouts As someone who still uses Netscape and an ancient version of Safari, I'm deeply disturbed by this development. I simply don't use sites that don't work with my browsers. This hasn't been a big problem, except that I need to find a new on-line stock broker.
http://www.infoworld.com/t/hacking/hacker-group-demands-idiot-tax-payday-lender-195964 Ted Samson, *InfoWorld*, 20 Jun 20 2012 Hacker group demands 'idiot tax' from payday lender Rex Mundi exposes thousands of customer details after payday lender AmeriCash refuses to fork over ransom opening paragraph: Hacker group Rex Mundi has made good on its promise to publish thousands of loan-applicant records it swiped from AmeriCash Advance after the payday lender refused to fork over between $15,000 and $20,000 as an extortion fee -- or, in Rex Mundi's terms, an "idiot tax."
Regarding the (alleged) 6M+ stolen passwords from LinkedIn:
They may really be stolen passwords, but suppose we put up a site that said:
"See if your password to <Organization's name here> was stolen. Please
enter your password here and the encrypted version will be matched against
the list of stolen passwords: _______"
You are likely to get a lot of fish to bite on that hook. You can identify
the fish by their IP or their cookies.
Such a site? https://lastpass.com/linkedin/
There were two kinds of sites that offered to check your password as to
whether it was in the captured list. One kind accepted a plaintext password
and generated the hashed password; the other only accepted a hashed password
(which it told you how to create).
Actually, that particular site probably had honest intentions. However, it
pointed out this problem of submitting a password and suggested that users
look at the page's source code to confirm that the plaintext password was
not transmitted (as though most people can figure this out).
HOWEVER, even submitting your hashed password to a site is still unsafe. If
the site can determine who submits it (by IP, cookies, referring link, etc.)
and can thereby guess the account of the submitter, and is able to know
(now, or later) the paintext password for that hash, then the account is
compromised.
The problem ("Let me test your password to see if it is
compromised/safe/secure") is real and is one that many, or most, users might
not recognize. Letting people think that sites that do this are safe may
make opportunities for sites that have bad intent.
It might be worth pointing out the papers about passwords referenced here:
http://www.ieee-security.org/TC/SP2012/press.html
Coming in your Future! - "An important message from your .bank!" Dear valued customer of [bank name]. You've probably heard all the news about the great new revolutionary technology on the Internet, making your life so much easier with thousands of exciting new domain names! Here at [bank name] we're proud to announce that we're changing our Web address from the old [bank name].com to the fantastic and wonderful for our customers [bank name].bank. This will allow us to provide you with many new services at even lower cost! However, before we can start saving you money and making your life beautiful, we need you to verify your account information on our new [bank name].bank site. This is necessary for you to continue having access to your funds, but will only take a minute of your time. Please click immediately on [legit looking link using obscured URL leading to criminal phishing site] and join the new domain name banking world with us! Also be sure to verify your account information at our [bank name].rewards and [bank name].suckers sites! We value you. [Thank you, ICANN. LW]
"A serious security vulnerability discovered in MySQL was disclosed this weekend. It basically allows anyone to bypass authentication and login directly into the database. We tried on a few 64bit Ubuntu systems and were able to replicate the issue (it seems that only 64 bit platforms are affected)." http://j.mp/LXunyu (Sucuri via NNSquad) Of course, having MySQL accessible directly from the Net without connection restrictions is A Bad Idea in any case.
http://www.forbes.com/sites/bruceschneier/2012/05/30/the-vulnerabilities-market-and-the-future-of-security/ The Vulnerabilities Market and the Future of Security Recently, there have been several articles about the new market in zero-day exploits: new and unpatched computer vulnerabilities. It's not just software companies, who sometimes pay bounties to researchers who alert them of security vulnerabilities so they can fix them. And it's not only criminal organizations, who pay for vulnerabilities they can exploit. Now there are governments, and companies who sell to governments, who buy vulnerabilities with the intent of keeping them secret so they can exploit them. This market is larger than most people realize, and it's becoming even larger. Forbes recently published a price list for zero-day exploits, along with the story of a hacker who received $250K from "a U.S. government contractor" (At first I didn't believe the story or the price list, but I have been convinced that they both are true.) Forbes published a profile of a company called Vupen, whose business is selling zero-day exploits. Other companies doing this range from startups like Netragard and Endgame to large defense contractors like Northrop Grumman, General Dynamics, and Raytheon. This is very different than in 2007, when researcher Charlie Miller wrote about his attempts to sell zero-day exploits; and a 2010 survey implied that there wasn't much money in selling zero days. The market has matured substantially in the past few years. This new market perturbs the economics of finding security vulnerabilities. And it does so to the detriment of us all. I've long argued that the process of finding vulnerabilities in software system increases overall security. This is because the economics of vulnerability hunting favored disclosure. As long as the principal gain from finding a vulnerability was notoriety, publicly disclosing vulnerabilities was the only obvious path. In fact, it took years for our industry to move from a norm of full-disclosure - announcing the vulnerability publicly and damn the consequences - to something called "responsible disclosure": giving the software vendor a head start in fixing the vulnerability. Changing economics is what made the change stick: instead of just hacker notoriety, a successful vulnerability finder could land some lucrative consulting gigs, and being a responsible security researcher helped. But regardless of the motivations, a disclosed vulnerability is one that - at least in most cases - is patched. And a patched vulnerability makes us all more secure. This is why the new market for vulnerabilities is so dangerous; it results in vulnerabilities remaining secret and unpatched. That it's even more lucrative than the public vulnerabilities market means that more hackers will choose this path. And unlike the previous reward of notoriety and consulting gigs, it gives software programmers within a company the incentive to deliberately create vulnerabilities in the products they're working on - and then secretly sell them to some government agency. No commercial vendors perform the level of code review that would be necessary to detect, and prove mal-intent for, this kind of sabotage. Even more importantly, the new market for security vulnerabilities results in a variety of government agencies around the world that have a strong interest in those vulnerabilities remaining unpatched. These range from law-enforcement agencies (like the FBI and the German police who are trying to build targeted Internet surveillance tools, to intelligence agencies like the NSA who are trying to build mass Internet surveillance tools, to military organizations who are trying to build cyber-weapons. All of these agencies have long had to wrestle with the choice of whether to use newly discovered vulnerabilities to protect or to attack. Inside the NSA, this was traditionally known as the "equities issue," and the debate was between the COMSEC (communications security) side of the NSA and the SIGINT (signals intelligence) side. If they found a flaw in a popular cryptographic algorithm, they could either use that knowledge to fix the algorithm and make everyone's communications more secure, or they could exploit the flaw to eavesdrop on others - while at the same time allowing even the people they wanted to protect to remain vulnerable. This debate raged through the decades inside the NSA. From what I've heard, by 2000, the COMSEC side had largely won, but things flipped completely around after 9/11. The whole point of disclosing security vulnerabilities is to put pressure on vendors to release more secure software. It's not just that they patch the vulnerabilities that are made public - the fear of bad press makes them implement more secure software development processes. It's another economic process; the cost of designing software securely in the first place is less than the cost of the bad press after a vulnerability is announced plus the cost of writing and deploying the patch. I'd be the first to admit that this isn't perfect - there's a lot of very poorly written software still out there - but it's the best incentive we have. We've always expected the NSA, and those like them, to keep the vulnerabilities they discover secret. We have been counting on the public community to find and publicize vulnerabilities, forcing vendors to fix them. With the rise of these new pressures to keep zero-day exploits secret, and to sell them for exploitation, there will be even less incentive on software vendors to ensure the security of their products. As the incentive for hackers to keep their vulnerabilities secret grows, the incentive for vendors to build secure software shrinks. As a recent EFF essay put it, this is "security for the 1%." And it makes the rest of us less safe.
IDair's new fingerprint reader captures prints from 6 meters away http://blog.al.com/breaking/2012/06/idairs_new_fingerprint_reader.html robert schaefer, Atmospheric Sciences Group, MIT Haystack Observatory Westford, MA 01886 781-981-5767 http://www.haystack.mit.edu
AP: Privacy Breach Discovered In Internet Address Bids via NNSquad http://j.mp/MvHLMa (AP / NPR) "This spring, ICANN had to suspend access to its system for letting bidders submit proposals after it discovered technical glitches that exposed some private data. That took more than a month to fix and restore. ICANN also goofed during Wednesday's announcement. It displayed Arabic names left to right rather than right to left, as the language is written. The latest breach provided more fodder for critics of ICANN and the name expansion. Skeptics have questioned ICANN's ability to run the program smoothly in the long run, given that technical problems have cropped up early on. "If this weren't all so incredibly serious, one could get quite a laugh over the concept of The Gang That Couldn't Shoot Straight being in charge of this process," Lauren Weinstein, co-founder of People For Internet Responsibility, said on his Privacy Forum mailing list." One might have hoped that a few hundred million dollars in gTLD application fees might have helped to enable at least basic technical competency. Obviously not.
http://j.mp/LnWM1i (This message on Google+) http://j.mp/LnVGTb (NPR) Another company, Afilias, says it applied for 305 top level domains, either on its own behalf or for its clients. The company currently operates .info and .mobi, among other enterprises. In a report for All Things Considered, NPR's Yuki Noguchi spoke to Roland LaPlante, a senior vice president at Afilias, about what companies want with the new domains. "They'll have complete control over what goes on in their top level domain. And that means in those domains there will be no spam, no phishing, no malware, none of the other evil things that are happening on the Internet today," LaPlante told Yuki. "So there's a big security benefit to having your own top level domain, particularly if counterfeiting has been an issue for you." I really have to call out this particular quote, because it's a classic example of a Big Lie in action. It is the very *existence* of all these new TLDs that will enable vast new empires of spam, phishing, malware, and the rest, because bad players will forge and use other obfuscation techniques to confuse Internet users via those names. There is no need for them to actually be in those TLDs for real—and Afilias must already know this.
If one removes the stylesheets, the pseudo embassy, http://en.wikipedia.org/wiki/American_Institute_in_Taiwan become the real embassy, http://www.facebook.com/photo.php?fbid=420427197980615&l=2f9174afad
Please report problems with the web pages to the maintainer