"Big Cable and other telecom industry groups warned that Google's support for DNS over HTTPS (DoH) 'could interfere on a mass scale with critical Internet functions, as well as raise data-competition issues,'" reports Ars Technica.

But are they really just worried DNS over HTTPS will end useful ISP practices that involve monitoring or modifying DNS queries? For example, queries to malware-associated domains can be a signal that a customer's computer is infected with malware. In some cases, ISPs also modify customers' DNS queries in-flight. For example, an easy way to block children from accessing adult materials is with an ISP-level filter that rewrites DNS queries for banned domains. Some public Wi-Fi networks use modified DNS queries as a way to redirect users to a network sign-on page. Some ISPs also use DNS snooping for more controversial purposes -- like ad targeting or policing their networks for copyright infringement. Widespread adoption of DoH would limit ISPs' ability to both monitor and modify customer queries.

It wouldn't necessarily eliminate this ability, since ISPs could still use these techniques for customers who use the ISP's own DNS servers. But if customers switched to third-party DNS servers -- either from Google or one of its various competitors -- then ISPs would no longer have an easy way to tell which sites customers were accessing. ISPs could still see which IP addresses a customer had accessed, which would give them some information -- this can be an effective way to detect malware infections, for example. But this is a cruder way to monitor Internet traffic. Multiple domains can share a single IP address, and domains can change IP addresses over time. So ISPs would wind up with reduced visibility into their customers' browsing habits.

But a switch to DoH would clearly mean ISPs had less ability to monitor and manipulate their customers' browsing activity. Indeed, for advocates that's the point. They believe users, not their ISPs, should be in charge... [I]t's hard to see a policy problem here. ISPs' ability to eavesdrop on their customers' DNS queries is little more than a historical accident. In recent years, websites across the Internet have adopted encryption for the contents of their sites. The encryption of DNS is the natural next step toward a more secure Internet. It may require some painful adjustments by ISPs, but that hardly seems like a reason for policymakers to block the change.

An anonymous reader quotes ZDNet: A Russian cyber-espionage hacker group has been spotted using a novel technique that involves patching locally installed browsers like Chrome and Firefox in order to modify the browsers' internal components. The end goal of these modifications is to alter the way the two browsers set up HTTPS connections, and add a per-victim fingerprint for the TLS-encrypted web traffic that originates from the infected computers...

According to a Kaspersky report published this week, hackers are infecting victims with a remote access trojan named Reductor, through which they are modifying the two browsers. This process involves two steps. They first install their own digital certificates to each infected host. This would allow hackers to intercept any TLS traffic originating from the host. Second, they modify the Chrome and Firefox installation to patch their pseudo-random number generation (PRNG) functions. These functions are used when generating random numbers needed for the process of negotiating and establishing new TLS handshakes for HTTPS connections.

Turla hackers are using these tainted PRNG functions to add a small fingerprint at the start of every new TLS connection.
The attack is being attributed to Turla, "a well-known hacker group believed to operate under the protection of the Russian government," ZDNet reports. And though the remote-access trojan already grants full control over a victim's device, one theory is the modified browsers offer "a secondary surveillance mechanism" if that trojan was discovered and removed. Researchers believe the malware is installed during file transfers over HTTP connections, suggesting an ISP had been compromised, according to the article.

"A January 2018 report from fellow cyber-security firm ESET revealed that Turla had compromised at least four ISPs before, in Eastern Europe and the former Soviet space, also with the purpose of tainting downloads and adding malware to legitimate files."

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.

Google has announced today new privacy-centered updates for three of its services -- namely Google Maps, YouTube, and Google Assistant. From a report: More specifically, Google Maps will be getting an incognito mode, YouTube is getting a history auto-delete option, and Google Assistant is getting support for voice commands that will help users manage the Assistant's own privacy settings. In addition, Google also launched a new Password Checkup feature that checks users' passwords if they've been leaked at other online services. Google first announced incognito mode for Google Maps earlier this year in May, at its Google I/O developer conference. The Google Maps incognito mode is modeled after the similarly named feature that's found in all modern browsers and has been present in Chrome since its launch, back in 2008. It allows Google Maps users to search and view locations without having this information added to their Google account history.

