Avira wants to contribute/build an own browser

[Thorsten Sick]

Hello Chromium developers

<cross post: security-team (they got it last week),
security-dev@chromium, chromium-dev@chromium, sorry>

My name is Thorsten Sick, I am a developer and security architect for
the German anti-virus company Avira. We got several million customers,
most of them are German/European (so we are not very well known in the
US). Our target customers are private customers - with no IT knowledge
required. We design our technology to be simple-to-use.

We are planning to ship a (more) secure browser soonish. I see it as a
distribution.

With that concept of a distribution we can add external Extensions by
default. The first one included is HTTPS-Everywhere.

I am experienced contributing to Open Source projects in the name of the
company (see: https://github.com/cuckoobox/cuckoo/graphs/contributors).
The browser team was formerly known as the Linux team, Open Source code
running through their veins.

Our concept (simplified) is to ship a Avira-branded Chromium. Security
features will be done in Extensions where possible or in external
programs (AV scanning). When a JS Extension API is missing we will add
it and send the code upstream (to avoid merge conflicts).

If we can minimize the difference between Chromium and "The Avira
Browser" to branding, default settings, pre-installed extension and
pre-installed external tools that would be great.

The Chromium security is very strong. But I think our speciality as an
AV company to classify files/behavior/urls will be an added benefit.

Doing the scanning in a proxy is not possible because more and more
network traffic gets encrypted ( \o/ ). So we will scan files/urls in
the browser.

Plus: With the proper Extension API something like behavior detection
in the browser will become possible.

We know about Aviator and want to avoid their mistakes....

What we need:

- Your feedback on our ideas so far
- A contact to someone who can help us setting up a repo to simplify
doing Pull Requests. Setting up the repo is not the problem. Doing it
smart - to reduce friction between us - is.
- Besides automatic merge/build/test (we want to be able to release our
version the same day as chromium gets released) there is a task we have
to do before we can start coding security stuff: Branding, maybe you can
point us to someone who knows more how to do it

Branding:
We want to replace the logo, add an extra line in the about dialog,
install in own path (so parallel installation is possible), pre-install
extensions, maybe have different default settings, direct users to our
own support page (you should not have to support our browser...).

We do not want to have any code-difference between Chromium and our
browser here, if we can avoid it.

To avoid merge conflicts a config file that is read during build time
would be best. Is there someone we can contact to get the relevant code
(to read the config file) into the chromium project ? Maybe also help us
doing our first Pull Requests (coding style, dos-and-donts, ...)

I want to reduce friction between our projects

Arne Usadel (in CC) is my boss and the boss of the browser team.

Any questions ?
Thorsten Sick

--
Avira Operations GmbH & Co. KG
Kaplaneiweg 1 | 88069 Tettnang | Deutschland / Germany
Telefon / Telephone: +49 7542-500 0
Telefax / Facsimile: +49 7542-500 3000

Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH | Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712 | Geschäftsführer: Travis Witteveen

Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters: Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief Executive Officer (CEO): Travis Witteveen

[John Abd-El-Malek]

If you don't have any code differences (which I agree it's best to avoid for a variety of reasons), then why go through the large effort of making your own releases and updates? Why not first try to make an extension that works with Chrome, and have your customers use Chrome's enterprise settings to ensure that it's installed on all computers on your customer's network? 

To avoid merge conflicts a config file that is read during build time
would be best. Is there someone we can contact to get the relevant code
(to read the config file) into the chromium project ? Maybe also help us
doing our first Pull Requests (coding style, dos-and-donts, ...)

I want to reduce friction between our projects

Arne Usadel (in CC) is my boss and the boss of the browser team.

Any questions ?
Thorsten Sick

--
Avira Operations GmbH & Co. KG
Kaplaneiweg 1 | 88069 Tettnang | Deutschland / Germany
Telefon / Telephone: +49 7542-500 0
Telefax / Facsimile: +49 7542-500 3000

Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH | Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712 | Geschäftsführer: Travis Witteveen

Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters: Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief Executive Officer (CEO): Travis Witteveen

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Mattias Nissler]

That indeed seems a sane first step before tying oneself to chromium's development and release cycle.

 

, and have your customers use Chrome's enterprise settings to ensure that it's installed on all computers on your customer's network? 

To avoid misunderstandings, enterprise settings are only an option for installations that have remote management e.g. via GPO. So that doesn't work for their "private customers" case mentioned at the top - which IIUC are consumer end users.

[Andrey]

You can read more informal tutorial about how to contribute to Chrome/Chromium here: http://meowni.ca/posts/chromium-101/ .

If you aren't going to replace Chrome interface like most other Chromium-based browsers do, just having separate branches of main repository for your version and the official version would probably be enough. I guess you don't want to change things like Blink or Pdfium, while all extension APIs and network code you want are in the main repository.

