Browsers have been pushing the movement to encrypt the web further, too. Early this year, Chrome and Firefox started showing users "Not secure" warnings when HTTP websites asked them to submit password or credit card information. In October, Chrome expanded the warning to cover all input fields, as well as all pages viewed in Incognito mode. Chrome has eventual plans to show a "Not secure" warning for all HTTP pages... The next big step in encrypting the web is ensuring that most websites default to HTTPS without ever sending people to the HTTP version of their site. The technology to do this is called HTTP Strict Transport Security (HSTS), and is being more widely adopted. Notably, the registrar for the .gov TLD announced that all new .gov domains would be set up with HSTS automatically...

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.

Posted
by
BeauHDon Monday November 13, 2017 @10:30PM
from the it's-about-time dept.

An anonymous reader writes: "It took only two years for all browser vendors to get on the same page regarding the new WebAssembly standard, and as of October 2017, all major browsers support it," reports Bleeping Computer. Project spearheads Firefox and Chrome were the first major browsers to graduate WebAssembly from preview versions to their respective stable branches over the summer. The second wave followed in the following weeks when Chromium-based browsers like Opera and Vivaldi also rolled out the feature as soon as it was added to the Chromium stable version. The last ones to ship WebAssembly in the stable branches were Apple in Safari 11.0 and Microsoft in Microsoft Edge (EdgeHTML 16), which is the version that shipped with the Windows 10 Fall Creators Update. Both were released last month. WebAssembly, or wasm, is a bytecode format for the web, allowing developers to send JavaScript code to browsers in smaller sizes, but also to compile from C/C++/Rust to wasm directly.

"We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018," Palmer says. The proposal is up in the air, and users can submit opinions against Google's intent to deprecate, but seeing how little PKP was adopted, it's most likely already out the door. A Neustar survey from March 2016 had PKP deployment at only 0.09% of all HTTPS sites. By August 2017, that needle had barely moved to 0.4% of all sites in the Alexa Top 1 Million.

Posted
by
msmash
on Thursday October 19, 2017 @11:20AM
from the brainstorming dept.

An anonymous reader writes: Google Chrome engineers are considering adding a special browser permission that will thwart the rising trend of in-browser cryptocurrency miners. Discussions on the topic of in-browser miners have been going on the Chromium project's bug tracker since mid-September when Coinhive, the first such service, launched. "Here's my current thinking," Ojan Vafai, a Chrome engineering working on the Chromium project, wrote in one of the recent bug reports. "If a site is using more than XX% CPU for more than YY seconds, then we put the page into 'battery saver mode' where we aggressively throttle tasks and show a toast [notification popup] allowing the user to opt-out of battery saver mode. When a battery saver mode tab is backgrounded, we stop running tasks entirely. I think we'll want measurement to figure out what values to use for XX and YY, but we can start with really egregious things like 100% and 60 seconds. I'm effectively suggesting we add a permission here, but it would have unusual triggering conditions [...]. It only triggers when the page is doing a likely bad thing."

An earlier suggestion had Google create a blacklist and block the mining code at the browser level. That suggestion was shut down as being too impractical and something better left to extensions.

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.

Posted
by
msmash
on Thursday September 14, 2017 @09:00AM
from the tightening-bolts dept.

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.

Posted
by
BeauHDon Saturday September 09, 2017 @08:00AM
from the hide-and-seek dept.

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.

Posted
by
EditorDavid
on Saturday August 19, 2017 @05:54PM
from the Chrome-come-calling dept.

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

Posted
by
msmash
on Monday August 07, 2017 @01:45PM
from the killing-things-to-move-forward dept.

An anonymous reader writes: Debian Linux "sid" is deprecating TLS 1.0 Encryption. A new version of OpenSSL has been uploaded to Debian Linux unstable. This version disables the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the only supported SSL/TLS protocol version. This will likely break certain things that for whatever reason still don't support TLS 1.2. I strongly suggest that if it's not supported that you add support for it, or get the other side to add support for it. OpenSSL made a release 5 years ago that supported TLS 1.2. The current support of the server side seems to be around 90%. I hope that by the time Buster releases the support for TLS 1.2 will be high enough that I don't need to enable them again. This move caused some concern among Debian users and sysadmins. If you are running Debian Unstable on server tons of stuff is going to broken cryptographically. Not to mention legacy hardware and firmware that still uses TLS 1.0. On the client side (i.e. your users), you need to use the latest version of a browser such as Chrome/Chromium and Firefox. The Older version of Android (e.g. Android v5.x and earlier) do not support TLS 1.2. You need to use minimum iOS 5 for TLS 1.2 support. Same goes with SMTP/mail servers, desktop email clients, FTP clients and more. All of them using old outdated crypto.

