Slashdot Mirror

An anonymous reader writes German newspaper FAZ reports (google translated version) that, after facing false DMCA claims by "FirstCrist, Copyright" and threatened by YouTube with takedown, a youtuber running the German version of Islam-critic Al Hayat TV had to disclose their identity in order to get the channel back online. Later, the channel staff got a mail containing a death threat by "FirstCrist, Copyright", containing: "thank you for your personal data. [...] take care your house gets police protection!" Employee names are now on Al Qaeda black lists.

An anonymous reader writes: Over the past couple of years, Google has implemented some changes to how Android handles SD cards that aren't very beneficial to users or developers. After listening to many rounds of complaints, this seems to have changed in Android 5.0 Lollipop. Google's Jeff Sharkey wrote, "[I]n Lollipop we added the new ACTION_OPEN_DOCUMENT_TREE intent. Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device. Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction. Just like the other document intents, apps can persist this access across reboots." Android Police adds, "All put together, this should be enough to alleviate most of the stress related to SD cards after the release of KitKat. Power users will no longer have to deal with crippled file managers, media apps will have convenient access to everything they should regardless of storage location, and developers won't have to rely on messy hacks to work around the restrictions."

sneakyimp writes: The Antares rocket operated by Orbital Sciences Corporation exploded on launch due to a "catastrophic anomaly" after a flawless countdown. No injuries are reported and all personnel are accounted for. According to the audio stream hosted by local news affiliate WTVR's website, the Cygnus spacecraft contained classified crypto technology and efforts are being made to cordon off the wreckage area. Additionally, interviews of personnel and witness reports are to be limited to appropriate government agencies so that an accident report can be generated. This accident is likely to have a detrimental effect on the stock price of Orbital Sciences Corp, traded on the NYSE. The Antares rocket's engines are based on old soviet designs from the '60s. While this is sure to be a blow to NASA due to the cost, it may well boost the fortunes of SpaceX, a chief competitor of Orbital Sciences. Both companies were recently awarded resupply contracts by NASA.

benrothke writes It's hard to go a day without some sort of data about information security and risk. Research from firms like Gartner are accepted without question; even though they can get their results from untrusted and unvetted sources. The current panic around Ebola shows how people are ill-informed about risk. While stressing over Ebola, the media is oblivious to true public health threats like obesity, heart disease, drunk driving, diabetes, and the like. When it comes to information security, it's not that much better. With myriad statistics, surveys, data breach reports, and global analyses of the costs of data breaches, there is an overabundance of data, and an under abundance of meaningful data. In Measuring and Managing Information Risk: A FAIR Approach, authors Jack Freund and Jack Jones have written a magnificent book that will change the way (for the better) you think about and deal with IT risk. Keep reading for the rest of Ben's review. Measuring and Managing Information Risk: A FAIR Approach author Jack Freund and Jack Jones pages 408 publisher Butterworth-Heinemann rating 10/10 reviewer Ben Rothke ISBN 978-0124202313 summary Superb overview to the powerful FAIR risk management methodology The book details the factor analysis of information risk (FAIR) methodology, which is a proven and credible framework for understanding, measuring, and analyzing information risk of any size or complexity. An Open Group standard, FAIR is a methodology and a highly effective quantitative analysis tool.

The power of FAIR is immense: it enables the risk practitioner to make well-informed decisions based on meaningful measurements. While that seems obvious, in practicality, it is a challenging endeavor.

FAIR is invaluable in that it helps the risk professional understand the language that the corporate board and senior executives speak. Understanding that and communicating in their language can make it much easier for information security to be perceived as a valued asset, as opposed to using Chicken Little statistics.

FAIR takes the risk professional out of the realm of the dealing with risk via the checklist; which only serves to produce meaningless measurements, into the world of quantitative, defendable results.

For those that are looking for a tool to create pretty executive summary charts with lots of colors, FAIR will sorely disappoint them. For those that are looking for a method to understand how to calculate qualitative risk to support a formal enterprise risk management program, they won't find a better guide than this book.

The book is an incredibly good reference that will force you to look again at how you view risk management. Jones writes in the preface that the book is not about checklists and formulas, but about critical thinking. The authors note that information security and operational risk has operated for far too long as an art, with not enough science. This is the gap that FAIR attempts to fill.

The authors write that risk decision making quality boils down to the quality of information decision makers are operating from, and the decision makers themselves. The book does a remarkable job of showing how a person can become a much better decision maker.

A subtle but important point the book makes early on is that many risk professionals confuse risk possibilities with risk probabilities. The FAIR method forces you to focus on probabilities and not to obsess with Ebola like possibilities. Such a quantitative analysis approach is what makes FAIR so beneficial.

The book spends a few chapters on going through FAIR risk ontology and terminology. Inconsistent and poorly defined terminology is one of the most significant challenges the information security and operational risk profession faces. Having a consistent set of logical terms and definitions that make up the FAIR framework significantly improves the quality of risk relations communications within an organization.

The value of having a consistent set of logical terms and definitions is significant. For example, the book notes that many people use the term threat. In the context of risk analysis, it might not be a real threat if there is no resulting loss. In that case, it would be considered a vulnerability event.

The challenge of FAIR is acclimating to its dialect. But once done, it creates an extremely powerful methodology for risk communication and management. And therein lays its power. Setting up a common framework for risk management becomes and invaluable tool to present risk ideas. In addition, it makes the findings much more objective and defendable.

In chapter 5, the authors address the biggest objections to quantitative risk management that it can't be measured or is simply unknowable. They agree that risk can't be measured at the micro level, but it can be effectively measured to the degree to reduce management's uncertainly about risk. They also importantly note that risk is a forward-looking statement about what may or come to pass in the future. With that, perfect accuracy is impossible; but effective quantitative risk management is very possible.

The power of FAIR is that is helps add clarity to ambiguous risk situations by giving you the tools to add data points to a situation that is purported to be unknowable.

Chapter 8 is an extremely enlightening chapter in that it provides 11 risk analysis examples. The examples do a great job of reinforcing the key FAIR concepts and methods.

In chapter 10, the authors write that the hardest part of learning FAIR is having to overcome bad habits. For most people, FAIR represents a recalibration of your mental model about what risk is and how it works. The chapter deals with common mistakes and stumbling blocks when performing a FAIR analysis. The 5 high-level categories of mistakes the chapter notes are: checking results, scoping, data, variable confusion and vulnerability analysis.

FAIR is a powerful methodology that can revolutionize risk management. The challenge is that it takes a village to make such a change. Management may be reticent to invest in what is perceived as yet another risk management framework.

But once you start using the language of FAIR and validate your findings, astute management will likely catch on. Over time, FAIR can indeed be a risk management game changer.

The book is flawless in its execution and description of the subject. The only critique is that in that the author's should have been a bit more transparent in the text when (especially in chapter 8) mentioning the FAIR software, in that it is their firm that makes the software.

For those that are willing to put in the time to understanding FAIR, this book it will make their jobs much easier. It will help them earn the trust of senior management, and make them much better risk management professionals in the process.

Reviewed by Ben Rothke.

You can purchase Measuring and Managing Information Risk: A FAIR Approach from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know

benrothke writes It's hard to go a day without some sort of data about information security and risk. Research from firms like Gartner are accepted without question; even though they can get their results from untrusted and unvetted sources. The current panic around Ebola shows how people are ill-informed about risk. While stressing over Ebola, the media is oblivious to true public health threats like obesity, heart disease, drunk driving, diabetes, and the like. When it comes to information security, it's not that much better. With myriad statistics, surveys, data breach reports, and global analyses of the costs of data breaches, there is an overabundance of data, and an under abundance of meaningful data. In Measuring and Managing Information Risk: A FAIR Approach, authors Jack Freund and Jack Jones have written a magnificent book that will change the way (for the better) you think about and deal with IT risk. Keep reading for the rest of Ben's review. Measuring and Managing Information Risk: A FAIR Approach author Jack Freund and Jack Jones pages 408 publisher Butterworth-Heinemann rating 10/10 reviewer Ben Rothke ISBN 978-0124202313 summary Superb overview to the powerful FAIR risk management methodology The book details the factor analysis of information risk (FAIR) methodology, which is a proven and credible framework for understanding, measuring, and analyzing information risk of any size or complexity. An Open Group standard, FAIR is a methodology and a highly effective quantitative analysis tool.

The power of FAIR is immense: it enables the risk practitioner to make well-informed decisions based on meaningful measurements. While that seems obvious, in practicality, it is a challenging endeavor.

FAIR is invaluable in that it helps the risk professional understand the language that the corporate board and senior executives speak. Understanding that and communicating in their language can make it much easier for information security to be perceived as a valued asset, as opposed to using Chicken Little statistics.

FAIR takes the risk professional out of the realm of the dealing with risk via the checklist; which only serves to produce meaningless measurements, into the world of quantitative, defendable results.

For those that are looking for a tool to create pretty executive summary charts with lots of colors, FAIR will sorely disappoint them. For those that are looking for a method to understand how to calculate qualitative risk to support a formal enterprise risk management program, they won't find a better guide than this book.

The book is an incredibly good reference that will force you to look again at how you view risk management. Jones writes in the preface that the book is not about checklists and formulas, but about critical thinking. The authors note that information security and operational risk has operated for far too long as an art, with not enough science. This is the gap that FAIR attempts to fill.

The authors write that risk decision making quality boils down to the quality of information decision makers are operating from, and the decision makers themselves. The book does a remarkable job of showing how a person can become a much better decision maker.

A subtle but important point the book makes early on is that many risk professionals confuse risk possibilities with risk probabilities. The FAIR method forces you to focus on probabilities and not to obsess with Ebola like possibilities. Such a quantitative analysis approach is what makes FAIR so beneficial.

The book spends a few chapters on going through FAIR risk ontology and terminology. Inconsistent and poorly defined terminology is one of the most significant challenges the information security and operational risk profession faces. Having a consistent set of logical terms and definitions that make up the FAIR framework significantly improves the quality of risk relations communications within an organization.

The value of having a consistent set of logical terms and definitions is significant. For example, the book notes that many people use the term threat. In the context of risk analysis, it might not be a real threat if there is no resulting loss. In that case, it would be considered a vulnerability event.

The challenge of FAIR is acclimating to its dialect. But once done, it creates an extremely powerful methodology for risk communication and management. And therein lays its power. Setting up a common framework for risk management becomes and invaluable tool to present risk ideas. In addition, it makes the findings much more objective and defendable.

In chapter 5, the authors address the biggest objections to quantitative risk management that it can't be measured or is simply unknowable. They agree that risk can't be measured at the micro level, but it can be effectively measured to the degree to reduce management's uncertainly about risk. They also importantly note that risk is a forward-looking statement about what may or come to pass in the future. With that, perfect accuracy is impossible; but effective quantitative risk management is very possible.

