Slashdot Mirror

Remember when Microsoft announced they'd be switching to Google's open source Chromium browser for developing their own Edge browser? At the time Google announced "We look forward to working with Microsoft and the web standards community to advance the open web, support user choice, and deliver great browsing experiences."

Now MSPoweruser reports Microsoft has indeed started collaborating on Chromium -- making suggestions like caret browsing and a native high-contrast mode -- and at least one of Microsoft's suggestions is already coming to Chrome. it looks like there is one feature that Chromium approved which will be making its way to Chrome soon. According to a new bug (via Techdows) filing on Chromium, Google is working on bringing text suggestions for hardware keyboard to Chrome soon. The feature will allow users to get suggestions as they type which is currently available on Windows 10 and on Microsoft Edge.

Google has just started working on the feature and has set the priority to 2 which suggests that the feature should be available sooner than later.

Google's bug-hunting researchers known as Project Zero have revealed a fresh zero-day vulnerability in macOS called "BuggyCow." "The attack takes advantage of an obscure oversight in Apple's protections on its machines' memory to enable so-called privilege escalation, allowing a piece of malware with limited privileges to, in some cases, pierce into deeper, far more trusted parts of a victim's Mac," reports Wired. "The trick's name is based on a loophole the hackers found in the so-called copy-on-write, or CoW, protection built into how MacOS manages a computer's memory." From the report: Some programs, when dealing with large quantities of data, use an efficiency trick that leaves data on a computer's hard drive rather than potentially clog up resources by pulling it into memory. That data, like any data in a computer's memory, can sometimes be used by multiple processes at once. The MacOS memory manager keeps a map of its physical location to help coordinate, but if one of those processes tries to change the data, the memory manager's copy-on-write safeguard requires it to make its own copy. Which is to say, a program can't simply change the data shared by all the other processes -- some of which could be more highly privileged, sensitive programs than the one requesting the change.

Google's BuggyCow trick, however, takes advantage of the fact that when a program mounts a new file system on a hard drive -- basically loading a whole collection of files rather than altering just one -- the memory manager isn't warned. So a hacker can unmount a file system, remount it with new data, and in doing so silently replace the information that some sensitive, highly privileged code is using. Technically, as a zero-day vulnerability with no patch in sight, BuggyCow applies to anyone with an Apple laptop or desktop. But given the technical skill and access needed to pull it off, you shouldn't lose much sleep over it. To even start carrying out this Rube Goldberg -- style attack, a hacker would need a victim to already have some form of malware running on their computer. And while BuggyCow would allow that malware to potentially mess with the inner workings of higher-privileged parts of the computer, it could do so only if it found a highly privileged program that kept its sensitive data on the hard drive rather than memory. Project Zero says it warned Apple about BuggyCow back in November, but Apple hadn't acted to patch it ahead of last week's public reveal.

An anonymous reader writes: Microsoft's Edge browser contains a secret whitelist that lets Facebook run Adobe Flash code behind users' backs. The whitelist allows Facebook's Flash content to bypass Edge security features such as the click-to-play policy that normally prevents websites from running Flash code without user approval beforehand.

The whitelist isn't new. It existed in Edge before, and prior to February 2018, it included 58 entries, including domains and subdomains for Microsoft's main site, the MSN portal, music streaming service Deezer, Yahoo, and Chinese social network QQ. The list was narrowed down to only two Facebook domains (facebook.com and apps.facebook.com) after a Google security researcher found that the whitelist mechanism had some security issues. The bug report also contains the original version of the whitelist, with all the 58 domains.

"Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including various ad blockers," reports The Register. "The drafted changes will also limit the capabilities available to extension developers, ostensibly for the sake of speed and safety. Chromium forms the central core of Google Chrome, and, soon, Microsoft Edge." From the report: In a note posted Tuesday to the Chromium bug tracker, Raymond Hill, the developer behind uBlock Origin and uMatrix, said the changes contemplated by the Manifest v3 proposal will ruin his ad and content blocking extensions, and take control of content away from users. Manifest v3 refers to the specification for browser extension manifest files, which enumerate the resources and capabilities available to browser extensions. Google's stated rationale for making the proposed changes is to improve security, privacy and performance, and supposedly to enhance user control.

But one way Google would like to achieve these goals involves replacing the webRequest API with a new one, declarativeNetRequest. The webRequest API allows extensions to intercept network requests, so they can be blocked, modified, or redirected. This can cause delays in web page loading because Chrome has to wait for the extension. In the future, webRequest will only be able to read network requests, not modify them. The declarativeNetRequest allows Chrome (rather than the extension itself) to decide how to handle network requests, thereby removing a possible source of bottlenecks and a potentially useful mechanism for changing browser behavior. The report notes that Adblock Plus "should still be available" since "Google and other internet advertising networks apparently pay Adblock Plus to whitelist their online adverts."

