4 ms·
Google is also going forward with deprecating the blocking portion of the webRequest API, it is already in Chrome Canary. The change will break extensions, and
by dessant 7y ago
Google is also going forward with deprecating the blocking portion of the webRequest API, it is already in Chrome Canary. The change will break extensions, and will make several use cases impossible which are not related to ad blocking, but center around privacy and security, or just a need to modify requests for various reasons.
Their reasoning is so baffling, and technically incorrect about browser performance and security, that there is one conclusion to be made: Google and the Chrome team is dishonest about why they're partially deprecating the webRequest API.
Extensions are free to observe requests and page content, and exfiltrate data at will, but you no longer have full control over the requests Chrome is making. It is about control, not your privacy and security.
- userbinator 7y agoIt is about control, not your privacy and security. The big organisations behind browsers have been spinning it this way for years, and unfortunately the majority still haven't realised the truth. It's the same strategy that makes "think of the children" and "war on terrorism" arguments so pernicious --- taking away freedom by reasoning that it's for a cause so "ostensibly good" that no one would be seen arguing against.
- 3xblah 7y ago"... that no one would be seen arguing against." They know some would argue against. What gives this away as "spin" is that they will not make these changes optional. A Google user cannot opt out of signing in with Javascript enabled and permitting a device fingerprint to be taken. Even in the case where the user can accept the risks of allowing sign in without JS, e.g., automated sign-in -- which as we know is very convenient for many HN readers -- there is no way to opt out. For example, the user may have email accounts that she does not use for anything sensitive, throwaway accounts. More savvy users, who truly are concerned about security of Google Mail, might purposely avoid using @gmail accounts for important matters. It is of little benefit to such users if Google fingerprints their devices "in order to keep [those] accounts safe". However, the benefits to Google of identifying users via device fingerprinting are numerous. Google is an online advertising sales company.
- dTal 7y agoIf you ask me, the same is true of the current culture of "a device must receive (automatic!) OTA updates from the manufacturer or it is insecure, and local administrative control is dangerous." And the the underlying logic is the same, a kind of nannying philosophy that holds that people are too witless and irresponsible to be trusted with freedom, and for their own good must be shepherded and coddled by a friendly Big Brother. Between my laptop running Linux, on which I am root and no changes in software are made unless I specifically authorize it, and an Android tablet which is constantly downloading "updates" from Google (and uploading god-knows-what), I know which one makes me feel more private and secure.
- chihuahua 7y agoI'm hoping that the new Microsoft Edge based on Chromium is going to be a viable alternative (with uBlock Origin)
- NotSammyHagar 7y agoBut won't they just follow google's changes, just like this one? They are more of the same. I'd be really surprised if they do anything different and major like this.
- smileybarry 7y agoThey added Tracking Prevention a while back (which also blocks Google) and (so far) they haven't merged back some Chrome changes, like removing "reopen closed tab" from the per-tab context menu. Given Tracking Prevention I have faith they'll take a stand with webRequest.
- iggldiggl 7y agoI seem to remember hearing something somewhere that for the time being, Chrome might internally actually continue supporting blocking webRequest listeners for the sake of private extensions used within the context of enterprise deployments of Chrome. As long as that's true, maintaining a fork that allows blocking webRequest listeners for everybody should be comparatively easy. However the moment they are removing that feature for good and perhaps also start rewriting the network code, that's when things are going to be interesting for any forks that don't agree with that direction...