The power of FAIR is that is helps add clarity to ambiguous risk situations by giving you the tools to add data points to a situation that is purported to be unknowable.

Chapter 8 is an extremely enlightening chapter in that it provides 11 risk analysis examples. The examples do a great job of reinforcing the key FAIR concepts and methods.

In chapter 10, the authors write that the hardest part of learning FAIR is having to overcome bad habits. For most people, FAIR represents a recalibration of your mental model about what risk is and how it works. The chapter deals with common mistakes and stumbling blocks when performing a FAIR analysis. The 5 high-level categories of mistakes the chapter notes are: checking results, scoping, data, variable confusion and vulnerability analysis.

FAIR is a powerful methodology that can revolutionize risk management. The challenge is that it takes a village to make such a change. Management may be reticent to invest in what is perceived as yet another risk management framework.

But once you start using the language of FAIR and validate your findings, astute management will likely catch on. Over time, FAIR can indeed be a risk management game changer.

The book is flawless in its execution and description of the subject. The only critique is that in that the author's should have been a bit more transparent in the text when (especially in chapter 8) mentioning the FAIR software, in that it is their firm that makes the software.

For those that are willing to put in the time to understanding FAIR, this book it will make their jobs much easier. It will help them earn the trust of senior management, and make them much better risk management professionals in the process.

Reviewed by Ben Rothke.

You can purchase Measuring and Managing Information Risk: A FAIR Approach from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know

CBC reports that a man pulled up to the War Memorial in downtown Ottawa, got out of his car, and shot a soldier with a rifle. The Memorial is right next to the Canadian Parliament buildings. A shooter (reportedly the same one, but unconfirmed) also approached Parliament and got inside before he was shot and killed. "Scott Walsh, who was working on Parliament Hill, said ... the man hopped over the stone fence that surrounds Parliament Hill, with his gun forcing someone out of their car. He then drove to the front doors of Parliament and fired at least two shots, Walsh said." Canadian government officials were quickly evacuated from the building, while the search continues for further suspects. This comes a day after Canada raised its domestic terrorism threat level. Most details of the situation are still unconfirmed -- CBC has live video coverage here. They have confirmed that there was a second shooting at the Rideau Center, a shopping mall nearby.

An anonymous reader writes with this excerpt from VentureBeat: Google today announced it is beefing up its two-step verification feature with Security Key, a physical USB second factor that only works after verifying the login site is truly a Google website. The feature is available in Chrome: Instead of typing in a code, you can simply insert Security Key into your computer's USB port and tap it when prompted by Google's browser. "When you sign into your Google Account using Chrome and Security Key, you can be sure that the cryptographic signature cannot be phished," Google promises. While Security Key works with Google Accounts at no charge, you'll need to go out and buy a compatible USB device directly from a Universal 2nd Factor (U2F) participating vendor.

cryptoz (878581) writes Apple is now adding barometers to its mobile devices: both new iPhones have valuable atmospheric pressure sensors being used for HealthKit (step counting). Since many Android devices have been carrying barometers for years, scientists like Cliff Mass have been using the sensor data to improve weather forecasts. Open source data collection projects like PressureNet on Android automatically collect and send the atmospheric sensor data to researchers.

NotInHere writes: Only three days after the public learned that the ChromeOS project was going to disable ext2fs support for external drives (causing Linux users to voice many protests on websites like Slashdot and the issue tracker), the ChromeOS team now plans to support it again. To quote Ben Goodger's comment: "Thanks for all of your feedback on this bug. We've heard you loud and clear. We plan to re-enable ext2/3/4 support in Files.app immediately. It will come back, just like it was before, and we're working to get it into the next stable channel release."

An anonymous reader writes In addition to Android 5.0 Lollipop, Google today also announced the first devices running the new version of its mobile operating system: the Nexus 6 and the Nexus 9. The former is a phablet built by Motorola, and the latter is a tablet built by HTC. The Nexus 6 is going up for pre-order on October 29, starting at $649. The Nexus 9 meanwhile is going up for pre-order this Friday (October 17), and you'll also be able to get it in stores on November 3.

An anonymous reader writes In addition to Android 5.0 Lollipop, Google today also announced the first devices running the new version of its mobile operating system: the Nexus 6 and the Nexus 9. The former is a phablet built by Motorola, and the latter is a tablet built by HTC. The Nexus 6 is going up for pre-order on October 29, starting at $649. The Nexus 9 meanwhile is going up for pre-order this Friday (October 17), and you'll also be able to get it in stores on November 3.

FhnuZoag writes: Last year, Andrew Wilkinson, founder of MetaLab, bought a Robocoin Bitcoin ATM, figuring it would be a fun little side project and a good way to help move Bitcoin forward. It did not quite turn out that way. He has now written a timeline of the 10-month, $25,000(CAD) struggle. In short: there was a massive shipping delay, a $2,000 charge to clear customs, no knowledge base, unhelpful support, and the ATM itself flat out didn't work.

An anonymous reader writes: Mozilla today officially launched Firefox 33 for Windows, Mac, Linux, and Android. Additions include OpenH264 support as well as the ability to send video content from webpages to a second screen. Firefox 33 for the desktop is available for download now on Firefox.com, and all existing users should be able to upgrade to it automatically. As always, the Android version is trickling out slowly on Google Play. Full changelogs are available here: desktop and Android."

theodp (442580) writes "Well, the College Board has posted the 2014 AP Computer Science Test scores. So, before the press rushes out another set of Not-One-Girl-In-Wyoming-Took-an-AP-CS-Exam stories, let's point out that no Wyoming students of either gender took an AP CS exam again in 2014 (.xlsx). At the overall level, the final numbers have changed somewhat (back-of-the-Excel-envelope calculations, no warranty expressed or implied!), but tell pretty much the same story as the preliminary figures — the number of overall AP CS test takers increased, while pass rates decreased despite efforts to cherry pick students with a high likelihood of success. What is kind of surprising is how little the test numbers budged for most states — only 8 states managed to add more than 100 girls to the AP CS test taker rolls — despite the PR push by the tech giants, including Microsoft, Google, and, Facebook. Also worth noting are some big percentage decreases at the top end of the score segments (5 and 4), and still-way-too-wide gaps that exist between the score distributions of the College Board's various ethnic segments (more back of the envelope calcs). If there's a Data Scientist in the house, AP CS exam figures grabbed from the College Board's Excel 2013 and 2014 worksheets can be found here (Google Sheets) together with the (unwalkedthrough) VBA code that was used to collect it. Post your insight (and code/data fixes) in the comments!"

An anonymous reader writes Chrome OS is based on the Linux kernel and designed by Google to work with web applications and installed applications. Chromebook is one of the best selling laptops on Amazon. However, devs decided to drop support for ext2/3/4 on external drivers and SD card. It seems that ChromiumOS developers can't implement a script or feature to relabel EXT volumes in the left nav that is insertable and has RW privileges using Files.app. Given that this is the main filesystem in Linux, and is thereby automatically well supported by anything that leverages Linux, this choice makes absolutely no sense. Google may want to drop support for external storage and push the cloud storage on everyone. Overall Linux users and community members are not happy at all.

An anonymous reader writes Chrome OS is based on the Linux kernel and designed by Google to work with web applications and installed applications. Chromebook is one of the best selling laptops on Amazon. However, devs decided to drop support for ext2/3/4 on external drivers and SD card. It seems that ChromiumOS developers can't implement a script or feature to relabel EXT volumes in the left nav that is insertable and has RW privileges using Files.app. Given that this is the main filesystem in Linux, and is thereby automatically well supported by anything that leverages Linux, this choice makes absolutely no sense. Google may want to drop support for external storage and push the cloud storage on everyone. Overall Linux users and community members are not happy at all.

An anonymous reader writes "Free software programmer Lennart Poettering has been part of his fair share of controversy in the open source community, and his latest essay may raise the most eyebrows yet. Poettering takes on the idea that the community is one big happy family and has some harsh words for the loudest and most obnoxious members. He says in part: "I don't usually talk about this too much, and hence I figure that people are really not aware of this, but yes, the Open Source community is full of a#@&oles, and I probably more than most others am one of their most favourite targets. I get hate mail for hacking on Open Source. People have started multiple 'petitions' on petition web sites, asking me to stop working (google for it). Recently, people started collecting Bitcoins to hire a hitman for me (this really happened!). Just the other day, some idiot posted a 'song' on youtube, a creepy work, filled with expletives about me and suggestions of violence. People post websites about boycotting my projects, containing pretty personal attacks. On IRC, people /msg me sometimes, with nasty messages, and references to artwork in 4chan style. And there's more. A lot more."

d33tah notes the announcement of Google Code-In 2014 and Google Summer of Code 2015. A call to all students: if you have ever thought it would be cool to write code and see it make a difference in the world, then please keep reading. We are excited to announce the next editions of two programs designed to introduce students to open source software development, Google Summer of Code for university students and Google Code-in for 13-17 year old students.

d33tah notes the announcement of Google Code-In 2014 and Google Summer of Code 2015. A call to all students: if you have ever thought it would be cool to write code and see it make a difference in the world, then please keep reading. We are excited to announce the next editions of two programs designed to introduce students to open source software development, Google Summer of Code for university students and Google Code-in for 13-17 year old students.

Almost a year ago you had a chance to ask professor Kevin Fu about medical device security. A number of events (including the collapse of his house) conspired to delay the answering of those questions. Professor Fu has finally found respite from calamity, coincidentally at a time when the FDA has issued guidance on the security of medical devices. Below you'll find his answers to your old but not forgotten questions. Fu: I apologize for the year-long delay, but my queue has rather overflowed after part of my house collapsed. See slide #11 for more information on the delay.

Medical device security is a challenging area because it covers a rather large set of disciplines including software engineering, clinical care, patient safety, electrical engineering, human factors, physiology, regulatory affairs, cryptography, etc. There are a lot of well meaning security engineers who have not yet mastered the culture and principles of health care and medicine, and similarly there are a lot of well meaning medical device manufacturers who have not yet mastered the culture and principles of information security and privacy. I started out as a gopher handing out authentication tokens for a paperless medical record system at a hospital in the early 1990s, but in the last decade have focused my attention on security of embedded devices with application to health and wellness.

I huddled with graduate students from my SPQR Lab at Michigan, and we wrote up the following responses to the great questions. We were not able to answer every question, but readers can find years worth of in-depth technical papers on blog.secure-medicine.org and spqr.eecs.umich.edu/publications.php and thaw.org.



Cochlear Implants
by mcspoo

How secure are Cochlear implants and their processors? Any chance I'm going to hear the voice of God (without the tooth implant, ala Real Genius?)

Fu: Classic cochlear implants are mostly analog circuits with some external supporting software. However, newer implants on the drawing board are looking at how to enable audiologists to adjust implant settings remotely from the cloud. There are, of course, some significant security and privacy issues that need to be resolved. But there are also good reasons for remote access. Namely, patient's bodies change overtime and an audiologist must tune the implant settings manually today. Remote control may simplify the life for patients from a demographic that may have difficulty making office visits.

Cochlear implants are amazing little devices to enable profoundly deaf patients to partially restore hearing. See the cover of Biodesign: The Process of Innovating Medical Technologies by Zenios, Makower, Yock. Also see Ultra Low Power Bioelectronics by Rahul Sarpeshkar. Cochlear implants consist of two major pieces: (1) an implant in the skull that directly stimulates the auditory nerve, and (2) a less resource-constrained external device worn on the scalp. The external device clips onto the scalp with a magnet to keep the implant paired. Think of the implant as special circuitry to wirelessly deliver sound as electrical impulses. Think of the external device as the source of power, sound inputs, and control.

I met a relatively young flight attendant a few years ago who had a cochlear implant. He explained that one day he suffered a routine cold that got worse and caused a rare infection that destroyed his auditory nerve. He lost his hearing. The cochlear implant sufficiently restored his hearing such that he and I could have a normal conversation.

You can imagine the complex security and privacy questions that will need to be considered when future devices go all "Internet of Things" or "TerraSwarm."



PCA Pumps?
by Digital Ebola

Have you explored changing the dosages on drug pumps? Either through exploiting the device directly or by exploiting the database backend? I reference the Hospira pumps that run Linux, allowing one to telnet to them as root with no password authentication. Hospira did issue an update to that but since pumps are so numerous, I'm sure that many hospitals have been slow to update. Thanks!

Fu: Pumps for medicine are amazing. Most people who have visited a hospital or seen a TV show should be aware of the plain old IV drip of saline solution to hydrate patients by gravity. It gets more interesting when a computer-controlled pump takes over from gravity. There are all sorts of pumps ranging from bed-side pumps to implantable pumps.

A PCA pump is short for a patient-controlled analgesia. I believe this question is referring to a bed-side pump rather than an implant. For instance, a patient may receive a PCA pump to deliver controlled pain medication such as morphine. Typical user interfaces consist of a "more please" button that delivers a bolus of drug via an IV.

A number of researchers have analyzed the attack surfaces for insulin infusion pumps, a special kind of externally worn pump for diabetics. Several faculty have done outstanding work in this space several years ago, and more recently a number of smart blackhat researchers have demonstrated the problems in ways more easily understandable by the general public. I think it's fair to say that manufacturers initially underestimated the importance of security requirements engineering during the early concept phases of product engineering. That said, the manufacturers are doing some amazing engineering. There is a game of catch-up, but I am optimistic that the manufacturers will improve by following the new U.S. FDA guidance on cybersecurityin good faith. Some manufacturers apparently have been thinking about security for a while. For instance, members of the insulin pump team at Medtronic recently were issued a medical device security patent filed way back in 2007!

Now on to the real question: what about the backdoor of the pump? No one likes to advertise the unsavory backdoors built into products---some by design and some by accident. It's out of sight, out of mind. On old CAT scans, you'll sometimes even find an "lp" Unix account enabled without a password. I don't know about this particular pump in question, but I would not be surprised if there are some ports left open for debugging or communication with online drug libraries. You will likely find some interesting traffic, perhaps not cryptographically protected, if you listen to the network. If you do find a problem, please be responsible and patient. Finding a vulnerability in a web browser is significantly different from finding a vulnerability in a medical device. The direct consequences on patients must be taken into account, and security researchers not collaborating with a physician are likely skating on thin ice. I recommend that researchers notify the FDA so that they may communicate the problem to the manufacturer. Call up the FDA people listed on the FDA cybersecurity guidance. Or file a MedWatch 3500 report. It once took a year for FDA to process one of my security reports; they are somewhat understaffed. FDA has tens of thousands of employees, but only about two of them focus on security. So be patient. They are good people doing the best they can with their scare resources. Remember, your U.S. readers elected the people who set the budget.



Clinical Data Systems
by DeathGrippe

Most clinics, hospitals, insurance companies and dental offices are extensively computerized and networked. Based on your experience, how often are these systems compromised?

Fu: I find a good rule of thumb to measure security of a clinical environment: count the number of Windows XP boxes. Why? Because these devices are more vulnerable to run-of-the-mill, conventional malware. At one large hospital, medical devices based on Windows XP were re-infected about every 12 days if the box is not protected. With "bandaid" approaches like firewalls and anti-virus, the devices can last longer before re-infection. Alas, you can't make good wine out of bad grapes. Windows XP lacks meaningful security requirements. Microsoft learned its lessons, and has improved the security requirements and approaches over the years. Microsoft ended all support for XP on April 8th of this year.

That said, Linux ain't no picnic either. All operating systems have risks and benefits. I believe the root of the problem is that software security lifecycles for consumer grade operating systems do not align well with the product lifecycles of medical devices. Medical devices need to remain safe and effective for a very long time.



What can I do if I have one?
by AmiMoJo

Say I have an implant that could be hacked, what can I do to protect myself? Are any vendors more reputable than others when it comes to security? Is tinfoil effective? Should I demand my doctor replaces known vulnerable equipment?

Fu: I think patients can take comfort in knowing that FDA has written meaningful guidance on cybersecurity that is likely a game changer for manufacturing. Also, I find that engineers at most medical device manufactures sincerely want to improve the security of their products. This positive attitude is unlike what one will find in adversarial industries like electronic voting where it's more common to see manufacturer denial of risks rather than mitigation risks. I've seen some large medical device manufacturers vendors organize security teams composed of dozens of employees across engineering, sales, marketing, you name it, the whole company. They are beginning to understand that information security and privacy has to become part of the corporate culture if the products make use of modern communication and computer technology.

On the other hand, I don't think you'll ever find a hack-proof computer---whether it be a laptop, smart fridge, or medical device. I used to believe that a computer buried in concrete was secure, until I buried one in the concrete foundation of my house and powered it up wirelessly. You could also go to your car dealer and replace your car with a crash-proof car after you run into a tree. You might get funny looks. A manufacturer cannot eliminate risk, but it can be smart about minimizing risk. For instance, one of the best ways to minimize security risk is to have meaningful security requirements during the concept phase of device engineering. The requirements won't prevent security problems, but lack of security requirements will prevent the product from having meaningful security down the line. One can argue that it's a lot cheaper to engineer security from the start rather than to retrofit, but that argument is no longer necessary since draft FDA guidance on cybersecurity is abundantly clear on expectations for security risk management during the manufacture of new devices.

If I were prescribed a medical device, I would accept it. Why? Anything with a computer is hackable by some adversary. So worrying about whether an implant can being hacked does not help answer the basic question: how to balance risk. If you are prescribed a medical device, then likely your doctor determined that you have a significant, predisposed risk. For instance, you might have a significant risk of sudden cardiac arrest. In general, you are much safer with a device than without.



Re:Start-ups
by Anonymous Coward

How good is malwaresoftware and the WattsUpDoc system at finding something potentially harmful on a device?

Fu: WattsUpDoc is a system that detects malware by analyzing patterns in the power outlet. It's basically a phase shift on the AC power line caused by reactive power and varying loads of the connected computer. The details get hairy and are written for the experts, so I'd refer you to the scientific paper. The beauty is that no software changes are required for the device being monitored (e.g., medical devices).

We published our report on WattsUpDoc at the USENIX HealthTech workshop. There is also a related paper on detecting web browser activity from the power lines. The performance surprised me: 95% accuracy for known malware, and 85% accuracy for previously unknown malware (unlabeled samples of a malware infection that were not in the training set). It works well because medical devices tend to do a small number of different things when working normally. We can detect the deviation.



Should the local IT team have full control over a system
by Joe_Dragon

Should the local IT team have full control over any system in place / should vendors be forced to let systems have AV and OS updates installed on them with out delays?

Fu: Hi Joe the Dragon. I shall call you Trogdor This is a good question, but it technically is a leading question because computing systems created by medical device manufacturers force the IT team to choose between bad and worse. In a more ideal world, we wouldn't need to worry about viruses in the first place. So let me go on a tangent for a moment. Buffer overflows? Maybe that medical device should not be written in C. SQL injection error? Maybe you shouldn't be running a web server with an embedded database inside a life-critical medical device in the first place. The IT folks catch a lot of blame ranging from breaches to clinician complaints of mucking up the clinical workflow. There's some truth to that, but realize that the IT folks are stuck with what they can buy or make.

Ok, now your question: Do you give IT the keys? I'm not gonna be tricked into answering that one. It depends. I think the most effective organizational structures are ones where the clinical safety teams and the IT security teams learn to speak each others' languages. The manufacturers need to be forthcoming about offering regular security updates for underlying 3rd party software if they make the business choice to use COTS software. Hey, COTS software is cheap for a reason. The best situation is when the leaders of these teams do not hesitate to call each other. That said, the most secure system might also be the most unsafe. The most safe system might be the least secure. There are cases where one might forgo security because a safety issue trumps. What if you lock out access to a hypothetical pacemaker after three failed password attempts? Probably not a good idea if you think for a moment. A secure system that cannot deliver care is neither safe nor effective. Striking the balance is tricky.

I have a long rant on software updates (NSFW).



Safer Programming Language
by Anonymous Coward

The C programming language is most often used for embedded devices. The language is poorly specified. Compilers sometimes have issues, and programmers find a zillion creative ways to make mistakes. MISRA C and its enforcement is a bag of hurt in the absence of certified tools. Has there been any work to define a more safe/sane programming language for embedded devices?

Fu: Yes, but it's certainly hard to find in the medical device community. My colleagues from aviation software safety brag about their safer languages and practices, and I do think it's a good idea for the medical device community to borrow ideas from avionics. However, there are a couple roadblocks.

First, there's a crapton of legacy software out there. Try this experiment: walk into the C suite (not the programming language, the corporate suite), then declare that you need to stop product development for 9 months in order to convert to architectures that have better security properties. I know of only one company that did this (hint, it's an automotive company).

