Google is facing a backlash over an internal tool for the company's Chrome browser that some employees worry is intended for spying on workers organizing protests and discussing workplace issues. From a report: To get around using the tool, some employees have turned to third-party browsers. That's prompted at least one security engineer at Google to voice concern over the possible vulnerabilities that using outside software could bring. The tool is a software extension for Google's Chrome browser, which is installed on all employee computers. It's designed to activate when workers create calendar events that include more than 100 people or use more than 10 rooms. Google said the tool is a pop-up reminder that asks people to "be mindful" before setting up large meetings. But some employees have accused Google management of trying to keep tabs on big gatherings. Google has called those claims "categorically false" and said the purpose of the tool is to cut down on calendar spam. To avoid the extension, employees are encouraging each other to use browsers other than Chrome, a Google security engineer wrote in an internal forum, screenshots of which were reviewed by CNET. Those browsers include Chromium, the open-source browser foundation on which Google Chrome is built, the engineer wrote, adding that people shifting to other browsers "has an impact on overall security of this fleet."

SmartAboutThings tipped us off to an interesting bug reported by ZDNet Thursday: For the fourth time in three months, a Symantec security product is crashing user apps, and this time it's the latest Chrome release, v78, which rolled out earlier this week, on Tuesday, October 22. According to reports on Reddit [1, 2] the Google support forums [1, 2], and in comments on the official Google Chrome blog, Symantec Endpoint Protection 14 is crashing Chrome 78 instances with an "Aw, Snap! Something went wrong while displaying this webpage" error... The errors have been plaguing users for the past two days, with the vast majority of reports coming from enterprise environments, where SEP installs are more prevalent....

According to the antivirus maker, the issues are only affecting SEP 14 users on Windows 10 RS1, Windows Server 2012, and Windows Server 2016 operating systems. Symantec users on other OS versions can fix this by updating to the latest SEP 14.2 release. Users of Microsoft Edge Chromium are also impacted, but the Chromium-based Edge version has not been officially released; hence there are almost no users impacted by this issue in the real world...

Symantec blamed the issue on Microsoft's Code Integrity security feature, which Google uses to protect the Chrome browser process. As a temporary solution, Symantec recommends that users exclude Chrome from receiving protection from their antivirus product, or modify their Chrome clients, so the browser starts without Code Integrity protections. However, this opens the browser to various attacks and is not recommended as long as users can simply use another browser until this is fixed.
ZDNet adds that the issue "should have not surprised Symantec staff, who received early warnings about this more than three months ago, according to a bug report filed in early August while Chrome 78 was still in testing in the Canary channel."

Microsoft appears to be porting its Edge browser to Linux, reports ZDNet: "We on the MS Edge Dev team are fleshing out requirements to bring Edge to Linux, and we need your help with some assumptions," wrote Sean Larkin, a member of Microsoft's Edge team....

Chrome, of course, is already available for Linux, so Microsoft should be able to deliver Chromium-based Edge to Linux distributions with minimal fuss.... [I]n June Microsoft Edge developers said there are "no technical blockers to keep us from creating Linux binaries" and that it is "definitely something we'd like to do down the road". Despite Chrome's availability on Linux, the Edge team noted there is still work to be done on the installer, updaters, user sync, and bug fixes, before it could be something to commit to properly.
Slashdot reader think_nix shared a link to the related survey that the Edge team has announced on Twitter. "If you're a dev who depends on Linux for dev, testing, personal browsing, please take a second to fill out this survey."

"Attackers are exploiting a zero-day vulnerability in Google's Android mobile operating system that can give them full control of at least 18 different phone models," reports Ars Technica, "including four different Pixel models, a member of Google's Project Zero research group said on Thursday night." The post also says there's evidence the vulnerability is being actively exploited.

An anonymous reader quotes Ars Technica: Exploits require little or no customization to fully root vulnerable phones. The vulnerability can be exploited two ways: (1) when a target installs an untrusted app or (2) for online attacks, by combining the exploit with a second exploit targeting a vulnerability in code the Chrome browser uses to render content. "The bug is a local privilege escalation vulnerability that allows for a full compromise of a vulnerable device," Stone wrote. "If the exploit is delivered via the Web, it only needs to be paired with a renderer exploit, as this vulnerability is accessible through the sandbox...."

