I'd like to add a vote to the "don't break uBlock Origin or other ad blocking extensions" camp. I believe very, very strongly in maintaining my ability to use ad blocking software on my browser, and I will switch myself to another browser to maintain that capability if required.
I will also switch everyone I support on a technical basis, and begin blocking Google's ads on a DNS level for not only my personal network but also the networks I manage at work. Up until now we've mostly turned a blind eye to ads, since it wasn't worth convincing executives that they should greenlight DNS filtering and it helps to pay for the products we all use in our personal time, but if Chromium and Google begin actively working to subvert user choice in this manner, my team will be much more incentivized to figure out a less-targeted solution than an ad blocker.
I urge the Chromium team to reconsider. I know many of the developers working on this team are interested in building a better browser and providing a better user experience; this, however, will not further those goals.
I urge Google to resurrect a real and active Standardization effort around WebExtensions. This is the *only* part of the Browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementors any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view.
</Daniel>
--
Privowny, Co-CTO & Vice-President Engineering
Hi
I would also like to raise a concern regarding this. In addition to ad blocking this seems to affect
also security software that rely on extension capabilities of dynamically blocking https traffic that is
rated as malicious or otherwise harmful for user. This includes pages spreading mal/spy/whateverware,
but also for example parental control type of functions, i.e. protecting (child) user from content categorized
as harmful/unwanted for him/her.
1) the 30K rule limit is utterly small. Indeed, some anti-phishing list alone may include millions of entries.
To be clear:
1. This change _IS NOT INTENDED TO GIMP AD BLOCKERS_. Rather, it is designed to make them faster and more secure. (Yes, even despite the limitations that might impact uBlock.)
2. The new proposed content blocking API _is not final_ and can/will be changed.
3. Threatening to switching to Firefox is not helpful and _WILL NOT CHANGE GOOLE'S MIND ABOUT THIS_.
If you don't understand this, please refrain from commenting as you'll only be decreasing the signal-to-noise ratio in this thread and thus making it more likely that the entire thread (including those who are expressing actual legitimate concerns about the limitations of the new API) gets ignored.
If you want to help:
1. Explain a specific use case that the new API can't handle (including a technical explanation of _why_ it can't handle that use-case)
2. Suggest constructive changes to manifest V3's API that will improve its capabilities _while still adhering to the stated goals of manifest V3_
3. If you can't do any of the above, please refrain from commenting so you don't just make things worse
Sorry if I sound aggressive. It just really frustrates me when constructive technical discussions get hijacked by large volumes of unconstructive, uniformed comments. It makes it way harder to get real work done.
Is there a proposed timeline for this change? Will V2 stick around for awhile or will it be deprecated the moment V3 moves to production?
The design doc mentions that the "new declarativeNetRequest API will be used as the primary content-blocking API in extensions" which implies that there will be other means for content blocking. If so, which is it referring to or is it mean to say "only" instead of "primary"?
The design doc states that the primary reason for disabling the blocking-variant of the webRequest API is that extensions could - potentially - take a long time to come up with a response to a request. Considering that this change affects the API that tens, if not hundreds, of millions of Chrome/Chromium users depend on and that the declaractive variant of the webRequest API has never made it out of its experimental phase, which other options have been taken into consideration so far? (e.g. limiting the time an extension can take to handle a request or "punishing" it if it's consistently slow)
Will there be ways for extension developers to extend the built-in content blocking features that the browser provides?
In Manifest V3, host permissions will be granted by the user at runtime (similar to activeTab, but with options for the user to choose to always run on a specific site or all sites)
--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/59fd14bd-24b3-44a7-b683-a224fd1c6296%40chromium.org.
The webRequest API offers much more flexibility than the declarative version, and there are some known cases that it won't properly address. Because of this, we are certain that we will need to keep the webRequest API around. We are discussing limiting its capabilities, though these exact limitations are still being discussed (and is the main reason we are gathering feedback about what can/cannot be accomplished today with declarativeNetRequest).
We did think about approaches like this. Overall, a declarative approach offered greater benefits (ensured performance and guaranteed execution) versus potentially allowing content that would have otherwise been blocked in pessimistic performance cases. This is particularly important for privacy-related content blockers, where a user may need absolute guarantees that something will be blocked 100% of the time (and won't be allowed through if an extension took to long to decide - which could even happen based on external factors, like other programs running).
Can you expand on this a bit? Certainly declarativeNetRequest allows developers to specify their own list of sites in addition to the resources already handled by subresource filtering. If you're referring to to expanding API capabilities (offering different matching capabilities or actions to take), these would require updates to Chromium itself.
I cannot guarantee anything i'm just sharing my thoughts .This discussion can last forever but if you ask me the current implementation is really bad, i'm not saying that chrome should brutally restrict everything but some restrictions must be done.And regarding other proposed solutions like what you've mentioned the more granular permissions system , that's still doesn't change anything because third party lists have the ability to manipulate those headers and even if the user agreed to modify the csp header how can you guarantee that the injected header will not be malicious ? or if the extension have a vulnerability that allows CRLF injection which will cause the response to "split" . so if some threat actor compromised one of those lists the results can be catastrophic.LSS in the current implementation the extensions api's introduces huge security concerns .
If you're using/developing an "OS app" that executing/using some sort of logic from a third party lists than yes that's a big security risk and very bad practice.Now If you misunderstood me i'm quite sorry but as i wrote above my concern is the ability of those third party lists to influence the extension logic, the only way to restrict those api properly is to allow only hardcoded manipulation (exactly what this manifest suggests) so google algorithms can properly check them before the end user installs the extension, any dynamic css manipulation is perfectly fine but dynamic manipulation of sensitive headers that can be controlled by third party lists is for me a huge security concern.
If you're using/developing an "OS app" that executing/using some sort of logic from a third party lists than yes that's a big security risk and very bad practice.
Now If you misunderstood me i'm quite sorry but as i wrote above my concern is the ability of those third party lists to influence the extension logic, the only way to restrict those api properly is to allow only hardcoded manipulation (exactly what this manifest suggests) so google algorithms can properly check them before the end user installs the extension, any dynamic css manipulation is perfectly fine but dynamic manipulation of sensitive headers that can be controlled by third party lists is for me a huge security concern.
On Sunday, January 27, 2019 at 11:38:31 AM UTC+2, wOxxOm wrote:
--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/veJy9uAwS00/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a81c52f7-60c3-4809-bf5c-3738a4e496f3%40chromium.org.