An anonymous reader shares a report: Chrome OS was originally a laptop platform, but slowly it's being reworked for tablet form factors. However, as that goes on, there have been some hiccups. Most recently, many have noted the poor performance of tablet mode especially on Chrome OS products like the Pixel Slate, but it seems a fix for that lag is incoming. If you tuned into any hands-on or review coverage of Google's Pixel Slate, you're likely familiar with the performance issues many have described. In tablet mode, Chrome OS has a lot of issues with lag. This is especially evident in the multitasking screen, and it seems that is the first thing Google is looking at to fix these problems. ChromeUnboxed notes a recent bug tracker which reveals how Google plans to start fixing Chrome OS tablet mode lag in the multitasking screen. Somewhat hilariously, it seems a big reason for the poor frame rates in the animations on this screen actually comes down to how the OS renders the rounded corners on this screen.

If you're a tab-hoarder, and you use Chrome browser, Google may have some news for you soon. The company is working on a scrollable tabstrip to make it easier for users to navigate through tabs, a developer was quoted as saying. Peter Casting, who works on Chrome UI, said, "scrollable tabstrip is in the works. In the meantime, try shift-clicking and ctrl-clicking to select multiple tabs at once, then drag out to separate Windows to group tabs by Window." TechDows, which first reported the development: We're expecting this as the related bug, the 'UI: tab overflow' bug created 10 years back, reports opening too many tabs causes add tab button (+) to disappear and tabs do not scroll then, the expected result has been mentioned as 'scrollable tabs.' Further reading: Google is raiding Firefox for Chrome's next UI features.

"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.

"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.

An anonymous reader quotes Digital Trends: With the launch of Chrome 69, Google stunned users last week with a surprising decision to no longer display the "www" and "m" part of the URL in the Chrome search bar, but user backlash forced Google to soften its stance. Google's course reversal, although welcomed by users, is only short term, and the search giant said it will change course once again with the release of the Chrome 70 browser....

Critics have argued that by not displaying the special-case subdomains, it was harder for users to identify sites as legitimate, and the move could lead to more scams on the internet. Others go as far as questioning Google's motives for not displaying the "www" and "m" portion of a web address, and these users speculated that the move may be to disguise Google's AMP -- or Accelerated Mobile Pages -- subdomain to make it indistinguishable for the actual domain....

With the launch of Chrome 70, Google plans on hiding the 'www' portion of a web address inside the search bar, but it will continue to display the 'm' subdomain. "We are not going to elide 'm' in M70 because we found large sites that have a user-controlled 'm' subdomain," Google Chromium product manager Emily Schecter said. "There is more community consensus that sites should not allow the 'www' subdomain to be user controlled."
ZDNet notes that while Chrome's billion-plus users were surprised, "Apple's Safari likewise hides the www and m but it hasn't caused as much concern, likely because of Google's outsized influence over the web and Chrome's dominance of the browser market."

TechRepublic quotes a community feedback post that had argued that "Lying about the hostname to novices and power users alike in the name of simplifying the UI seems imprudent from a security perspective."

An anonymous reader quotes ITWire: Google's move to strip out the www in domains typed into the address bar, beginning with version 69 of its Chrome browser, has drawn an enormous amount of criticism from developers who see the move as a bid to cement the company's dominance of the Web. The criticism comes a few days after Chrome's engineering manager Adrienne Porter Felt told the American website Wired that URLs need to be got rid of altogether. The change in Chrome version 69 means that if one types in a domain such as www.itwire.com into the browser search bar, the www portion is stripped out in the address bar when the page is displayed.

When asked about this change in a long discussion thread on a mailing list, a Google staffer wrote: "www is now considered a 'trivial' subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)..." A Google staffer attempted to justify the change, writing: "The subdomains reappear when editing the URL so people type the correct one. They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases..." But this drew an angry response from a poster who questioned the statement "this isn't information that most users need to concern themselves with in most cases" and asked: "According to who? This is simply an opinion stated as a fact...."

This is not the first time Google has been criticised for its moves to change the fundamental structure of URLs. Its Accelerated Mobile Pages, introduced in October 2015, have been criticised for obscuring the original URL of a page and reducing the chances of a reader going back to the original website. Probably for this reason, Apple last year decided that version 11 of iOS would update its Safari browser so that AMP links would be stripped out of an URL when the story was shared... "This is Google making subdomain usage decisions for other entities outside of Google," said yet another poster. "My domains and how subdomains are assigned and delegated are not Google's business to decide."
The controversy moved Slashdot reader Lauren Weinstein to write a new blog post. Its title? "Here's How to Disable Google Chrome's Confusing New URL Hiding Scheme."

UPDATE (9/15/18): Google has announced that after public outcry, they'll return the 'www' to Chrome's URL's -- but only until the next release.

An anonymous reader quotes ITWire: Google's move to strip out the www in domains typed into the address bar, beginning with version 69 of its Chrome browser, has drawn an enormous amount of criticism from developers who see the move as a bid to cement the company's dominance of the Web. The criticism comes a few days after Chrome's engineering manager Adrienne Porter Felt told the American website Wired that URLs need to be got rid of altogether. The change in Chrome version 69 means that if one types in a domain such as www.itwire.com into the browser search bar, the www portion is stripped out in the address bar when the page is displayed.

When asked about this change in a long discussion thread on a mailing list, a Google staffer wrote: "www is now considered a 'trivial' subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)..." A Google staffer attempted to justify the change, writing: "The subdomains reappear when editing the URL so people type the correct one. They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases..." But this drew an angry response from a poster who questioned the statement "this isn't information that most users need to concern themselves with in most cases" and asked: "According to who? This is simply an opinion stated as a fact...."