Google representatives wrote in an email: "Pixel 3 and 3a devices are not vulnerable to this issue, and Pixel 1 and 2 devices will be protected with the October Security Release, which will be delivered in the coming days. Additionally, a patch has been made available to partners in order to ensure the Android ecosystem is protected against this issue."

The use-after-free vulnerability originally appeared in the Linux kernel and was patched in early 2018 in version 4.14, without the benefit of a tracking CVE. That fix was incorporated into versions 3.18, 4.4, and 4.9 of the Android kernel. For reasons that weren't explained in the post, the patches never made their way into Android security updates.

"Today we're announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources," promises an announcement on the Chromium blog.

It notes that Chrome users already make HTTPS connections for more than 90% of their browsing time, and "we're now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date." In a series of steps outlined below, we'll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users...

HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users' privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between. In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites...
Starting in December of 2019, Chrome 79 will include a new setting to unblock mixed content on specific sites. "This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default..."

Then in Chrome 80, mixed audio and video resources will be autoupgraded to https://, and if they fail to load Chrome will block them by default.

sharkbiter shares a report from ZDNet: Over the course of the last year and a half, Apple has effectively neutered ad blockers in Safari, something that Google has been heavily criticized all this year. But unlike Google, Apple never received any flak, and came out of the whole process with a reputation of caring about users' privacy, rather than attempting to "neuter ad blockers." The reasons may be Apple's smaller userbase, the fact that changes rolled out across years instead of months, and the fact that Apple doesn't rely on ads for its profits, meaning there was no ulterior motive behind its ecosystem changes.

The reason may have to do with the fact that Apple is known to have a heavy hand in enforcing rules on its App Store, and that developers who generally speak out are usually kicked out. It's either obey or get out. Unlike in Google's case, where Chrome is based on an open-source browser named Chromium and where everyone gets a voice, everything at Apple is a walled garden, with strict rules. Apple was never criticized for effectively "neutering" or "killing ad blockers" in the same way Google has been all this year. In Google's case, the pressure started with extension developers, but it then extended to the public. There was no public pressure on Apple mainly because there aren't really that many Safari users to begin with. With a market share of 3.5%, Safari users aren't even in the same galaxy as Chrome and its 65% market lead.

Furthermore, there is also the problem of public perception. When Apple rolled out a new content blocking feature to replace the old Safari extensions and said it was for everyone's privacy -- as extensions won't be able to access browsing history -- everyone believed it. On the other hand, ads are Google's life blood, and when Google announced updates that limited ad blockers, everyone saw it a secret plan for a big corp to keep its profits intact, rather than an actual security measure, as Google said it was.

Developers of the LastPass password manager have patched a vulnerability that made it possible for websites to steal credentials for the last account the user logged into using the Chrome or Opera extension. Ars Technica reports: The vulnerability was discovered late last month by Google Project Zero researcher Tavis Ormandy, who privately reported it to LastPass. In a write-up that became public on Sunday, Ormandy said the flaw stemmed from the way the extension generated popup windows. In certain situations, websites could produce a popup by creating an HTML iframe that linked to the Lastpass popupfilltab.html window, rather than through the expected procedure of calling a function called do_popupregister(). In some cases, this unexpected method caused the popups to open with a password of the most recently visited site. "Because do_popupregister() is never called, ftd_get_frameparenturl() just uses the last cached value in g_popup_url_by_tabid for the current tab," Ormandy wrote. "That means via some clickjacking, you can leak the credentials for the previous site logged in for the current tab."

On Friday, LastPass published a post that said the bugs had been fixed and described the "limited set of circumstances" required for the flaws to be exploited. "To exploit this bug, a series of actions would need to be taken by a LastPass user including filling a password with the LastPass icon, then visiting a compromised or malicious site and finally being tricked into clicking on the page several times," LastPass representative Ferenc Kun wrote. "This exploit may result in the last site credentials filled by LastPass to be exposed. We quickly worked to develop a fix and verified the solution was comprehensive with Tavis."

