Google: Difference between revisions

Gde (talk | contribs)
Anti-consumer incidents: Add section on Google Assistant 3rd party list support
 
Line 38: Line 38:
Manifest V3 disabled the <code>webRequestBlocking</code> permission in the <code>webRequest</code> API<ref>{{Cite web |date=2023-03-09 |title=Replace blocking web request listeners {{!}} Chrome Extensions {{!}} Chrome for Developers |url=https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |url-status=live |archive-url=https://web.archive.org/web/20250614074559/https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |archive-date=2025-06-14 |access-date=2025-08-12 |website=Chrome for Developers}}</ref>, preventing many ad content blockers from working.<ref>{{Cite web |date=2024-09-26 |title=Understanding Manifest V3 and the Future of uBlock Origin |url=https://ublockorigin.com/ |url-status=live |archive-url=https://web.archive.org/web/20250812114916/https://ublockorigin.com/ |archive-date=2025-08-12 |access-date=2025-08-12 |website=uBlock Origin - Free, open-source ad content blocker}}</ref> Google cites performance reasons <ref>{{Cite web |date=2023-03-09 |title=Replace blocking web request listeners {{!}} Chrome Extensions {{!}} Chrome for Developers |url=https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |url-status=live |archive-url=https://web.archive.org/web/20250614074559/https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |archive-date=2025-06-14 |access-date=2025-08-12 |website=Chrome for Developers |quote="In Manifest V2, blocking web requests could significantly degrade both the performance of extensions and the performance of pages they work with."}}</ref>, but this is dubious; restricting content blockers prevents users from impeding their tracking and surveillance, meaning they can create a larger profit from the data gained. This is likely the ulterior motive, although unproven.
Manifest V3 disabled the <code>webRequestBlocking</code> permission in the <code>webRequest</code> API<ref>{{Cite web |date=2023-03-09 |title=Replace blocking web request listeners {{!}} Chrome Extensions {{!}} Chrome for Developers |url=https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |url-status=live |archive-url=https://web.archive.org/web/20250614074559/https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |archive-date=2025-06-14 |access-date=2025-08-12 |website=Chrome for Developers}}</ref>, preventing many ad content blockers from working.<ref>{{Cite web |date=2024-09-26 |title=Understanding Manifest V3 and the Future of uBlock Origin |url=https://ublockorigin.com/ |url-status=live |archive-url=https://web.archive.org/web/20250812114916/https://ublockorigin.com/ |archive-date=2025-08-12 |access-date=2025-08-12 |website=uBlock Origin - Free, open-source ad content blocker}}</ref> Google cites performance reasons <ref>{{Cite web |date=2023-03-09 |title=Replace blocking web request listeners {{!}} Chrome Extensions {{!}} Chrome for Developers |url=https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |url-status=live |archive-url=https://web.archive.org/web/20250614074559/https://developer.chrome.com/docs/extensions/develop/migrate/blocking-web-requests |archive-date=2025-06-14 |access-date=2025-08-12 |website=Chrome for Developers |quote="In Manifest V2, blocking web requests could significantly degrade both the performance of extensions and the performance of pages they work with."}}</ref>, but this is dubious; restricting content blockers prevents users from impeding their tracking and surveillance, meaning they can create a larger profit from the data gained. This is likely the ulterior motive, although unproven.


=== Google Assistant 3rd Party List Support ===
===Google Assistant 3rd Party List Support===
On June 20th, 2023, Google disabled 3rd party list support for Google Assistant<ref>{{Cite web |access-date=2025-09-16 |title=Where are my old lists? |url=https://support.google.com/assistant/answer/9415862#zippy=%2Cwhere-are-my-old-lists |archive-url=https://web.archive.org/web/20250427212604/https://support.google.com/assistant/answer/9415862#zippy=%2Cwhere-are-my-old-lists |archive-date=2025-04-27}}</ref>. This feature allowed lists through 3rd party services such as AnyList or Todoist to be managed via Google Assistant. The only list provider available through Google Assistant after this change was Google Keep<ref>{{Cite web |last=Mathur |first=Chandraveer |website=Android Police |date=2023-05-31 |title=Google Assistant is killing support for notes and lists integration with third-party apps |url=https://www.androidpolice.com/google-assistant-ending-support-third-party-notes-lists/}}</ref>.
On June 20th, 2023, Google disabled 3rd party list support for Google Assistant<ref>{{Cite web |access-date=2025-09-16 |title=Where are my old lists? |url=https://support.google.com/assistant/answer/9415862#zippy=%2Cwhere-are-my-old-lists |archive-url=https://web.archive.org/web/20250427212604/https://support.google.com/assistant/answer/9415862#zippy=%2Cwhere-are-my-old-lists |archive-date=2025-04-27}}</ref>. This feature allowed lists through 3rd party services such as AnyList or Todoist to be managed via Google Assistant. The only list provider available through Google Assistant after this change was Google Keep<ref>{{Cite web |last=Mathur |first=Chandraveer |website=Android Police |date=2023-05-31 |title=Google Assistant is killing support for notes and lists integration with third-party apps |url=https://www.androidpolice.com/google-assistant-ending-support-third-party-notes-lists/}}</ref>.


Line 54: Line 54:


===Not providing a solution for Pixel devices bricked due to switching slots, flashing certain ROMs, downgrading the OS, or installing the June 2025 update===
===Not providing a solution for Pixel devices bricked due to switching slots, flashing certain ROMs, downgrading the OS, or installing the June 2025 update===
Numerous Google Pixel phones have gotten bricked as a result of different use cases, such as accidentally switched slots, flashing custom ROMs or downgrading the bootloader version of the device after an Anti-Rollback (ARB) increment, accidentally or otherwise<ref>{{Cite web |last=Simons |first=Hadlee |date=2025-08-26 |title=Some Pixels are bricked and Google apparently won't help revive them |url=https://www.androidauthority.com/google-pixel-phones-bricked-3591218/ |url-status=live |access-date=2025-09-11 |website=Android Authority}}</ref>. The device enters an emergency download (EDL) state, where it refuses to enter fastboot or recovery mode, making it near impossible to repair. The only way to fix it is to load recovery firmware onto the RAM and flash a working version of Android from there.
Numerous Google Pixel phones have gotten bricked as a result of different use cases, such as accidentally switched slots, flashing custom ROMs or downgrading the bootloader version of the device after an Anti-Rollback (ARB) increment, accidentally or otherwise<ref>{{Cite web |last=Simons |first=Hadlee |date=2025-08-26 |title=Some Pixels are bricked and Google apparently won't help revive them |url=https://www.androidauthority.com/google-pixel-phones-bricked-3591218/ |url-status=live |access-date=2025-09-11 |website=Android Authority}}</ref>. The device enters an emergency download state called Pixel ROM Recovery, which is a Google modification of Samsung's EUB mode on Exynos chipsets. In this mode, it refuses to enter Android recovery or Fastboot, making it near impossible to restore the operating system on the device. The only way to fix it is to use Pixel ROM Recovery to boot a special, Google-signed recovery bootloader into RAM and flash a working version of Android from there.


However, this recovery firmware is inaccessible to the public, and is not possible to create without Google's private keys. This makes it impossible to repair a device in this state, other than to do a complicated J-TAG repair by unsoldering and resoldering the UFS chip or by replacing the motherboard altogether. Google stores and service centers outside of the US do not offer support for the device if it is out of warranty, even though the issue is completely fixable by software.
This recovery bootloader is just a regular bootloader as it appears in Google factory images, but with a special "USB boot" bit flag set to 1. <ref>{{Cite web |date=2025-08-11 |title=Pixel devices getting bricked / stuck in Pixel ROM Recovery after flashing AOSP-based builds with Android 15 QPR2 (BP1A.250305.019) |url=https://issuetracker.google.com/issues/402455330#comment19}}</ref>
 
However, this recovery bootloader is inaccessible to the public, and is not possible to recreate it without Google's private keys. This makes it impossible to repair a device in this state, other than to do a technically challenging repair involving desoldering the UFS chip to repopulate its contents or by replacing the motherboard altogether. Google stores and service centers outside of the US do not offer support for the device if it is out of warranty, even though the issue is completely fixable by software.


Numerous developers have worked on trying to find a solution to this issue, and have succeeded to varying extents. However, devices bricked due to the ARB trigger remain impossible to fix. Google has not provided any recovery images to resolve this issue, despite there being a sizable post on their bug tracker.<ref name=":4">{{Cite web |date=2025-08-10 |title=Pixel recovery bootloaders lack security reasoning for guarding |url=https://issuetracker.google.com/issues/437705274 |url-status=live |access-date=2025-09-11 |website=Google IssueTracker}}</ref><ref>{{Cite web |date=2025-03-12 |title=Pixel devices getting bricked / stuck in Pixel ROM Recovery after flashing AOSP-based builds with Android 15 QPR2 (BP1A.250305.019) |url=https://issuetracker.google.com/issues/402455330 |url-status=live |access-date=2025-09-11 |website=Google IssueTracker}}</ref> despite the fact that Google providing the recovery images for the repair will not compromise security, as explained by one of the developers in their report.<ref name=":4" />
Numerous developers have worked on trying to find a solution to this issue, and have succeeded to varying extents. However, devices bricked due to the ARB trigger remain impossible to fix. Google has not provided any recovery images to resolve this issue, despite there being a sizable post on their bug tracker.<ref name=":4">{{Cite web |date=2025-08-10 |title=Pixel recovery bootloaders lack security reasoning for guarding |url=https://issuetracker.google.com/issues/437705274 |url-status=live |access-date=2025-09-11 |website=Google IssueTracker}}</ref><ref>{{Cite web |date=2025-03-12 |title=Pixel devices getting bricked / stuck in Pixel ROM Recovery after flashing AOSP-based builds with Android 15 QPR2 (BP1A.250305.019) |url=https://issuetracker.google.com/issues/402455330 |url-status=live |access-date=2025-09-11 |website=Google IssueTracker}}</ref> despite the fact that Google providing the recovery images for the repair will not compromise security, as explained by one of the developers in their report.<ref name=":4" />