This is not the first time Google has been criticised for its moves to change the fundamental structure of URLs. Its Accelerated Mobile Pages, introduced in October 2015, have been criticised for obscuring the original URL of a page and reducing the chances of a reader going back to the original website. Probably for this reason, Apple last year decided that version 11 of iOS would update its Safari browser so that AMP links would be stripped out of an URL when the story was shared... "This is Google making subdomain usage decisions for other entities outside of Google," said yet another poster. "My domains and how subdomains are assigned and delegated are not Google's business to decide."
The controversy moved Slashdot reader Lauren Weinstein to write a new blog post. Its title? "Here's How to Disable Google Chrome's Confusing New URL Hiding Scheme."

UPDATE (9/15/18): Google has announced that after public outcry, they'll return the 'www' to Chrome's URL's -- but only until the next release.

An anonymous reader quotes ITWire: Google's move to strip out the www in domains typed into the address bar, beginning with version 69 of its Chrome browser, has drawn an enormous amount of criticism from developers who see the move as a bid to cement the company's dominance of the Web. The criticism comes a few days after Chrome's engineering manager Adrienne Porter Felt told the American website Wired that URLs need to be got rid of altogether. The change in Chrome version 69 means that if one types in a domain such as www.itwire.com into the browser search bar, the www portion is stripped out in the address bar when the page is displayed.

When asked about this change in a long discussion thread on a mailing list, a Google staffer wrote: "www is now considered a 'trivial' subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)..." A Google staffer attempted to justify the change, writing: "The subdomains reappear when editing the URL so people type the correct one. They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases..." But this drew an angry response from a poster who questioned the statement "this isn't information that most users need to concern themselves with in most cases" and asked: "According to who? This is simply an opinion stated as a fact...."

This is not the first time Google has been criticised for its moves to change the fundamental structure of URLs. Its Accelerated Mobile Pages, introduced in October 2015, have been criticised for obscuring the original URL of a page and reducing the chances of a reader going back to the original website. Probably for this reason, Apple last year decided that version 11 of iOS would update its Safari browser so that AMP links would be stripped out of an URL when the story was shared... "This is Google making subdomain usage decisions for other entities outside of Google," said yet another poster. "My domains and how subdomains are assigned and delegated are not Google's business to decide."
The controversy moved Slashdot reader Lauren Weinstein to write a new blog post. Its title? "Here's How to Disable Google Chrome's Confusing New URL Hiding Scheme."

UPDATE (9/15/18): Google has announced that after public outcry, they'll return the 'www' to Chrome's URL's -- but only until the next release.

An anonymous reader quotes ITWire: Google's move to strip out the www in domains typed into the address bar, beginning with version 69 of its Chrome browser, has drawn an enormous amount of criticism from developers who see the move as a bid to cement the company's dominance of the Web. The criticism comes a few days after Chrome's engineering manager Adrienne Porter Felt told the American website Wired that URLs need to be got rid of altogether. The change in Chrome version 69 means that if one types in a domain such as www.itwire.com into the browser search bar, the www portion is stripped out in the address bar when the page is displayed.

When asked about this change in a long discussion thread on a mailing list, a Google staffer wrote: "www is now considered a 'trivial' subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)..." A Google staffer attempted to justify the change, writing: "The subdomains reappear when editing the URL so people type the correct one. They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases..." But this drew an angry response from a poster who questioned the statement "this isn't information that most users need to concern themselves with in most cases" and asked: "According to who? This is simply an opinion stated as a fact...."

This is not the first time Google has been criticised for its moves to change the fundamental structure of URLs. Its Accelerated Mobile Pages, introduced in October 2015, have been criticised for obscuring the original URL of a page and reducing the chances of a reader going back to the original website. Probably for this reason, Apple last year decided that version 11 of iOS would update its Safari browser so that AMP links would be stripped out of an URL when the story was shared... "This is Google making subdomain usage decisions for other entities outside of Google," said yet another poster. "My domains and how subdomains are assigned and delegated are not Google's business to decide."
The controversy moved Slashdot reader Lauren Weinstein to write a new blog post. Its title? "Here's How to Disable Google Chrome's Confusing New URL Hiding Scheme."

UPDATE (9/15/18): Google has announced that after public outcry, they'll return the 'www' to Chrome's URL's -- but only until the next release.

Since the release of Chrome 69 earlier this week, countless of users have gone on social media and Google Product Forums to complain about "blurry" or "fuzzy" text inside Chrome. ZDNet: The blurred font issue isn't only limited to text rendered inside a web page, users said, but also for the text suggestions displayed inside the address bar search drop-down, and Chrome's Developer Tools panel. [...] According to reports, the issue only manifests for Chrome 69 users on Windows. Those who rolled back to Chrome 68 stopped having problems. Users said that changing Chrome, operating system, or screen DPI settings didn't help. "Our team is investigating reports of this behavior. You can find more information in this public bug report," a Google spokesperson said last night after first user complaints started surfacing online. Some users have also expressed concerns over Chrome not showing "trivial subdomains" including www and secure lock sign in the address bar.

