Space

We May Have Jupiter To Thank For the Nitrogen In Earth's Atmosphere 46

Posted by Soulskill
from the jupiter-never-forgets-our-birthday dept.
An anonymous reader writes: Nitrogen makes up about 78% of the Earth's atmosphere. It's also the 4th most abundant element in the human body. But where did all the nitrogen on Earth come from? Scientists aren't sure, but they have a new theory. Back when the solar system was just a protoplanetary disk, the ice orbiting the early Sun included ammonia, which has a nitrogen atom and three hydrogen atoms. But there needed to be a way for the nitrogen to get to the developing Earth. That's where Jupiter comes in. During its theorized Grand Tack, where it plunged into the inner solar system and then retreated outward again, it created shock waves in the dust and ice cloud surrounding the sun. These shock waves caused gentle heating of the ammonia ice, which allowed it to melt and react with chromium-bearing metal to form a mineral called carlsbergite. New research (abstract) suggests this mineral was then present when the Earth's accretion happened, supplying much of the nitrogen we would eventually need for life.
Opera

Opera Founder Is Back, WIth a Feature-Heavy, Chromium-Based Browser 158

Posted by timothy
from the sink-within-a-sink dept.
New submitter cdysthe writes Almost two years ago, the Norwegian browser firm Opera ripped out the guts of its product and adopted the more standard WebKit and Chromium technologies, essentially making it more like rivals Chrome and Safari. But it wasn't just Opera's innards that changed; the browser also became more streamlined and perhaps less geeky. Many Opera fans were deeply displeased at the loss of what they saw as key differentiating functionality. So now Jon von Tetzchner, the man who founded Opera and who would probably never have allowed those drastic feature changes, is back to serve this hard core with a new browser called Vivaldi. The project's front page links to downloads of a technical preview, available for Linux, Mac OS X, and Windows. Firefox users who likewise prefer a browser with more rather than fewer features (but otherwise want to stick with Firefox) might also consider SeaMonkey, which bundles not just a browser but email, newsgroup client and feed reader, HTML editor, IRC chat and web development tools.
Google

Google Explains Why WebView Vulnerability Will Go Unpatched On Android 4.3 577

Posted by samzenpus
from the no-patch-for-you dept.
MojoKid writes If you're running Android 4.3 or earlier, you're pretty much out of luck when it comes to a baked-in defense against a WebView vulnerability that was discovered earlier this month by security analyst Tod Beardsley. The vulnerability leaves millions of users open to attack from hackers that choose to exploit the security hole. WebView is a core component of the Android operating system that renders web pages. The good news is that the version of WebView included in Android 4.4 KitKat and Android 5.0 Lollipop is based on Chromium and is not affected by the vulnerability. The bad news is that those running Android 4.3 and earlier are wide open, which means that 60 percent of Android users (or nearly one billion customers) are affected. What's most interesting is that Google has no trouble tossing grenades at the feet of Microsoft and Apple courtesy of its Project Zero program, but doesn't seem to have the resources to fix a vulnerability that affects a substantial portion of the Android user base.
Chrome

With Community Help, Chrome Could Support Side Tabs Extension 117

Posted by timothy
from the thinking-along-different-axes dept.
jones_supa writes The lack of a vertical tab strip (or "Tree Style Tab" as the Firefox extension is called) has been under a lot of discussion under Chrome/Chromium bug tracker. Some years ago, vertical tabs existed as an experimental feature enabled with a "secret" command line parameter, but that feature was eventually removed from the browser. Since then, Google has been rather quiet about whether such feature is still on the roadmap. Now, a Google engineer casts some light on the issue. He says that a tree-style interface for tabs would be overly complex as a native implementation, but Google would back the idea of improving the extensions interface to support a sidebar-like surface to render the tab UI on, if someone from the open source community would step forward to do the work to drive the feature to completion.
Chrome

Google Chrome Will Block All NPAPI Plugins By Default In January 107

Posted by samzenpus
from the end-of-the-line dept.
An anonymous reader writes Google today provided an update on its plan to remove Netscape Plugin Application Programming Interface (NPAPI) from Chrome, which the company says will improve the browser's security, speed, and stability, as well as reduce complexity in the code base. In short, the latest timeline is as follows: Block all plugins by default in January 2015, disable support in April 2015, and remove support completely in September 2015. For context, Google first announced in September 2013 that it was planning to drop NPAPI. At the time, Google said anonymous Chrome usage data showed just six NPAPI plugins were used by more than 5 percent of users, and the company was hoping to remove support from Chrome "before the end of 2014, but the exact timing will depend on usage and user feedback."
Chrome

Chrome 39 Launches With 64-bit Version For Mac OS X and New Developer Features 67

