An anonymous reader writes: SafeBrowse, a Chrome extension with more than 140,000 users, contains an embedded JavaScript library in the extension's code that mines for the Monero cryptocurrency using users' computers and without getting their consent. The additional code drives CPU usage through the roof, making users' computers sluggish and hard to use.

Looking at the SafeBrowse extension's source code, anyone can easily spot the embedded Coinhive JavaScript Miner, an in-browser implementation of the CryptoNight mining algorithm used by CryptoNote-based currencies, such as Monero, Dashcoin, DarkNetCoin, and others. This is the same technology that The Pirate Bay experimented with as an alternative to showing ads on its site. The extension's author claims he was "hacked" and the code added without his knowledge.

An anonymous reader writes from a report via Bleeping Computer: The Project Zero team at Google has created a new tool for testing browser DOM engines and has unleashed it on today's top five browsers, finding most bugs in Apple's Safari. Results showed that Safari had by far the worst DOM engine, with 17 new bugs discovered after Fratric's test. Second was Edge with 6, then IE and Firefox with 4, and last was Chrome with only 2 new issues. The tests were carried out with a new fuzzing tool created by Google engineers named Domato, also open-sourced on GitHub. This is the third fuzzing tool Google creates and releases into open-source after OSS-Fuzz and syzkaller. Researchers focused on testing DOM engines for vulnerabilities because they expect them to be the next target for browser exploitation after Flash reaches end-of-life in 2020.

A member of Adobe's Product Security Incident Response Team (PSIRT) accidentally posted the PGP keys for PSIRT's email account -- both the public and the private keys. According to Ars Technica, "the keys have since been taken down, and a new public key has been posted in its stead." From the report: The faux pas was spotted at 1:49pm ET by security researcher Juho Nurminen. Nurminen was able to confirm that the key was associated with the psirt@adobe.com e-mail account. To be fair to Adobe, PGP security is harder than it should be. What obviously happened is that a PSIRT team member exported a text file from PSIRT's shared webmail account using Mailvelope, the Chrome and Firefox browser extension, to add to the team's blog. But instead of clicking on the "public" button, the person responsible clicked on "all" and exported both keys into a text file. Then, without realizing the error, the text file was cut/pasted directly to Adobe's PSIRT blog.

Between Google Chrome, Microsoft Edge, and Internet Explorer, Chrome has been found to be the most resilient against attacks, an analysis by security researchers has found. Firefox, Safari, and Opera were not included in the test. From a report: "Modern web browsers such as Chrome or Edge improved security in recent years. Exploitation of vulnerabilities is certainly more complex today and requires a higher skill than in the past. However, the attack surface of modern web browsers is increasing due to new technologies and the increasing complexity of web browsers themselves," noted Markus Vervier, Managing Director of German IT security outfit X41 D-Sec (and one of the researchers involved in the analysis). The researchers' aim was to determine which browser provides the highest level of security in common enterprise usage scenarios.

Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:

This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.

What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.

Starting next year, Google Chrome will only autoplay a given piece of content when the media won't play sound or the user has indicated an interest in the media. The company was experimenting with such an option last month, but now it looks to be part of the browser's roadmap. VentureBeat reports: Chrome 63 will add a new user option to completely disable audio for individual sites. This site-muting option will persist between browsing sessions, allowing users to customize when and where audio will play. Chrome 64 will take the controls to the next level. By this version, Google's browser will allow autoplay to occur only when users want media to play. Here is Google's timeline for making autoplaying sound more consistent with user expectations in Chrome: September 2017: Site muting available in Chrome 63 Beta, begin collecting Media Engagement Index (MEI) data in Chrome 62 Canary and Dev; October 2017: Site muting available in Chrome 63 Stable, autoplay policies available in Chrome 63 Canary and Dev; December 2017: Autoplay policies available in Chrome 64 Beta; January 2018: Autoplay policies available in 64 Stable.