An anonymous reader writes: "Google has patched a vulnerability in the Chrome browser that allows an attacker to retrieve sensitive information from other sites via audio or video HTML tags," reports Bleeping Computer. The attack breaks CORS -- Cross-Origin Resource Sharing, a browser security feature that prevents sites from loading resources from other websites -- and will attempt to load resources (some of which can reveal information about users) inside audio and video HTML tags. During tests, a researcher retrieved age and gender information from Facebook users, but another researcher says the bug can be also used to retrieve data from corporate backends or private APIs. Ron Masas, a security researcher with Imperva, first discovered and reported this issue to Google. The bug was fixed at the end of July with the release of Chrome v68.0.3440.75.

An anonymous reader writes: "The Mozilla Foundation, the organization behind the Firefox browser, is working on adding a new feature to its browser that is similar to the Site Isolation feature that Google rolled out to Chrome users this year," reports Bleeping Computer. "[Chrome's] Site Isolation works by opening a new browser process for any domain/site the user loads in a tab." The feature has been recently rolled out to 99% of the Chrome userbase. "But Chrome won't be the only browser with Site Isolation," adds Bleeping Computer. "Work on a similar feature also began at Mozilla headquarters back in April, in a plan dubbed Project Fission." Mozilla engineers say that before rolling out Project Fission (Site Isolation), they need to optimize Firefox's memory usage first. Work has now started on shaving off 7MB of RAM from each Firefox content process in order to bring down per-process RAM usage to around 10MB, a limit Mozilla deems sustainable for rolling out Site Isolation.

An anonymous reader quotes a report from The Register: A remote-code execution vulnerability in Windows Defender -- a flaw that can be exploited by malicious .rar files to run malware on PCs -- has been traced back to an open-source archiving tool Microsoft adopted for its own use. The bug, CVE-2018-0986, was patched on Tuesday in the latest version of the Microsoft Malware Protection Engine (1.1.14700.5) in Windows Defender, Security Essentials, Exchange Server, Forefront Endpoint Protection, and Intune Endpoint Protection. This update should be installed, or may have been automatically installed already on your device. The vulnerability can be leveraged by an attacker to achieve remote code execution on a victim's machine simply by getting the mark to download -- via a webpage or email or similar -- a specially crafted .rar file while the anti-malware engine's scanning feature is on. In many cases, this analysis set to happen automatically.

When the malware engine scans the malicious archive, it triggers a memory corruption bug that leads to the execution of evil code smuggled within the file with powerful LocalSystem rights, granting total control over the computer. The screwup was discovered and reported to Microsoft by legendary security researcher Halvar Flake, now working for Google. Flake was able to trace the vulnerability back to an older version of unrar, an open-source archiving utility used to unpack .rar archives. Apparently, Microsoft forked that version of unrar and incorporated the component into its operating system's antivirus engine. That forked code was then modified so that all signed integer variables were converted to unsigned variables, causing knock-on problems with mathematical comparisons. This in turn left the software vulnerable to memory corruption errors, which can crash the antivirus package or allow malicious code to potentially execute.

An anonymous reader writes: A Google security researcher has found and helped patch a severe vulnerability in Keeper, a password manager application that Microsoft has been bundling with some Windows 10 distributions this year... "This is a complete compromise of Keeper security, allowing any website to steal any password," Tavis Ormandy, the Google security researcher said, pointing out that the password manager was still vulnerable to a same vulnerability he reported in August 2016, which had apparently been reintroduced in the code.

Based on user reports, Microsoft appears to have been bundling Keeper as part of Windows 10 Pro distributions since this past summer.
The article reports that Keeper issued a fix -- browser extension version 11.4 -- within less than 24 hours.

An anonymous reader writes: A Google security researcher has found and helped patch a severe vulnerability in Keeper, a password manager application that Microsoft has been bundling with some Windows 10 distributions this year... "This is a complete compromise of Keeper security, allowing any website to steal any password," Tavis Ormandy, the Google security researcher said, pointing out that the password manager was still vulnerable to a same vulnerability he reported in August 2016, which had apparently been reintroduced in the code.

Based on user reports, Microsoft appears to have been bundling Keeper as part of Windows 10 Pro distributions since this past summer.
The article reports that Keeper issued a fix -- browser extension version 11.4 -- within less than 24 hours.

In April Chrome began marking HTTP pages as "not secure" in its address bar if the pages had password or credit card fields. They're about to take the next step. An anonymous reader quotes SearchEngineLand: Last night, Google sent email notifications via Google Search Console to site owners that have forms on web pages over HTTP... Google said, "Beginning in October 2017, Chrome will show the 'Not secure' warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode."
Google warned in April that "Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we're ready to take the next steps..."

"Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the 'Not secure' warning when users type data into HTTP sites."