Mozilla has switched on Firefox's tracking protection feature for everyone on Windows and Android, dialing up its effort to protect privacy from website publishers and advertisers that would like to keep tabs on your online behavior. From a report: Mozilla enabled tracking protection for new Firefox users in June, but now it's on for everyone, the nonprofit said Tuesday. Tracking protection is all the rage among browser makers, including Apple's Safari, Brave Software's Brave and Microsoft's new Chromium-based Edge. Even Google's Chrome, long the laggard among major browsers, is starting to tackle the problem. It's a thorny issue for websites and advertisers that seek to improve advertising revenue by targeting ads based on their assessment of your interests. "Currently over 20% of Firefox users have Enhanced Tracking Protection on. With today's release, we expect to provide protection for 100% of ours users by default," Mozilla said in a blog post Tuesday.

Microsoft is killing support for the EPUB document format in Edge classic, and it won't be supported in the new, Chromium-based version of Microsoft Edge. Thurrott reports: "Download an .epub app to keep reading," a notification in Edge classic reads when you load an EPUB document. "Microsoft Edge will no longer be supporting [sic] e-books that use the .epub file extension. Visit the Microsoft Store to see our recommended .epub apps." Aside from the contorted grammar and word usage in the notification -- it's "support" not "be supporting," Microsoft -- the linked webpage is a "Reading room" area on the Microsoft Store that includes audiobook apps in addition to e-book apps. So good luck with that.

Microsoft provides a more grammatically correct explanation for the change on its Microsoft Edge support site, which notes that "Microsoft Edge will no longer support e-books that use the .epub file extension." The site also links to the same terrible Microsoft Store area, but adds that "you can expect to see more added over time as we partner with companies like the DAISY Consortium to add additional, accessible apps... These apps are expected to be available in the Microsoft Store after September 2019." Given that, it's likely that EPUB support will disappear in Edge classic sometime after those apps appear in the Store.

Microsoft today made a beta version of its Chromium Edge browser available to download for macOS and Windows platforms, as it looks to convince users to give its revamped version of desktop browser a try. The company said the new beta version is built for "everyday use." From a report: Those on the Dev and Canary channels will continue to be able to run those builds along with the new Beta channel builds. For those on the Canary builds, Microsoft is releasing a new Collections feature today. Microsoft is announcing a couple of other big milestones today: the company says it has had more than 1 million downloads on the preview builds of Edge to date, and it's received more than 140,000 individual pieces of feedback from users so far.

An anonymous reader quotes MSPoweruser: Google Chrome always had a bit of a love-hate relationship when it comes to managing FTP links. The web browser usually downloads instead of rendering it like other web browsers. However, if you're using FTP then you might have to look elsewhere soon as Google is planning to remove FTP support altogether.

In a post (via Techdows), Google, today announced its intention to deprecate FTP support starting with Chrome v80. The main issue with FTP right now is security and the protocol doesn't support encryption which makes it vulnerable and Google has decided it's no longer feasible to support it.

"Upcoming changes in Google Chrome and Mozilla Firefox may finally spark the end for Extended Validation certificates as the browsers plan to do away with showing a company's name in the address bar," reports Bleeping Computer. When connecting to a secure web site, an installed SSL/TLS certificate will encrypt the communication between the browser and web server. These certificates come in a few different flavors, with some claiming to offer a more thorough verification process or extra perks. One certificate, called EV Certificates, are known for having a browser display the owner of the certificate directly in the browser's address bar. This allegedly makes the site feel more trustworthy to a visitor.

In reality, the different types of SSL/TLS certificates all serve a single purpose and that is to encrypt the communication between a browser and web site. Anything extra is seen by many as just a marketing gimmick to charge customers for a more expensive "trustworthy" certificate. In numerous blog posts, security researcher Troy Hunt has stated that EV Certificates will soon be dead as more and more sites switch away from them, because they are much harder to manage due to extra verification times, and because people have become to associate a padlock with a secure site rather than a company name.

With Safari already removing EV Certificate company info from the address bar, most mobile browsers not showing it, and Chrome and Mozilla desktop browsers soon to remove it, Hunt's predictions are coming true. EV Certificates will soon be dead.
AmiMoJo shared this post from Google's Chromium blog: Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection. Further, the EV badge takes up valuable screen real estate, can present actively confusing company names in prominent UI, and interferes with Chrome's product direction towards neutral, rather than positive, display for secure connections. Because of these problems and its limited utility, we believe it belongs better in Page Info.