[...] The company said YouTube will get a feature called "history auto-delete." Google is also rolling out new privacy features to its voice assistant -- Google Assistant. These updates come after last week the company rolled out changes to its privacy policy on how Google Assistant handles voice recordings in response to concerns related to third-party contractors listening in on users' voice recordings. But in the coming weeks, Google users will be able to query the Google Assistant itself about these privacy settings.

Google's plans to implement DNS over HTTPS in Chrome are being investigated by a committee in the U.S. House of Representatives, while the Justice Department has "recently received complaints" about the practice, according to the Wall Street Journal.

An anonymous reader quotes Engadget: While Google says it's pushing for adoption of the technology to prevent spying and spoofing, House investigators are worried this would give the internet giant an unfair advantage by denying access to users' data. The House sent a letter on September 13th asking if Google would use data handled through the process for commercial purposes... Internet service providers are worried that they may be shut out of the data and won't know as much about their customers' traffic patterns. This could "foreclose competition in advertising and other industries," an alliance of ISPs told Congress in a September 19th letter...

Mozilla also wants to use the format to secure DNS in Firefox, and the company's Marshall Erwin told the WSJ that the antitrust gripes are "fundamentally misleading." ISPs are trying to undermine the standard simply because they want continued access to users' data, Erwin said. Unencrypted DNS helps them target ads by tracking your web habits, and it's harder to thwart DNS tracking than cookies and other typical approaches.

HTTP/3, the next major iteration of the HTTP protocol, is getting a big boost today with support added in Cloudflare, Google Chrome, and Mozilla Firefox. From a report: Starting today, Cloudflare announced that customers will be able to enable an option in their dashboards and turn on HTTP/3 support for their domains. That means that whenever users visit a Cloudflare-hosted website from an HTTP/3-capable client, the connection will automatically upgrade to the new protocol, rather than being handled via older versions. On the browser side, Chrome Canary added support for HTTP/3 earlier this month. Users can enable it by using the Chrome command-line flags of "--enable-quic --quic-version=h3-23". In addition, Mozilla too announced it would roll out support for HTTP/3. The browser maker is scheduled to ship HTTP/3 in an upcoming Firefox Nightly version later this fall.

A faulty Google Chrome update is likely to blame for the issue Monday that resulted in Mac Pro workstations being rendered unusable at a number of Hollywood studios. "We recently discovered that a Chrome update may have shipped with a bug that damages the file system on MacOS machines," the company wrote in a forum post. "We've paused the release while we finalize a new update that addresses the problem." Variety reports: Reports of Mac Pro workstations refusing to reboot started to circulate among video editors late Monday. At the time, the common denominator among impacted machines seemed to be the presence of Avid's Media Composer software. The issue apparently knocked out dozens of machines at multiple studios, with one "Modern Family" reporting that the show's entire editing team was affected. Avid's leadership updated users of its software throughout the day, advising them to back up their work and not to reboot their machines.

The real culprit was apparently a recent release of Google's Keystone software, which is included in its Chrome browser to automatically download updates of the browser. On computers that had Apple's System Integrity Protection disabled, the update corrupted the computer's file system, making it impossible to reboot. System Integrity Protection is an Apple technology that is meant to ensure that malicious software doesn't corrupt core system files. Google advised affected users on how to uninstall the Chrome update, and also suggested that most users may not be at risk at all. "If you have not taken steps to disable System Integrity Protection and your computer is on OS X 10.9 or later, this issue cannot affect you," the forum post reads. A possible connection to Chrome was first detailed on the Mr. Macintosh blog Tuesday afternoon. As for why several Hollywood studios were hit the hardest, one theory suggests it's because many of the video editors had to disable System Integrity Protection in order to work with external audio and video devices that are common in professional editing setups.

Variety also suggests that the hardware dongles used for licensing Avid may have played some role in the shut-downs.

A possible computer virus attack has knocked out Mac Pro workstations for many film and TV editors across Los Angeles. According to Variety, the issue -- which is causing the workstations to refuse to reboot -- is widespread among users of Mac Pro computers running older versions of Apple's operating system as well as Avid's Media Composer software. From the report: Avid said in a statement that it was aware of the issue: "Avid is aware of the reboot issue affecting Apple Mac Pro devices running some Avid products, which arose late yesterday. This issue is top priority for our engineering and support teams, who have been working diligently to determine and resolve the root cause. As we learn more, we will immediately publish information -- directly to our customers and via our community forums and social media platforms -- in order to resolve this issue for all affected customers and prevent any further issues."