New submitter aafrn writes: "Ran Bar-Zik, a web developer at AOL, has discovered and reported a bug in Google Chrome that allows websites to record audio and video without showing a visual indicator," reports BleepingComputer. "The bug is not as bad as it sounds, as the malicious website still needs to get the user's permission to access audio and video components, but there are various ways in which this issue could be weaponized to record audio or video without the user's knowledge. The bug's central element is a 'red circle and dot' icon that Chrome usually shows when recording audio or video streams." Bar-Zik discovered that if the JavaScript code that does the actual audio and video recording is launched inside a small popup, the icon is not shown anymore. This opens the door for various types of scenarios, where an attacker that has tricked a user into granting him permission to record audio and video records user data but when the user doesn't expect this (no visual indicator). For example, an attacker could disguise audio/video recording code inside popup ads. If the user doesn't close the popup, the popup continues to stream audio and video from the victim's house. Google declined to consider this a security bug.

An anonymous reader writes: "Over the past decade, ambient light sensors have become quite common in smartphones, tablets, and laptops, where they are used to detect the level of surrounding light and automatically adjust a screen's intensity to optimize battery consumption... and other stuff," reports Bleeping Computer. "The sensors have become so prevalent, that the World Wide Web Consortium (W3C) has developed a special API that allows websites (through a browser) to interact with a device's ambient light sensors. Browsers such as Chrome and Firefox have already shipped versions of this API with their products." According to two privacy and security experts, Lukasz Olejnik and Artur Janc, malicious web pages can launch attacks using this new API and collect data on users, such as URLs they visited in the past and extract QR codes displayed on the screen. This is possible because the light coming from the screen is picked up by these sensors. Mitigating such attacks is quite easy, as it only requires browser makers and the W3C to adjust the default frequency at which the sensors report their readings. Furthermore, the researcher also recommends that browser makers quantize the result by limiting the precision of the sensor output to only a few values in a preset range. The two researchers filed bug reports with both Chrome and Firefox in the hopes their recommendations will be followed.

An anonymous reader quotes a report from Ars Technica: A broad array of Android phones is vulnerable to attacks that use booby-trapped Wi-Fi signals to achieve full device takeover, a researcher has demonstrated. The vulnerability resides in a widely used Wi-Fi chipset manufactured by Broadcom and used in both iOS and Android devices. Apple patched the vulnerability with Monday's release of iOS 10.3.1. "An attacker within range may be able to execute arbitrary code on the Wi-Fi chip," Apple's accompanying advisory warned. In a highly detailed blog post published Tuesday, the Google Project Zero researcher who discovered the flaw said it allowed the execution of malicious code on a fully updated 6P "by Wi-Fi proximity alone, requiring no user interaction." Google is in the process of releasing an update in its April security bulletin. The fix is available only to a select number of device models, and even then it can take two weeks or more to be available as an over-the-air update to those who are eligible. Company representatives didn't respond to an e-mail seeking comment for this post. The proof-of-concept exploit developed by Project Zero researcher Gal Beniamini uses Wi-Fi frames that contain irregular values. The values, in turn, cause the firmware running on Broadcom's wireless system-on-chip to overflow its stack. By using the frames to target timers responsible for carrying out regularly occurring events such as performing scans for adjacent networks, Beniamini managed to overwrite specific regions of device memory with arbitrary shellcode. Beniamini's code does nothing more than write a benign value to a specific memory address. Attackers could obviously exploit the same series of flaws to surreptitiously execute malicious code on vulnerable devices within range of a rogue access point.

An anonymous reader writes: Chromium engineers are discussing plans to change how JavaScript popups work inside Chrome and other similar browsers. In a proposal published on the Google Developers portal, the Chromium team acknowledged that JavaScript popups are consistently used to harm users.

To combat this threat, Google engineers say they plan to make JavaScript modals, like the alert(), confirm(), and dialog() methods, only work on a per-tab basis, and not per-window. This change means that popups won't block users from switching and closing the tab, putting an end to any overly-aggresive tactics on the part of the website's owner(s).

There is no timeline on Google's decision to move JavaScript popups to a per-tab model, but Chromium engineers have been debating this issue since July 2016 as part of Project OldSpice. A similar change was made to Safari 9.1, released this week. Apple's decision came after crooks used a bug in Safari to block users on malicious pages using popups. Crooks then tried to extort payment, posing as ransomware.

Earlier this month, a Slashdot reader asked fellow Slashdotters what they recommended regarding the use of password managers. In their post, they voiced their uncertainty with password managers as they have been hacked in the past, citing an incident in early 2016 where LastPass was hacked due to a bug that allowed users to extract passwords stored in the autofill feature. Flash forward to present time and we now have news that three separate bugs "would have allowed a third-party to extract passwords from users visiting a malicious website." An anonymous Slashdot reader writes via BleepingComputer: LastPass patched three bugs that affected the Chrome and Firefox browser extensions, which if exploited, would have allowed a third-party to extract passwords from users visiting a malicious website. All bugs were reported by Google security researcher Tavis Ormandy, and all allowed the theft of user credentials, one bug affecting the LastPass Chrome extension, while two impacted the LastPass Firefox extension [1, 2]. The exploitation vector was malicious JavaScript code that could be very well hidden in any online website, owned by the attacker or via a compromised legitimate site.

