Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, they're not exactly of the same mind.

Apple blocks not only the content, but the ability to even monitor as well. So there is a little extra with the Apple way.

You'd hope google would follow suit, but given their business model it's understandable if they don't. (Not that I'm a supporter of Google's business model, just that I understand why the ability to monitor is still there.)



I can't follow your reasoning. How does Google's business model justify allowing 3rd party Chrome extensions to snoop on user traffic?


Chrome has not proposed any change that would prevent extensions from monitoring all traffic. You are ascribing a good motivation to Google, but Google’s actions are inconsistent with your hypothetical motivation.

Specifically, Google proposes to continue allowing extensions to observe all requests, but extensions can’t block requests based on these observations.


> extensions can’t block requests based on these observations

The new API is called "declarativeNetRequest" and allows extensions to block requests: https://developer.chrome.com/extensions/declarativeNetReques...

"There are the following kinds of rules:

* Rules that block a network request.

* Rules that prevent a request from getting blocked by negating any matching blocked rules.

* Rules that redirect a network request.

* Rules that remove headers from a network request."

> Google proposes to continue allowing extensions to observe all requests

Their expressed intention is to disallow such behavior in the future:

"The declarativeNetRequest API is an alternative to the webRequest API. At its core, this API allows extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension. Thus, instead of the above flow where Chrome receives the request, asks the extension, and then eventually gets the result, the flow is that the extension tells Chrome how to handle a request and Chrome can handle it synchronously. This allows us to ensure efficiency since a) we have control over the algorithm determining the result and b) we can prevent or disable inefficient rules. This is also better for user privacy, as the details of the network request are never exposed to the extension."

(Source: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...)


Quoting from the same page, one paragraph up from your big quote:

> In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged.

I rest my case.


Well, yes. There’s a transition in progress. I would expect the older API to be deprecated or removed in a future version, probably within a couple of years.


I'm sorry, are we seriously pretending that the "inefficient rules" aren't going to just happen to be the ones that affect Google ads?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: