search

brave / go-update

Component update server for brave-core written in Go
Mozilla Public License 2.0
29 stars 23 forks source link

Use chromium version to determine AdBlock version #23

Open jumde opened 5 years ago

jumde commented 5 years ago

For example ad-block is currently on format v4. That's where this 4 comes from in: ~/Library/Application\ Support/BraveSoftware/Brave-Browser-Beta/cffkpbalmllkdoenhmdmpbkajipdjfam/1.0.133/4/ABPFilterParserData.dat

The Brave Browser is smart enough to know to update the extension to v5 if it has client code from brave/ad-block that specifies the current version as v5 format.

The problem is, we need to go to version 5 format soon. This wouldn't be a problem for it landing in master only. But to do this we need to be able to keep old installs still working.

we'd want the ability to update extensions differently depending on the Chromium version in use.

So mainly we'd like to have the ability to have Chromium 73 and below use a differently packaged format v4 extension. And Chromium 74 and above use a differently packaged format v5 extension. Both would keep the same extension ID.

This would need changes for both brave/brave-core-crx-packager and brave/go-update. Mainly we'd just coordinate ad-block format updates on major chromium update releases so it works out nicely.

antonok-edm commented 4 years ago

See also discussion from https://github.com/brave/brave-browser/issues/7316.

There is an example of minimum version querying on the autoupdating developer documentation:

Advanced usage: minimum browser version

As we add more APIs to the extensions system, it's possible you will want to release an updated version of an extension or app that will work only with newer versions of the browser. While Google Chrome itself is autoupdated, it can take a few days before the majority of the user base has updated to any given new release. To ensure that a given update will apply only to Google Chrome versions at or higher than a specific version, you add the "prodversionmin" attribute to the element in your update manifest. For example:

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
   <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' prodversionmin='3.0.193.0'/>
  </app>
</gupdate>

This would ensure that users would autoupdate to version 2 only if they are running Google Chrome 3.0.193.0 or greater.

mherrmann commented 4 years ago

Would it make sense for me to look into implementing this @jumde? We can get the browser version from prodversion in the request: {"request":{"@os":"linux","@updater":"","acceptformat":"crx2,crx3","app":[...],"arch":"x64","dedup":"cr","hw":{"physmemory":15},"lang":"","nacl_arch":"x86-64","os":{"arch":"x86_64","platform":"Linux","version":"5.8.0-0.bpo.2-amd64"},"prodchannel":"stable","prodversion":"87.1.18.38","protocol":"3.1","requestid":"{634731f7-ab1c-4247-a437-fc05a529b054}","sessionid":"{6695c16e-6687-459e-a577-0797f803282a}","updaterchannel":"stable","updaterversion":"87.1.18.38"}}

mherrmann commented 4 years ago

@pes10k @antonok-edm do you still need this feature? @jumde suggested I ask you.

pes10k commented 4 years ago

@mherrmann this would be handy (though better to key off the brave version than the chromium version, if we need to fix something in a hot fix). This would be very handy because then we could have more flexibility in changing the structure of the adblock DAT files, which would make a number of things much more plesant.

It would also be good to all us to key off the brave version when fetching HTTPSEverywhere data, for similar reasons