Second, the universities are at fault. I once asked a senior engineer at a medical device manufacturer why they wrote in C and assembly for their implantable medical device firmware. The engineer explained, that's who they can hire! The universities produce the graduates, and we are not training them sufficiently for trustworthy computing. When we teach students C and C++, we are handing them loaded weapons. Many of the students are talented and can respect the unchecked power of C and assembly. It's especially good for high performance systems and hand-optimized inner loop code. However, if we want to see improvements in choices of programming languages, universities need to produce engineers who understand the risks of different programming languages. No one language is perfect for every situation. I highly recommend reading Prof. John Knight's book on Fundamentals of Dependable Computing for Software Engineers to learn about how to match the programming language to the risks.



What to do when security is unfixable?
by Anonymous Coward

Seeing the abysmal state of computer security, even basic computer reliability expectations (which Dijkstra already noted, years ago), it's no surprise that embedded systems are no better. Simply because you usually don't see them and are thus less likely to notice just how poorly and insecurely the software is done. So how do we convince these people in the medical apparatus industry to leave well alone with the networking and wireless and bells and whistles, and simply deliver us machinery that does what it does, keep us alive, and not also surf the 'web for cat videos, or leave the door open for someone to come along with the latest exploit kit? Why do these things have to be connected at all?

Fu: A couple responses. A lot of medical devices are not networked in the sense of our home computers on the Internet. Many are connected with sneakernet. Yet the malware still can get in. Sleep labs are notorious for malware because patients bring in USB sticks of music, plus unwanted bonus material. I know one large medical device that was offline, but got infected by Conficker during the split second that the vendor temporarily enabled the Internet connection to download a software update. Sad.

Keep in mind that manufacturers create products because they think they can sell them. If consumers did not express interest in questionably secure products, then we'd see better security. If insurance rates were tied to cybersecurity hygiene, we'd see security economics at work. Unfortunately, security and privacy are out of sight and out of mind as you point out. For instance, hospitals often demand the bells and whistles. I witnessed one physician checking Gmail and the web on a medical records system during surgery. I didn't have a chance to explain the risks of drive-by downloads as he was occupied teaching a young resident how to catheterize the anesthetized patient. I know another hospital system where they let radiologists check email on the medical devices because staff wanted access to email, and there wasn't enough desk space for a second computer.

I have a set of slides on wireless where I make the argument that wireless is like bacon. People think it makes everything taste better. Wireless communication and network connections do serve an important role, but one needs to make a case-by-case judgement for each device. I like the concept of wireless to reduce infection rates during surgical implantations of defibrillators and pacemakers. About 1-2% of implantations result in major complications such as infection, and about 1% of these cases are fatal. Wireless does introduce security risks. While the security architectures can be greatly improved, I'd rather be insecurely alive than securely dead from an infection.



Medical device security vs. Open standards?
by Anonymous Coward

In the ever increasing world of consumerized technology (Apps, smartphones, smarter cars etc.), how do you see medical device security staying relevant and cutting edge while maintaining adequate security? More and more people can and probably will ask "why can't I use with my ?". For instance,could a secure, but open interface be created for Insulin pumps which would allow an end-user app to aggregate multiple data sources into a better snapshot of that person, while still being secure and protected from hijacking by a 3rd party?

Fu: I agree that the natives will get restless if they perceive security as a problem rather than a solution. However, consumers have become accustomed to crap in a hurry during the 1990s transition from postcards to hyperconnected electronic communication. I think it will be difficult to create magic walled gardens or magic interfaces that "add" security because security is not a product, it's a property and a process. I see three areas where one can improve the trustworthiness of medical device software: early concept phases, post market surveillance, and all the fun stuff between (design, implementation, testing, verification, validation, etc.). There's a significant security focus on the implementation and finding bugs, but by that time much of the fate is sealed by the requirements engineering. I think more time should be spent at the concept phase on hazard analysis, risk management, etc. so that implementations are less likely to have security problems. Then spend time on post-market surveillance so you can measure the shifting effectiveness of the security mechanisms as the threats evolve.

Today, the worries are mostly conventional malware slowing down medical devices or causing malfunctions. We've begun to see signs of nation state threats, and we should use our time carefully as threats rarely decrease in severity.

I'd encourage computer science students to work for a medical device manufacturer or FDA rather than the latest Silicon Valley startup. The problems will be interesting and will bring great personal satisfaction. For creative students who enjoy writing and open ended problem solving in health care, apply to graduate schools that carry out medical device security research! Best wishes.

An anonymous reader writes MINIX 3 is a small POSIX-compliant operating system aimed at high reliability (embedded) applications. A major new version of MINIX 3 (3.3.0) is now available for download at www.minix3.org. In addition to the x86, the ARM Cortex A8 is now supported, with ports to the BeagleBoard and BeagleBones available. Finally, the entire userland has been redone in 3.3.0 to make it NetBSD compatible, with thousands of NetBSD packages available out of the box. MINIX 3 is based on a tiny (13 KLoC) microkernel with the operating system running as a set of protected user-mode processes. Each device driver is also a separate process. If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing. The full announcement, with links to the release notes and notes on installation, can be found at the Minix Google Groups page.

An anonymous reader writes: Google recently announced Chrome will be gradually phasing out support for certificates using SHA-1 encryption. They said, "We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it." Developer Eric Mill has written up a post explaining why SHA-1 is dangerously weak, and why moving browsers away from acceptance of SHA-1 is a lengthy, but important process. Both Microsoft and Mozilla have deprecation plans in place, but Google's taking the additional step of showing the user that it's not secure. "This is a gutsy move by Google, and represents substantial risk. One major reason why it's been so hard for browsers to move away from signature algorithms is that when browsers tell a user an important site is broken, the user believes the browser is broken and switches browsers. Google seems to be betting that Chrome is trusted enough for its security and liked enough by its users that they can withstand the first mover disadvantage. Opera has also backed Google's plan. The Safari team is watching developments and hasn't announced anything."

benrothke writes Most books about cloud computing are either extremely high-level quasi-marketing tomes about the myriad benefits of the cloud without any understanding of how to practically implement the technology under discussion. The other type of cloud books are highly technical references guides, that provide technical details, but for a limited audience. In Architecting the Cloud: Design Decisions for Cloud Computing Service Models, author Michael Kavis has written perhaps the most honest book about the cloud. Make no doubt about it; Kavis is a huge fan of the cloud. But more importantly, he knows what the limits of the cloud are, and how cloud computing is not a panacea. That type of candor makes this book an invaluable guide to anyone looking to understand how to effective deploy cloud technologies. Keep reading below for the rest of Ben's review. Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) author Michael Kavis pages 224 publisher Wiley rating 9/10 reviewer Ben Rothke ISBN 978-1118617618 summary Extremely honest and enlightening book on how to effectively use the cloud The book is an excellent balance of the almost boundless potential of cloud computing, mixed with a high amount of caution that the potential of the cloud can only be manifest with effective requirements and formal security architecture.

The full title of the book is: Architecting the Cloud: Design Decisions for Cloud Computing Service Models: SaaS, PaaS, and IaaS. One of the mistakes of using the cloud is that far too many decision makers rush in, without understanding the significant differences (and they are significant) between the 3 main cloud service models.

In chapter 1, he provides a number of enthusiastic cloud success stories to set the stage. He shows how a firm was able to build a solution entirely on the public cloud with a limited budget. He also showcases Netflix, whose infrastructure is built on Amazon Web Services (AWS).

Chapter 3 is titled cloud computing worst practices and the book would be worth purchasing for this chapter alone. The author has a number of cloud horror stories and shows the reader how they can avoid failure when moving to the cloud. While many cloud success stories showcase applications developed specifically for the cloud, the chapter details the significant challenges of migrating existing and legacy applications to the cloud. Such migrations are not easy endeavors, which he makes very clear.

In the chapter, Kavis details one of the biggest misguided perceptions of cloud computing, in that it will greatly reduce the cost of doing business. That is true for some cloud initiatives, but definitely not all, as some cloud marketing people may have you believe.

Perhaps the most important message of the chapter is that not every problem is one that needs to be solved by cloud computing. He cites a few examples where not going with a cloud solution was actually cheaper in the long run.

The book does a very good job of delineating the differences between the various types of cloud architectures and service models. He notes that one reason for leveraging IaaS over PaaS, is that when a PaaS provider has an outage, the customer can only wait for the provider to fix the issue and get the services back online. With IaaS, the customer can architect for failure and build redundant services across multiple physical or virtual data centers.

For many CIO's, the security fears of the cloud means that they will immediately write-off any consideration of cloud computing. In chapter 9, the author notes that almost any security regulation or standard can be met in the cloud. As none of the regulations and standard dictate where the data must specifically reside.

The book notes that for security to work in the cloud, firm's needs to apply 3 key strategies for managing security in cloud-based applications, namely centralization, standardization and automation.

In chapter 10, the book deals with creating a centralized logging strategy. Given that logging is a critical component of any cloud-based application; logging is one of the areas that many firms don't adequate address in their move to the cloud. The book provides a number of approaches to use to create an effective logging strategy.

The only issue I have with the book is that while the author is a big fan of Representational state transfer (REST), many firms have struggled to obtain the benefits he describes. RESTful is an abstraction of the architecture of the web; namely an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

I think the author places too much reliance on RESTful web services and doesn't detail the challenges in making it work properly.RESTful is not always the right choice even though it is all the rage in some cloud design circle.

While the book is part of the Wiley CIO Series, cloud architects, software and security engineers, technical managers and anyone with an interest in the cloud will find this an extremely valuable resource.

Ironically, for those that are looking for ammunition why the cloud is a terrible idea, they will find plenty of evidence for it in the book. But the reasons are predominantly that those that have failed in the cloud, didn't know why they were there in the first place, or were clueless on how to use the cloud.

For those that want to do the cloud right, the book provides a vendor neutral approach and gives the reader an extremely strong foundation on which to build their cloud architecture.

The book lists the key challenges that you will face in the migration to the cloud, and details how most of those challenges can be overcome. The author is sincere when he notes areas where the cloud won't work.

For those that want an effective roadmap to get to the cloud, and one that provides essential information on the topic, Architecting the Cloud: Design Decisions for Cloud Computing Service Models is a book that will certainly meet their needs.

Reviewed by Ben Rothke.

You can purchase Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.

benrothke writes Most books about cloud computing are either extremely high-level quasi-marketing tomes about the myriad benefits of the cloud without any understanding of how to practically implement the technology under discussion. The other type of cloud books are highly technical references guides, that provide technical details, but for a limited audience. In Architecting the Cloud: Design Decisions for Cloud Computing Service Models, author Michael Kavis has written perhaps the most honest book about the cloud. Make no doubt about it; Kavis is a huge fan of the cloud. But more importantly, he knows what the limits of the cloud are, and how cloud computing is not a panacea. That type of candor makes this book an invaluable guide to anyone looking to understand how to effective deploy cloud technologies. Keep reading below for the rest of Ben's review. Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) author Michael Kavis pages 224 publisher Wiley rating 9/10 reviewer Ben Rothke ISBN 978-1118617618 summary Extremely honest and enlightening book on how to effectively use the cloud The book is an excellent balance of the almost boundless potential of cloud computing, mixed with a high amount of caution that the potential of the cloud can only be manifest with effective requirements and formal security architecture.