HTML templates that are used in Chrome interface are located in chrome/browser/resources folder. For example, about menu action opens chrome://chrome url which is produced from chrome/browser/resources/uber/uber.html and contains an iframe produced from chrome/browser/resources/help/help.html. Also look into chrome/browser/browser_resources.grd file which connects numerical constants in the code to actual resources. You can also find interface strings and references to their translations in ui/strings/ui_strings.grd, chrome/app/chromium_strings.grd and content/app/strings/content_strings.grd files. In general, all *.grd files are of interest to you. chrome/app/theme/theme_resources.grd file contains references to IDR_PRODUCT_LOGO id which corresponds to the Chromium logo.

BTW, are you going to implement auto-update? Chromium doesn't have one.

-- Andrey Khalyavin

[MSI Team]

Adding to the previous post:

Chromium does not auto-update and requires the user to completely re-download Chromium to receive updates. However, Chrome regularly auto-updates to its latest and greatest version, and allows the user to update it anytime. Chrome Canary is the most similar Chrome to Chromium but regularly auto-updates and allows user-requested updating.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Thorsten Sick]

Hi Andrey

Thanks. You made my day. Your answers simplifies so many of our next steps.

<removed cross-posting from security-dev, AFAIK they are all in this
list as well>

So far we wrote a POC doing changes in the code. We expected merge
conflicts and got lots of them :-) .Some of them can now be fixed by
changing config files/templates. There are things that can not be solved
that way:

The installation path is hard-coded. We want to install our browser and
it's config in a separate directory, so parallel installation (chromium
+ avira browser) is possible. It is a "functional" constant, not a UI
one. What do you think, would a code change that reads this kind of
"branding" data from a config file be accepted ? Where to place the
config file (maybe there is already one for that kind of information ?).
We would code it. Afterwards the browser would be more flexible, the
code cleaner and we would have less merge conflicts.

(Example: chrome/installer/util/browser_distribution.cc; base::string16
BrowserDistribution::GetInstallSubDir() )

For the updater: we will ship the browser with our own AV updater. We
will have to bundle it with the AV technology for scanning URLs/files
anyway. Thanks for the warning.

Thorsten Sick

> To unsubscribe from this group and stop receiving emails from it, send
> an email to security-dev...@chromium.org

> <mailto:security-dev...@chromium.org>.

[Peter Kasting]

On Tue, Mar 24, 2015 at 1:46 AM, Thorsten Sick <thorst...@avira.com> wrote:

What do you think, would a code change that reads this kind of
"branding" data from a config file be accepted ?

I'm not personally in charge of that, but if I were, I would propose that such a change be configurable at compile time rather than runtime.

In general, reading config files is more complex, more fragile, and potentially less performant, which are all reasons why we often prefer compile-time configurability.

 

Where to place the
config file (maybe there is already one for that kind of information ?).
We would code it. Afterwards the browser would be more flexible, the
code cleaner and we would have less merge conflicts.

(Example: chrome/installer/util/browser_distribution.cc; base::string16
BrowserDistribution::GetInstallSubDir()  )

This is already compile-time configurable -- note how different implementations exist in the source tree already.  Presumably, in your build you would add a chrome/installer/util/our_awesome_distribution.{h,cc} pair of files.

PK

[Thorsten Sick]

Hi

I would also prefer compile time. The config file I mentioned is a
compile config (or several). Like *.grd. Andrey Khalyavin pointed us in
the right direction.

One of our next tasks will be to experiment with the "official" way of
changing the browser. Currently we have kind of "sed s/chromium/Avira
browser/gi" in the source code as a proof of concept. As expected this
is not very sustainable.... But we had to find out what we want before
we can go to the next step: How to achieve it without breaking stuff.

We will be back with specific questions, I think.

Thanks
Thorsten Sick

[Will Harris]

>Besides automatic merge/build/test (we want to be able to release our

>version the same day as chromium gets released) 

[resend from right email!]

Hi Thorsten,

Chromium runs on a continuous build process so our build systems will typically emit a new build a few times a day.  Chrome has more of a regular release schedule with Canary, Dev, Beta and Stable becoming more and more stable and less likely to have introduced regressions.  Security fixes and regressions that are found after the next Chrome release branches will normally be manually back merged into Stable and Beta to ensure by the time Stable comes out, it (hopefully) has all the fixes, but none of the regressions.

If you are tracking the Chromium build then it's likely you might get regressions being introduced into your browser, as well as experimental or not-fully-stable code.

How often were you planning on updating/releasing your browser?  Were you planning on tracking chromium, or attempting to track e.g. Chrome stable branch-head?  When a security fix comes out will you be cherry-picking it into your release branch, or just building/releasing a new browser from head of chromium?