"A lot of L.A. post shops and people out on shows having their Macs slowly crash," reported video post-production consultant Matt Penn on Twitter. Freelance film editor Marcus Pun reposted a message from a popular Avid Facebook user group, advising users not to turn off their workstations. Other users reported that multiple computers at their company were affected by the issue, with social media chatter indicating that a number of different companies, and even major shows like "Modern Family," were affected by the issue. UPDATE: The issue appears to be caused by a Google Chrome update gone haywire.

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.

According to Abner Li from 9to5Google, Google is working on a new "Smart Screenshots" feature that integrates Google Lens abilities into the Google app's screenshot function. From the report: The Google app has long had an "Edit & share screenshots" ability where captures made within Search would reveal cropping and annotation tools. Meanwhile, Assistant has long maintained a "What's on my screen" capability that analyzes what you're currently viewing for search suggestions. Google app 10.61 reveals work on "Smart Screenshots" that combine those two features. Like before, a toolbar -- which interestingly uses a four-color light bar -- appears after you take a screenshot. A small preview is shown at the left with a pencil button overlaid. You can open the system share sheet, but the Google app also suggests a frequently used app.

The most interesting addition is Lens. "Exploring with Lens" could be intended as a "Screen search" replacement given that Lens is increasingly taking over visual lookup throughout first-party apps, like Chrome. After taking a capture, Smart Screenshots have an easy way to invoke Lens for search, OCR, and finding visually "similar items." The existing editing tools (Annotating, Cropping, and Sharing) will remain and this new functionality appears to even use the same settings toggle to enable. It's unclear if this functionality once live will again be limited to screenshots taken within Search, or if it will expand to be systemwide and invokable anywhere. A notification from the Google app could appear after capturing a screenshot.

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

Google is starting to make its Chrome 77 browser update available to Windows, Mac, iOS, and Android this week. While there are many visual changes to Chrome this time, Google is introducing a new send webpage to devices feature. From a report: You can right-click on a link and a new context menu will appear that simply lets you send links to other devices where you use Chrome. If you're using Chrome on iOS you'll need to have the app open and a small prompt will appear to accept the sent tab. The feature has started showing up on Windows, Android, and iOS versions of Chrome, but it doesn't appear to be enabled in the macOS variant just yet. Chrome has long supported the ability to browse your open and recent tabs across multiple devices, but this send to device feature just makes things a little quicker if you're moving from browsing on a PC or laptop to a phone or vice versa.

Google has announced plans to test the new DNS-over-HTTPS (DoH) protocol inside Google Chrome starting with v78, scheduled for release in late October this year. From a report: The DNS-over-HTTPS protocol works by sending DNS requests to special DoH-compatible DNS resolvers. The benefit comes from the fact that DNS requests are sent via port 443, as encrypted HTTPS traffic, rather than cleartext, via port 53. This hides DoH requests in the unending stream of HTTPS traffic that moves across the web at any moment of the day and prevents third-party observers from tracking users' browsing histories by recording and looking at their unencrypted DNS data. The news that Google is looking into testing DoH in Chrome comes just as Mozilla announced plans over the weekend to gradually enable DoH by default for a small subset of users in the US later this month.

An anonymous reader quotes 9to5Google: Like it or not, Chromebooks do have something of an expiration date when you purchase them, namely that one day they'll stop receiving updates. Thankfully, that date is typically over five years after the Chromebook's original release. For some, however, Chrome OS has been wrongly indicating this week that their Chromebook has received its "final update" many years too early.

Just like the Chrome browser on desktop and Android, Chrome OS has four different update "channels" -- Stable, Beta, Dev, and Canary. Each one of these after Stable trades a level of stability for more rapid updates, with Canary receiving highly unstable updates almost every day. People who are bold enough to put their Chromebook on Dev or Canary have been facing an interesting new issue for the past few days. Upon restarting their device, Chrome OS immediately displays a notification warning that "this is the last automatic software and security update for this Chromebook." Of course, if you're seeing this message this week, there's a decent chance that this is not actually the case.