The full title of the book is: Architecting the Cloud: Design Decisions for Cloud Computing Service Models: SaaS, PaaS, and IaaS. One of the mistakes of using the cloud is that far too many decision makers rush in, without understanding the significant differences (and they are significant) between the 3 main cloud service models.

In chapter 1, he provides a number of enthusiastic cloud success stories to set the stage. He shows how a firm was able to build a solution entirely on the public cloud with a limited budget. He also showcases Netflix, whose infrastructure is built on Amazon Web Services (AWS).

Chapter 3 is titled cloud computing worst practices and the book would be worth purchasing for this chapter alone. The author has a number of cloud horror stories and shows the reader how they can avoid failure when moving to the cloud. While many cloud success stories showcase applications developed specifically for the cloud, the chapter details the significant challenges of migrating existing and legacy applications to the cloud. Such migrations are not easy endeavors, which he makes very clear.

In the chapter, Kavis details one of the biggest misguided perceptions of cloud computing, in that it will greatly reduce the cost of doing business. That is true for some cloud initiatives, but definitely not all, as some cloud marketing people may have you believe.

Perhaps the most important message of the chapter is that not every problem is one that needs to be solved by cloud computing. He cites a few examples where not going with a cloud solution was actually cheaper in the long run.

The book does a very good job of delineating the differences between the various types of cloud architectures and service models. He notes that one reason for leveraging IaaS over PaaS, is that when a PaaS provider has an outage, the customer can only wait for the provider to fix the issue and get the services back online. With IaaS, the customer can architect for failure and build redundant services across multiple physical or virtual data centers.

For many CIO's, the security fears of the cloud means that they will immediately write-off any consideration of cloud computing. In chapter 9, the author notes that almost any security regulation or standard can be met in the cloud. As none of the regulations and standard dictate where the data must specifically reside.

The book notes that for security to work in the cloud, firm's needs to apply 3 key strategies for managing security in cloud-based applications, namely centralization, standardization and automation.

In chapter 10, the book deals with creating a centralized logging strategy. Given that logging is a critical component of any cloud-based application; logging is one of the areas that many firms don't adequate address in their move to the cloud. The book provides a number of approaches to use to create an effective logging strategy.

The only issue I have with the book is that while the author is a big fan of Representational state transfer (REST), many firms have struggled to obtain the benefits he describes. RESTful is an abstraction of the architecture of the web; namely an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

I think the author places too much reliance on RESTful web services and doesn't detail the challenges in making it work properly.RESTful is not always the right choice even though it is all the rage in some cloud design circle.

While the book is part of the Wiley CIO Series, cloud architects, software and security engineers, technical managers and anyone with an interest in the cloud will find this an extremely valuable resource.

Ironically, for those that are looking for ammunition why the cloud is a terrible idea, they will find plenty of evidence for it in the book. But the reasons are predominantly that those that have failed in the cloud, didn't know why they were there in the first place, or were clueless on how to use the cloud.

For those that want to do the cloud right, the book provides a vendor neutral approach and gives the reader an extremely strong foundation on which to build their cloud architecture.

The book lists the key challenges that you will face in the migration to the cloud, and details how most of those challenges can be overcome. The author is sincere when he notes areas where the cloud won't work.

For those that want an effective roadmap to get to the cloud, and one that provides essential information on the topic, Architecting the Cloud: Design Decisions for Cloud Computing Service Models is a book that will certainly meet their needs.

Reviewed by Ben Rothke.

You can purchase Architecting the Cloud: Design Decisions for Cloud Computing Service Models (SaaS, PaaS, and IaaS) from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.

IonOtter (629215) writes Matt Haughey, founder of MetaFilter, has challenged a Cease & Desist letter from Sundance Vacations, a seller of time-shares with a reputation for aggressive sales tactics and suppression of criticism. Only this time, it seems that the plaintiff may have forged court documents ordering Mr. Haughey, Facebook, Google, Yahoo, Bing and other search engines to remove any and all mentions of the links and posts in question. Legal blog Popehat has picked this up as well, prompting Ken White to wryly note, "...Sundance Vacations is about to learn about the Streisand Effect." The story is gaining traction, and being picked up by Boing-Boing, as well as hitting the first page of search results on Google.

An anonymous reader writes The Google Quantum AI Team has announced that they're bringing in a team from the University of California at Santa Barbara to build quantum information processors within the company. "With an integrated hardware group the Quantum AI team will now be able to implement and test new designs for quantum optimization and inference processors based on recent theoretical insights as well as our learnings from the D-Wave quantum annealing architecture." Google will continue to work with D-Wave, but the UC Santa Barbara group brings its own areas of expertise with superconducting qubit arrays.

Rambo Tribble writes: In an apparent move to push those using older browsers to update, Google is reported to be serving outdated search pages to said browsers. The older pages lack features available on the newer versions, and this policy compounds with the limits announced in 2011 on Gmail support for older web clients. As a Google engineer put it, "We're continually making improvements to Search, so we can only provide limited support for some outdated browsers." The BBC offers a fairly comprehensive analysis.

An anonymous reader writes: Mozilla today officially launched Firefox 32 for Windows, Mac, Linux, and Android. Additions include a new HTTP cache for improved performance, public key pinning support, and easy language switching on Android. The Android version is trickling out slowly on Google Play. Changelogs are here: desktop and mobile.

speedplane writes: Last week, Elon Musk's SpaceX fired two challenges (PDFs) at Jeff Bezos' Blue Origin over U.S. Patent 8,678,321, entitled "Sea landing of space launch vehicles and associated systems and methods." The patent appears to cover a method of landing a rocket on a floating platform at sea. In their papers, SpaceX says that "by 2009, the earliest possibly priority date listed on the face of the patent, the basic concepts of 'rocket science' were well known and widely understood. The "rocket science" claimed in the '321 patent was, at best, 'old hat[.]'" Blue Origin has approximately three months to file a preliminary response to the challenge. You can review the litigation documents here and here. (Disclosure: I run the website hosting several of the above documents.)

An anonymous reader writes Following the blocking of Uber in Berlin, DE, the district court of Frankfurt/Main has issued a restraining order for Uber services all over Germany (German original). The district court is alleging "uncompetitive behavior" (Unlauteres Wettbewerbsverhalten) on Uber's part, and has proclaimed that not following the restraining order will result in a fine of €250.000 or imprisonment. This ruling is related to the German "Personenbeförderungsgesetz" and is outlining that no legal entity (person, enterprise) is allowed to transfer passengers without having passed the relevant tests and having the appropriate insurance coverage.

sfcrazy (1542989) writes, based on a report from Ted T'so, that Kernel developer Dmitry Monakhov was detained for 15 days for disobeying a police officer. The debacle came about when Monakhov decided to protest the recent invasion into Ukraine by Russian armed forces. Monakhov is using Twitter to keep people informed about his experience with the Russian judicial system; a human translator can probably do a better job than Google in this case.

An anonymous reader writes Linus Torvalds released Linux 3.17-rc2 today in commemoration of the 23rd anniversary of the original kernel announcement. It was on 25 August 1991 that he announced his new OS project to the Minix users list.

