Slashdot Mirror

Michael J. Ross writes "With the proliferation of handheld devices that allow access to the Web, more business owners and other technology decision-makers are demanding that their organizations' websites be fully accessible on those devices, and even be repackaged as new web-based applications. But designers and developers who may be quite proficient in making non-mobile websites and web apps, can feel uncertain as to how to craft those products, or even where to start the process of learning how to do so. Recently, several books have been published to address this need, including Build Mobile Websites and Apps for Smart Devices, authored by Earle Castledine, Myles Eftos, and Max Wheeler." Read on for the rest of Michael's review Build Mobile Websites and Apps for Smart Devices author Earle Castledine, Myles Eftos, Max Wheeler pages 300 pages publisher SitePoint rating 8/10 reviewer Michael J. Ross ISBN 978-0987090843 summary An approachable guide to getting started building mobile web apps. This title was published by SitePoint on 29 June 2011, under the ISBN 978-0987090843. The book's contents span 300 pages, and are organized into a preface, eight chapters, an appendix, and an index. The preface contains the usual meta information about a technical book; but what really shines is its intro section, which enthusiastically entices the reader to jump into the burgeoning field of mobile web development. The appendix, comprising little more than two pages, presents only the most basic information on how to utilize whatever native web server might be running on the reader's Linux, OS X, or Windows Vista/7 machine. The more than 49 percent of computer owners still using Windows XP (as of this writing), will need to look elsewhere for information on installing and configuring Apache, IIS, or some other web server, should they want to test their apps locally. In terms of prerequisites for this book, readers are expected to be proficient in HTML, CSS, and JavaScript, but not necessarily HTML5 and CSS3, whose concepts are explained as needed throughout the text.

The publisher maintains a web page for the book, where visitors can find the table of contents, errata (none as of this writing), the book's index, and three free sample chapters (Chapters 1, 2, and 4) in PDF format. Visitors can order the print version of the book, the electronic version (in three different formats: PDF, EPUB, and MOBI), and an online course hosted by Learnable (comprising lessons, video tutorials, Q&A sessions, and the example code).

The first chapter introduces the basic concepts and rationale of mobile apps, as well as some of the key decisions one will face in creating them, such as whether to make a web app versus a native app, and the options for providing a mobile experience. The authors briefly describe the example app — a tool for recording and sharing celebrity sightings — which is designed and created sequentially in the material that follows. But the chapter does not fulfill the promise made for it in the preface, where the reader is told he will "be guided through the process of designing and building a mobile web application"; on the contrary, the chapter does not explain how to design and build one.

That effort begins in the second chapter, where the authors discuss some high-level considerations for designing the user interfaces of mobile devices, as well as the benefits and drawbacks of various navigation and content structuring options. The bulk of the narrative involves wireframing the design for the example app, selecting colors and fonts, and crafting an appropriate icon for it. Readers learn of the advantages of using relative units in their CSS, but not how to get all the elements positioned properly regardless of the target device's resolution, when mixing relative units for text and pixel units for images. The section "Scalable Images," later in the subsequent chapter, is a start, but is not sufficient for non-SVG images.

Chapter 3, "Markup for Mobile," is the longest of them all, primarily because it presents much if not all of the source code written by the authors for the initial version of their example app. The majority of the code is in HTML and CSS, with a focus upon the effects made possible using HTML5 and CSS3. Also discussed are the resource limitations of typical mobile devices, content and menu display options, image techniques and scalability, viewport meta element settings, icons, multimedia, and more. Oddly, on pages 71-72, the resource limitations of iOS are repeated, with only slightly different wording. How could the proofreaders have missed this glaring redundancy?

The fourth chapter, "Mobile Web Apps," addresses the logical next step: enhancing a mobile website so it can function as a web app — for which JavaScript is used extensively. After briefly mentioning a couple of the better-known mobile development frameworks, the authors select jQuery as a library for working with the DOM, to speed development and make the example code more platform neutral. There follows an interesting discussion of touch events on mobile devices, how they compare to mouse events, and techniques for best handling them. But the main goal is to show how to load, swap, and go back to pages so as to most closely simulate the snappy behavior of native apps. The extensive code and narrative in this chapter are the most complex of any in the book, and thus will likely be the most challenging for any reader who is not adept with JavaScript and/or jQuery, or who does not have the patience to work through the example code.

At first glance, it would appear that native apps have a huge advantage over web apps, in that they can access information from their mobile devices' capabilities — such as accelerometers and cameras — historically unavailable to mobile web browsers. Fortunately, an increasing number of standard interfaces are allowing web apps to access that data — and this is the topic of the fifth chapter. The reader is shown how to capture and utilize geolocation data, device rotation and acceleration, as well as shake and touch gestures. The chapter concludes with coverage of how to use HTML5 Offline Web Applications API for enabling an app to work when no network access is available. The subsequent chapter, "Polishing up Our App," shows the reader how to do just that — specifically, preventing the navigation header from scrolling off the screen, handling click processing delays, displaying dialog boxes, storing data on the client device, and other differences. The narrative is clear, except for a perplexing ornithological expression, "Duck-type" (page 182). Experienced developers will appreciate the section on mobile coding best practices, based on controllers and custom events — for minimizing programming headaches as a project's code becomes sizable.

The last two chapters explain how to convert a web app into a native app, using PhoneGap, an HTML5 application platform that allows a Web app to access those resources of the mobile device that would otherwise be unavailable, such as data in the filesystem and images from any built-in camera. Before demonstrating the details of how to implement those capabilities, the authors show how to install the development environments for all of the supported platforms (including Apple iOS and Google Android), and then PhoneGap itself. Lastly, readers learn how to try to monetize their finished web apps by uploading them to the various app stores.

The authors make extensive use of example source code, to illustrate the ideas being discussed, which works well, partly because the code is generally explained clearly and commented as needed. A code archive is available containing the source code used in the book, except that of the first two chapters and the last two, which collectively is minimal. (Look for the "Downloads" button on that GitHub page to avoid having to download all the files separately.) Beware that some of the sample code appears to be incorrect or incomplete, e.g., stars.html in the directories "ch3" and "ch4" appear to be unstyled, and "javascripts/ch3/untitled file" is empty. Readers who elect to type in any code directly from the book, should watch out for "curly quotes" (e.g., page 230), and instead substitute the corresponding straight equivalents.

In terms of the physical presentation of the book, at 9.9 x 8 inches, it is taller and wider than the standard nowadays, allowing for what appears to be a relatively larger font, which makes the text more readable. The attractive color figures are a welcome change from the usual black-and-white screenshots found in most computer books. They enhance the overall appearance of the book's interior and the experience of reading the narrative.

Speaking of which, most of the narrative is quite clear. However, one critical topic for mobile design is screen resolution, including how to best defensively account for that in one's design and coding. This book's coverage of the topic is divided into at least two different places (pages 40 and 55), and should have been consolidated, in the third chapter. Unlike most programming books littered with chapter summaries, this one appears to have only one section with a summary, which oddly does not summarize the information presented in the section, but instead offers some interpretation thereof. Also, American readers might stumble over a few of the words that use the English/Australian spelling, e.g., "license" (page 239).