[Thorsten Sick]

Hello Will

Our goal is to build in sync with the chromium releases. Currently we
are creating our build systems and test systems.
There will be a long beta phase where we do release-fire-drills.

The exact plans are not final yet, but if we want to have a secure
browser, we will have to release with chromium (and not wait for the
attack windows to grow).

For that having the option to just brand the released chromium browser
by runtime config would have been cool. But we will manage with
compiling it ourselves.

There will be a Beta browser. Not sure yet if it is more towards a
nightly build or more towards a classic beta.

Internally we do have nightly builds already (chromium head + our mods
for comparison). But I do not know if making a brittle browser publicly
available has any benefits.

I think that we will cherry-pick security fixes into the stable
chromium. Is there a way to get notified when a out-of-band release is
about to happen ?

Currently we plan to have only one version out (not maintaining old ones).

Feature wise we will tend to be in the chromium (not chrome) line, so I
think that is the way to go. But you can still convince me (and the
team) to do it differently.

...you can see, we notified you all quite early, some things are not
decided yet :-) Lots of learning and experimenting is required.

Suggestions are very welcome
Thorsten Sick

Am 24.03.2015 um 19:21 schrieb Will Harris:
>>Besides automatic merge/build/test (we want to be able to release our
>>version the same day as chromium gets released)
>

> Hi Thorsten,
>
> Chromium runs on a continuous build process so our build systems will
> typically emit a new build a few times a day. Chrome has more of a
> regular release schedule with Canary, Dev, Beta and Stable becoming more
> and more stable and less likely to have introduced regressions.
> Security fixes and regressions that are found after the next Chrome
> release branches will normally be manually back merged into Stable and
> Beta to ensure by the time Stable comes out, it (hopefully) has all the
> fixes, but none of the regressions.
>
> If you are tracking the Chromium build then it's likely you might get
> regressions being introduced into your browser, as well as experimental
> or not-fully-stable code.
>
> How often were you planning on updating/releasing your browser? Were
> you planning on tracking chromium, or attempting to track e.g. Chrome
> stable branch-head? When a security fix comes out will you be
> cherry-picking it into your release branch, or just building/releasing a
> new browser from head of chromium?
>

> Will
>
> On Tue, Mar 24, 2015 at 4:54 AM, Thorsten Sick <thorst...@avira.com

> Telefon / Telephone: +49 7542-500 0 <tel:%2B49%207542-500%200>
> Telefax / Facsimile: +49 7542-500 3000 <tel:%2B49%207542-500%203000>

>
> Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> | Geschäftsführer: Travis Witteveen
>
> Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> Executive Officer (CEO): Travis Witteveen
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org

> <mailto:chromi...@chromium.org>

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>

[PhistucK]

When you write "chromium releases", you mean Chrome releases, as Chromium does not get released officially anywhere. Right?

There are very few commits to a release branch after it is released to stable, so if you track these commits (a few per day is the most, unless something drastic happens) and the Chrome release blog, you should always be up to date with the out of band releases.

Google does not support more than one released stable at a time, so you are aligned here. Out of band releases are patches to the current stable, not to the previous one.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Thorsten Sick]

Hi

Am 25.03.2015 um 15:04 schrieb PhistucK:
> When you write "chromium releases", you mean Chrome releases, as
> Chromium does not get released officially anywhere. Right?

Aem, right. Have to watch my wording. Using Ubuntu I get a "Chromium"
package, that just adds to my confusion :-)

> There are very few commits to a release branch after it is released to
> stable, so if you track these commits (a few per day is the most, unless
> something drastic happens) and the Chrome release blog, you should
> always be up to date with the out of band releases.

Two sources to monitor seems simple and reliable. Thanks.

> Google does not support more than one released stable at a time, so you
> are aligned here. Out of band releases are patches to the current
> stable, not to the previous one.

\o/

(Rainer Semma currently handles our build experiments, I added him to CC)

Thanks
Thorsten Sick

>
> ☆*PhistucK*

> <tel:%2B49%207542-500%203000> <tel:%2B49%207542-500%203000>

> >
> > Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> > 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> > Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> > | Geschäftsführer: Travis Witteveen
> >
> > Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> > 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> > Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> > Executive Officer (CEO): Travis Witteveen
> >
> > --
> > --
> > Chromium Developers mailing list: chromi...@chromium.org <mailto:chromi...@chromium.org>

> > <mailto:chromi...@chromium.org

