[HN Gopher] Manifest V3 now available on M88 Beta
___________________________________________________________________
Manifest V3 now available on M88 Beta
Author : pspeter3
Score : 69 points
Date : 2020-12-09 18:05 UTC (4 hours ago)
(HTM) web link (blog.chromium.org)
(TXT) w3m dump (blog.chromium.org)
| rasz wrote:
| Right now (as of ~81) Chrome will load first website from
| previously saved session without waiting for extensions to
| initialize - all privacy/blocker extensions are ignored on first
| page load, "run_at": "document_start" is not obeyed, because
| loading first website 200ms faster once per daily session is more
| important than loading adblocker!
| https://github.com/Tampermonkey/tampermonkey/issues/1083
|
| The 'making extensions safer for everyone' Manifest V3 keeps the
| ability to spy on all traffic, but removes ability to modify
| headers/block requests. Killing Blocking (blocking = synchronous
| meaning wont complete until extension decides what to do with it)
| webRequest API means no more:
|
| -intelligent/dynamic blockers
|
| -User Agent modifications
|
| -modifying CSP rules to disable javascript/web fonts etc
|
| Google is removing control from users hands, from the code users
| want to run. This is one of the steps in a battle against general
| computing. https://boingboing.net/2012/01/10/lockdown.html You no
| longer own a computer, you own a Google Web Appliance.
| moritonal wrote:
| You still own the computer, you just download Chrome (rather
| than any of the alts) and give them power.
|
| It's Google that are breaking the internet for people, and
| getting away with it because of their market share. I've not
| used Chrome for ages and use Edge only where things don't work
| (like Google Photos).
| woofwoofwoof wrote:
| End of uBlock origin as we know it I guess?
| rasz wrote:
| Yes. End of uBlock, end of Twitch adblock, end of any blocker
| requiring in flight header modification to work.
| The_rationalist wrote:
| I'm not up to date on the topic but
|
| _Additionally, we are currently planning to change the rule
| limit from maximum of 30k rules per extension to a global maximum
| of 150k rules.
|
| The Declarative Net Request API now allows for the registration
| and removal of dynamic rules - specified at runtime rather than
| statically in the manifest. We've also added the capability to
| remove common tracking headers, such as Referer, Cookie, and Set-
| Cookie.
|
| The blocking version of the Web Request API remains available for
| managed extensions because of the deep integrations that
| enterprises may have between their software suites and Chrome._
|
| It seems that the publicized drawbacks have been addressed, which
| drawbacks remains? What could prevent uBlock Origin support?
| rasz wrote:
| This means every uBO user would have to install as "managed
| extensions" whatever this means. This pretty much kills uBO.
| acrispino wrote:
| See rgorhill's comment from 2018:
|
| https://bugs.chromium.org/p/chromium/issues/detail?id=896897...
|
| It's not just about the limit.
| The_rationalist wrote:
| Didn't gorhill update its view with the change made since to
| the v3?
| elaus wrote:
| The fact that they indicated to increase the rule limit for
| over a year but haven't done so yet (the beta still has a limit
| of 30k) doesn't seem like they really have addressed the
| drawbacks. I wouldn't think increasing that limit would take
| that much time if it's a pressing issue but maybe I'm missing
| something.
| kevingadd wrote:
| The limit is still 30k. As is typical with Chrome's devrel
| (they did the exact same thing with Web Audio multiple times)
| they tell the web community that they are going to fix
| problems, and then just don't fix anything and go ahead and
| ship a bad product. At best shouting about it gets a delay so
| you have more time to plan for the fact that they're shooting
| your product or service in the head.
| ComputerGuru wrote:
| FYI: Manifest v3 -> new Chrome extension manifest version.
| frongpik wrote:
| The manifest that disables uBO?
| blibble wrote:
| wow, even stooping as low as to quoting eyeo (the people behind
| AdBlock Plus), whose business model is to extort money out of you
| if you don't want to be blocked (their "approved ads" list)
|
| the annoucement of manifest v3 moved me to firefox, glad to see I
| didn't waste my effort
| kgwxd wrote:
| I've been having a hard time figuring out what Mozilla is
| really going to do with this. Best I can find [1] is "no
| immediate plans" to fundamentally break uBlock Origin. That
| phrasing makes me feel queasy.
|
| [1] https://blog.mozilla.org/addons/2019/09/03/mozillas-
| manifest...
| XzetaU8 wrote:
| Regarding Manifest v3 in Firefox, watch this recent video
| from the Ad Blocker Dev Summit 2020
|
| "Rob Wu & Philipp Kewisch - The Future of Content Blockers in
| Firefox - Adblocker Dev Summit 2020"
|
| https://www.youtube.com/watch?v=tpDFS-GUytg
| apazzolini wrote:
| Manifest v3 prompted my permanent move to Firefox as well. Good
| riddance, Chrome.
| dsissitka wrote:
| They did stop showing the value at [0] but if [1] is up to date
| it looks like the limit is still 30,000.
|
| What do you all plan to do?
|
| At the moment I'm using Brave. I like that their position on
| Manifest v3 has been clear since day one.
|
| Edit: I just tested it and the limit is still 30,000. Here's the
| error if you're curious:
|
| https://imgur.com/a/EmywSUk
|
| [0]
| https://developer.chrome.com/docs/extensions/reference/decla...
|
| [1]
| https://github.com/chromium/chromium/blob/987f407f2e293f9737...
| The_rationalist wrote:
| I read that _we are currently planning to change the rule limit
| from maximum of 30k rules per extension to a global maximum of
| 150k rules._
| dsissitka wrote:
| My concern is they said that 18 months ago and the limit
| still appears to be 30,000. I think I'm going to check out
| the beta and see if that's the case.
|
| Edit: I just tested it and the limit is still 30,000. Here's
| the error if you're curious:
|
| https://imgur.com/a/EmywSUk
| rasz wrote:
| That limit is just a red herring, they will bump it up at some
| point as a gesture of good will to drown out voices of valid
| opposition against the removal of blocking webRequest API. Its
| the classic Magicians look at my right hand move, while the
| left one is crushing little bird and pocketing its remains.
| celsoazevedo wrote:
| Time to move to Firefox or to a Chromium-based browser that will
| continue to support current extensions.
| [deleted]
| speedgoose wrote:
| I'm curious to see what Microsoft will do with Edge. That could
| give them a clear advantage.
| qnxub wrote:
| If DNS over HTTPS becomes standard, and Manifest V3 lands in
| Chromium-based browsers, Safari, and Firefox, how are we supposed
| to block ads?
| blibble wrote:
| I suspect the plan is to make ad blockers impotent by reducing
| their ability to adapt quickly to new forms of block evasion
|
| the ad blockers slowly become more and more useless, people
| stop using them entirely, and google's the biggest winner
| zamadatix wrote:
| There is a clear and obvious path to implementing Manifest V3 in
| a way that best serves users overall and this path involves
| working with the uBlock Origin team/gorhill and the concerns
| they've brought up with the change. Until that happens I refuse
| to believe any train of thought that this is a user focused
| change and not a ad revenue focused change. To be clear that it
| has some benefit to users that can be pointed out does not make
| the change user focused in the same way putting a solar cellphone
| charger on a cargo ship doesn't make it environmentally friendly.
|
| It'd be a different discussion if this was presented as an ad
| revenue focused change but it's presented as if it's user focus
| and the community is driving the direction of how it's
| implemented. Clearly this is not the case, in a conveniently true
| way, and it'd be such a simple thing to clear up. Even if the
| uBlock Origin team ends up saying "hmm, we really all got
| together and thought about it and there was nothing else to
| change that couldn't impact user privacy significantly" at least
| it removes the divide and controversy.
|
| Throwing references from companies with shady practices that
| exclude Google ads from their blocking does nothing to show a
| willingness to work with developers on what's best for users, in
| fact it makes the situation look even more shady.
|
| I don't know if gorhill reads HN but on the off chance he does
| thank you for your work.
| fastest963 wrote:
| I know a lot of people think Manifest V3 is here only to break
| adblockers but it seems like it's trying to solve a real problem.
| Adblockers currently only work by having full access to every
| tab, iframe, page, etc. What happens when an adblocker is sold
| and the new owner secretly installs spyware to steal all of your
| passwords and cookies? This has happened multiple times already
| with extensions in the past.
|
| It seems to me like Chrome is trying to limit use-cases that
| require full access to every single site you visit. How will
| Firefox solve this problem better than Chrome or Safari? It seems
| inevitable that the status quo for these extensions is going
| away.
| rektide wrote:
| > What happens when an adblocker is sold and the new owner
| secretly installs spyware to steal all of your passwords and
| cookies? This has happened multiple times already with
| extensions in the past.
|
| This idea that we need to keep locking down markets because one
| day things go bad is really really not good. We should not deny
| ourselves software because there are bad usages of it.
|
| These fear-inducing scenarios are all bad because they are low
| information marketplaces. The consumer has no idea what
| extensions really do, they don't see when major changes happen
| to the software they use, they don't see ownership changes,
| they don't see what data is gathered, they don't see where data
| goes. And yes, we can't expect consumers to watch & attend all
| of these things. Which is why it's important consumers be able
| to rely on each other, to have some way to signal danger &
| emergencies to one another.
|
| Instead of trying to create a marketplace where information &
| understanding can flow, instead of allowing genuine competition
| based on markets, we continue building markets assuming every
| buyers is & forever will be a totally blind idiot with no help,
| no friends, no other voices to help them make their decisions.
|
| I'm so fired of Fear Uncertainty and Doubt. The security
| apparatchik of the web today terrifies me. Deny deny deny.
| Close down close down close down. Severe connections, pull up
| the draw bridges, flood the moats, send out the alligators. I
| tire of these defensive wars, I tire of giving up ground,
| because the web has some pretense of being a perfectly secure
| place. I would much rather us be intertwingled, allow bold
| exploration of systems, mingling together, & while doing that
| figure out ways forward that permit some risk.
|
| Extensions are the most vital & powerful capability on the web.
| They are what make it better than everything else. Keeping the
| user sovereign, giving them amazing mind blowingly powerful
| extensions, is how the web keeps from becoming just another
| app. Those great powers can be abused. But we need to find ways
| to permit these powers to exist anyways.
| AaronFriel wrote:
| If I were a product manager at Google working on solving that
| real problem, I'd ask, "What are the APIs and permissions an
| ad-blocker needs to be able to function performantly?" And that
| would typically then involve going to stakeholders, i.e.:
| people who actually write adblockers, and asking them what they
| need.
|
| That is very, very obviously not what happened. And any attempt
| to spin this as "solving a real problem" ignores that Google
| employs tens of thousands of professionals who are trained to
| follow the approach above in response to solving problems. This
| is a business decision and the stakeholders aren't ad-blockers,
| they're ad networks.
| rasz wrote:
| Thats exactly what they did, they asked a question "What are
| the APIs and permissions an ad-blocker needs to be able to
| function performantly?" and killed the most obvious API to
| solve their problem.
|
| You see, Googles problem is not the same one as their users.
| Googles problem is lost revenue due to adblockers.
| danShumway wrote:
| > it seems like it's trying to solve a real problem
|
| People aren't mad that the Chromium team is trying to solve a
| real problem, they're mad that the Chromium team is utterly
| failing to solve that problem, and introducing new problems in
| the process.
|
| Under Manifest V3, requests can still be monitored, they just
| can't be modified. So this isn't really helping with spying.
|
| And even if the change did help with spying, _adblockers_ help
| with spying. Firefox will solve this problem better than Chrome
| or Safari by hopefully balancing the relative privacy risks
| from extensions and from ads and not by making clumsy fixes
| that introduce additional problems.
|
| We all recognize that extension security is an issue. The
| question is how to make things more secure without introducing
| additional privacy risks by weakening adblockers. If adblockers
| legitimately need full access to the page in order to work
| effectively, we can't just stick our fingers in our ears and
| pretend that they don't need that access. We can't just pretend
| that declarative blocking is good enough just because it would
| be more convenient for us if it was good enough.
|
| I would welcome a security model that made adblockers safer
| without making them less effective. Does anyone have one to
| propose? Because I don't want a half-baked solution implemented
| in my browser just because "we have to do something" -- and
| that's what I think Manifest V3 is.
| neolog wrote:
| Confiks comment above proposes
|
| > For example, they could have chosen a system where privacy-
| sensitive information like visited URLs are fed into a part
| of the extension which is a side-effect free function
| returning limited information. As they already have
| capability-based extension permissions, this would not be
| terribly hard to add if they would set their mind to it.
| danShumway wrote:
| On one hand, no, I don't think this would work, because
| part of what advanced adblockers like Ublock Origin allow
| is script insertion into pages and source rewrites when you
| request HTML pages. There's not a good, simple way I'm
| aware of to prevent data exfiltration in that kind of
| environment. Once I have the ability to change a page's
| source code before the browser loads it, I suspect I can
| kind of do anything.
|
| On the other hand, that proposal would make it at least
| marginally harder for malicious scripts to go undetected,
| and it's at least as much (if not more) of an improvement
| to privacy than the system Manifest V3 is going with, given
| that V3 doesn't prevent request monitoring, network
| requests from extensions, or script injection into the
| page. And there are probably ways to implement what you're
| talking about without breaking a huge number of extensions.
|
| So I don't think that's a solution, but it's significantly
| better than what Manifest V3 is trying to do.
| sneak wrote:
| > _Adblockers currently only work by having full access to
| every tab, iframe, page, etc. What happens when an adblocker is
| sold and the new owner secretly installs spyware to steal all
| of your passwords and cookies?_
|
| Perhaps installing something (A) on Monday should not give the
| developer/publisher the right or ability to arbitrarily exec B
| on your machine on Tuesday.
|
| No-interaction updates are the problem here. They amount to a
| remote code exec vulnerability, exploited just as you describe.
| userbinator wrote:
| Precisely. Google essentially introduced this problem
| themselves with silent updates --- that and perhaps the rest
| of the software industry that wants to turn everything into a
| service...
|
| The normalisation of silent change is one of the worst things
| to have happened to software in the last decade.
| jefftk wrote:
| An ad blocker that did not auto update would quickly go
| stale. Removing updating support for extensions would be even
| less popular!
|
| (Disclosure: I work for Google, speaking only for myself)
| sneak wrote:
| The logic in an ad blocker rarely needs to be updated, only
| the non-executable filter lists.
| jefftk wrote:
| If you have automatically updating data the extension can
| be an interpreter, which can be asked to do anything.
| sneak wrote:
| Well, sure, but it seems like extensions that download
| remote code are being explicitly banned by Google per
| TFA. I can't imagine that they intend that to extend to
| even non-executable tabular data.
| zamadatix wrote:
| It's an unrealistic expectation that the user is going to do
| anything other than click "allow" the 273rd time you ask if
| the extension they installed 5 years ago should be allowed to
| update.
| sneak wrote:
| The only expectation that I expressed is that installing
| program A on Monday is not automatic consent to
| automatically downloading and running a different program B
| on Tuesday, which I think is a wholly realistic one.
|
| It seems you believe that I was indicating that the user
| should be presented with prompts to update, when I said no
| such thing.
| yonixw wrote:
| Please give your alternative to manual update, instead of
| leaving us hanging...
| burtonator wrote:
| Chrome extension developer here and I can absolutely confirm
| that this is true.
|
| The last few years they've gotten more and more strict about
| which permissions they hand out.
|
| The one I need is similar to ad blocking and every time I
| request ANYTHING new they're very strict about explaining why I
| need it.
|
| Our extension Allows you to convert pages from HTML to EPUB and
| for this I need the ability to fetch any arbitrary image and
| read the data and that's not actually possible from Javascript
| due to CORS.
|
| The turnaround time for each approval is also increased and it
| takes about 72 hours for us to get approval for every change
| right now.
|
| Our extension if you're interested:
|
| https://chrome.google.com/webstore/detail/save-to-polar/jkfd...
| Confiks wrote:
| It indeed is trying to solve a real problem, but also
| conveniently breaks effective ad blocking. Doing that is a
| choice; there are other measures they could've taken to improve
| privacy to the same level while keeping granular blocking
| intact.
|
| For example, they could have chosen a system where privacy-
| sensitive information like visited URLs are fed into a part of
| the extension which is a side-effect free function returning
| limited information. As they already have capability-based
| extension permissions, this would not be terribly hard to add
| _if_ they would set their mind to it.
|
| More manual reviewing of valuable extensions would also be a
| path. They don't need to allow all extensions this permissions,
| and there doesn't need to be a level playing field for
| extensions here. It's just that Google doesn't see effective ad
| blocking as valuable, but rather the opposite.
| fastest963 wrote:
| I'm not sure how easy it would be to implement/ensure that a
| single function is side-effect-free in an extension given
| that the rest of the extension needs to be able to use the
| network and download filter lists.
|
| Safari went with an even more restrictive solution for
| content blockers and it seems like at least Chrome has been
| working with various developers to iron out the kinks with
| their solution before it goes live.
| rndgermandude wrote:
| It doesn't have to be side effect free, it just has to run
| in an execution environment that cannot exfiltrate data.
|
| Make it into a special kind of "content script", that gets
| a blank javascript environment that does not have any of of
| the usual means to communicate with the outside world (no
| XHR, no access to any DOM, no access to any message
| passing, and so on).
|
| E.g. a browser could have a special kind of "content
| blocker" script environment that gets fed request objects
| by the browser. The script can then examine all the data in
| the request object (the requested URL, the headers, etc)
| and make a decision to DENY or ALLOW and communicate this
| decision back to the browser in a single well-define way,
| and that's the only communication to the outside world it
| is allowed to do. No way for it to exfiltrate data.
| Extensions can be allowed to pass data into the environment
| via some form of uni-directional message passing, e.g. to
| update filter rules, but the content script cannot respond
| (and thus cannot exfiltrate data in a response).
|
| Browsers already define different execution environments
| with different APIs available in them for different
| purposes, e.g. you have the same-origin limited
| environments for websites that feature Web APIs such as DOM
| and XHR, and those environments come in different flavors
| (no access to certain APIs such as the location API if
| you're not "secure"), Proxy-Auto-Configuration (PAC)
| scripts have yet another environment, extension scripts get
| yet another environment, extension content scripts yet
| another, internal browser pages such as the settings pages
| of browsers often get environments with access to some
| privileged APIs etc. To define a few more specialized
| environments for privacy-sensitive stuff shouldn't be too
| hard.
| [deleted]
| gorhill wrote:
| > Chrome is trying to limit use-cases that require full access
| to every single site you visit
|
| That argument is always made and every single time there needs
| to be a reminder that:
|
| The webRequest API -- used to observe all network requests --
| will still be available, it just won't be able to be used to
| block or redirect network requests, but still can be used to
| observe all outgoing network requests and all incoming response
| headers.
|
| Additionally, content blockers require the injection of content
| scripts on all pages and all frames embedded in those pages in
| order to properly implement additional blocking mechanisms
| which can't be done through network filtering.
|
| So essentially content blockers such as the current crop of top
| content blockers will still need to see all the sites visited
| by users in order to meet what users expect from their blocker.
| fastest963 wrote:
| Previously the webRequest API was the only way to do content
| blocking but now that there's an alternate way to do it they
| can block extensions still using the old way or gate it
| behind a special scary warning.
|
| > Additionally, content blockers require the injection of
| content scripts on all pages and all frames embedded in those
| pages in order to properly implement additional blocking
| mechanisms which can't be done through network filtering.
|
| My OP was talking about a very real problem where extensions
| are being sold and nefariously used to sniff credentials
| because they have full control over the tab execution
| environment. How do you propose to solve that problem while
| still allowing adblocking?
| rasz wrote:
| There is no alternative way. You need to manipulate headers
| to modify CSP. No control over CSP means no way to block js
| from running altogether (Content-Security-Policy: script-
| src http: https:), to block web fonts (Content-Security-
| Policy: font-src *), to block twitch ads (overriding origin
| and referrer).
| magicalist wrote:
| > _Manifest V3 is here only to break adblockers but it seems
| like it 's trying to solve a real problem. Adblockers currently
| only work by having full access to every tab, iframe, page,
| etc._
|
| Indeed, which is exactly why Safari said they moved to this
| model years ago.
| danShumway wrote:
| And as a result, Safari has some of the worst adblocking out
| of any of the major browsers.
|
| Safari gets pulled out fairly often as an example of why
| declarative APIs are fine for adblocking, but if you actually
| dig into what the adblocking ecosystem around Safari looks
| like, it turns out it's a pretty good example of why
| declarative adblocking _isn 't_ good enough. There are tons
| of hoops to jump through, the best adblockers on Safari are
| running separate desktop applications to communicate with
| their extension and bypass some of Apple's more arduous
| restrictions. Talk to the Adguard devs about whether Safari's
| API is sufficient on its own to make an effective adblocker.
|
| The only reason why Apple's move got less criticism than
| Google's is because comparatively not many people use Safari,
| and most of us don't really care what the extension ecosystem
| looks like on Safari.
| ameshkov wrote:
| AdGuard dev here. Can confirm - it's not sufficient. But
| the reason it got less criticism is a little different.
| Content blocking in Safari was never good, and content
| blocking API when it just appeared was a move forward. The
| problem is that it's been five years and it hasn't got any
| viable improvements. Manifest V3 in its current state is
| already way ahead of Safari. But how good will it be 5 or
| 10 years from now?
| rasz wrote:
| Apple moved in this direction because Apple is all about
| restricting you from running any code Apple didnt sell to you
| in the first place. They are in a war against general
| computing.
| coldtea wrote:
| > _Apple moved in this direction because Apple is all about
| restricting you from running any code Apple didnt sell to
| you in the first place._
|
| This is about Safari, which is not about preventing you
| from "running any code Apple didnt sell to you in the first
| place". It's about security/privacy.
|
| > _They are in a war against general computing_
|
| Well, general computing has many shortcomings that don't
| exist in computer as appliance. For some, the latter is
| better.
| akalsz wrote:
| > This is about Safari, which is not about preventing you
| from "running any code Apple didnt sell to you in the
| first place". It's about security/privacy.
|
| I might be misunderstanding you, but isn't this
| "security/privacy" argument basically "end users can't be
| trusted when it comes to installing extensions that
| respect their privacy, so let's get rid of _potentially_
| malicious extensions with arbitrary content blocking
| logic and enforce our single way of content blocking
| instead "?
|
| Which certainly sounds like preventing the end user from
| "running any code Apple didnt sell to you in the first
| place".
| gnomewascool wrote:
| Yes, I totally agree that Manifest V3 solves some real problems
| -- in the case of many webextensions, I would welcome the
| ability to manually control which domains the extension can run
| in.
|
| However, the move to Manifest V3 also involves curtailing the
| power of extensions, including those that I trust as much or
| more than the browser itself. I want uBlock origin to be able
| to intercept and filter requests according to the logic that
| gorhill deems most sensible rather than however Chromium wants
| it to be done, since I trust gorhill far more than Google (and
| possibly slightly more than even Mozilla). I don't think that
| any of the tiny extensions that I've written to scratch my own
| itch require any of the capabilities removed in Manifest V3,
| but if they did, I'd also want them to keep having them.
| fastest963 wrote:
| > However, the move to Manifest V3 also involves curtailing
| the power of extensions, including those that I trust as much
| or more than the browser itself. I want uBlock origin to be
| able to intercept and filter requests according to the logic
| that gorhill deems most sensible rather than however Chromium
| wants it to be done, since I trust gorhill far more than
| Google (and possibly slightly more than even Mozilla).
|
| So what happens if gorhill's account is hacked or he gets
| tired of working on the extension and sells it to the highest
| bidder? These are not theoretical problems, they've happened
| multiple times in the past.
|
| I'm not saying Manifest V3 is the perfect solution but these
| are very real problems that cause me to not install any
| extensions that can access all sites.
___________________________________________________________________
(page generated 2020-12-09 23:01 UTC)