Is Google making the wrong response to the DataSpii report on a "catastrophic data leak"? The EFF writes: In response to questions about DataSpii from Ars Technica, Google officials pointed out that they have "announced technical changes to how extensions work that will mitigate or prevent this behavior." Here, Google is referring to its controversial set of proposed changes to curtail extension capabilities, known as Manifest V3.

As both security experts and the developers of extensions that will be greatly harmed by Manifest V3, we're here to tell you: Google's statement just isn't true. Manifest V3 is a blunt instrument that will do little to improve security while severely limiting future innovation... The only part of Manifest V3 that goes directly to the heart of stopping DataSpii-like abuses is banning remotely hosted code. You can't ensure extensions are what they appear to be if you give them the ability to download new instructions after they're installed.

But you don't need the rest of Google's proposed API changes to stop this narrow form of bad extension behavior. What Manifest V3 does do is stifle innovation...
The EFF makes the following arguments Google's proposal:

• Manifest V3 will still allow extensions to observe the same data as before, including what URLs users visit and the contents of pages users visit
• Manifest V3 won't change anything about how "content scripts" work...another way to extract user browsing data.
• Chrome will still allow users to give extensions permission to run on all sites.

In response Google argued to Forbes that the EFF "fails to account for the proposed changes to how permissions work. It is the combination of these two changes, along with others included in the proposal, that would have prevented or significantly mitigated incidents such as this one."

But the EFF's technology projects director also gave Forbes their response. "We agree that Google isn't killing ad-blockers. But they are killing a wide range of security and privacy enhancing extensions, and so far they haven't justified why that's necessary."

And in the same article, security researcher Sean Wright added that Google's proposed change "appears to do little to prevent rogue extensions from obtaining information from loaded sites, which is certainly a privacy issue and it looks as if the V3 changes don't help."

The EFF suggests Google just do a better job of reviewing extensions.

"Google has finally chopped the 'www' from Chrome's address bar after delaying the controversial move due to a backlash," reports TechRepublic: The move to remove 'www' was initially planned for last year, when Google announced it would cut "trivial subdomains" from the address bar in Chrome 69. Now Google has begun truncating the visible URL in Chrome for desktop and Android, rolling out the change in version 76 of the browser, released this week. By default sites in Chrome now no longer display the "https" scheme or the "www" subdomain, with the visible address starting after this point. To view the full URL, users now have to click the address bar twice on desktop and once on mobile. Google has argued the move is driven by a desire for greater simplicity and usability of Chrome...

However the announcement provoked a fresh wave of criticism, from those who say the move will confuse users and even potentially make it easier for them to inadvertently connect to fake sites... There are also some who claim Google's motivation in changing how the URL is displayed may be to make it harder for users to tell whether they are on a page hosted on Google's Accelerated Mobile Pages subdomain...

Google says it has also built a Chrome extension that doesn't obfuscate the URL to "help power users recognize suspicious sites and report them to Safe Browsing". Despite the backlash from some online, Chrome isn't the first browser to truncate the URL in this way, with Apple's Safari similarly hiding the full address.

Google researchers have shared details of five flaws in Apple's iMessage software that could make its devices vulnerable to attack. The BBC reports: In one case, the researchers said the vulnerability was so severe that the only way to rescue a targeted iPhone would be to delete all the data off it. Another example, they said, could be used to copy files off a device without requiring the owner to do anything to aid the hack. Apple released fixes last week. But the researchers said they had also flagged a sixth problem to Apple, which had not been rectified in the update to its mobile operating system.

Apple's own notes about iOS 12.4 indicate that the unfixed flaw could give hackers a means to crash an app or execute commands of their own on recent iPhones, iPads and iPod Touches if they were able to discover it. Apple has not commented on this specific issue, but has urged users to install the new version of iOS, which addresses Google's other discoveries as well as a further range of glitches and threats. One of the two Google researchers involved - Natalie Silvanovich - intends to share more details of her findings at a presentation at the Black Hat conference in Las Vegas next month.