> <mailto:chromi...@chromium.org>>
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/a/chromium.org/group/chromium-dev
> >
> >
>
> --
> Avira Operations GmbH & Co. KG
> Kaplaneiweg 1 | 88069 Tettnang | Deutschland / Germany
> Telefon / Telephone: +49 7542-500 0 <tel:%2B49%207542-500%200>
> Telefax / Facsimile: +49 7542-500 3000 <tel:%2B49%207542-500%203000>
>
> Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> | Geschäftsführer: Travis Witteveen
>
> Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> Executive Officer (CEO): Travis Witteveen
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> <mailto:chromi...@chromium.org>
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

> To unsubscribe from this group and stop receiving emails from it,
> send an email to chromium-dev...@chromium.org

> <mailto:chromium-dev%2Bunsu...@chromium.org>.

[Peter Kasting]

On Wed, Mar 25, 2015 at 7:44 AM, Thorsten Sick <thorst...@avira.com> wrote:

Am 25.03.2015 um 15:04 schrieb PhistucK:
> When you write "chromium releases", you mean Chrome releases, as
> Chromium does not get released officially anywhere. Right?

Aem, right. Have to watch my wording. Using Ubuntu I get a "Chromium"
package, that just adds to my confusion :-)

Many Linux distros don't ship official Chrome releases, but instead take our source code and provide it (or builds of it) to their users, sometimes with their own patches applied.

The Linux world is fairly messy and confusing in this regard compared to Chrome on other platforms.

PK

[Thorsten Sick]

Hi

After some experimentation with building we developed one more plan
(amongst others). We could code the command line option to pass a config
file that does the "branding". In that case we could start the browser
by a central control tool (that will also start our AV,
hooking-protection, ... other things to protect the browser). In that
case we could ship the default chrome as "The Avira Browser" (maybe we
find a better name till then).

For that to work we would also have to send all our Chrome extending
feature-patches upstream.

Branding will require:
- Changed standard paths (for parallel installation with chrome)
- Default extensions to load (they will be part of our protection strategy)
- Maybe some icons
- Replace some URLs (to our own support pages, for example. No one else
should have to do the support for our browser)
- Change the description in the about box from "Chrome" to something
like "The Avira Browser powered by Chrome" (to avoid confusion)
- Add a Avira browser version number

Plan A will be:
This config is compile time and we will compile the browser. Maybe merge
our security feature patches in as well. With Plan A we are more flexible.

Plan B is:
This config is run time and we can take the official chrome browser
(that already has our security-feature-patches). With this plan we will
be more on the security-patched side.

We will still have to build the browser ourself for beta testing. But
the panic-phase with staying in sync with security releases upstream
will be more relaxed.

I prefer Plan B. What is your opinion ? Do you want that runtime config
option ? We could write it and I promise: Without config there will be
no slowdown

Your opinion, please
Thorsten Sick

[John Abd-El-Malek]

On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick <thorst...@avira.com> wrote:

Hi

After some experimentation with building we developed one more plan
(amongst others). We could code the command line option to pass a config
file that does the "branding". In that case we could start the browser
by a central control tool (that will also start our AV,
hooking-protection, ... other things to protect the browser). In that
case we could ship the default chrome as "The Avira Browser" (maybe we
find a better name till then). 

For that to work we would also have to send all our Chrome extending
feature-patches upstream.

Patches are accepted on a case-by-case basis.  i.e. we can't make a statement here about whether any or all will be accepted or not. Given the large complexity in Chrome, owners might not want to add additional code paths just for a fringe (in relation to the total number of Chrome installations) use cases.

 

Branding will require:

Note that Google Chrome's branding can't be changed by others.

 

- Changed standard paths (for parallel installation with chrome)

- Default extensions to load (they will be part of our protection strategy)

We have stopped allowing third party software to modify the installed extensions for security reasons.

 

- Maybe some icons
- Replace some URLs (to our own support pages, for example. No one else
should have to do the support for our browser)
- Change the description in the about box from "Chrome" to something
like "The Avira Browser powered by Chrome" (to avoid confusion)
- Add a Avira browser version number

ditto to the above about this not being changeable for Google Chrome.

 

--
--
Chromium Developers mailing list: chromi...@chromium.org

[Avi Drissman]

On Thu, Mar 26, 2015 at 8:59 AM, Thorsten Sick <thorst...@avira.com> wrote:

- Change the description in the about box from "Chrome" to something
like "The Avira Browser powered by Chrome" (to avoid confusion)

As a side note, perhaps "... powered by Chromium", but not "... powered by Chrome". Chromium is an open-source project whose code you are building upon. Chrome is Google's Chromium-based browser, and you are not proposing building upon it.

Avi

[Thorsten Sick]

Hi

Sorry, I got confused by Chrome/Chromium (again). Seems depending on
what I just read/discussed I tend to continue to use on of those names.
Team internally we do not make that difference (but I agree there is
one)...How did you manage to keep them apart ? :-)