Earlier this month, a Slashdot reader asked fellow Slashdotters what they recommended regarding the use of password managers. In their post, they voiced their uncertainty with password managers as they have been hacked in the past, citing an incident in early 2016 where LastPass was hacked due to a bug that allowed users to extract passwords stored in the autofill feature. Flash forward to present time and we now have news that three separate bugs "would have allowed a third-party to extract passwords from users visiting a malicious website." An anonymous Slashdot reader writes via BleepingComputer: LastPass patched three bugs that affected the Chrome and Firefox browser extensions, which if exploited, would have allowed a third-party to extract passwords from users visiting a malicious website. All bugs were reported by Google security researcher Tavis Ormandy, and all allowed the theft of user credentials, one bug affecting the LastPass Chrome extension, while two impacted the LastPass Firefox extension [1, 2]. The exploitation vector was malicious JavaScript code that could be very well hidden in any online website, owned by the attacker or via a compromised legitimate site.

Earlier this month, a Slashdot reader asked fellow Slashdotters what they recommended regarding the use of password managers. In their post, they voiced their uncertainty with password managers as they have been hacked in the past, citing an incident in early 2016 where LastPass was hacked due to a bug that allowed users to extract passwords stored in the autofill feature. Flash forward to present time and we now have news that three separate bugs "would have allowed a third-party to extract passwords from users visiting a malicious website." An anonymous Slashdot reader writes via BleepingComputer: LastPass patched three bugs that affected the Chrome and Firefox browser extensions, which if exploited, would have allowed a third-party to extract passwords from users visiting a malicious website. All bugs were reported by Google security researcher Tavis Ormandy, and all allowed the theft of user credentials, one bug affecting the LastPass Chrome extension, while two impacted the LastPass Firefox extension [1, 2]. The exploitation vector was malicious JavaScript code that could be very well hidden in any online website, owned by the attacker or via a compromised legitimate site.

An anonymous reader quotes BleepingComputer: Google has gone public with details of a second unpatched vulnerability in Microsoft products, this time in Edge and Internet Explorer, after last week they've published details about a bug in the Windows GDI (Graphics Device Interface) component... The bug, discovered by Google Project Zero researcher Ivan Fratric, is tracked by the CVE-2017-0037 identifier and is a type confusion, a kind of security flaw that can allow an attacker to execute code on the affected machine, and take over a device.

Details about CVE-2017-0037 are available in Google's bug report, along with proof-of-concept code. The PoC code causes a crash of the exploited browser, but depending on the attacker's skill level, more dangerous exploits could be built... Besides the Edge and IE bug, Microsoft products are also plagued by two other severe security flaws, one affecting the Windows GDI component and one the SMB file sharing protocol shipped with all Windows OS versions...
Google's team notified Microsoft of the bug 90 days ago, only disclosing it publicly on Friday.

ShaunC writes: In a bug that's been christened "Cloudbleed," Cloudflare disclosed today that some of their products accidentally exposed private user information from a number of websites. Similar to 2014's Heartbleed, Cloudflare's problem involved a buffer overrun that allowed uninitialized memory contents to leak into normal web traffic. Tavis Ormandy, of Google's Project Zero, discovered the flaw last week. Affected sites include Uber, Fitbit, and OK Cupid, as well as unnamed services for hotel booking and password management. Cloudflare says the bug has been fixed, and Google has purged affected pages from its search index and cache. Further reading: The Register, Ars Technica

An anonymous reader writes: "For the second time in three months, Google engineers have disclosed a bug in the Windows OS without Microsoft having released a fix before Google's announcement," reports BleepingComputer. "The bug in question affects the Windows GDI (Graphics Device Interface) (gdi32.dll)..." According to Google, the issue allows an attacker to read the content of the user's memory using malicious EMF files. The bad news is that the EMF file can be hidden in other documents, such as DOCX, and can be exploited via Office, IE, or Office Online, among many.

"According to a bug report filed by Google's Project Zero team, the bug was initially part of a larger collection of issues discovered in March 2016, and fixed in June 2016, via Microsoft's security bulletin MS16-074. Mateusz Jurczyk, the Google engineer who found the first bugs, says the MS16-074 patches were insufficient, and some of the issues he reported continued to remain vulnerable." He later resubmitted the bugs in November 2016. The 90-days deadline for fixing the bugs expired last week, and the Google researcher disclosed the bug to the public after Microsoft delayed February's security updates to next month's Patch Tuesday, for March 15.
Microsoft has described Google's announcements of unpatched Windows bugs as "disappointing".

Yaron Friedman, a software engineer at Google, writes on Chromium blog: In 2015, we added a new feature to Chrome for Android that allows developers to prompt users to add their site to the Home screen for fast and convenient access. That feature uses an Android shortcut, which means that web apps don't show up throughout Android in the same way as installed native apps. In the next few weeks we'll be rolling out a new version of this experience in Chrome beta. With this new version, once a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way than before. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