Posted by Soulskill
from the almost-over-the-hill dept.
An anonymous reader writes "Google today released Chrome 39 for Windows, Mac, and Linux. The biggest addition in this release is 64-bit support for OS X, which first arrived in Chrome 38 beta. Unlike on Windows, where 32-bit and 64-bit versions will both continue to be available (users currently have to opt-in to use the 64-bit release), Chrome for Mac is now only available in 64-bit. There are also a number of security fixes and developer features. Here's the full changelog.
Chromium

Building All the Major Open-Source Web Browsers 106

Posted by Soulskill
from the who-needs-packages dept.
An anonymous reader writes: Cristophe de Dinechin, long-time software developer, has an interesting article on the processes involved in building the major browsers. From the article:

"Mozilla Firefox, Chromium (the open-source variant of Chrome) and WebKit (the basis for Safari) are all great examples of open-source software. The Qt project has a simple webkit-based web browser in their examples. So that's at least four different open-source web browsers to choose from. But what does it take to actually build them? The TL;DR answer is that these are complex pieces of software, each of them with rather idiosyncratic build systems, and that you should consider 100GB of disk space to build all the browsers, a few hours of download, and be prepared to learn lots of new, rather specific tools."
Internet Explorer

Microsoft's JavaScript Engine Gets Two-Tiered Compilation 46

Posted by Soulskill
from the under-the-hood dept.
jones_supa writes: The Internet Explorer team at Microsoft recently detailed changes to the JavaScript engine coming in Windows 10. A significant change is the addition of a new tier in the Just-in-Time (JIT) compiler. In Windows 10, the Chakra JS engine now includes a second JIT compiler that bridges the gap between slow, interpreted code and fast, optimized code. It uses this middle-tier compiler, called Simple JIT, as a "good enough" layer that can move execution away from the interpreter quicker than the Full JIT can. Microsoft claims that the changes will allow certain workloads to "run up to 30% faster". The move to a two-tiered JIT compiler structure mirrors what other browsers have done. SpiderMonkey, the JavaScript engine in Firefox, has an interpreter and two compilers: Baseline and IonMonkey. In Google Chrome, the V8 JavaScript engine is also a two-tiered system. It does not use an interpreter, but compiles on a discrete background thread.
Data Storage

After Negative User Response, ChromeOS To Re-Introduce Support For Ext{2,3,4} 183

Posted by Soulskill
from the squeeky-wheels dept.
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."
Chrome

ChromeOS Will No Longer Support Ext2/3/4 On External Drives/SD Cards 345

Posted by timothy
from the hope-this-is-reverted dept.
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.
Chrome

Chrome 38 Released: New APIs and 159 Security Fixes 55

Posted by Soulskill
from the onward-and-upward dept.
An anonymous reader writes: In addition to updating Chrome for iOS, Google has released Chrome 38 for Windows, Mac, and Linux. While Chrome 38 beta brought a slew of new features, the stable release is pretty much just a massive security update. This means that, with Chrome 38, Google isn't adding any features to the stable channel (full changelog). That said, Chrome 38 does address 159 security issues (including 113 "relatively minor ones"). Google spent $75,633.70 in bug bounties for this release.
Google

Chrome For Mac Drops 32-bit Build 129

Posted by samzenpus
from the more-bits dept.
jones_supa writes Google has revealed that it's launching the finished 64-bit version of Chrome 39 for OS X this November, which already brought benefits in speed, security and stability on Windows. However at this point the 32-bit build for Mac will cease to exist. Just to make it clear, this decision does not apply to Windows and Linux builds, at least for now. As a side effect, 32-bit NPAPI plugins will not work on Chrome on Mac version 39 onwards. The affected hardware are only the very first x86-based Macs with Intel Core Duo processors. An interesting question remains, whether the open source version of Chrome, which is of course Chromium, could still be compiled for x86-32 on OS X.
Encryption

Why Google Is Pushing For a Web Free of SHA-1 108

Posted by Soulskill
from the collision-course dept.
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."
Chrome

Google Introduces HTML 5.1 Tag To Chrome 94

Posted by timothy
from the tagging-wars-ensue dept.
darthcamaro (735685) writes "Forget about HTML5, that's already passe — Google is already moving on to HTML5.1 support for the upcoming Chrome 38 release. Currently only a beta, one of the biggest things that web developers will notice is the use of the new "picture" tag which is a container for multiple image sizes/formats. Bottom line is it's a new way to think about the "IMG" tag that has existed since the first HTML spec."
Chromium

Chromium 37 Launches With Major Security Fixes, 64-bit Windows Support 113

Posted by Unknown Lamer
from the almost-makes-up-for-<dialog> dept.
An anonymous reader writes Google has released Chrome/Chromium version 37 for Windows, Mac, and Linux. Among the changes are better-looking fonts on Windows and a revamped password manager. There are 50 security fixes, including several to patch a sandbox escaping vulnerability. The release also brings stable 64-bit Windows support which ...offers many benefits for speed, stability and security. Our measurements have shown that the native 64-bit version of Chrome has improved speed on many of our graphics and media benchmarks. For example, the VP9 codec that’s used in High Definition YouTube videos shows a 15% improvement in decoding performance. Stability measurements from people opted into our Canary, Dev and Beta 64-bit channels confirm that 64-bit rendering engines are almost twice as stable as 32-bit engines when handling typical web content. Finally, on 64-bit, our defense in depth security mitigations such as Partition Alloc are able to far more effectively defend against vulnerabilities that rely on controlling the memory layout of objects. The full changelog.
Security