Am 26.03.2015 um 15:19 schrieb John Abd-El-Malek:
>
>
> On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick <thorst...@avira.com
> <mailto:thorst...@avira.com>> wrote:
>
> Hi
>
> After some experimentation with building we developed one more plan
> (amongst others). We could code the command line option to pass a config
> file that does the "branding". In that case we could start the browser
> by a central control tool (that will also start our AV,
> hooking-protection, ... other things to protect the browser). In that
> case we could ship the default chrome as "The Avira Browser" (maybe we
> find a better name till then).
>
>
> For that to work we would also have to send all our Chrome extending
> feature-patches upstream.
>
>
> Patches are accepted on a case-by-case basis. i.e. we can't make a
> statement here about whether any or all will be accepted or not. Given
> the large complexity in Chrome, owners might not want to add additional
> code paths just for a fringe (in relation to the total number of Chrome
> installations) use cases.
>
>
>
> Branding will require:
>
>
> Note that Google Chrome's branding can't be changed by others.

Ok, better replace that with Chromium. Are there any objections to
sub-brand chromium ? Are there any (legal) restrictions ? Best practices
? We do not want to hide the chromium heritage.

>
> - Changed standard paths (for parallel installation with chrome)
>
> - Default extensions to load (they will be part of our protection
> strategy)
>
>
> We have stopped allowing third party software to modify the installed
> extensions for security reasons.

Right. Thanks. A config file setting the default extensions would have
to be signed by a trusted entity. Verified on load. ...causing lots of
trouble in it's wake. The pre-installed extensions is a core concept for
us to add security features (less merge conflicts). So I assume Plan B
(runtime config) is much more complex than first thaught or maybe even
just failed. So back to Plan A (compile-time config).

> Telefon / Telephone: +49 7542-500 0 <tel:%2B49%207542-500%200>
> Telefax / Facsimile: +49 7542-500 3000 <tel:%2B49%207542-500%203000>

>
> Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> | Geschäftsführer: Travis Witteveen
>
> Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> Executive Officer (CEO): Travis Witteveen
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org

> <mailto:chromi...@chromium.org>

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>

[John Abd-El-Malek]

I'm still not sure I understand why you can't publish an extension that you point users to install. Yes it's not automatic, but even if you do all below, someone can just go and install a random browser that doesn't have any of this.

Chromium is BSD licensed so its pretty permissable.

[Thorsten Sick]

Hi John

Am 26.03.2015 um 16:06 schrieb John Abd-El-Malek:
> I'm still not sure I understand why you can't publish an extension that
> you point users to install. Yes it's not automatic, but even if you do
> all below, someone can just go and install a random browser that doesn't
> have any of this.

There will be a bunch of extensions (one extension per feature),
external programs (hook monitoring kernel modules to fight banking
trojans, Anti-Virus solution, ....) that will be bundled with the browser.

(by the way: My company already published some extensions. But if we
want to do the more crazy features we need a bit more control over the
browser. Just scanning for malware in downloaded files and urls gets boring)

What we will ship should not require _any_ technical know-how. Maybe
they even do not know what a browser is or does. So we will have to
install it all in one go. Full automatic. And keep the user interfaces
of the extensions simple.

These extensions will be in the store and everyone could just build a
similar browser by downloading them and getting our external tools, I
think. But that does not trouble me.

IMHO it now is essential to build security technology for everyone. Even
if it is a bit tricky....

Thorsten Sick

> On Thu, Mar 26, 2015 at 7:59 AM, Thorsten Sick <thorst...@avira.com
> <mailto:thorst...@avira.com>> wrote:
>
> Hi
>
> Sorry, I got confused by Chrome/Chromium (again). Seems depending on
> what I just read/discussed I tend to continue to use on of those names.
> Team internally we do not make that difference (but I agree there is
> one)...How did you manage to keep them apart ? :-)
>
> Am 26.03.2015 um 15:19 schrieb John Abd-El-Malek:
> >
> >
> > On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick <thorst...@avira.com <mailto:thorst...@avira.com>

> <tel:%2B49%207542-500%203000> <tel:%2B49%207542-500%203000>

> >
> > Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> > 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> > Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> > | Geschäftsführer: Travis Witteveen
> >
> > Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> > 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> > Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> > Executive Officer (CEO): Travis Witteveen
> >
> > --
> > --
> > Chromium Developers mailing list: chromi...@chromium.org <mailto:chromi...@chromium.org>

> > <mailto:chromi...@chromium.org

> <mailto:chromi...@chromium.org>>
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/a/chromium.org/group/chromium-dev
> >
> >
>
> --
> Avira Operations GmbH & Co. KG
> Kaplaneiweg 1 | 88069 Tettnang | Deutschland / Germany