Google engineer Mike West writes: As part of our ongoing effort to accurately communicate the transport security status of a given page, we're planning to label resources delivered over the FTP protocol as "Not secure", beginning in Chrome 63 (sometime around December, 2017). We didn't include FTP in our original plan, but unfortunately its security properties are actually marginally worse than HTTP (delivered in plaintext without the potential of an HSTS-like upgrade). Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month, and the real risk to users presented by non-secure transport, labeling it as such seems appropriate. We'd encourage developers to follow the example of the linux kernel archives by migrating public-facing downloads (especially executables!) from FTP to HTTPS.

After deciding to distrust Symantec's certificates in March, Google has decided to release a more detailed plan for how that process will go. Tom's Hardware reports: Starting with Chrome 66 (we're now at version 61), the browser will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Website operators that use Symantec certificates issued before that date should be looking to replace their certificates by April 2018, when Chrome 66 is expected to come out. Starting with Chrome 62 (next version), the built-in DevTools will also warn operators of Symantec certificates that will be distrusted in Chrome 66. After December 1, the new infrastructure managed by DigiCert will go into effect, and any new certificates issued by the old Symantec infrastructure will no longer be valid in Chrome. By November 2018, Chrome 70 will come out and will completely remove trust in all Symantec certificates that have ever been issued. Website operators can replace their old Symantec certificates with certificates from DigiCert from December 1 or from any other CA trusted by Google's Chrome browser.

An anonymous reader writes: Google Chrome 63 will include a new security feature that will detect when third-party software is performing a Man-in-the-Middle (MitM) attack that hijacks the user's Internet connection.... Most MitM toolkits fail to correctly rewrite the user's encrypted connections, causing SSL errors that Chrome will detect. The new Chrome 63 feature is in the form of a new warning screen. This new error will appear whenever Chrome detects a large number of SSL connection errors in a short timespan, a sign that someone is trying -- and failing -- to intercept the user's web traffic. This includes both malware and legitimate applications, such as antivirus and firewall applications. The new Chrome error won't show up for all antivirus and firewall software, but only for those that do not rewrite SSL connections in a proper way, resulting in SSL errors.
Chrome 63 is set for release on December 5, but users can already test it by enabling it in the Google Chrome dev branch.

An anonymous reader quotes a report from Bleeping Computer: Mozilla will drop an iconic section of its UI -- the search bar -- and will use one singular input bar atop the browser, similar to the approach of most Chromium browsers. This change will go live in Firefox 57, scheduled for release on November 14, and will be part of Photon -- the codename used to describe Firefox's new user interface (UI) -- also scheduled for a public release in v57. Mozilla engineers aren't removing the search bar altogether, but Firefox will hide this UI element by default. Users can still re-enable it by going to "Preferences -> Search -> Search Bar" and choosing the second option. The current Firefox search bar is redundant since most of its features can be performed by the URL address bar.

Catalin Cimpanu, reporting for BleepingComputer: Microsoft has declined to patch a security bug Cisco Talos researchers discovered in the Edge browser, claiming the reported issue is by design. Apple and Google patched a similar flaw in Safari (CVE-2017-2419) and Chrome (CVE-2017-5033), respectively. According to Cisco Talos researcher Nicolai Grodum, the vulnerability can be classified as a bypass of the Content Security Policy (CSP), a mechanism that allows website developers to configure HTTP headers and instruct the browsers of people visiting their site what resources (JavaScript, CSS) they can load and from where. The Content Security Policy (CSP) is one of the tools that browsers use to enforce Same-Origin Policy (SOP) inside browsers. Grodum says that he found a way to bypass CSP -- technical details available here -- that will allow an attacker to load malicious JavaScript code on a remote site and carry out intrusive operations such as collecting information from users' cookies, or logging keystrokes inside the page's forms, and others.

Artem Tashkinov writes: Soon to be released Firefox 56 says that out of 35+ add-ons that I have installed only a single one is a proper WebExtension which means that Firefox 57 will disable over 95% of my add-ons many of which I just cannot live without and for most of them there are simply no alternatives. This number of add-ons sound like an overkill, but actually they are all pretty neat and improve your browsing abilities. That's the reason why I'm using Firefox 52 ESR, which still fully supports XUL add-ons, however after June 2018, it will stop being supported.

Let's list the most famous ones:

• DownThemAll is still largely irreplaceable since you can download from many parts of the internet much faster if you split the downloaded files in chunks and download them simultaneously;
• GreaseMonkey allows you to fix or extend your favourite websites using JavaScript;Lazarus: Form Recovery has saved my time and life numerous times; it regularly backups the contents of web forms and allows to restore them after browser restart or accidental page refresh;
• NoScript: allows you to whitelist JS execution only for websites that you really trust; JS has been used as an attack and tracking tool since its inception;
• Status-4-Ever and Classic Theme Restorer return Firefox to the time when it was a powerful tool with its own identity and looks, and not a Chrome clone;
• UnMHT add-on allows you to save complete web pages as a single MHT file;

So what will you do less than a year from now?

The latest version of Google Chrome has launched, bringing a host of new developer features like JavaScript modules and WebUSB support. An anonymous Slashdot reader shares a report from VentureBeat: Google has launched Chrome 61 for Windows, Mac, and Linux. Additions in this release include JavaScript modules and WebUSB support, among other developer features. You can update to the latest version now using the browser's built-in silent updater or download it directly from google.com/chrome. Google also released Chrome 61 for Android today. In addition to performance and stability fixes, you can expect two new features: Translate pages with a more compact toolbar and pick images with an improved image picker.

Chrome now supports JavaScript modules natively via the new element, letting developers declare a script's dependencies. Modules are already popular in third-party build tools, which use them to bundle only the required scripts. Native support means the browser can fetch granular dependencies in parallel, taking advantage of caching, avoiding duplications across the page, and ensuring the script executes in the correct order, all without a build step. Google recommends these two blog posts for more information: ECMAScript modules in browsers and ES6 Modules in Depth. Speaking of JavaScript, Chrome 61 also upgrades the browser's V8 JavaScript engine to version 6.1. Developers can expect performance improvements and a binary size reduction. The WebUSB API meanwhile allows web apps to access user-permitted USB devices. This enables all the functionality provided by hardware peripherals such as keyboards, mice, printers, and gamepads, while still preserving the security guarantees of the web.

The latest allegation against Google? Jon von Tetzchner, creator of the web browser Opera, says the search giant deliberately undermined his new browser, Vivaldi. Rowland Manthorpe, writing for Wired: In a blogpost titled, "My friends at Google: it is time to return to not being evil," von Tetzchner accuses the US firm of blocking Vivaldi's access to Google AdWords, the advertisements that run alongside search results, without warning or proper explanation. According to Von Tetzchner, the problem started in late May. Speaking at the Oslo Freedom Forum, the Icelandic programmer criticised big tech companies' attitude toward personal data, calling for a ban on location tracking on Facebook and Google. Two days later, he suddenly found Vivaldi's Google AdWords campaigns had been suspended. "Was this just a coincidence?" he writes. "Or was it deliberate, a way of sending us a message?" He concludes: "Timing spoke volumes." Von Tetzchner got in touch with Google to try and resolve the issue. The result? What he calls "a clarification masqueraded in the form of vague terms and conditions." The particular issue was the end-user license agreement (EULA), the legal contract between a software manufacturer and a user. Google wanted Vivaldi to add one to its website. So it did. But Google had further complaints. According to emails shown to WIRED, Google wanted Vivaldi to add an EULA "within the frame of every download button." The addition was small -- a link below the button directing people to "terms" -- but on the web, where every pixel matters, this was a potential competitive disadvantage. Most gallingly, Chrome, Google's own web browser, didn't display a EULA on its landing pages. Google also asked Vivaldi to add detailed information to help people uninstall it, with another link, also under the button.

Google Chrome will soon allow users to permanently mute websites, a feature that will cheer millions who suffer through autoplaying videos on (annoying) websites every day. From a report: According to Google's Francois Beaufort, the Chrome team is still experimenting with this feature. In the early version, the sound toggle is in the page info popup, which you can access by clicking on the far left of the address bar. That's either an info icon or a "Secure" label for sites that have HTTPS enabled. There are already various toggles in there now for things like Flash, JavaScript, notifications, and so on. Soon, a sound toggle will be added that works in the same way. Sites on which you disable sound will remain that way until you turn them back on.

According to recent warnings issued by Avira, CSIS Security Group, and Kaspersky Lab, a virulent spam campaign has hit Facebook Messenger during the past few days. "The Facebook spam messages contain a link to what appears to be a video," reports Bleeping Computer. "The messages arrive from one of the user's friends, suggesting that person's account was also compromised." From the report: The format of the spam message is the user's first name, the word video, and a bit.ly or t.cn short-link. Users that click on the links are redirected to different pages based on their geographical location and the type of browser and operating system they use. It's been reported that Firefox users on Windows and Mac are being redirected to a page offering a fake Flash Player installer. Kaspersky says this file installs adware on users' PCs. On Chrome, the spam campaign redirects users to a fake YouTube page pushing a malicious extension. It is believed that crooks use this Chrome extension to push adware and collect credentials for new Facebook accounts, which they later use to push the spam messages to new users.

An anonymous reader shares a report: In case you haven't heard the news, JavaScript and NodeJS are single handedly eating the world of software. NodeJS is an Open Source server-side JavaScript environment based on the V8 JS rendering engine found in Google Chrome. Once only thought of as a "hipster" framework, NodeJS is fastly becoming one of the most commonly used languages in building web applications and is beginning to find its way into the Enterprise. Netflix, Microsoft, PayPal, Uber, and IBM have adopted the popular "hipster" server-side JavaScript engine for use inside high traffic, high profile production projects. Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node. In addition to Node, Netflix is also using ReactJS in their stack. PayPal too is moving away from Java and onto JavaScript and NodeJS for use in their web application platform. Uber has built its massive driver / rider matching system on Node.js Distributed Web Architecture. IBM has also embraced NodeJS as well. Even Microsoft has embraced NodeJS, offering direct integrations into their Azure Platform, releasing a wealth of tutorials targeted at Node and they have even announced plans to fork the project and build their own version of Node powered by their Edge Javascript engine instead of Chrome's V8.

An anonymous reader writes: "Google engineers have added two new features to the Chrome browser that will alert users of extensions that hijack proxy settings or the new tab page," reports Bleeping Computer. Google has been testing these two techniques sparingly with a small subset of users for more than a year, but they have now landed in Google Canary. The techniques are used by malicious Chrome extensions to hijack traffic and insert ads, or to redirect search traffic to affiliate search engine programs. The addition of these popup alerts are part of Google's plan to fight malicious Chrome extensions that have been starting to plague the Web Store.

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

Google Allo, the chat app that arrived on the iPhone and Android devices last year, now has a web counterpart. Head of product for Allo and video chat app Duo, Amit Fulay, tweeted: "Allow for web is here! Try it on Chrome today. Get the latest Allo build on Android before giving it a spin." Engadget reports: To give it a go, you'll need to open the Allo app on your device and use that to scan a QR code you can generate at this link. Once you've scanned the code, Allo pulls up your chat history and mirrors all the conversations you have on your phone. Most of Allo's key features, including smart replies, emoji, stickers and most importantly the Google Assistant are all intact here. In fact, this is the first time you can really get the full Google Assistant experience through the web; it's been limited to phones and Google Home thus far.