An anonymous reader shares a report from VentureBeat: Google today launched Chrome 76 for Windows, Mac, Linux, Android, and iOS. The release includes Adobe Flash blocked by default, Incognito mode detection disabled, multiple PWA improvements, and more developer features. You can update to the latest version now using Chrome's built-in updater or download it directly from google.com/chrome. Google has been taking baby steps to kill off Flash for years. In 2015, Chrome started automatically pausing less important Flash content. In 2016, Chrome started blocking "behind the scenes" Flash content and using HTML5 by default. In July 2017, however, Adobe said it would kill Flash by 2020. With Chrome 76, Flash is now blocked by default. Users can still turn it on in settings, but next year, Flash will be removed from Chrome entirely.

"Google is giving Chrome extension makers until October 15 to minimize the amount of data they collect during browser sessions or face expulsion from the Chrome Web Store," reports PC Magazine: The change addresses how the extensions generally need to request certain permissions from your browser in order to function. However, some of these permissions can be pretty powerful; they can include the ability to take desktop screenshots, capture audio from a microphone, and collect data from the local file system, among other things, which can open the door to potential abuse.

The risks prompted Google to work toward securing the 180,000+ Chrome extensions on the company's official web store. "We're requiring extensions to only request access to the least amount of data," the company said in a Tuesday blog post. "While this has previously been encouraged of developers, now we're making this a requirement for all extensions."

Security researcher Jonathan Leitschuh has publicly disclosed a serious zero-day vulnerability for the Zoom video conference app on Macs that could allow websites to turn on user cameras without permission. The Verge reports: He has demonstrated that any website can open up a video-enabled call on a Mac with the Zoom app installed. That's possible in part because the Zoom app apparently installs a web server on Macs that accepts requests regular browsers wouldn't. In fact, if you uninstall Zoom, that web server persists and can reinstall Zoom without your intervention. Leitschuh details how he responsibly disclosed the vulnerability to Zoom back in late March, giving the company 90 days to solve the problem. According to Leitschuh's account, Zoom doesn't appear to have done enough to resolve the issue. The vulnerability was also disclosed to both the Chromium and Mozilla teams, but since it's not an issue with their browsers, there's not much those developers can do. The report notes that you can "patch" the vulnerability by making sure the Mac app is up to date and also disabling the setting that allows Zoom to turn your camera on when joining a meeting. "Again, simply uninstalling Zoom won't fix this problem, as that web server persists on your Mac," reports The Verge. "Turning off the web server requires running some terminal commands, which can be found at the bottom of the Medium post."

If you're looking to try out a Linux distro that is not based on Ubuntu, Mageia 7 might be worth your consideration. It arrives two years after the release of Mageia 6 -- so unsurprisingly, the changelog is fairly long. The Mageia developers share the significant packages that have been updated below. Significant package updates include: kernel 5.1.14, rpm 4.14.2, dnf 4.2.6, Mesa 19.1, Plasma 5.15.4, GNOME 3.32, Xfce 4.14pre, Firefox 67, Chromium 73, and LibreOffice 6.2.3. Donald Stewart, Mageia developer, adds: There are lots of new features, exciting updates, and new versions of your favorite programs, as well as support for very recent hardware. There are classical installer images for both 32-bit and 64-bit architectures, as well as live DVDs for 64-bit Plasma, GNOME, Xfce, and 32-bit Xfce.

The Google Earth team recently released a beta preview of a WebAssembly port of Google Earth. The new port runs in Chrome and other Chromium-based browsers, including Edge (Canary version) and Opera, as well as Firefox. From a report: The port thus brings cross-browser support to the existing Earth For Web version, which uses the native C++ codebase and Chrome's Native Client (NaCl) technology. Difference in multi-threading support between browsers leads to varying performance. Google Earth was released 14 years ago and allowed users to explore the earth through the comfort of their home. This original version of Google Earth was released as a native C++ based application intended for desktop install because rendering the whole world in real time required advanced technologies that weren't available in the browser. Google Earth was subsequently introduced for Android and iOS smartphones, leveraging the existing C++ codebase through technologies such as NDK and Objective-C++. In 2017, Google Earth was released for the Chrome browser, using Google's Native Client (NaCl) to compile the C++ code and run it in the browser.