> Telefon / Telephone: +49 7542-500 0 <tel:%2B49%207542-500%200>
> Telefax / Facsimile: +49 7542-500 3000 <tel:%2B49%207542-500%203000>
>
> Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> | Geschäftsführer: Travis Witteveen
>
> Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> Executive Officer (CEO): Travis Witteveen
>
>

--

[John Abd-El-Malek]

On Thu, Mar 26, 2015 at 8:17 AM, Thorsten Sick <thorst...@avira.com> wrote:

Hi John

Am 26.03.2015 um 16:06 schrieb John Abd-El-Malek:
> I'm still not sure I understand why you can't publish an extension that
> you point users to install. Yes it's not automatic, but even if you do
> all below, someone can just go and install a random browser that doesn't
> have any of this.

There will be a bunch of extensions (one extension per feature),
external programs (hook monitoring kernel modules to fight banking
trojans, Anti-Virus solution, ....) that will be bundled with the browser.

The choice of having multiple extensions is yours. You can also have one extension. This would also be better for the user as each extension incurs resource overhead.

[John Abd-El-Malek]

On Thu, Mar 26, 2015 at 8:31 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Thu, Mar 26, 2015 at 8:17 AM, Thorsten Sick <thorst...@avira.com> wrote:

Hi John

Am 26.03.2015 um 16:06 schrieb John Abd-El-Malek:
> I'm still not sure I understand why you can't publish an extension that
> you point users to install. Yes it's not automatic, but even if you do
> all below, someone can just go and install a random browser that doesn't
> have any of this.

There will be a bunch of extensions (one extension per feature),
external programs (hook monitoring kernel modules to fight banking
trojans, Anti-Virus solution, ....) that will be bundled with the browser.

The choice of having multiple extensions is yours. You can also have one extension. This would also be better for the user as each extension incurs resource overhead.

 

(by the way: My company already published some extensions. But if we
want to do the more crazy features we need a bit more control over the
browser. Just scanning for malware in downloaded files and urls gets boring)

I'm confused, earlier you mentioned that the changes are just related to branding, which didn't imply other changes in Chrome.

[Thorsten Sick]

Hi John

We want to add Extension API when we need it (for example: There is a
API that would allow to scan Downloads, but it seems not to be possible
to scan embedded PDF/Flash/Java objects - will have to verify that).
so we will add the API in chromium source, contribute it. And our
extension will then be able to forward these files to our scanner for
scanning. Malware Exploit Kits are using Java/Flash/Silverlight/PDF
Exploits.

We hope to make all chromium features generic, simple and nice, so you
will accept them. If you do not accept them, we can still compile our
own browser and merge our changes in.

Best case would be the only diff between our browser and the upstream is
branding, preinstalled extensions and additional tools running in
parallel. That's why we got the idea to maybe just have a config
handling these difference (either at runtime or at compile time).

We already experimented with adding features. We got our weekly merge
conflicts earlier than expected (<200 commits diff.).

We want to release our browser in parallel to the upstream releases
(security reasons). So avoiding merge conflicts is essential.

Currently we are still in the "let's experiment" phase. I want to
include you developers as good and early as possible, because I saw what
happened with the Aviator project.

Hope that sums it up quite well....
Thorsten Sick

> > <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>> wrote:
> >
> > Hi
> >
> > Sorry, I got confused by Chrome/Chromium (again). Seems depending on
> > what I just read/discussed I tend to continue to use on of those names.
> > Team internally we do not make that difference (but I agree there is
> > one)...How did you manage to keep them apart ? :-)
> >
> > Am 26.03.2015 um 15:19 schrieb John Abd-El-Malek:
> > >
> > >
> > > On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick <thorst...@avira.com <mailto:thorst...@avira.com>
> <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>

> > <mailto:chromi...@chromium.org <mailto:chromi...@chromium.org>>>

> > > View archives, change email options, or unsubscribe:
> > > http://groups.google.com/a/chromium.org/group/chromium-dev
> > >
> > >
> >
> > --
> > Avira Operations GmbH & Co. KG
> > Kaplaneiweg 1 | 88069 Tettnang | Deutschland / Germany

> > Telefon / Telephone: +49 7542-500 0 <tel:%2B49%207542-500%200> <tel:%2B49%207542-500%200>
> > Telefax / Facsimile: +49 7542-500 3000 <tel:%2B49%207542-500%203000>
> <tel:%2B49%207542-500%203000>
> >
> > Registergericht: Amtsgericht Ulm, HRA 722586 | USt.-IdNr.: DE
> > 815289569 | Pers. haftende Gesellschafterin: Avira OP GmbH |
> > Firmensitz: Tettnang | Registergericht: Amtsgericht Ulm, HRB 726712
> > | Geschäftsführer: Travis Witteveen
> >
> > Commercial Register: Amtsgericht Ulm, HRA 722586 | VAT-ID: DE
> > 815289569 | Personally Liable Partner: Avira OP GmbH | Headquarters:
> > Tettnang | Commercial Register: Amtsgericht Ulm, HRB 726712 | Chief
> > Executive Officer (CEO): Travis Witteveen
> >
> >
>
> --