JustAnotherOldGuy quotes a report from Boing Boing: The World Wide Web Consortium's Encrypted Media Extensions (EME) is a DRM system for web video, being pushed by Netflix, movie studios, and a few broadcasters. It's been hugely controversial within the W3C and outside of it, but one argument that DRM defenders have made throughout the debate is that the DRM is optional, and if you don't like it, you don't have to use it. That's not true any more. Some time in the past few days, Google quietly updated Chrome (and derivative browsers like Chromium) so that Widevine (Google's version of EME) can no longer be disabled; it comes switched on and installed in every Chrome instance. Because of laws like section 1201 of the U.S. Digital Millennium Copyright Act (and Canada's Bill C11, and EU implementations of Article 6 of the EUCD), browsers that have DRM in them are risky for security researchers to audit. These laws provide both criminal and civil penalties for those who tamper with DRM, even for legal, legitimate purposes, and courts and companies have interpreted this to mean that companies can punish security researchers who reveal defects in their products. Further reading: Boing Boing and Hacker News.

Google announced in a blog post today that it will be rolling out a feature over the next few months that starts disabling Flash and displaying HTML5 content instead on certain websites. Google notes, "This change disables Adobe Flash Player unless there's a user indication that they want Flash content on specific sites, and eventually all websites will require the user's permission to run Flash." VentureBeat reports: Google has deployed the change for half of the people who are using Chrome 56 beta, which rolled out yesterday, Google technical program manager Eric Deily wrote in a blog post. Then, "in the next few days," Deily wrote, the feature will be active for 1 percent of users of Chrome 55 stable. And by February 2016 it will be live for all users in Chrome 56 stable, Deily wrote. The idea is to lessen the dependence on a web component that can cause a drag on CPU and memory usage and shorten battery life as a result. Flash also has a track record of security issues.

An anonymous reader quotes a report from VentureBeat: Google today announced plans to kill off Chrome apps for Windows, Mac, and Linux in early 2018. Chrome extensions and themes will not be affected, while Chrome apps will continue to live on in Chrome OS. Here's the deprecation timeline:

Late 2016: Newly published Chrome apps will not be available to Windows, Mac, and Linux users (when developers submit apps to the Chrome Web Store, they will only show up for Chrome OS). Existing Chrome apps will remain available as they are today and developers can continue to update them.
Second half of 2017: The Chrome Web Store will no longer show Chrome apps on Windows, Mac, and Linux.
Early 2018: Chrome apps will not load on Windows, Mac, and Linux. There appears to be two main reasons why Google is killing Chrome apps off now. First, as Google explains in a blog post: "For a while there were certain experiences the web couldn't provide, such as working offline, sending notifications, and connecting to hardware. We launched Chrome apps three years ago to bridge this gap. Since then, we've worked with the web standards community to enable an increasing number of these use cases on the web. Developers can use powerful new APIs such as service worker and web push to build robust Progressive Web Apps that work across multiple browsers." Secondly, Chrome apps aren't very popular: "Today, approximately 1 percent of users on Windows, Mac and Linux actively use Chrome packaged apps, and most hosted apps are already implemented as regular web apps. Chrome on Windows, Mac, and Linux will therefore be removing support for packaged and hosted apps over the next two years."

An anonymous reader writes: Google Chrome is going to stop people from accidentally deleting everything they've been doing. A future version of the app will stop the backspace button from also functioning as a "back" button. The change has already been rolled out in some experimental versions of the app, and has upset some users. Developers have said that the feature is only being partly enabled for now, in case there is "sufficient outcry" and it needs to be rolled back. People regularly press the button thinking that they're deleting a word from a form, developers said, but then find that they weren't actually typing into that form and so accidentally go back, losing everything they've done.

An anonymous reader writes: On Friday, Google announced it is making changes to Chrome Web Store's User Data Policy to ensure developers are more transparent about how their extensions handle customer data. The company has notified developers and is giving them three months to comply with the changes. Come July 15, 2016, company says, extensions that violate the policy will be removed from the Chrome Web Store.The announcement comes amid a report that pointed out a rogue extension in the Chrome Web Store. The incident was one of many we have seen in the past few months. Following are the requirements that a developer must meet: 1. Be transparent about the handling of user data and disclose privacy practices. 2. Post a privacy policy and use encryption, when handling personal or sensitive information. 3. Ask users to consent to the collection of personal or sensitive data via a prominent disclosure, when the use of the data isn't related to a prominent feature.

An anonymous reader writes: Mozilla seems to think a new future for Firefox [lies in Chrome]. While they claim that it is only about new ways of browser design, it is also an open secret that they are running into more and more problems lately with web compatibility. [Senior VP Mark Mayo caused a storm by revealing that the Firefox team is working on a next-generation browser that will run on the same technology as Google's Chrome browser. The project, named Tofino, will not use Firefox's core technology, Gecko, but will instead plumb for Electron, which is built on the technology behind Google's rival Chrome browser, called Chromium.] The benefit of Chromium/Electron would be that it is a solution they could pull much faster forward than their own Servo plans [Servo being Mozilla's Rust-based web engine]. What the real outcome of all this will be, only Mozilla knows so far. But inside Mozilla there is much resistance against such plans... Interesting times are ahead.

jones_supa writes: Moving a big software project to a new compiler can be a lot of work, and few projects are bigger than the Chromium web browser. In addition to the main Chromium repository, which includes all of WebKit, there are over a hundred other open-source projects which Chromium incorporates by reference, totaling more than 48,000 C/C++ files and 40,000 header files. As of March 11th, Chromium has switched to Visual C++ 2015, and it doesn't look like it's looking back. The tracking bug for this effort currently has over 330 comments on it, with contributions from dozens of developers. Bruce Dawson has written an interesting showcase of some VC++ compiler bugs that the process has uncovered. His job was to investigate them, come up with a minimal reproduce case, and report them to Microsoft. The Google and Microsoft teams get praise for an excellent symbiotic relationship, and the compiler bugs have been fixed quickly by the Visual Studio team.

An anonymous reader writes: Google today announced it is removing the notification center from Chrome for Windows, Mac, and Linux. The reason the company is giving for the change is simple: "In practice, few users visit the notification center." The notification center in Chrome OS will remain. Google said this change will take effect for Windows, Mac, and Linux users "in the upcoming release." To be clear, this is not in reference to yesterday's Chrome 46 launch — the notification center is still there. We thus expect that the notification center will thus be removed in Chrome 47, which is slated to arrive in about six weeks.

An anonymous reader writes: I've been using Google Chrome almost exclusively for more than 3 years. I stopped using Mozilla Firefox because it was becoming bloated and slow, and I migrated all my bookmarks etc. to Chrome. Now Chrome plans to end NPAPI support — which means that I will not be able to access any sites that use Java, and I need this for work. I tried going back to Firefox for a couple of days but it still seems slow — starting it takes time, even the time taken to load a page seems more than Chrome. So what are my options now? Export all my bookmarks and go back to Mozilla Firefox and just learn to live with the performance drop? Or can I tweak Firefox performance in any way? FWIW, I am on a Windows 7 machine at work. Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.

jones_supa writes: After lots of work by Chrome for Android team and a huge change, Chrome for Android is now almost entirely open source, a Google engineer announced in Reddit. Over 100,000 lines of code, including Chrome's entire user interface layer, has been made public, allowing anyone with the inclination to do so to look at, modify, and build the browser from source. Licensing restrictions prevent certain media codecs, plugins and Google service features form being included, hence the "almost." This is on par with the open source Chromium browser that is available on the desktop.

An anonymous reader writes: I am interested in Chromebooks, for the reasons that Google successfully pushes them: my carry-around laptops serve mostly as terminals, rather than CPU-heavy workhorses, and for the most part the whole reason I'm on my computer is to do something that requires a network connection anyhow. My email is Gmail, and without particularly endorsing any one element, I've moved a lot of things to online services like DropBox. (Some offline capabilities are nice, but since actual Chromebooks have been slowly gaining offline stuff, and theoretically will gain a lot more of that, soon, I no longer worry much about a machine being "useless" if the upstream connection happens to be broken or absent. It would just be useless in the same way my conventional desktop machine would be.) I have some decent but not high-end laptops (Core i3, 2GB-4GB of RAM) that I'd enjoy repurposing as Chromebooks without pedigree: they'd fall somewhat short of the high-end Pixel, but at no out-of-pocket expense for me unless I spring for some cheap SSDs, which I might.

So: how would you go about making a Chromebook-like laptop? Yes, I could just install any Linux distro, and then restrain myself from installing most apps other than a browser and a few utilities, but that's not quite the same; ChromeOS is nicely polished, and very pared down; it also seems to do well with low-memory systems (lots of the current models have just 2GB, which brings many Linux distros to a disk-swapping crawl), and starts up nicely quick.

It looks like the most "authentic" thing would be to dive into building Chromium OS (which looks like a fun hobby), but I'd like to find something more like Cr OS — only Cr OS hasn't been updated in quite a while. Perhaps some other browser-centric pared-down Linux would work as well. How would you build a system? And should I go ahead and order some low-end 16GB SSDs, which I now see from online vendors for less than $25?

As reported by TechCrunch, "Google says it plans to propose HTTP2-over-QUIC to the IETF as a new Internet standard in the future," having disclosed a few days ago that about half of the traffic from Chrome browsers is using QUIC already. From the article: The name "QUIC" stands for Quick UDP Internet Connection. UDP's (and QUIC's) counterpart in the protocol world is basically TCP (which in combination with the Internet Protocol (IP) makes up the core communication language of the Internet). UDP is significantly more lightweight than TCP, but in return, it features far fewer error correction services than TCP. ... That's why UDP is great for gaming services. For these services, you want low overhead to reduce latency and if the server didn't receive your latest mouse movement, there's no need to spend a second or two to fix that because the action has already moved on. You wouldn't want to use it to request a website, though, because you couldn't guarantee that all the data would make it. With QUIC, Google aims to combine some of the best features of UDP and TCP with modern security tools.

An anonymous reader writes The next version of Firefox will roll out a 'pushed' blocklist of revoked intermediate security certificates, in an effort to avoid using 'live' Online Certificate Status Protocol (OCSP) checks. The 'OneCRL' feature is similar to Google Chrome's CRLSet, but like that older offering, is limited to intermediate certificates, due to size restrictions in the browser. OneCRL will permit non-live verification on EV certificates, trading off currency for speed. Chrome pushes its trawled list of CA revocations every few hours, and Firefox seems set to follow that method and frequency. Both Firefox and Chrome developers admit that OCSP stapling would be the better solution, but it is currently only supported in 9% of TLS certificates.

An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.

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."

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.

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."

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.

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 ?"