This move will also affect for Android 4.3 users or stock MS-Windows 7/IE users (which has TLS 1.2 switched off in Internet Options.) Not to mention all the mail servers out there running outdated crypto.

Posted
by
msmash
on Friday July 21, 2017 @09:00AM
from the floor-is-all-yours dept.

Dustin Kirkland, Ubuntu Product and Strategy at Canonical, writes: Howdy all- Back in March, we asked the HackerNews community, "What do you want to see in Ubuntu 17.10?": https://ubu.one/AskHN. A passionate discussion ensued, the results of which are distilled into this post: http://ubu.one/thankHN. In fact, you can check that link, http://bit.ly/thankHN and see our progress so far this cycle. We already have a beta code in 17.10 available for your testing for several of those:

And several others have excellent work in progress, and will be complete by 17.10:

- Autoremove old kernels from /boot- EXT4 encryption with fscrypt- Better GPU/CUDA support

In summary -- your feedback matters! There are hundreds of engineers and designers working for *you* to continue making Ubuntu amazing! Along with the switch from Unity to GNOME, we're also reviewing some of the desktop applications we package and ship in Ubuntu. We're looking to crowdsource input on your favorite Linux applications across a broad set of classic desktop functionality. We invite you to contribute by listing the applications you find most useful in Linux in order of preference.

Posted
by
msmash
on Thursday July 20, 2017 @02:20PM
from the it's-happening dept.

An anonymous reader shares a post: Chromium, the open source project behind Google Chrome, Opera and several other browsers, is going to support MP3. This would enable users and websites to play MP3 files in Chromium browser. A Chromium contributor informed about this, "We have approval from legal to go ahead and move MP3 into non-proprietary codecs list." The MP3 support in Chromium is targeted for version 62.

Posted
by
EditorDavid
on Saturday July 01, 2017 @11:38AM
from the study-claims dept.

Templer421 shares an article from National Review:
A new study by Environmental Progress warns that toxic waste from used solar panels now poses a global environmental threat. The Berkeley-based group found that solar panels create 300 times more toxic waste per unit of energy than nuclear-power plants. Discarded solar panels, which contain dangerous elements such as lead, chromium, and cadmium, are piling up around the world, and there's been little done to mitigate their potential danger to the environment. "We talk a lot about the dangers of nuclear waste, but that waste is carefully monitored, regulated, and disposed of," says Michael Shellenberger, founder of Environmental Progress, a nonprofit that advocates for the use of nuclear energy. "But we had no idea there would be so many panels -- an enormous amount -- that could cause this much ecological damage." Solar panels are considered a form of toxic, hazardous electronic or "e-waste," and according to EP researchers Jemin Desai and Mark Nelson, scavengers in developing countries like India and China often "burn the e-waste in order to salvage the valuable copper wires for resale. Since this process requires burning off plastic, the resulting smoke contains toxic fumes that are carcinogenic and teratogenic (birth defect-causing) when inhaled."
A spokesman for the Solar Energy Industries Association argues that the study is incorrect, and that in fact solar panels are "mainly made up of easy-to-recycle materials that can be successfully recovered and reused at the end of their useful life."

Posted
by
EditorDavid
on Saturday June 03, 2017 @12:34PM
from the near-native-performance dept.

An anonymous reader quotes Tom's Hardware
Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly... Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly. WebAssembly can give web apps near-native performance, offers support for more CPU features, and is simpler to implement in browsers and use by developers.

Posted
by
BeauHDon Tuesday May 30, 2017 @06:20PM
from the visual-learning dept.

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.

Posted
by
BeauHDon Friday April 21, 2017 @12:00AM
from the come-to-light dept.

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.

Posted
by
BeauHDon Wednesday April 05, 2017 @10:30PM
from the take-your-pick dept.

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.

Posted
by
msmash
on Thursday March 30, 2017 @02:20PM
from the tidying-things-up dept.

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.

Posted
by
BeauHDon Thursday March 23, 2017 @08:25PM
from the play-by-the-rules dept.

An anonymous Slashdot reader writes from a report via BleepingComputer: Google Chrome engineers announced plans to gradually remove trust in old Symantec SSL certificates and intent to reduce the accepted validity period of newly issued Symantec certificates, following repeated slip-ups on the part of Symantec. Google's decision comes after the conclusion of an investigation that started on January 19, which unearthed several problems with Symantec's certificate issuance process, such as 30,000 misused certificates. In September 2015, Google also discovered that Symantec issued SSL certificates for Google.com without authorization. Symantec blamed the incident on three rogue employees, whom it later fired. This move from Google will force all owners of older Symantec certificates to request a new one. Google hopes that by that point, Symantec would have revamped its infrastructure and will be following the rules agreed upon by all the other CAs and browser makers.