[Thiago Farina]

You maybe understimating the complexity of managing a full release of a Chromium-based browser.

Are there really demand for more anti-virus features builtin inside the browser for Windows users?

--

Thiago Farina

[Paweł Hajdan, Jr.]

Please also note what happened to Rockmelt (http://rockmelt.tumblr.com/post/47705335178/an-update-on-the-existing-rockmelt-browser):

"What we didn’t know was how much time we’d spend keeping up with Chromium (the open source foundation of Chrome, upon which Rockmelt is based). What started out as 10% of our time soon became 50%–taking away cycles we needed to spend doing the innovative stuff that made us different."

Paweł

[Christian Biesinger]

FYI, NPAPI won't be supported much longer, so soon Java and Silverlight won't work in Chrome anymore.

-christian

[Thorsten Sick]

Hi Christian

Thanks. I already saw that. I really hope that will reduce the
plugin-based malware at least for this browser. If it turns out easy to
do I would still like to have a option to scan those embeded objects.
Complex file formats going into complex parsers from sources somewhere
on the internet.....always risky. Working on AV for several years now I
saw lots of innovation in malware we did not expect. Having an optional
second line of defense (by scan-classify-block) is good, IMHO.

And remember: Proxy scanning will be dead soon (HTTPS \o/ ) and we will
help to kill it by bundling Https-Everywhere to the browser. Currently
AV is able to scan most content at a local proxy. Currently we are at
20% HTTPS traffic. This will be more soon. (Let's encrypt).

By the way: Will be AFK next week. Other team members are reading the
list as well, but did not actively join the conversation yet.

Thorsten Sick

Am 26.03.2015 um 17:39 schrieb Christian Biesinger:
> FYI, NPAPI won't be supported much longer, so soon Java and Silverlight
> won't work in Chrome anymore.
>
> -christian
>
> On Mar 26, 2015 11:44, "Thorsten Sick" <thorst...@avira.com

> <mailto:thorst...@avira.com>> wrote:
>
> Hi John
>

> > <mailto:j...@chromium.org <mailto:j...@chromium.org>>> wrote:
> >
> >
> >
> > On Thu, Mar 26, 2015 at 8:17 AM, Thorsten Sick
> > <thorst...@avira.com <mailto:thorst...@avira.com>

> > > <mailto:thorst...@avira.com
> <mailto:thorst...@avira.com> <mailto:thorst...@avira.com
> <mailto:thorst...@avira.com>>>> wrote:
> > >
> > > Hi
> > >
> > > Sorry, I got confused by Chrome/Chromium (again).
> Seems depending on
> > > what I just read/discussed I tend to continue to use
> on of those names.
> > > Team internally we do not make that difference (but
> I agree there is
> > > one)...How did you manage to keep them apart ? :-)
> > >
> > > Am 26.03.2015 um 15:19 schrieb John Abd-El-Malek:
> > > >
> > > >
> > > > On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick
> <thorst...@avira.com <mailto:thorst...@avira.com>
> <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>
> > <mailto:thorst...@avira.com
> <mailto:thorst...@avira.com> <mailto:thorst...@avira.com
> <mailto:thorst...@avira.com>>>

[Thorsten Sick]

Thanks Pawel

We tech guys are very aware of this. But I did not know about Rockmet
yet. This blog will help us convince the non-tech guys that our approach
is the only one with some chance of success. That Blog confirms our
obervations from the last weeks. This is why our goal is to send our
changes upstream or implement as much as possible outside of the browser
(with the browser side changes being reduced to API to connect to).

I hoped to be able to do "branding" at runtime. But I just learned on
this list that this will be hard/impossible. Because an essential part
of what we call "our branding package" is pre-installing several
extensions. And this is not possible at runtime.

I am a little bit scared by the size but the options we would get are
worth the risk.

So far AV was very restricted by the OS/environment it is running on. If
there is not API for Foo, you can just fall back to scanning files....
This will be the first time we have the option to "prepare the
battlegound" and get all information we need from the tool we protect.

(Will be AFK next week)
Thorsten Sick

Am 26.03.2015 um 17:18 schrieb Paweł Hajdan, Jr.:
> Please also note what happened to Rockmelt
> (http://rockmelt.tumblr.com/post/47705335178/an-update-on-the-existing-rockmelt-browser):
>
> "What we didn’t know was how much time we’d spend keeping up with
> Chromium (the open source foundation of Chrome, upon which Rockmelt is
> based). What started out as 10% of our time soon became 50%–taking away
> cycles we needed to spend doing the innovative stuff that made us
> different."
>
> Paweł
>
> On Thu, Mar 26, 2015 at 4:43 PM, Thorsten Sick <thorst...@avira.com

> <mailto:thorst...@avira.com>> wrote:
>
> Hi John
>

> > > <mailto:thorst...@avira.com <mailto:thorst...@avira.com>
> <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>>>
> wrote:
> > >
> > > Hi
> > >
> > > Sorry, I got confused by Chrome/Chromium (again). Seems depending on
> > > what I just read/discussed I tend to continue to use on of those names.
> > > Team internally we do not make that difference (but I agree there is
> > > one)...How did you manage to keep them apart ? :-)
> > >
> > > Am 26.03.2015 um 15:19 schrieb John Abd-El-Malek:
> > > >
> > > >
> > > > On Thu, Mar 26, 2015 at 5:59 AM, Thorsten Sick <thorst...@avira.com <mailto:thorst...@avira.com>
> <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>
> > <mailto:thorst...@avira.com <mailto:thorst...@avira.com>
> <mailto:thorst...@avira.com <mailto:thorst...@avira.com>>>

[Thorsten Sick]

Hello Thiago

The last weeks we did several experiments on how to best
merge/build/release the browser and we already experienced that it could
be hard. We already integrated what we learned into our plans. Hope they
work.

We saw Banking malware that injects hooks into browsers (the Virus-Lab
guys who told me that just forgot which browser they tested....before
you ask. They will have to test again :-) ) So it is monitoring the API
calls.