Some of the phrasing will likely befuddle the majority of readers, especially in cases where the authors fail to define their terms, e.g., the first bullet point on page 47. There are a few minor inconsistencies in the writing, such as "fill out forms" and "fill in a form" (on the same page, 32), but nothing that would cause confusion on the reader's part. The overall writing style is friendly, although sometimes overdone with an excessive use of exclamation marks (e.g., page 40). The text contains some errata (including several that suggest that the SitePoint copyeditors are unfamiliar with the ability of even a common word processor such as Microsoft Word to detect duplicate words): "to thank to" (page xxi), "the the" (pages 8 and 84), "for for" (13), "look at [in] Chapter 6" (34), "let[']s break" (44), ", (" (54 and 142), "no way to we can used" (55), "[up] to this point" (82), "try and" (82, 93, 131, and 167; should read "try to"), "support [for] standalone mode" (89), "are are" (139), "it's" (162; should read "its"), "if there are" (172; should read "if there were"), "ultimately .depend" (196), "On[c]e you've installed" (203), "we're yet" (212; should read "we've yet"), "an an" (225), "more detail that" (238; should read "more detail than"), and "a a" (240).

Yet none of the aforementioned problems are of great significance, and do not detract from the value of the material presented. All three authors have extensive experience in designing and developing mobile web applications, and this is reflected in the authority with which they not only offer the technical details, but also make recommendations to the reader. This book would serve as an excellent starting point for any web programmer who wishes to learn how to create mobile web sites and applications.

Michael J. Ross is a freelance web developer and writer.

You can purchase Build Mobile Websites and Apps for Smart Devices from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "With the proliferation of handheld devices that allow access to the Web, more business owners and other technology decision-makers are demanding that their organizations' websites be fully accessible on those devices, and even be repackaged as new web-based applications. But designers and developers who may be quite proficient in making non-mobile websites and web apps, can feel uncertain as to how to craft those products, or even where to start the process of learning how to do so. Recently, several books have been published to address this need, including Build Mobile Websites and Apps for Smart Devices, authored by Earle Castledine, Myles Eftos, and Max Wheeler." Read on for the rest of Michael's review Build Mobile Websites and Apps for Smart Devices author Earle Castledine, Myles Eftos, Max Wheeler pages 300 pages publisher SitePoint rating 8/10 reviewer Michael J. Ross ISBN 978-0987090843 summary An approachable guide to getting started building mobile web apps. This title was published by SitePoint on 29 June 2011, under the ISBN 978-0987090843. The book's contents span 300 pages, and are organized into a preface, eight chapters, an appendix, and an index. The preface contains the usual meta information about a technical book; but what really shines is its intro section, which enthusiastically entices the reader to jump into the burgeoning field of mobile web development. The appendix, comprising little more than two pages, presents only the most basic information on how to utilize whatever native web server might be running on the reader's Linux, OS X, or Windows Vista/7 machine. The more than 49 percent of computer owners still using Windows XP (as of this writing), will need to look elsewhere for information on installing and configuring Apache, IIS, or some other web server, should they want to test their apps locally. In terms of prerequisites for this book, readers are expected to be proficient in HTML, CSS, and JavaScript, but not necessarily HTML5 and CSS3, whose concepts are explained as needed throughout the text.

The publisher maintains a web page for the book, where visitors can find the table of contents, errata (none as of this writing), the book's index, and three free sample chapters (Chapters 1, 2, and 4) in PDF format. Visitors can order the print version of the book, the electronic version (in three different formats: PDF, EPUB, and MOBI), and an online course hosted by Learnable (comprising lessons, video tutorials, Q&A sessions, and the example code).

The first chapter introduces the basic concepts and rationale of mobile apps, as well as some of the key decisions one will face in creating them, such as whether to make a web app versus a native app, and the options for providing a mobile experience. The authors briefly describe the example app — a tool for recording and sharing celebrity sightings — which is designed and created sequentially in the material that follows. But the chapter does not fulfill the promise made for it in the preface, where the reader is told he will "be guided through the process of designing and building a mobile web application"; on the contrary, the chapter does not explain how to design and build one.

That effort begins in the second chapter, where the authors discuss some high-level considerations for designing the user interfaces of mobile devices, as well as the benefits and drawbacks of various navigation and content structuring options. The bulk of the narrative involves wireframing the design for the example app, selecting colors and fonts, and crafting an appropriate icon for it. Readers learn of the advantages of using relative units in their CSS, but not how to get all the elements positioned properly regardless of the target device's resolution, when mixing relative units for text and pixel units for images. The section "Scalable Images," later in the subsequent chapter, is a start, but is not sufficient for non-SVG images.

Chapter 3, "Markup for Mobile," is the longest of them all, primarily because it presents much if not all of the source code written by the authors for the initial version of their example app. The majority of the code is in HTML and CSS, with a focus upon the effects made possible using HTML5 and CSS3. Also discussed are the resource limitations of typical mobile devices, content and menu display options, image techniques and scalability, viewport meta element settings, icons, multimedia, and more. Oddly, on pages 71-72, the resource limitations of iOS are repeated, with only slightly different wording. How could the proofreaders have missed this glaring redundancy?

The fourth chapter, "Mobile Web Apps," addresses the logical next step: enhancing a mobile website so it can function as a web app — for which JavaScript is used extensively. After briefly mentioning a couple of the better-known mobile development frameworks, the authors select jQuery as a library for working with the DOM, to speed development and make the example code more platform neutral. There follows an interesting discussion of touch events on mobile devices, how they compare to mouse events, and techniques for best handling them. But the main goal is to show how to load, swap, and go back to pages so as to most closely simulate the snappy behavior of native apps. The extensive code and narrative in this chapter are the most complex of any in the book, and thus will likely be the most challenging for any reader who is not adept with JavaScript and/or jQuery, or who does not have the patience to work through the example code.

At first glance, it would appear that native apps have a huge advantage over web apps, in that they can access information from their mobile devices' capabilities — such as accelerometers and cameras — historically unavailable to mobile web browsers. Fortunately, an increasing number of standard interfaces are allowing web apps to access that data — and this is the topic of the fifth chapter. The reader is shown how to capture and utilize geolocation data, device rotation and acceleration, as well as shake and touch gestures. The chapter concludes with coverage of how to use HTML5 Offline Web Applications API for enabling an app to work when no network access is available. The subsequent chapter, "Polishing up Our App," shows the reader how to do just that — specifically, preventing the navigation header from scrolling off the screen, handling click processing delays, displaying dialog boxes, storing data on the client device, and other differences. The narrative is clear, except for a perplexing ornithological expression, "Duck-type" (page 182). Experienced developers will appreciate the section on mobile coding best practices, based on controllers and custom events — for minimizing programming headaches as a project's code becomes sizable.

The last two chapters explain how to convert a web app into a native app, using PhoneGap, an HTML5 application platform that allows a Web app to access those resources of the mobile device that would otherwise be unavailable, such as data in the filesystem and images from any built-in camera. Before demonstrating the details of how to implement those capabilities, the authors show how to install the development environments for all of the supported platforms (including Apple iOS and Google Android), and then PhoneGap itself. Lastly, readers learn how to try to monetize their finished web apps by uploading them to the various app stores.

The authors make extensive use of example source code, to illustrate the ideas being discussed, which works well, partly because the code is generally explained clearly and commented as needed. A code archive is available containing the source code used in the book, except that of the first two chapters and the last two, which collectively is minimal. (Look for the "Downloads" button on that GitHub page to avoid having to download all the files separately.) Beware that some of the sample code appears to be incorrect or incomplete, e.g., stars.html in the directories "ch3" and "ch4" appear to be unstyled, and "javascripts/ch3/untitled file" is empty. Readers who elect to type in any code directly from the book, should watch out for "curly quotes" (e.g., page 230), and instead substitute the corresponding straight equivalents.

In terms of the physical presentation of the book, at 9.9 x 8 inches, it is taller and wider than the standard nowadays, allowing for what appears to be a relatively larger font, which makes the text more readable. The attractive color figures are a welcome change from the usual black-and-white screenshots found in most computer books. They enhance the overall appearance of the book's interior and the experience of reading the narrative.

Speaking of which, most of the narrative is quite clear. However, one critical topic for mobile design is screen resolution, including how to best defensively account for that in one's design and coding. This book's coverage of the topic is divided into at least two different places (pages 40 and 55), and should have been consolidated, in the third chapter. Unlike most programming books littered with chapter summaries, this one appears to have only one section with a summary, which oddly does not summarize the information presented in the section, but instead offers some interpretation thereof. Also, American readers might stumble over a few of the words that use the English/Australian spelling, e.g., "license" (page 239).

Some of the phrasing will likely befuddle the majority of readers, especially in cases where the authors fail to define their terms, e.g., the first bullet point on page 47. There are a few minor inconsistencies in the writing, such as "fill out forms" and "fill in a form" (on the same page, 32), but nothing that would cause confusion on the reader's part. The overall writing style is friendly, although sometimes overdone with an excessive use of exclamation marks (e.g., page 40). The text contains some errata (including several that suggest that the SitePoint copyeditors are unfamiliar with the ability of even a common word processor such as Microsoft Word to detect duplicate words): "to thank to" (page xxi), "the the" (pages 8 and 84), "for for" (13), "look at [in] Chapter 6" (34), "let[']s break" (44), ", (" (54 and 142), "no way to we can used" (55), "[up] to this point" (82), "try and" (82, 93, 131, and 167; should read "try to"), "support [for] standalone mode" (89), "are are" (139), "it's" (162; should read "its"), "if there are" (172; should read "if there were"), "ultimately .depend" (196), "On[c]e you've installed" (203), "we're yet" (212; should read "we've yet"), "an an" (225), "more detail that" (238; should read "more detail than"), and "a a" (240).

Yet none of the aforementioned problems are of great significance, and do not detract from the value of the material presented. All three authors have extensive experience in designing and developing mobile web applications, and this is reflected in the authority with which they not only offer the technical details, but also make recommendations to the reader. This book would serve as an excellent starting point for any web programmer who wishes to learn how to create mobile web sites and applications.

Michael J. Ross is a freelance web developer and writer.

You can purchase Build Mobile Websites and Apps for Smart Devices from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jfruhlinger writes "McAfee yesterday outlined what it calls Operation Shady RAT, a five-year campaign of cyberespionage launched by a national government against international organizations and private corporations. That government was almost certainly China's, so the question becomes: why are the Western nations silent about it? One fact revealed by the raids is that, predictions of cyberpunk novels nonwithstanding, private companies are still quite weak in the face of national governments — and it's those national governments that must act against such intrusions."

bonch writes "Google's accusation of patent abuse toward its competitors has generated many responses, some of which have asked whether Android's free price is anti-competitive. Drawing comparisons to Microsoft's antitrust trial, in which they were accused of giving away Internet Explorer to drive competitors out of the browser market, Thurrott argues that Google's rivals are 'leveling the playing field' through patent fees by removing an artificial price advantage funded by monopoly search revenues. 'One could argue that Google is using its dominance in search advertising to unfairly gain entry into another market by giving that new product, Android, away for free. Does this remind you of any famous antitrust case?'"

msmoriarty writes "The second-ever federal CIO (the first, Vivek Kundra, resigned in June) will be Steven VanRoekel, who worked with Microsoft for 15 years, running the company's Web Services and Platform Strategy and Windows Server Solutions groups. He went to the FCC in 2009, where he then advocated for open government and open platforms. VanRoekel's title on his twitter feed has already been changed to 'United States Chief Information Officer.'" According to reader dcblogs, VanRoekel is also a hefty political donor, having given $50,000 toward Obama's inauguration festivities.

Today's promised mystery announcement from NASA has finally been made: dotancohen writes "A NASA orbiter has found possible evidence for water on the surface of Mars that flows seasonally. The water likely would be salty, in keeping with the salty Martian environment." Adds an anonymous reader: "Dark, finger-like features appear and extend down some Martian slopes during late spring through summer, fade in winter, and return during the next spring, NASA says, and repeated observations have tracked the seasonal changes in these recurring features on several steep slopes in the middle latitudes of Mars' southern hemisphere." You can find more on the claimed find at NASA TV.

An anonymous reader writes "IEEE Spectrum reports that Stanford's CS221 course 'Introduction to Artificial Intelligence' will be offered online for free. Anyone can sign up and take the course, along with several hundred Stanford undergrads. The instructors are Sebastian Thrun, known for his self-driving cars, and Peter Norvig, director of research at Google. Online students will actually have to do all the same work as the Stanford students. There will be at least 10 hours per week of studying, along with weekly graded homework assignments and midterm and final exams. The instructors, who will be available to answer questions, will issue a certificate for those who complete the course, along with a final grade that can be compared to the grades of the Stanford students. The course, which will last 10 weeks, starts on October 2nd, and online enrollment is now open." When asked how they would deal with ten thousand students, Professor Thrun replied: "We will use something akin to Google Moderator to make sure Peter and I answer the most pressing questions. Our hypothesis is that even in a class of 10,000, there will only be a fixed number of really interesting questions (like 15 per week). There exist tools to find them."

chicksdaddy writes with a post in Threat Post. From the article: "Dillon Beresford used a presentation at the Black Hat Briefings on Wednesday to detail more software vulnerabilities affecting industrial controllers from Siemens, including a serious remotely exploitable denial of service vulnerability, more hard-coded administrative passwords, and even an easter egg program buried in the code that runs industrial machinery around the globe. In an interview Tuesday evening, Beresford said he has reported 18 separate issues to Siemens and to officials at ICS CERT, the Computer Emergency Response Team for the Industrial Control Sector. Siemens said it is readying a patch for some of the holes, including one that would allow a remote attacker to gain administrative control over machinery controlled by certain models of its Step 7 industrial control software."

snydeq writes "Neil McAllister sees Oracle's buggy Java SE 7 release as only the latest misstep in a mounting litany of bad behavior. 'Who was the first to alert the Java community? The Apache Foundation. Oh, the irony. This is the same Apache Foundation that resigned from the Java Community Process executive committee in protest after Oracle repeatedly refused to give it access to the Java Technology Compatibility Kit,' McAllister writes. 'It seems as if Oracle would like nothing better than to stomp Apache and its open source Java efforts clean out of existence.'"

snydeq writes "Neil McAllister sees Oracle's buggy Java SE 7 release as only the latest misstep in a mounting litany of bad behavior. 'Who was the first to alert the Java community? The Apache Foundation. Oh, the irony. This is the same Apache Foundation that resigned from the Java Community Process executive committee in protest after Oracle repeatedly refused to give it access to the Java Technology Compatibility Kit,' McAllister writes. 'It seems as if Oracle would like nothing better than to stomp Apache and its open source Java efforts clean out of existence.'"

ipsender writes with a NASA announcement: "NASA will host a news briefing on Thursday, Aug. 4, at 11 a.m. PDT (2 p.m. EDT) about a significant new Mars science finding. The briefing will be held at NASA Headquarters in Washington. The new finding is based on observations from NASA's Mars Reconnaissance Orbiter, which has been orbiting the Red Planet since 2006." You can catch the briefing online at the NASA TV site.

pbahra writes with an editorial in the Wall Street Journal. From the article: "A few weeks ago Microsoft's European chairman told TechEurope that the average amount of venture capital per head across Europe was just $7. ... Finnish blog ArcticStartup has extrapolated figures showing the total average VC investment per capita for the country was $46 in 2010... The question of why this country on the edge of the Arctic Circle should have such active entrepreneurs came up again in a conversation with Wilhelm Taht, the marketing director of Flowd... 'With Nokia changing gear there is a lot of technical know-how all of a sudden which wasn't available even two years ago,' said Mr.Taht, diplomatically, about the savage job cuts at the struggling mobile phone giant. 'There's a culture of technically savvy engineers. Finns are not necessarily very talkative people, but when it comes to what they know about computers and programming it's pretty staggering.'"

Hugh Pickens writes "Bloomberg reports that Google has accused Microsoft, Apple, and Oracle of waging a 'hostile, organized campaign' against Android by purchasing patents to keep them out of Google's hands and to make it more expensive for handset makers to use Android. 'We thought it was important to speak out and make it clear that we're determined to preserve Android as a competitive choice for consumers, by stopping those who are trying to strangle it,' writes David Drummond, Google's chief legal officer. Android's success has resulted in a 'hostile, organized campaign against Android by Microsoft, Oracle, Apple and other companies, waged through bogus patents.'" Microsoft has responded, saying they offered to bid jointly with Google on the Nortel patents, but Google refused. Some think Google is being hypocritical with their stance on patents changing now that Android appears to infringe on a bunch.

Hugh Pickens writes "Bloomberg reports that Google has accused Microsoft, Apple, and Oracle of waging a 'hostile, organized campaign' against Android by purchasing patents to keep them out of Google's hands and to make it more expensive for handset makers to use Android. 'We thought it was important to speak out and make it clear that we're determined to preserve Android as a competitive choice for consumers, by stopping those who are trying to strangle it,' writes David Drummond, Google's chief legal officer. Android's success has resulted in a 'hostile, organized campaign against Android by Microsoft, Oracle, Apple and other companies, waged through bogus patents.'" Microsoft has responded, saying they offered to bid jointly with Google on the Nortel patents, but Google refused. Some think Google is being hypocritical with their stance on patents changing now that Android appears to infringe on a bunch.

A steady stream of people have submitted notes this morning saying that the story we (and the entire internet, and even NPR's Marketplace) mentioned recently talking about browser platform correlating with IQ looks like a hoax. Of course, if you read the Slashdot discussion, you probably would have known this already, but now everyone knows. The company responsible for the survey, AptiQuant, looks to not be real.

GhostX9 writes "Charlie Miller, Accuvant Principal Research Consultant and keynote speaker at NATO's recent International Conference on Cyber Conflict, speaks with Alan Dang of Tom's Hardware about living in an unsecured world. He goes over his recent MacBook battery exploit and the challenges of computing security in the upcoming future. Quoting: '[W]hat we can do (and this is the approach the industry is sort of taking) is make it so hard and expensive to pull off attacks that it becomes economically infeasible for most attackers. ... The way we make it more difficult is to reduce the number of vulnerabilities and ensure users' software is up to date and "secure by default." Also, make the OS resilient to attack with things like stack canaries, ASLR, DEP, and sandbox applications so that multiple exploits are needed. We also need to better control the software loaded on our devices (i.e. Apple's App Store model). So, instead of having to write a single exploit, it takes three or four in order to perform an attack. This means most attackers won't be able to pull it off, and those who can will have to spend much more time working it out.'"

AzTechGuy writes "Early this year I received one of the 'Whitebox' routers to test the speed of my ISP and compare it to the advertised speed. Today I received an email that they have released the first report with another report due at the end of the year. My results do not correspond with the results reflected in the report." It appears that most ISPs are within 80% of their advertised speeds during peak hours with Verizon leading the pack mostly exceeding their advertised rates. Cablevision users, on the other hand, shouldn't expect more than half of the promised bandwidth (youch!).

Dog's_Breakfast writes "In a declining economy, software licenses become a luxury. Linux and the BSDs offer free alternatives. As the USA toys with the possibility of defaulting on its national debt (and thus risking economic collapse), the author wonders if this might not, at last, lead to 'The Year of the Linux Desktop.'"

An anonymous reader writes "With its recent mass suspension of accounts, Google has highlighted its desire to create a social network that is very different to the way many (including those whose accounts were suspended) would want to see it. The metaphor of the Cathedral and the Bazaar used for software development can be applied to the two types of social networks being proposed by Google on the one hand and the pseudonym supporters on the other. Google's Cathedral model emphasizes order and control whilst the bazaar model supports users who can be anonymous, have multiple identities, interact with anyone they please, and remain unobserved."

Slashdot regular contributor Bennett Haselton wrote in this week to say that "The proposed "Telex" anti-censorship system could technically work, but unless I'm missing something, it would more cost-effective to spend the same resources on fighting censorship using existing technologies." His essay on the subject follows.

Professor Alex Halderman published a paper in July describing a new anti-censorship system called Telex, whereby users in censored countries could request banned websites by sending an encrypted request to an SSL-enabled website (i.e., a Web address beginning with https://) outside of their country -- even if the owner of the SSL-enabled website is not participating in the scheme. Since encrypted communications usually contain some random variation, that random variation can be used to embed hidden messages, which can then be decoded by any third-party observer who intercepts the communication and knows how to decode the hidden message. The third-party observer still cannot decode the original encrypted communication between the end user and the SSL-enabled website -- SSL is designed to be unbreakable by all but the intended recipient -- but the observer can decode the "side message" that was designed to be intercepted in transit. So a Telex-enabled router, in the process of passing the communication along, would notice the hidden request for a banned website, and pass the requested content back to the original user.

By analogy, suppose Mrs. Smith wants to send a letter to a friend. Mrs. Smith knows the letter will be sealed, and supposedly unopenable by the postman. But Mrs. Smith also has many choices of colored envelopes to use, and she has agreed with the postman on a color-coded system -- red for "Meet me tonight at the Motel 6", blue for "Not tonight, he suspects something" -- that the postman can "decode" when he picks up the envelope for delivery. The choice of envelope color is the "random variation" inherent in the sending of the message, which the message sender can use to send a "side message" to anyone who passes it along and who knows the system. The postman -- who is analogous to the Telex-enabled router -- has no access to the original sealed message inside the envelope, but he understands the side message just fine. (A Telex user may have no control over what routers their messages pass through, though, so they simply have to hope that there are enough Telex-enabled routers on the Internet that one of them will pick up the message and decode it. Imagine many different amorous mail carriers in the Postal Service, and any one of them who finds the colored envelope will be happy to show up at the appointed time, if Mrs. Smith is not picky.)

The novel feature of Telex is that it would not require the cooperation of the owner of the SSL-enabled website in order to work. You could send an encrypted communication to any website -- https://www.paypal.com/ for example -- and any Telex-enabled routers along the pathway traveled by the connection, would be able to decode the embedded message hidden in the randomness of the encryption. By contrast, for a user to make use of a typical proxy website like Vtunnel, the owner of the Vtunnel website has to set up the site as a proxy; this means the supply of such sites is limited to those websites whose owners have installed proxy software, and the censors have a greater chance of finding and blocking them all. Telex, on the other hand, would continue to work as long as the user in the censored country was able to access any SSL-enabled website, as long as their request happened to pass through a Telex-enabled router.

So far, so good. But this would presumably require an investment of at least several million dollars by any major backbone provider who wanted to try it, by re-configuring their major routers to speak the Telex protocol, and then potentially hundreds of millions of dollars for a sustained long-term effort. (As Halderman says, "We like to envision this technology as a possible government-level response to government-level censorship.") So here's my question: If any backbone provider (or government entity) wanted to go to that trouble to support the cause of fighting Internet censorship, why wouldn't it be much more straightforward for them to just set up proxy websites themselves?

Professor Halderman didn't respond to my inquiry on that point. The Telex FAQ notes that censorious governments can easily block new proxy sites once they find out about them. But in many censored countries, most proxy sites are not blocked, either because the government isn't trying, or they can't keep up. In China, hardly any proxy sites are blocked at all, as the government seems to put more of their resources into suppressing local dissent directly. Meanwhile in Iran, the censors do put more resources into actually blocking proxy sites -- but because Iran is on the U.S. State Department's embargo list, Iranian censors can't buy Internet censoring software from U.S. companies, so they have to find and block the sites themselves. As a result, newly released proxy sites often stay unblocked longer in Iran than they do in other Middle Eastern countries that use U.S.-made blocking software. Meanwhile, Saudi Arabia, for whatever reason, doesn't seem to block proxy sites at all for the time being. (Saudi Arabia is a strange outlier, since most conservative Islamic countries that filter the Web, also block proxy sites as well. It's not clear why Saudi Arabia doesn't.) So if a government or a philanthropist wants to help the cause of fighting censorship, just set up some proxy sites and pay to keep them running -- and you'll be helping the residents of all of those countries right away, for starters. This is in fact what Voice of America (through their various proxy programs) and the founders of UltraSurf (a privately funded network of anti-censorship servers) have been doing all along.

Even in the case of countries like U.A.E. and Yemen that are reasonably quick at finding and blocking proxy sites (as a result of using Western-made blocking software), the most cost-effective way to help these users is probably to set up more proxy sites, hosted at different locations and with perhaps with legitimate-looking "decoy" content, so that U.S. censorware companies can't keep up. My experience has been that the more money you spend (using unique IP addresses, buying .com domains instead of cheap .info ones, and setting up lots of proxies so that each one is sent to only a subset of your target audience), the longer the proxy sites last. You can also use proxy-like services (such as Tor, Hotspot Shield and UltraSurf) to route traffic through dedicated servers, to circumvent censorship in a way that is more transparent and convenient to the end user.

In short, existing proxy sites (and proxy-like services) do the job pretty well for many censored countries, and a massive cash expenditure on setting up more proxies (equivalent to the cost of setting up the Telex system) would probably be enough to demolish all other national filtering schemes completely. The software and tools to run proxy sites have already been tried and tested; all it takes to run them is money. Telex, by contrast, would require backbone providers to alter the architecture of their systems -- which means large-scale testing, isolation of any problems that arise, and countless other potential headaches. And that's not even counting the fact that censorious countries might detect which backbone providers are using Telex, and block all traffic from their countries to any sites hosted on those networks.

So I think Telex is a brilliant technical achievement, and I'd be happy if it got deployed, but I'd be scratching my head as to why the backbone providers (or the government, or whoever sponsored the effort) decided to kill a gnat with a flamethrower. I deal in flyswatters for a living, and they get the job done.

Slashdot regular contributor Bennett Haselton wrote in this week to say that "The proposed "Telex" anti-censorship system could technically work, but unless I'm missing something, it would more cost-effective to spend the same resources on fighting censorship using existing technologies." His essay on the subject follows.

Professor Alex Halderman published a paper in July describing a new anti-censorship system called Telex, whereby users in censored countries could request banned websites by sending an encrypted request to an SSL-enabled website (i.e., a Web address beginning with https://) outside of their country -- even if the owner of the SSL-enabled website is not participating in the scheme. Since encrypted communications usually contain some random variation, that random variation can be used to embed hidden messages, which can then be decoded by any third-party observer who intercepts the communication and knows how to decode the hidden message. The third-party observer still cannot decode the original encrypted communication between the end user and the SSL-enabled website -- SSL is designed to be unbreakable by all but the intended recipient -- but the observer can decode the "side message" that was designed to be intercepted in transit. So a Telex-enabled router, in the process of passing the communication along, would notice the hidden request for a banned website, and pass the requested content back to the original user.

By analogy, suppose Mrs. Smith wants to send a letter to a friend. Mrs. Smith knows the letter will be sealed, and supposedly unopenable by the postman. But Mrs. Smith also has many choices of colored envelopes to use, and she has agreed with the postman on a color-coded system -- red for "Meet me tonight at the Motel 6", blue for "Not tonight, he suspects something" -- that the postman can "decode" when he picks up the envelope for delivery. The choice of envelope color is the "random variation" inherent in the sending of the message, which the message sender can use to send a "side message" to anyone who passes it along and who knows the system. The postman -- who is analogous to the Telex-enabled router -- has no access to the original sealed message inside the envelope, but he understands the side message just fine. (A Telex user may have no control over what routers their messages pass through, though, so they simply have to hope that there are enough Telex-enabled routers on the Internet that one of them will pick up the message and decode it. Imagine many different amorous mail carriers in the Postal Service, and any one of them who finds the colored envelope will be happy to show up at the appointed time, if Mrs. Smith is not picky.)

The novel feature of Telex is that it would not require the cooperation of the owner of the SSL-enabled website in order to work. You could send an encrypted communication to any website -- https://www.paypal.com/ for example -- and any Telex-enabled routers along the pathway traveled by the connection, would be able to decode the embedded message hidden in the randomness of the encryption. By contrast, for a user to make use of a typical proxy website like Vtunnel, the owner of the Vtunnel website has to set up the site as a proxy; this means the supply of such sites is limited to those websites whose owners have installed proxy software, and the censors have a greater chance of finding and blocking them all. Telex, on the other hand, would continue to work as long as the user in the censored country was able to access any SSL-enabled website, as long as their request happened to pass through a Telex-enabled router.

So far, so good. But this would presumably require an investment of at least several million dollars by any major backbone provider who wanted to try it, by re-configuring their major routers to speak the Telex protocol, and then potentially hundreds of millions of dollars for a sustained long-term effort. (As Halderman says, "We like to envision this technology as a possible government-level response to government-level censorship.") So here's my question: If any backbone provider (or government entity) wanted to go to that trouble to support the cause of fighting Internet censorship, why wouldn't it be much more straightforward for them to just set up proxy websites themselves?

Professor Halderman didn't respond to my inquiry on that point. The Telex FAQ notes that censorious governments can easily block new proxy sites once they find out about them. But in many censored countries, most proxy sites are not blocked, either because the government isn't trying, or they can't keep up. In China, hardly any proxy sites are blocked at all, as the government seems to put more of their resources into suppressing local dissent directly. Meanwhile in Iran, the censors do put more resources into actually blocking proxy sites -- but because Iran is on the U.S. State Department's embargo list, Iranian censors can't buy Internet censoring software from U.S. companies, so they have to find and block the sites themselves. As a result, newly released proxy sites often stay unblocked longer in Iran than they do in other Middle Eastern countries that use U.S.-made blocking software. Meanwhile, Saudi Arabia, for whatever reason, doesn't seem to block proxy sites at all for the time being. (Saudi Arabia is a strange outlier, since most conservative Islamic countries that filter the Web, also block proxy sites as well. It's not clear why Saudi Arabia doesn't.) So if a government or a philanthropist wants to help the cause of fighting censorship, just set up some proxy sites and pay to keep them running -- and you'll be helping the residents of all of those countries right away, for starters. This is in fact what Voice of America (through their various proxy programs) and the founders of UltraSurf (a privately funded network of anti-censorship servers) have been doing all along.

Even in the case of countries like U.A.E. and Yemen that are reasonably quick at finding and blocking proxy sites (as a result of using Western-made blocking software), the most cost-effective way to help these users is probably to set up more proxy sites, hosted at different locations and with perhaps with legitimate-looking "decoy" content, so that U.S. censorware companies can't keep up. My experience has been that the more money you spend (using unique IP addresses, buying .com domains instead of cheap .info ones, and setting up lots of proxies so that each one is sent to only a subset of your target audience), the longer the proxy sites last. You can also use proxy-like services (such as Tor, Hotspot Shield and UltraSurf) to route traffic through dedicated servers, to circumvent censorship in a way that is more transparent and convenient to the end user.

In short, existing proxy sites (and proxy-like services) do the job pretty well for many censored countries, and a massive cash expenditure on setting up more proxies (equivalent to the cost of setting up the Telex system) would probably be enough to demolish all other national filtering schemes completely. The software and tools to run proxy sites have already been tried and tested; all it takes to run them is money. Telex, by contrast, would require backbone providers to alter the architecture of their systems -- which means large-scale testing, isolation of any problems that arise, and countless other potential headaches. And that's not even counting the fact that censorious countries might detect which backbone providers are using Telex, and block all traffic from their countries to any sites hosted on those networks.

So I think Telex is a brilliant technical achievement, and I'd be happy if it got deployed, but I'd be scratching my head as to why the backbone providers (or the government, or whoever sponsored the effort) decided to kill a gnat with a flamethrower. I deal in flyswatters for a living, and they get the job done.

asto21 Wrote in to tell us that CmdrTaco forgot to mention the most awesome thing at the Detroit Maker Faire this past weekend, a fire breathing pony cleverly controlled via Wii-mote.

suraj.sun writes "Microsoft has ceased publishing the estimated locations of millions of laptops, cell phones, and other devices with Wi-Fi connections around the world after a CNET article on Friday highlighted privacy concerns. The decision to rework Live.com's geolocation service comes following scrutiny of the way Microsoft made available its database assembled by both Windows Phone 7 phones and what the company calls 'managed driving' by Street View-like vehicles that record Wi-Fi signals accessible from public roads. Every Wi-Fi device has a unique ID, sometimes called a MAC address, that cannot normally be changed."

itwbennett writes "When last we left the Oracle/Google patent infringement saga, Oracle had been ordered by Judge William Alsup to lower its claim for damages to $100 million, give or take. Today Judge Alsup denied Google's attempt to get a potentially damaging e-mail redacted. 'What we've actually been asked to do by Larry and Sergey is to investigate what technology alternatives exist to Java for Android and Chrome,' Google engineer Tim Lindholm wrote in the Aug. 2010 e-mail. 'We've been over a hundred of these and think they all suck. We conclude that we need to negotiate a license for Java.'"

Hugh Pickens writes "The Washington Post reports that Judge Richard D. Bennett harshly criticized US prosecutor William M. Welch III for his treatment of a former spy agency official Thomas Drake, who was accused of leaking classified material. Bennett called the delays in the now-closed case 'unconscionable' and compared it to British tyranny in the colonial era. In 2007, FBI agents raided Drake's house, but it took over two years for officials to indict him. 'And then, over a year later, on the eve of trial, in June of 2011, the government says, "Whoops, we dropped the whole case,"' Bennett said. Drake was given a mild penalty for pleading guilty to the misdemeanor charge of exceeding authorized use of a computer: a year's probation and 240 hours of community service while all 10 felony counts were dropped. 'That's four years of hell that a citizen goes through,' Bennett said. 'It was not proper. It doesn't pass the smell test.' In contrast with his tough words for Welch, Bennett singled out for praise Drake's public defenders, James Wyda and Deborah L. Boardman, saying their work on behalf of Drake was 'at the highest level of professionalism.' Judge Welch said the matter was now closed and addressed Drake: 'I wish you the best of luck in the rest of your life.'"

Hugh Pickens writes "The Washington Post reports that Judge Richard D. Bennett harshly criticized US prosecutor William M. Welch III for his treatment of a former spy agency official Thomas Drake, who was accused of leaking classified material. Bennett called the delays in the now-closed case 'unconscionable' and compared it to British tyranny in the colonial era. In 2007, FBI agents raided Drake's house, but it took over two years for officials to indict him. 'And then, over a year later, on the eve of trial, in June of 2011, the government says, "Whoops, we dropped the whole case,"' Bennett said. Drake was given a mild penalty for pleading guilty to the misdemeanor charge of exceeding authorized use of a computer: a year's probation and 240 hours of community service while all 10 felony counts were dropped. 'That's four years of hell that a citizen goes through,' Bennett said. 'It was not proper. It doesn't pass the smell test.' In contrast with his tough words for Welch, Bennett singled out for praise Drake's public defenders, James Wyda and Deborah L. Boardman, saying their work on behalf of Drake was 'at the highest level of professionalism.' Judge Welch said the matter was now closed and addressed Drake: 'I wish you the best of luck in the rest of your life.'"

1sockchuck writes "How many servers is Google using? The company won't say, but a new report places the number at about 900,000. The estimate is based on data Google shared with researcher Jonathan Koomey, for a new report on data center power use. The data updates a 2007 report to Congress, and includes a surprise: data centers are using less energy than projected, largely due to the impact of the recession (buying fewer servers) and virtualization."

Hugh Pickens writes "Some of the same vulnerabilities that the Stuxnet superworm used to sabotage centrifuges at a nuclear plant in Iran exist in the country's top high-security prisons where programmable logic controllers (PLCs) control locks on cells and other facility doors. Researchers have already written three exploits for PLC vulnerabilities they found. 'Most people don't know how a prison or jail is designed; that's why no one has ever paid attention to it,' says John Strauchs, who plans to discuss the issue and demonstrate an exploit against the systems at the DefCon hacker conference next week. 'How many people know they're built with the same kind of PLC used in centrifuges?' A hacker would need to get his malware onto the control computer either by getting a corrupt insider to install it via an infected USB stick or send it via a phishing attack aimed at a prison staffer, since some control systems are also connected to the internet, Strauchs claims. 'Bear in mind, a prison security electronic system has many parts beyond door control such as intercoms, lighting control, video surveillance, water and shower control, and so forth,' adds Strauchs. 'Once we take control of the PLC we can do anything (PDF). Not just open and close doors. We can absolutely destroy the system. We could blow out all the electronics.'"

hackingbear writes "Taiwanese technology giant Foxconn will replace some of its workers with 1 million robots in three years to cut rising labor expenses and improve efficiency. Foxconn, the world's largest maker of computer components, which assembles products for Apple, Sony and Nokia, employing 1 million (human) laborers in mainland China, is in the spotlight after a string of suicides of workers at its massive Chinese plants. As labor regulations tighten up in China, human laborers demanding wage rises become replaceable."

msmoriarty writes "Given the level of interest in the recent highest-paid programmers discussion, our reporter decided to do a follow-up looking into the languages and skills needed to work on high-frequency trading systems. There's actually a pretty wide range of languages/tools used, but Linux is the 'default' OS and, not surprisingly, the 'ability to work under pressure when the traders are screaming at you' is a must-have skill."

gavron writes "The US Department of Justice will review the Nortel patent sale to the entity formed by Apple, Microsoft, and others. This is the same sale that the Canadian authorities declined to review because the $4B+ deal was valued by them at less than $328M. According to a (paywalled) Wall Street Journal report, 'The Justice Department wants to know whether [the consortium] intends to use them defensively to deter patent lawsuits against its members, or offensively against rivals.'"

jrepin writes "Georg Greve from Free Software Foundation Europe has often been asked to explain what he considers necessary prerequisites for an open, free, sustainable approach toward what is often called 'The Cloud,' or also 'Software as a Service.' He gives 7 ingredients that are necessary for freedom in the cloud. For example, 'it should be illegal to change privacy policies on users without their explicit consent. They need to know what is changing, and how, and what will be the resulting level of privacy they enjoy – in the same clear, transparent and understandable manner.'"

suraj.sun tips this report from the H Online: "The hopes that the VP8 codec at the heart of Google's open source WebM video standard would remain unchallenged in the patent arena are diminishing after the MPEG LA says 12 parties hold patents that its evaluators consider essential to the codec. ... No VP8 patent pool has been formed yet; the MPEG LA says it met with the patent holders in late June and is 'continuing to facilitate that discussion' but the decision to form a pool is up to the patent holders. ... Google responded to the MPEG LA's interview saying it is 'firmly committed to the project and establishing an open codec for HTML5 video' and noting the April launch of the WebM CCL, a community cross-licencing agreement for essential WebM related patents."

hackingbear writes "The Xinhua news agency reports that a signaling equipment circuit design flaw and lack of safety alertness in railway management caused a high-speed train to ram into a stalled train near the city of Wenzhou in east China's Zhejiang Province on Saturday, leaving 40 people dead and 191 injured. A lightning strike triggered the malfunction, which resulted in a green alert light failing to turn red, leaving railway personnel unaware of the stalled train, the official said. The Beijing National Railway Research and Design Institute of Signal and Communication Co., which was responsible for designing and building the signaling system, has posted an apology letter on its website, offering condolences and promising to 'shoulder any due punishments that may result from the investigation.' Domestic media has raised more questions over the explanation. 'Why was such seriously flawed equipment in use for nearly two years without being detected? Why was it installed in as many as 76 rail stations across the country? Are there other problems with the railway apart from equipment flaws?'"

Ubisoft made headlines a couple days ago for bringing back their restrictive DRM for an upcoming racing game. Speaking with PCGamer in response to the overwhelmingly negative feedback to this news, a Ubisoft representative said the company has seen "a clear reduction in piracy of our titles which required a persistent online connection," adding, "from that point of view the requirement is a success." One wonders how they measured this, and how they compare it to sales lost due to the bad press it's generated.

The Bad Astronomer writes "As posted earlier on Slashdot, a Forbes Op/Ed claims there is a 'gaping hole in global warming' theories, based on a recent paper. However, both the Forbes article and the paper on which it's based are themselves seriously flawed. The paper has been excoriated by climate scientists, saying the model used is 'unrealistic' and 'incorrect,' and the author has a track record of using bad models to make incorrect conclusions."

Lisandro writes "Lucid Imagination just posted an announcement about a severe bug in the recently released Java 7. Apparently some loops are mis-compiled due to errors in the HotSpot compiler optimizations, which causes programs to fail. This bug affects several Apache projects directly — Apache Lucene Core and Apache Solr have already raised a warning, noting that the bug might be present in Java 6 as well."

An anonymous reader writes "Game developer David Braben caused geeks to get excited back in May when he announced plans to develop and release a $25 PC. It is called the Raspberry Pi and takes the form of a USB stick that can be plugged into the HDMI port of a display ready to act as a fully-functional PC. Two months on and the spec of the PCB layout has been finalized and an alpha release has been sent to manufacture. Any doubts this PC wasn't going to happen should now disappear as this alpha board is expected to be almost the same as the final production unit. Although we don't know a release date as of yet, the Raspeberry Pi Foundation is promising images of the alpha boards in a couple of weeks."

Gibbs-Duhem writes "It makes me very nervous that my Android phone has access to my email/AIM/G-talk/Facebook, protected only by a presumably fairly easily hacked geometric password protection scheme. Even more because simply attaching the phone to a USB port allows complete access to the internal memory and SD card regardless of whether a password is entered. I have no idea how much of that information ranging from cached emails to passwords stored in plaintext is accessible when mounting the device as a USB drive, and that worries me." For the rest of Gibbs-Duhem's question about issues in Android security, read on below. Gibbs-Duhem continues:"I have a lot of sensitive information in my email, including passwords for websites and confidential business/technical strategy discussions (not to mention personal emails ranging from racy emails from boyfriends to health discussions). My email and messaging client passwords are difficult to type (or even remember), so I would ideally want them saved in the device, although at least having something like a keyring password that needed to be re-entered after a time delay would make me feel better. This leaves me relying on encryption and OS level security to protect me.

I'm okay with this on my real laptop and computers as my hard disks are software encrypted and I make a habit of locking my session whenever I leave my desk. For instance, if I lost my laptop, the odds of the thief getting access to my information is minimal. However, I don't feel that this is at all true for my phone (which is frankly far more likely to be lost).

How is it that the Slashdot security pros handle this issue? Do you just not use email or the many other incredibly convenient capabilities of new Android smartphones due to the risk? Or are there specific ways in which we can guarantee (or at least greatly augment) the existing security practices?"

Last year Ubisoft introduced DRM for their PC games that required a constant internet connection, going so far as to terminate single-player games if the connection was interrupted. After facing outrage, boycotts, and DDoS attacks, Ubisoft seemed to have softened their stance, issuing a patch for two games that allowed offline play. Unfortunately, it seems the change wasn't permanent; Ubisoft's upcoming racing game Driver: San Francisco marks the return of the contentious DRM.

Last year Ubisoft introduced DRM for their PC games that required a constant internet connection, going so far as to terminate single-player games if the connection was interrupted. After facing outrage, boycotts, and DDoS attacks, Ubisoft seemed to have softened their stance, issuing a patch for two games that allowed offline play. Unfortunately, it seems the change wasn't permanent; Ubisoft's upcoming racing game Driver: San Francisco marks the return of the contentious DRM.

jrepin writes "KDE 4.7 releases provide many new features and improved stability and performance. Lots of visual polishing took place with an update to the Oxygen icons, and improved consistency between panel items such as clock and notification areas. The window manager KWin brings a new shadow system and can now run on OpenGL ES supporting hardware, making it better suited for mobile devices. Network management widget is much improved. Navigating through applications and recent files is easier with the addition of breadcrumbs to the Kickoff application launcher. Kontact groupware solution rejoins the rest of the KDE software, with increased stability, better connection to new services and sharing of communication information between more applications. Dolphin file manager has a cleaner default appearance. The menu bar is hidden, but easy to reach and restore. The file searching interface has been improved. Marble the virtual globe now has voice navigation support and a map creation wizard. Gwenview image viewer now offers the ability to compare two or more pictures side by side. Digikam photo management app brings face detection and recognition."

CWmike writes "A brewing legal dispute between Sony and one of its insurers over data breach liability claims highlights the challenges that companies can sometimes face in getting insurance providers to cover expenses arising from cybersecurity incidents. Zurich American Insurance Co. asked the court last week to absolve it of any responsibility for defending or indemnifying Sony against claims arising from the recent data breaches at the company. The data breaches at Sony's PlayStation Network, Sony Entertainment Online and Sony Pictures resulted in account data on close to 100 million individuals becoming exposed and over 12 million credit and debit cards being compromised. The breaches have so far resulted in at least 55 putative class-action lawsuits being filed against Sony in the U.S and another three lawsuits filed against it in Canada. Sony expects to spend close to $180 million in the next year alone on breach-related costs. But analysts say insurance might not have even been worth it in Sony's case: 'There aren't many success stories where cyber insurance [has played] a significant role in reducing the cost of incidents,' said Gartner analyst John Pescatore. Um, better security as an insurance policy maybe?"

CWmike writes "A brewing legal dispute between Sony and one of its insurers over data breach liability claims highlights the challenges that companies can sometimes face in getting insurance providers to cover expenses arising from cybersecurity incidents. Zurich American Insurance Co. asked the court last week to absolve it of any responsibility for defending or indemnifying Sony against claims arising from the recent data breaches at the company. The data breaches at Sony's PlayStation Network, Sony Entertainment Online and Sony Pictures resulted in account data on close to 100 million individuals becoming exposed and over 12 million credit and debit cards being compromised. The breaches have so far resulted in at least 55 putative class-action lawsuits being filed against Sony in the U.S and another three lawsuits filed against it in Canada. Sony expects to spend close to $180 million in the next year alone on breach-related costs. But analysts say insurance might not have even been worth it in Sony's case: 'There aren't many success stories where cyber insurance [has played] a significant role in reducing the cost of incidents,' said Gartner analyst John Pescatore. Um, better security as an insurance policy maybe?"

CWmike writes "A brewing legal dispute between Sony and one of its insurers over data breach liability claims highlights the challenges that companies can sometimes face in getting insurance providers to cover expenses arising from cybersecurity incidents. Zurich American Insurance Co. asked the court last week to absolve it of any responsibility for defending or indemnifying Sony against claims arising from the recent data breaches at the company. The data breaches at Sony's PlayStation Network, Sony Entertainment Online and Sony Pictures resulted in account data on close to 100 million individuals becoming exposed and over 12 million credit and debit cards being compromised. The breaches have so far resulted in at least 55 putative class-action lawsuits being filed against Sony in the U.S and another three lawsuits filed against it in Canada. Sony expects to spend close to $180 million in the next year alone on breach-related costs. But analysts say insurance might not have even been worth it in Sony's case: 'There aren't many success stories where cyber insurance [has played] a significant role in reducing the cost of incidents,' said Gartner analyst John Pescatore. Um, better security as an insurance policy maybe?"

CWmike writes "A brewing legal dispute between Sony and one of its insurers over data breach liability claims highlights the challenges that companies can sometimes face in getting insurance providers to cover expenses arising from cybersecurity incidents. Zurich American Insurance Co. asked the court last week to absolve it of any responsibility for defending or indemnifying Sony against claims arising from the recent data breaches at the company. The data breaches at Sony's PlayStation Network, Sony Entertainment Online and Sony Pictures resulted in account data on close to 100 million individuals becoming exposed and over 12 million credit and debit cards being compromised. The breaches have so far resulted in at least 55 putative class-action lawsuits being filed against Sony in the U.S and another three lawsuits filed against it in Canada. Sony expects to spend close to $180 million in the next year alone on breach-related costs. But analysts say insurance might not have even been worth it in Sony's case: 'There aren't many success stories where cyber insurance [has played] a significant role in reducing the cost of incidents,' said Gartner analyst John Pescatore. Um, better security as an insurance policy maybe?"

jfruhlinger writes "Dropbox was a service that many techies fell in love with, only to be disappointed when they found out about its dodgy security and dubious copyright claims. The company's tried to make amends — but what other options are there for those who have had enough? While there's nothing quite as seamless out there, it's not difficult to build your own Dropbox alternatives from freely available software and services from other vendors."

jfruhlinger writes "Dropbox was a service that many techies fell in love with, only to be disappointed when they found out about its dodgy security and dubious copyright claims. The company's tried to make amends — but what other options are there for those who have had enough? While there's nothing quite as seamless out there, it's not difficult to build your own Dropbox alternatives from freely available software and services from other vendors."

1800maxim writes "As it turns out, Google didn't only grab the hotspot SSIDs and MAC addresses with its Street View cars. As this article at CNET notes, Google also recorded location data of computers using wireless cards, as well as cell phones and other Wi-Fi devices. Google's explanation is that the data collection was accidental, and they declined to answer further questions from CNET."

Kevin Kelly has for decades been involved in some of the most interesting projects I know about, and in his roles as founding editor (and now editor at large) of Wired Magazine and editor of The Whole Earth Catalog has helped spread the word about many others. Kelly is probably as close to a Rennaisance man as it's possible to be in the 21st century, having more-than-passing interest and knowledge in a range of topics from genetic sequencing and other ways that we can use measurement in pursuit of improved health to how technology is used and reused in real life. Among other projects, he's also the founder of CoolTools, which I consider to be (unsurprisingly) the closest current equivalent to the old Whole Earth Catalogs. (Disclaimer: I've had a few reviews published there, too.) (He's also one of the founders of The WELL, now part of Salon.) Kelly is also Secretary of the Board of Directors of the Long Now Foundation, the group which for years has been designing a clock to ring on 10,000 years in the future. Below, ask questions of Kelly, bearing in mind please the Slashdot interview guidelines: ask as many questions as you want, but please keep them to one per comment. He'll get back soon with his answers.