Instead, these final update warnings are caused by a bug in the most recent versions of Chrome OS.

schwit1 shares a Forbes article by Joe Toscano, a former experience design consultant for Google who in 2017 "decided to step away from my role consulting with Google, due to ethical concerns."

This summer he got a big surprise when he looked in Chrome's "addresses" panel at chrome://settings/addresses It turns out Google has info connecting me to my grandma (on my dad's side) who's alive and well but has never had the internet, and my grandpa (on my mom's side), who recently passed away in March 2019 and also never had the internet. This was disturbing for several reasons, the biggest of which being that neither of them had ever logged onto the internet in their lives. Neither even had the internet in their homes their entire lives! Beyond that, Google knew their exact addresses and their middle initials. I couldn't even have told you those things about my grandparents...

[T]he data wasn't manually entered by me or anyone using my account, but yet the data is associated with my account? How did that happen? The only thing I can think of is that at one point in history my grandpa gave his information to someone or some company in real life and his information was sold to Google at one point or another... But then that led me to another question: How did his data get associated with my Google account...?

Other questions I have: What other information does Google have about me/my family/others that I don't know about...?
He's now asking readers if they have any idea how Google connected him to his dead grandpa -- and whether Google is somehow creating an ancestry database.

Toscano also discovered Chrome has been creating a list of "Never Saved" passwords at chrome://settings/passwords?search=credentials even though "At no point did I tell Google to create and store a list of websites I had logged into that they didn't get access to but would like access to at some point in the future. Maybe in the Terms of Service/Privacy Policy I agreed to this, but who knows? Not the majority of us, and it's just creepy."

And in an update Toscano writes that he hopes the article will "provoke thought" about "why we willingly allow this to happen": Why is it okay that the internet is designed to be a surveillance machine? Why isn't it designed to be private by design? Is this how we want to carry on? Just because something is legal doesn't mean it's right. What would you like to see done? How would you like to see things changed?

Long-time Slashdot reader AmiMoJo quotes VentureBeat: Google, which has already paid security researchers over $15 million since launching its bug bounty program in 2010, today increased the scope of its Google Play Security Reward Program (GPSRP). Security researchers will now be rewarded for finding bugs across all apps in Google Play with 100 million or more installs. At the same time, the company launched the Developer Data Protection Reward Program (DDPRP) in collaboration with [bug bounty platform] HackerOne. That program is for data abuses in Android apps, OAuth projects, and Chrome extensions....

Google also uses this vulnerability data to create automated checks that scan all Google Play apps for similar vulnerabilities. Affected app developers are notified via the Play Console. The App Security Improvement (ASI) program provides them with information on the vulnerability and how to fix it. In February, Google revealed that ASI has helped over 300,000 developers fix over 1,000,000 apps on Google Play.
The article also notes that Android apps and Chrome extensions found to be abusing data "will be removed from Google Play and the Chrome Web Store."

A mobile security company has carried out a research investigation to address the popular conspiracy theory that tech giants are listening to conversations. From a report: The internet is awash with posts and videos on social media where people claim to have proof that the likes of Facebook and Google are spying on users in order to serve hyper-targeted adverts. Videos have gone viral in recent months showing people talking about products and then ads for those exact items appear online. Now, cyber security-specialists at Wandera have emulated the online experiments and found no evidence that phones or apps were secretly listening. Researchers put two phones -- one Samsung Android phone and one Apple iPhone -- into a "audio room". For 30 minutes they played the sound of cat and dog food adverts on loop. They also put two identical phones in a silent room.

The security specialists kept apps open for Facebook, Instagram, Chrome, SnapChat, YouTube, and Amazon with full permissions granted to each platform. They then looked for ads related to pet food on each platform and webpage they subsequently visited. They also analyzed the battery usage and data consumption on the phones during the test phase. They repeated the experiment at the same time for three days, and noted no relevant pet food adverts on the "audio room" phones and no significant spike in data or battery usage.

New submitter q4Fry writes: When Google released its changes to the Chrome WebExtensions API for comment, many groups criticized them for cutting off ad-blockers at the knees. Now, Mozilla has released its plan for following (and departing from) the APIs that Chrome may adopt.