rtoz writes Google has just announced a new processor for Project Ara. The mobile Rockchip SoC will function as an applications processor, without requiring a bridge chip. A prototype of the phone with the Rockchip CPU, will be available early next year. Via Google+ post, Project Ara team Head Paul Eremenko says "We view this Rockchip processor as a trailblazer for our vision of a modular architecture where the processor is a node on a network with a single, universal interface -- free from also serving as the network hub for all of the mobile device's peripherals." (Project Ara is Google's effort to create an extensible, modular cellphone; last month we mentioned a custom version of Linux being developed for the project, too.)

benrothke writes When I got a copy of Social Engineering in IT Security Tools, Tactics, and Techniques by Sharon Conheady, my first thought was that it likely could not have much that Christopher Hadnagy didn't already detail in the definitive text on the topic: Social Engineering: The Art of Human Hacking. Obviously Hadnagy thought differently, as he wrote the forward to the book; which he found to be a valuable resource. While there is overlap between the two books; Hadnagy's book takes a somewhat more aggressive tool-based approach, while Conheady take a somewhat more passive, purely social approach to the topic. There are many more software tools in Hadnagy; while Conheady doesn't reference software tools until nearly half-way through the book. This book provides an extensive introduction to the topic and details how social engineering has evolved through the centuries. Conheady writes how the overall tactics and goals have stayed the same; while the tools and techniques have been modified to suit the times. Keep reading for the rest of Ben's review. Social Engineering in IT Security Tools, Tactics, and Techniques author Sharon Conheady pages 272 publisher McGraw-Hill Osborne Media rating 8/10 reviewer Ben Rothke ISBN 978-0071818469 summary Great resource on which to build a social engineering testing program Coming in at about 250 pages, the book finds a good balance between high-level details and actionable tactical things to execute on. Without getting bogged down in filler. Since the social engineering tools and techniques only get better, the advantage Conheady's book has it that it details a lot that has changed in the 4 years since Hadnagy's book came out.

In chapter 1, she writes about mumble attacks, which are telephone-based social engineering attacks that are targeted at call center agents. The social engineer will pose as a speech-impaired customer or as a person calling on behalf of the speech-impaired customer. The goal of this method is to make the victims; in this case call center agents feel awkward or embarrassed and release the desired information. Given the pressure in which most call center agents are under; this is a simple yet highly effective attack.

Like Hadnagy, this also has a detailed social engineering test methodology. Conheady details a methodology with 5 stages: planning and target identification, research and reconnaissance, scenario creation, attack execution and exit, and reporting. She notes that one does not have to be a slave to the methodology, and it can be modified depending on the project.

Social engineering can often operate on the limit of what is legal and ethical. The author goes to great lengths to write what the ethical and legal obligations are for the tester.

The book is filled with lots of practical advice as Conheady is seasoned and experienced in the topic. From advice to dealing with bathrooms as a holding location, gaining laptop connectivity and more; she writes of the many small details that can make the difference between a successful social engineering test and a failed one.

The book also details many areas where the job of the social engineer is made easy based on poor security practices at the location. Chapter 7 details how many locations have access codes on doors often don't do much to keep social engineers out. Many doors have 4-character codes, and she writes that she has seen keypads where the combination numbers have been so worn down that you can spot them straightaway.

As noted earlier, the book focuses more on the human techniques of social engineering than on software tools. She does not ignore that tools and in chapter 9 provides a list of some of the more popular tools to use, including Maltego, Cree.py and others. She also has lists of other tools to use such as recording devices, bugging devices, phone tools and more.

With all those, she still notes that the cell phone is the single most useful item you can bring with you on a social engineering test. She writes that some of the many uses a cell phone has is to discourage challengers, fake a call to look busy, use the camera and more.

While most of the book is about how to execute a social engineering test, chapter 10 details how you can defend against social engineering. She notes that it is notoriously difficult to defend against social engineering because it targets the weakest link in the security chain: the end-user. She astutely notes that a firm can't simply roll out a patch and immunize its staff against the latest social engineering attack. Even though there are vendors who make it seem like you can. The chapter also lists a number of indicators that a firm may be experiencing a social engineering attack.

Hadnagy's book is still the gold-standard on the topic. But Social Engineering in IT Security Tools, Tactics, and Techniques certainly will give it a run for the money.

Hadnagy's approach to social engineering is quite broad and aggressive. Conheady takes more of a kinder, gentler approach to the topic. For those that are looking for an effective guide on which to build their social engineering testing program on, this certainly provides all of the core areas and nearly everything they need to know about the fundamentals of the topic.

Reviewed by Ben Rothke.

Last week you had a chance to ask Bjarne Stroustrup about programming and C++. Below you'll find his answers to those questions. If you didn't get a chance to ask him a question, or want to clarify something he said, don't forget he's doing a live Google + Q & A today at 12:30pm Eastern. Cutting features and old syntax?
by Katatsumuri

Sometimes well-established languages keep adding new features and syntactic constructs until most developers are not even aware of all the possibilities and use maybe 20% in their usual daily work. The old features and syntax are kept around for compatibility and to keep the old guard content, even if cutting them would lead to faster compilation, more elegant language and less confusion.

This may be part of the reason for the constant introduction of new trendy languages with radically simplified syntax and libraries... Which then follow the same pattern. Few languages are introducing new paradigms, many are trying to be a "better" C++, Java, LISP, JavaScript or Perl.

Do you think this cycle is inevitable, or could it be a good idea to sometimes clean up the syntax and the obscure features in new specification versions, to keep the established languages more competitive?

Bjarne: Languages grow. The alternative is stagnation because there is nothing the maintainer of a large code base hates more than working code breaking – even if that code is full of avoidable errors. We dream of cleaning up the mess, but somehow there is never the month or couple of years needed. I dream of “cleaning up the mess” as much as the next guy, and I know the mess better than most. It is hard to evolve a language compatibly, but IMO it is harder still to make a major – worthwhile – breaking change. Stagnation is not something I can accept – we can and must do better (even if that takes compromises).

You probably didn’t mean that, but “syntax” isn’t the most important aspect of software development. People will suffer atrocious syntax to get valuable functionality (C++ template meta-programming is an example). Also, developers and maintainers of production code eventually tire of cute (often very terse) syntax. “Syntax” is the user-interface for programmers, rather than the system itself. What we hope for is a minimal and logical interface to a useful semantics.

For any reasonable definition of “paradigm” (a words I use only very rarely), there are very few new paradigms coming along, so people have to be happy with incremental changes. Slow steady progress can – over time – add up to major improvements. However, few people take the longer (decades) view.



On the evolution of C++
by stox

How do you feel about the evolution of C++ since it was first implemented with Cfront? What began as a pretty straightforward language has been expanded to significant complexity. Has this evolution been positive, or has it been an attempt to make the language apply to too many possible applications?

Bjarne: C++14 is a far better tool for software development than “C with Classes” was, far more powerful in the key areas that “C with Classes” was invented to deal with. It is more expressive, better checked, generates faster code, and is applicable in areas that “C with Classes” could not touch. The cost has been complexity. My aim has been constant: a direct mapping to hardware plus zero-overhead abstraction. C++ is not the best language for everyone and everything, but then I never promised that it would be. However, C++ is an excellent tool for attacking a vast variety of system design and implementation problems.

I hope that the tide has turned so that C++ is becoming more “novice friendly.” C++11 and C++14 are steps on that route: auto, range-for, lambdas, uniform initialization, concepts, etc., all makes it easier to express simple things simply (without loss of performance). For example, a friend sent me this C++99 code (simplified, of course, but from a large code base):

// old code:

std::vector::const_iterator cit = MemVec.cbegin();
for ( ; cit != v.end(); ++cit) {
if (LookForPatterm(*cit))
return true ;
}
return false;

He deemed this to be somewhat messy and in need of improvement. For starters, we can eliminate the long type name by letting auto deduce it:

// first step:

for (auto cit = MemVec.cbegin(); cit != v.end(); ++cit) {
if (LookForPatterm(*cit))
return true ;
}
return false ;

auto is the oldest C++11 feature. I implemented in in 1983/84, but was forced to remove it for C compatibility reasons. It provides the ability to deduce a type from and initializer; after all, the compiler knows the type of MemVec.cbegin() so why should I need to repeat it? Note how the scope of cit is now limited to its area of use.

We can simplify regular loops using a range-for, so we get:

// second simplification:

for (const auto& x : v)
{
if (LookForPatterm(x))
return true ;
}
return false ;

There is now no iterator, so it cannot be accidentally or deliberately modified in the loop. Now it is obvious that we should have used a standard-library algorithm:

// good:

return find_if(cbegin(v), cend(v), LookForPattern) != v.cend() ;

That’s where my friend stopped, observing that it was now also obvious how to use a lambda as the operation in other places. Being a fan of range/container algorithms, I would have said:

// my variant:

return find_if(v,LookForPattern)!=v.cend();

This involves having a range version of find_if lying around somewhere. For example:

// range version of std::find_if:

template
Iterator find_if(Cont& c, Pred p)
{
return std::find_if(begin(c),end(c),p);
}

Next time such an improvement is needed, I think my friend and his colleagues will jump directly to one of the later variants. With a bit of luck, they will even have tool to help them find candidates for simplification.



Regrets
by Anonymous Coward

What do you regret most in C++ and how would you like to change it?

Bjarne: No regrets! Seriously, a language grows up at a specific time and in a specific environment. To survive that language has to be viable at every stage of its evolution. I’d hate to second guess 1980s vintage Bjarne. He was at least as smart as I am and had a far better grasp of the world at the time. Simply saying, “if I had had a few million dollars for buying market share with ‘free’ libraries or for developing a better definition of templates C++ would have been better” just isn’t intellectually honest.

If I had a time machine, I just might jump back to 1987 and drop a sketch of a design of templates with concepts on Bjarne’s desk. He was working on the template design at the time and knew the problems with template parameter requirements well. Unfortunately, neither he nor anyone else at the time knew how to simultaneously get generality, performance, and well-specified interfaces. Given a bit of help from the time traveler, he might very well have gotten the point. Then, in 1990, we would have been able to write:

void sort(Sortable& c); // sort random-access sequences of elements with
void user(vector& vs, vector>& vc)

{
sort(vs); // OK
sort(vc); // error: vs not Sortable; complex does not have }

However, I don’t have a time machine, so we had to wait until next year (or now if you use the concepts branch of GCC).



Future of C++ Standard Library
by DaphneDiane

One of the recent concerns raised with C++ compared to other popular languages is the breadth of the standard library. I know that the C++ standard committee was looking at adding a C++ transformed version of Cairo to the standard. And of course there is boost. What else do you see coming to address the perceived API shortcomings?

Bjarne: C++ is a formally standardized language. It is defined by the ISO. Compared to other such languages, C++ has a huge and growing standard library. However, compared by commercially owned languages, such as Java and C#, the ISO C++ standard library is tiny. We – the C++ standards committee – do not have the resources to buy market share. The committee is trying to add useful libraries as fast as it can safely do so. The standard library is most important because it creates a common foundation, but it can never be sufficient for the needs of the huge community.

We somehow have to create a better “exchange” for open-source and other libraries. We will also have to work harder on library interoperability. There are a huge number of C++ libraries “out there,” but they tend not to be designed for interoperability and many producers of libraries have their very own programming styles and specialized assumptions.

To speed up standardization – especially the standardization of libraries – the ISO C++ standards committee has started “study groups” producing “technical specifications.” A technical specification is not a full-blown international standard, but it is a document produced by the order of 20 people and approved by the full committee. Current library TSs in progress are:

File system
Library foundation (e.g., optional and string_view)
Ranges (for people tired of saying v.begin(),v.end() and much, much more)
Concurrency (threads, etc.)
Parallelism (parallel algorithms, networking, and more)
Numerics (incl. SIMD)
Transactional Memory (has core language parts)
I/O (incl. 2D graphics)
See here for details.



ABI
by gbjbaanb

Do you think that one thing holding C++ back is the lack of a standardized binary interface?

Currently if I want to make a module that can be consumed by others (whether than is others using a different language, or a different C++ compiler, or even just to use a pre-built module without sources) I have to export everything as C and use its (de-facto if nothing else) binary standard.

I think an ABI for C++ would increase its "real world" attractiveness considerably with little, if any, overhead. Do you agree, or are there issues around this that make it a significant challenge (apart from vendor adoption of course).

Bjarne: A C++ ABI would be a huge boon to the C++ community, however, it is not an easy problem to solve technically and most C++ implementation providers have a huge user bases that would howl in outrage if binary compatibility with their previous version was broken.

To solve the technical problem, we would need the ABI to cover basic object layout (easy), class hierarchies (not hard), and abstractions using templates (hard). An ABI that could not handle std::vector, std::map, and similar user-supplied abstractions would be a failure. I do not (in any detail) know how to do that.

To solve the political problem, we would need all vendors on a platform to adopt that ABI (probably impossible except in the longer term) or provide it as an “exchange format” in addition to their traditional ABI.



Which feature would you add to C++?
by jonwil

If you could add one feature to C++ (either the language or the standard library) and have it adopted in the C++ standard and supported by all the compilers etc., what would it be and why?

Bjarne: Ah! Just one feature? You must be kidding, but I’ll say “concepts.” They will change the way people think of generic programming and of programming in general, and we’ll have them next year. They are already shipping in a branch of GCC and will be an ISO C++ TS (Technical Specification) in 2015 (I hope and expect).

People have mentioned more standard libraries and a standard ABI. I’d like to see higher-level concurrency models –the type-safe C++11 threads and locks are still too low level. I’d like to eliminate the need for the visitor pattern workaround; for example, see:

Y. Solodkyy, G. Dos Reis and B. Stroustrup: Open Pattern Matching for C++. ACM GPCE'13.
Y. Solodkyy, G. Dos Reis, and B. Stroustrup: Open and Efficient Type Switch for C++. Proc. OOPSLA'12.
P. Pirkelbauer, Y. Solodkyy, and B. Stroustrup: Open Multi-Methods for C++. ACM GPCE’07.

Remember that an academic paper plus an implementation does not add up to a complete standards proposal, but wouldn’t you like to be able to write:

bool intersect(virtual Shape&, virtual Shape&); // non-member virtual function

void user(Shape& s1, Shape& s2)
{
if (intersect(s1,s2)) //
//
}

Assuming suitable overloads of intersect() to handle Shapes that are Circles, Triangles, etc. The alternative today is a mess of if-statements, some clever special-purpose workaround, or an elaborate visitor setup.



C++ without the C
by kthreadd

Apple recently introduced a language they call Swift or Objective-C without the C. It is technically a completely different language from Objective-C though. When C++ started out it had the major benefit that it was (mostly) compatible with C which at the time was immensely popular, making it trivial to mix new C++ code with existing C code. Today C is still a popular language but not as widely used as it once was. Assuming that C++ could drop C compatibility, how would you take that opportunity to improve C++?

Bjarne: People tend to underestimate C. Today, we probably don’t need C compatibility (except to keep billions of lines of critical code running), but we do need a direct map to hardware. If we didn’t have C or the C-level subset of C++, we would have to find a different way to do that map. Languages without C’s problems typically rely on C or C++ to do their dirty work for them.

I think we should think more about isolating unsafe code in a program than to eliminate it. Putting the necessary unsafe code into a different language limits our control of it, limits what can be communicated to it, and typically imposes overheads.

That said, when people rail against C, and by implication C++, they usually (and correctly in case of C and C-style C++) point to two problems: lack of type safety and the lack of abstraction mechanisms. Together, those two problems leave people with lots and lots of low-level code in which bugs can hide (e.g., buffer overflows, invalid pointers, and resource leaks).

C++ attacks these problems by providing alternatives. You can write type-safe code in C++; you can write simple code that doesn’t leak or leave invalid pointers behind; you can do so with zero overhead compared to lower-level alternatives. Consider:

vector collect(const string& terminator)
{
vector res;
for (string s; cin>>s && s!=terminator; )
res.push_back(s);
return res;
}

void user() { auto ss = collect("end"); // ss is a vector
// }

I used C++11’s move semantics and auto to simplify that code. Note the absence of memory management code and the absence of leaks. Returning containers by value is simple and efficient in C++11 because the standard library provide move constructors for all containers, such as vector.

The problem is that many people don’t write such simple code and are stuck with the old problems hidden in lots of far more complicated code.

I don’t actually think that there is less C and C++ programming these days. I think that in absolute terms there is more than ever, and not just people working on “legacy code.” People are confused by unscientific estimates of usage and especially by the fact that there is much more software development these days, so that the amount of C and C++ is declining relative to the total. In particular, I think I see significant growth of C++ in its core domains. The number of C++ programmers today is more likely to be 4 or 5 million than the 3 million I estimated ten years ago. But it is hard to count programmers.



Hour of Code
by Orestesx

What is your opinion of the "Hour of Code" as promoted by CSEdWeek? Does it trivialize computer science education?

Bjarne: I guess that anything that popularizes hands-on software development experience is good. On that count, I’m in favor of Lego, programming contests, Raspberry Pie, etc. Too many people think science and (especially) engineering boring.

Do color change and explosive chemistry experiments trivialize chemistry? Do demonstrations of Newton’s cradle and prisms trivialize physics? No! You need to inspire and motivate students in preparation for the necessary hard work. I think Computer Science should be taught as a serious academic discipline – like Physics and Biology – for which years of work is needed for mastery, rather than as a basic skill that must be quickly mastered by all. I think the serious work should start in high school, like it is (or IMO should be) for mathematics, physics, and biology. It is not just child’s play. It could start in university if it wasn’t that students tend not to choose fields of study in university that they have not encountered in high school.

Not everybody can become a good programmer. The world needs a lot of programmers, maybe 20 million, but we don’t need a billion. We need to distinguish between the education of professionals and giving people a bit of computer literacy. People seem confused about this or unwilling to accept that serious preparation is needed for people who build serious software. Our lives and livelihood depends on software. Just think of the amount of computing that goes into delivering your food to your table: agriculture, transport, telecommunications, embedded systems, planning, scheduling, etc. You cannot milk a herd of cows without the help of computers these days! Or at least you cannot if you have to keep records of the cows’ health and production for the obligatory quality control. I would strongly prefer for critical software to be developed and maintained by professionals. I’m less concerned about the quality of your favorite videogame or the advertisements that pop up to annoy me when I try to read the news.

I’m more interested in the engineering part of computer science than the pure science part. Computer science is among other things a set of science-based practical skills, an engineering discipline.



Personal programming projects
by kthreadd

Apart from work, do you have any personal programming projects going on? Which type of programming do you like most and is there a particular project that you would like to implement?

Bjarne: I tend to look at three kinds of code: code that creates trouble in the context of the C++ standard (subtle cases and proposals), small experiments with programming techniques, and production code. This implies looking on a lot of libraries and writing lots of small examples. Unfortunately, my “day job” plus my standards work do not leave time for significant personal projects.



Code rejuvenation
by SansEverything

You speak a lot about code rejuvenation and bringing old code to new standards. As you are working on C++14, many compilers do not fully support C++11 yet. In the past, it was even worse. Don't you think that this lack of feature support from compilers is a major problem and the biggest obstacle to code rejuvenation?

Bjarne: No. C++11 and/or C++14 implementation availability is not a major problem. Both are getting remedied fast, faster than I would have believed a couple of years ago. The adoption of C++11 is far faster than the C++98 adoption was. Waiting a year or two is not a significant problem in this context. There is plenty of work that can be done today.

When I talk about “rejuvenation” (some people call it “modernization” or “upgrading”), I mean rewriting large amounts of code written in styles known to complicate comprehension, hide bugs, and hinder optimization. I’m thinking of C-style code, code overusing class hierarchies, and some examples of complex template metaprogramming. Such code also tend to prevent newer, better, and simpler techniques to be used in newer code. The reason is partly that the need interoperate with such code messes up new code, partly that programmers steeped in the old style are reluctant to believe that the newer techniques work.

For example, I’d like to replace uses of arrays and pointers with std::arrays and vectors. I’d like to eliminate macros. I’d like to replace old-style for loops with range-for loops. I’d like to eliminate overuse of free store (heap). I’d like to break up large functions into smaller and more precisely defined ones. I’d like to replace ad hoc code with algorithms. I’d like to replace hand-crafted containers with standard-library ones. If I can, I’d like to eliminate race conditions and increase the amount of concurrency. I want to do all that without adding run-time overheads.

Typically, we cannot afford to rewrite the old code by hand. So when I talk about rejuvenation, I focus on (static) code analysis and code transformation: we must automate the rejuvenation process as far as possible. The reason I don’t refer to this as “refactoring” is that I’m typically not interested in a process that produces 100% compatible code. Some of the transformations I want require human attention. I want major improvement, not bug compatibility. People are working to produce such tools.

alphadogg (971356) writes with news that the transition from Windows to GNU/Linux in Munich may be in danger The German city of Munich, long one of the open-source community's poster children for the institutional adoption of Linux, is close to performing a major about-face and returning to Microsoft products. Munich's deputy mayor, Josef Schmid, told the Süddeutsche Zeitung that user complaints had prompted a reconsideration (Google translation to English) of the city's end-user software, which has been progressively converted from Microsoft to a custom Linux distribution — "LiMux" — in a process that dates back to 2003.

theodp writes As teachers excitedly tweet about completing their summer CS Professional Development at Google and Microsoft, and kids get ready to go back to school, Code.org is inviting educators to check out their K-5 Computer Science Curriculum (beta), which is slated to launch in September (more course details). The content, Code.org notes, is a blend of online activities ("engineers from Google, Microsoft, Facebook, and Twitter helped create this tutorial," footnotes explain) and 'unplugged' activities, lessons in which students can learn computing concepts with or without a computer. It's unclear if he's reviewed the material himself, but Chicago Mayor Rahm Emanuel is grateful for the CS effort ("Thank you for teaching our students these critical skills").

In addition to being the creator of C++, Bjarne Stroustrup is a Managing Director in the technology division of Morgan Stanley, a Visiting Professor in Computer Science at Columbia University, and a Distinguished Research Professor in Computer Science at Texas A&M University. Bjarne has written a number of books and was elected a member of the National Academy of Engineering. He will be doing a live Google + Q & A within the C++ community on August 20th, 2014 at 12:30pm EST, but has agreed to answer your questions first. As usual, ask as many as you'd like, but please, one per post.

An anonymous reader writes Have you heard of personalized postage stamps? You pay the value of the stamps plus a fee and the post office prints official stamps usable for postage which show (almost) anything you can put into a jpeg file. An Austrian Tibet supporter found out what 'almost' means. He submitted a picture of the Dalai Lama with the text 'His Holiness the Dalai Lama,' but the Austrian post office refused to produce these stamps. Stampnews and the Neue Zuercher Zeitung (autotranslation) reported that this had been due to pressure from the Chinese embassy in Vienna. Now there is a video showing how visual cryptography has been used to get around this attempt at censorship [caution: organ music] .

An anonymous reader writes "Beginning with the Chrome 38 Beta it's now possible to watch Netflix without any Wine/Silverlight plug-ins but will work natively using Chrome's DRM-HTML5 video capabilities with Netflix. The steps just involve using the latest beta of Chrome and an HTTP user-agent switcher to tell Netflix you're a Windows Chrome user, due to Netflix arbitrarily blocking the Linux build."

An anonymous reader writes "Google today released a preview SDK of Google Fit available to developers. The tool provides APIs for apps and device manufacturers to store and access activity data from fitness apps and sensors on Android and other devices (like wearables, heart rate monitors or connected scales). Google warns that the preview release contains the Google Fit APIs for Android, but does not contain the REST API or the Android Wear APIs, which will be included in the official release. Furthermore, while it will let you develop and test fitness apps, they cannot be published to Google Play until official release."

benrothke writes Cyberwarfare is a controversial topic. At the 2014 Infosec World Conference, Marcus Ranum gave a talk on Cyberwar: Putting Civilian Infrastructure on the Front Lines, Again. Whether it was the topic or just Marcus being Marcus, about a third of the participants left within the first 15 minutes. They should have stayed, as Ranum, agree with him or not, provided some riveting insights on the topic. In Introduction to Cyber-Warfare: A Multidisciplinary Approach, authors Paulo Shakarian, Jana Shakarian and Andrew Ruef provide an excellent overview of the topic. The book takes a holistic, or as they call it multidisciplinary, approach. It looks at the information security aspect of cyberwarfare, as well the military, sociological and other aspects. Keep reading for the rest of Ben's review. Introduction to Cyber-Warfare: A Multidisciplinary Approach author Paulo Shakarian, Jana Shakarian and Andrew Ruef pages 336 publisher Syngress rating 9/10 reviewer Ben Rothke ISBN 978-0124078147 summary Outstanding overview and guide to cyberwarfare The book is divided into 3 parts and 13 densely packed and extremely well-researched and footnoted chapters. The book provides numerous case studies of the largest cyberwarfare events to date. Issues around China and their use of cyberwarfare constitute a part of the book. Chapter 7 details the Chinese cyber strategy and shows how the Chinese cyber doctrine and mindset is radically different from that of those in the west.

The book compares the board games of chess (a Western game) and Go (a Chinese game) and how the outcomes and strategies of the games are manifest in each doctrine.

The chapter also shows how the Chinese government outlawed hacking, while at the same time the military identified the best and most talented hackers in China, and integrated them into Chinese security firms, consulting organizations, academia and the military.

One of the more fascinating case studies details the cyber war against the corporate world from China. The book provides a number of examples and details the methodologies they used, in addition to providing evidence of how the Chinese were involved.

For an adversary, one of the means of getting information is via social networks. This is often used in parallel by those launching some sort of cyberwarfare attack. LinkedIn is one of the favorite tools for such an effort. The authors write of the dangers of transitive trust; where user A trusts user B, and user B trusts user C. Via a transitive trust, user A will then trust user C based simply on the fact that user B does. This was most manifest in the Robin Sage exercise. This was where Thomas Ryan created a fictitious information security professional names Robin Sage. He used her fake identity and profile to make friends with others in the information security world, both commercial, federal and military and he was able to fool even seasoned security professionals. Joan Goodchild wrote a good overview of the experiment here.

In chapter 10, the book details how Iraqi insurgents viewed Predator drones video feeds. Woody Allen said that eighty percent of success is just showing up. In this case, all the insurgents had to do was download the feed, as it was being transmitted unencrypted. Very little cyberwarfare required.

When the drone was being designed, the designers used security by obscurity in their decision not to encrypt the video feed. They felt that since the Predator video feeds were being transmitted on frequencies that were not publicly known, no access control, encryption or other security mechanisms would be needed.

The downside is that once the precise frequency was determined by the insurgency, in the case of the Predator drone, the Ku-band, the use of the SkyGrabber satellite internet downloader made it possible for them to effortless view the video feeds.

The only negative about the book is a minor one. It has over 100 pictures and illustrations. Each one states: for the color version of this figure, the reader is referred to the online version of the book. Having that after every picture is a bit annoying. Also, the book never says where you can find the online version.

How good is this book? The reality is that this book should indeed be read by everyone in Washington, as they are making decisions on the topic, without truly understanding it.

For most readers, this will be the book that tells them everyone they need to know that their congressman should know. Most people will never be involved with any sort of warfare, and most corporate information security professional will not get involved with cyberwarfare. Nonetheless, Introduction to Cyber-Warfare: A Multidisciplinary Approach is a fascinating read about a most important subject.

Reviewed by Ben Rothke

You can purchase Introduction to Cyber-Warfare: A Multidisciplinary Approach from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available for review from our library please let us know.

benrothke writes Cyberwarfare is a controversial topic. At the 2014 Infosec World Conference, Marcus Ranum gave a talk on Cyberwar: Putting Civilian Infrastructure on the Front Lines, Again. Whether it was the topic or just Marcus being Marcus, about a third of the participants left within the first 15 minutes. They should have stayed, as Ranum, agree with him or not, provided some riveting insights on the topic. In Introduction to Cyber-Warfare: A Multidisciplinary Approach, authors Paulo Shakarian, Jana Shakarian and Andrew Ruef provide an excellent overview of the topic. The book takes a holistic, or as they call it multidisciplinary, approach. It looks at the information security aspect of cyberwarfare, as well the military, sociological and other aspects. Keep reading for the rest of Ben's review. Introduction to Cyber-Warfare: A Multidisciplinary Approach author Paulo Shakarian, Jana Shakarian and Andrew Ruef pages 336 publisher Syngress rating 9/10 reviewer Ben Rothke ISBN 978-0124078147 summary Outstanding overview and guide to cyberwarfare The book is divided into 3 parts and 13 densely packed and extremely well-researched and footnoted chapters. The book provides numerous case studies of the largest cyberwarfare events to date. Issues around China and their use of cyberwarfare constitute a part of the book. Chapter 7 details the Chinese cyber strategy and shows how the Chinese cyber doctrine and mindset is radically different from that of those in the west.

The book compares the board games of chess (a Western game) and Go (a Chinese game) and how the outcomes and strategies of the games are manifest in each doctrine.

The chapter also shows how the Chinese government outlawed hacking, while at the same time the military identified the best and most talented hackers in China, and integrated them into Chinese security firms, consulting organizations, academia and the military.

One of the more fascinating case studies details the cyber war against the corporate world from China. The book provides a number of examples and details the methodologies they used, in addition to providing evidence of how the Chinese were involved.

For an adversary, one of the means of getting information is via social networks. This is often used in parallel by those launching some sort of cyberwarfare attack. LinkedIn is one of the favorite tools for such an effort. The authors write of the dangers of transitive trust; where user A trusts user B, and user B trusts user C. Via a transitive trust, user A will then trust user C based simply on the fact that user B does. This was most manifest in the Robin Sage exercise. This was where Thomas Ryan created a fictitious information security professional names Robin Sage. He used her fake identity and profile to make friends with others in the information security world, both commercial, federal and military and he was able to fool even seasoned security professionals. Joan Goodchild wrote a good overview of the experiment here.

In chapter 10, the book details how Iraqi insurgents viewed Predator drones video feeds. Woody Allen said that eighty percent of success is just showing up. In this case, all the insurgents had to do was download the feed, as it was being transmitted unencrypted. Very little cyberwarfare required.

When the drone was being designed, the designers used security by obscurity in their decision not to encrypt the video feed. They felt that since the Predator video feeds were being transmitted on frequencies that were not publicly known, no access control, encryption or other security mechanisms would be needed.

The downside is that once the precise frequency was determined by the insurgency, in the case of the Predator drone, the Ku-band, the use of the SkyGrabber satellite internet downloader made it possible for them to effortless view the video feeds.

The only negative about the book is a minor one. It has over 100 pictures and illustrations. Each one states: for the color version of this figure, the reader is referred to the online version of the book. Having that after every picture is a bit annoying. Also, the book never says where you can find the online version.

How good is this book? The reality is that this book should indeed be read by everyone in Washington, as they are making decisions on the topic, without truly understanding it.

For most readers, this will be the book that tells them everyone they need to know that their congressman should know. Most people will never be involved with any sort of warfare, and most corporate information security professional will not get involved with cyberwarfare. Nonetheless, Introduction to Cyber-Warfare: A Multidisciplinary Approach is a fascinating read about a most important subject.

Reviewed by Ben Rothke

You can purchase Introduction to Cyber-Warfare: A Multidisciplinary Approach from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available for review from our library please let us know.

An anonymous reader writes: In response to an inquiry from European data protection regulators, Google has detailed how they evaluate and act on requests to de-index search results. Google's procedures for responding to "right-to-be-forgotten" requests are explained in a lengthy document that was made publicly available. "Google of course claims its own economic interest does not come into play when making these rtbf judgements — beyond an 'abstract consideration' of a search engine needing to help people find the most relevant information for their query. ... Google also goes into lengthy detail to justify its decision to inform publishers when it has removed links to content on their sites — a decision which has resulted in media outlets writing new articles about delisted content, thereby resulting in the rtbf ruling causing the opposite effect to that intended (i.e. fresh publicity, not fair obscurity)."

coop0030 (263345) writes Adafruit held a 2014 Raspberry Pi Photography contest that has completed with the winners selected. You can see the winning photographs as well as all of the entries. Andrew Mulholland, using a Raspberry Pi powered LEGO panobot, is the winning photographer. He's also provided a video of how his winning photographs were put together.

necro81 (917438) writes "Gaza's only power plant (see this profile at IEEE Spectrum — duct tape and bailing wire not included) has been knocked offline following an Israeli strike. Reports vary, but it appears that Israeli tank shells caused a fuel bunker at the plant to explode. Gaza, already short on electricity despite imports from Israel and Egpyt, now faces widening blackouts."

stephendavion (2872091) writes "Chinese aircraft manufacturer China Aviation Industry General Aircraft (CAIGA) has started trial production of its TA600 amphibious aircraft, claimed to be the world's largest of its kind. With an expected maiden flight late next year, the Chinese plane would replace Japan's ShinMaywa US-2 short takeoff and landing (STOL) aircraft as the largest of its kind globally." Take a look at a side profile illustration of the CA-600, on this Korean language page. The TA600 has a huge maximum takeoff weight of 53.5 tons, but looks a bit puny compared to Howard Hughes' H-4 Hercules.

New submitter Tim the Gecko (745081) writes Comcast has announced 1Tb/s of Internet facing, native IPv6 traffic, with more than 30% deployment to customers. With Facebook, Google/YouTube, and Wikipedia up to speed, it looks we are past the "chicken and egg" stage. IPv6 adoption by other carriers is looking better too with AT&T at 20% of their network IPv6 enabled, Time Warner at 10%, and Verizon Wireless at 50%. The World IPv6 Launch site has measurements of global IPv6 adoption.

NotInHere (3654617) writes As promised, version 33 of the Firefox browser will fetch the OpenH264 module from Cisco, which enables Firefox to decode and encode H.264 video, for both the <video> tag and WebRTC, which has a codec war on this matter. The module won't be a traditional NPAPI plugin, but a so-called Gecko Media Plugin (GMP), Mozilla's answer to the disliked Pepper API. Firefox had no cross-platform support for H.264 before. Note that only the particular copy of the implementation built and blessed by Cisco is licensed to use the h.264 patents.

NotInHere (3654617) writes As promised, version 33 of the Firefox browser will fetch the OpenH264 module from Cisco, which enables Firefox to decode and encode H.264 video, for both the <video> tag and WebRTC, which has a codec war on this matter. The module won't be a traditional NPAPI plugin, but a so-called Gecko Media Plugin (GMP), Mozilla's answer to the disliked Pepper API. Firefox had no cross-platform support for H.264 before. Note that only the particular copy of the implementation built and blessed by Cisco is licensed to use the h.264 patents.