Malware we saw monitors the browser and is waiting till the user opens a
banking web-page. Then it displays an own dialog "Hello I am your bank,
please enter your pin number here".

Malware we saw remote-controls the browser using a VNC session...

(all that has coffee-kitchen-chat-detail-grade. Will be investigating
into detail later)

These are all attacks from the outside into the browser. Some of them
can not be solved by the browser alone. We will never be as good as the
Security team handling SOP attacks, I think. But we know malware.

With that knowledge we can contribute the security of the browser. Some
things (anti-hooking) is better done in a kernel module.

I think as soon as we are in Beta I will start writing Blog posts with
more details and plans. Currently there is the Fog-of-war produced by
the merge/build/test process....

Will be AFK next week

Thorsten Sick

[Michal Zalewski]

Speaking of Aviator, please be also very careful and thoughtful with
the design of the extension itself; Aviator made extremely bold
security promises, but its ultimate failing was just an once-secret
implementation that did not live up to the claims.

In this context, I remember talking to Sorin Mustaca from Avira late
last year, when I think I noticed that your Chrome extension was
sending the visited URLs (including HTTPS ones!) via GET requests to
http://offers.avira.com/...

In general, I think there are very delicate privacy-usability
tradeoffs to strike when adding phishing and malware detection
mechanisms to browsers, and being very forthcoming about the design
and implementation may be a noble goal.

/mz

[Thorsten Sick]

Hi

Sorry for keeping you waiting, was out of office

Am 27.03.2015 um 18:57 schrieb Michal Zalewski:
> Speaking of Aviator, please be also very careful and thoughtful with
> the design of the extension itself; Aviator made extremely bold
> security promises, but its ultimate failing was just an once-secret
> implementation that did not live up to the claims.

I as a tech guy would aim for a "more secure browser". We never can be
perfect.

> In this context, I remember talking to Sorin Mustaca from Avira late
> last year, when I think I noticed that your Chrome extension was
> sending the visited URLs (including HTTPS ones!) via GET requests to
> http://offers.avira.com/...

Thanks. I forwarded that to the manager who is in charge. Hope this is
fixed or will be fixed soon. In this case it is quite simple (offers
being a convenience feature). With an extreme example it is easy to see
that sometimes there could be a privacy vs security tradeoff:

- The user is using TOR to be privacy protected
- At the same time, the best Avira technologies to protect against
malicious sites are cloud based (file cloud and url cloud)
- And we will have to solve it in a way that non-IT specialists can use
it :-)

Hope we will find an acceptable approach. The user should at least be
informed about the side effects each technology has and have a smart
auto-pilot guiding him.

> In general, I think there are very delicate privacy-usability
> tradeoffs to strike when adding phishing and malware detection
> mechanisms to browsers, and being very forthcoming about the design
> and implementation may be a noble goal.
>
> /mz

Interesting years ahead...
Thorsten Sick