Google Forks OpenSSL, Announces BoringSSL 128

Posted by Soulskill
from the if-you-want-something-done-right dept.
An anonymous reader writes Two months after OpenBSD's LibReSSL was announced, Adam Langley introduces Google's own fork of OpenSSL, called BoringSSL. "[As] Android, Chrome and other products have started to need some subset of these [OpenSSL] patches, things have grown very complex. The effort involved in keeping all these patches (and there are more than 70 at the moment) straight across multiple code bases is getting to be too much. So we're switching models to one where we import changes from OpenSSL rather than rebasing on top of them. The result of that will start to appear in the Chromium repository soon and, over time, we hope to use it in Android and internally too." First reactions are generally positive. Theo de Raadt comments, "Choice is good!!."
Networking

PHK: HTTP 2.0 Should Be Scrapped 220

Posted by Unknown Lamer
from the just-give-up dept.
Via the HTTP working group list comes a post from Poul-Henning Kamp proposing that HTTP 2.0 (as it exists now) never be released after the plan of adopting Google's SPDY protocol with minor changes revealed flaws that SPDY/HTTP 2.0 will not address. Quoting: "The WG took the prototype SPDY was, before even completing its previous assignment, and wasted a lot of time and effort trying to goldplate over the warts and mistakes in it. And rather than 'ohh, we get HTTP/2.0 almost for free', we found out that there are numerous hard problems that SPDY doesn't even get close to solving, and that we will need to make some simplifications in the evolved HTTP concept if we ever want to solve them. ... Wouldn't we get a better result from taking a much deeper look at the current cryptographic and privacy situation, rather than publish a protocol with a cryptographic band-aid which doesn't solve the problems and gets in the way in many applications ? ... Isn't publishing HTTP/2.0 as a 'place-holder' is just a waste of everybody's time, and a needless code churn, leading to increased risk of security exposures and failure for no significant gains ?"
Encryption

30-Day Status Update On LibreSSL 164

Posted by Soulskill
from the all-the-hyperlinks-you-can-handle dept.
ConstantineM writes: "Bob Beck — OpenBSD, OpenSSH and LibreSSL developer and the director of Alberta-based non-profit OpenBSD Foundation — gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing for a drop-in replacement, without the #ifdef spaghetti and without its own "OpenSSL C" dialect.

Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.

To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation."
Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.
Programming

GitHub Open Sources Atom, Their Text Editor Based On Chromium 121

Posted by Unknown Lamer
from the emacs-does-it-better dept.
First time accepted submitter aojensen (1503269) writes "GitHub has made good on promises to open source Atom, a programmer's text editor based on Chromium. Atom is released under the MIT license (source repository). GitHub announced the following on their blog: 'Because we spend most of our day in a text editor, the single most important feature we wanted in an editor was extensibility. Atom is built with the same open source technologies used by modern web browsers. ... But more importantly, extending Atom is as simple as writing JavaScript and CSS, two languages used by millions of developers each day.'

Apart from being extensible via HTML, JavaScript, and CSS, Atom also offers out-of-the-box Node.js integration, a modular design with a built-in package manager (apm), and extensive features such as file system browser, themes, project-wide search and replace, panes, snippets, code folding, and more. Launched only 10 weeks ago, Atom seems to have a well-established ecosystem of packages and extensions already."
The editor is based on atom-shell, a more general framework for building desktop apps using JavaScript/HTML. Beware: according to the FAQ, by default it sends "usage data" to Google Analytics (which can be disabled at least).
Security

Heartbleed Disclosure Timeline Revealed 62

Posted by samzenpus
from the when-did-you-know dept.
bennyboy64 (1437419) writes "Ever since the Heartbleed flaw in OpenSSL was made public there have been various questions about who knew what and when. The Sydney Morning Herald has done some analysis of public mailing lists and talked to those involved with disclosing the bug to get the bottom of it. The newspaper finds that Google discovered Heartbleed on or before March 21 and notified OpenSSL on April 1. Other key dates include Finnish security testing firm Codenomicon discovering the flaw independently of Google at 23:30 PDT, April 3. SuSE, Debian, FreeBSD and AltLinux all got a heads up from Red Hat about the flaw in the early hours of April 7 — a few hours before it was made public. Ubuntu, Gentoo and Chromium attempted to get a heads up by responding to an email with few details about it but didn't, as the guy at Red Hat sending the disclosure messages out in India went to bed. By the time he woke up, Codenomicon had reported the bug to OpenSSL."