csagan5

/e/ uses all of Bromite's patches as well; I asked them to mention this in the About section, since it is basically a rebranded Bromite that they are shipping.

ungoogled-chromium[1] and Bromite[2] have had a patch to disable this for a while now

[1] https://github.com/Eloston/ungoogled-chromium/blob/14fb2b0/p...

[2] https://github.com/bromite/bromite/blob/410fc50/build/patche...

Nobody can uncritically take his side but what you are implying here is that we should consider him "less" because of an unrelated story.

In Chromium it might not be blocked just because of an oversight (or because there was no consensus), see my other comment (and its parent): https://news.ycombinator.com/item?id=23253264

Interestingly enough they are already blocking these attacks for background requests, see https://github.com/chromium/chromium/blob/83.0.4103.53/third...

Perhaps they simply forgot to cover also the WebSockets case, or the discussion on the related bug was not allowing for expanding the coverage.

Exactly, port scans on my public IP address are not an attack, but crossing the boundary to my localhost and private networks is malicious behavior.

There is an open Chromium bug for this: https://bugs.chromium.org/p/chromium/issues/detail?id=378566

I hope they consider it still valid and not close it.

These are the blocked ports: https://github.com/chromium/chromium/blob/83.0.4103.53/net/b...

Accessing localhost and LAN addresses works perfectly fine, except for those ports.

I am going to patch Bromite so that it doesn't allow any access to localhost nor private networks.

That's a good approach; the other alternative is to use F-Droid client, but it comes with its own bugs.

https://www.bromite.org/fdroid

> About security fixes, yes, between end of 2019 and today, new problems emerged in Chromium (not specific to Kiwi though), and there is some work to backport. Should it have been done earlier ? Certainly.

I am talking about telling users that they should not use a browser which is potentially vulnerable. Clear communication about the current status is not the same as planning an update.

> I see you have StartPage, DuckDuckGo, AdGuard, already in partners, and if they don't pay you, I encourage you to contact them, as they should.

There is no partnership with anyone. DuckDuckGo is a search engine already in upstream Chromium. StartPage search engine was removed months ago and some filters from AdGuard are used used in the combined Bromite filter.

There is no partnership and no payments of any kind because then there would be a conflict of interest to remove a search engine from the default choices while it is also a source of income.

> Also, thanks for the kind words at the end, you really pushed onto open-sourcing Kiwi too. Though sometimes you are a bit extreme for me :)

I am glad you are willing to be more open about these topics, these are I believe at the core of open source. I also wish you to make the project sustainable and fun to maintain.

You have not answered to the user's concern whether his browser is up to date with all the security fixes found in Chromium after v77.

I did not mention Bromite at all, what are you talking about?

There is no FUD here, let me write down some facts for you:

* users install Kiwi which does not contain all the security fixes of upstream stable Chromium (v81); this is been going on for several months now

* users do the same for Bromite and the Bromite SystemWebView

I warn everyone equally about this problem, nobody should run an outdated browser because of all the security issues, look at 2019 alone here: https://www.cvedetails.com/vulnerability-list/vendor_id-1224...

More facts:

* the current version of Kiwi, in Play Store and in source form, still is not up to date and covering the security issues fixed by upstream Chromium

* Kiwi was not open source until now and its repository was plain lying about it (https://web.archive.org/web/20190719191635/https://github.co...), making people think it was open source while you published only a few unusable patches

* even now there is no commit history making the source code unusable and unauditable

* you included trackers at some point in Kiwi and visits were going to some search server of yours

Did I miss anything? I am glad you decided to open source it but it does not change the above facts.

Kiwi: it is severely outdated and you installed it before it was open source.

And you trust instead a closed-source browser which has not been updated in months? Aside from the trust component I suggest you to use an up-to-date browser because of the security vulnerabilities which affect them.

Since there is no commit history I would also like to know which Chromium version this is based on, so that a diff can be made.

It had a GitHub repo (https://github.com/kiwibrowser/android) described as "source code used in Kiwi", but it was just a Chromium codebase thrown there without the actual patches.

Glad to see it's open source now however there is no commit history (thus no individual patches) and it's not possible to see which version of Chromium this was forked from.

It is not and has never been, see https://github.com/kiwibrowser/android/issues/12#issuecommen...

It could be argued that a similar violation is present (since March 2019) in Chromium for the Widevine CDM provisioning request, see https://github.com/bromite/bromite/issues/471

Basically all users opening the browser will contact www.googleapis.com to get a unique "Protected Media Identifier", without opening any web page and even before any ToS/EULA is accepted (and there is no user consent either).

The poster is the author of Kiwi browser, which unfortunately is closed source [0], but I have reason to believe he is familiar - as I am for the Bromite project - with all the (sometimes shady) internals of the Chromium codebase; it is indeed off-topic to discuss the header issue there but I would say that there is no explicit intention to derail it (and no advantage), just incorrect netiquette.

[0]: https://github.com/kiwibrowser/android/issues/12#issuecommen...

Credits to the ungoogled-chromium project [0] for the patch [1] which is also used in Bromite since 15 February 2018 to prevent this type of leaks; see also my reply here: [2]

[0]: https://github.com/Eloston/ungoogled-chromium

[1]: https://github.com/bromite/bromite/blob/79.0.3945.139/build/...

[2]: https://github.com/bromite/bromite/issues/480#issuecomment-5...

Edit: the article has been kindly edited, thanks to the author

> /e/ has modified the source code of various parts of AOSP and Chromium web browser to stop informing Google (and the NSA as a consequence of CLOUD Act) of user activity.

The article is incorrect also about the browser: it is simply packing a re-branded Bromite browser.

Yes, there have been some issues reliability with the host; they should be solved now, see also: https://github.com/bromite/bromite/issues/378

> They did add a reference to the original project to the AUTHORS file, so I'd like to believe in a variation of Hanlon's razor: Never attribute to malice that which is adequately explained by laziness.

This would be all fine and agreeable if they had not contacted me first, see my first comment :) of course I can still do contact them pointing out the situation, but let me say that given the nice project manifesto (https://e.foundation/wp-content/uploads/e-manifesto.pdf ) and the large amount of open source projects being involved...there must be expectations of this type :)

I do not claim malice - but I feel like the exact bare minimum was done there, which is not that surprising given that I declined creating/maintaining the customised fork that then they created.

By the way, Bromite itself is mostly a curated, maintained and adapted (for Android) list of patches from other projects, plus a good chunk of patches developed by me for Bromite itself.

I keep correct attribution of all patches as much as possible and I would feel more accomplished if also the work of other patches' authors (countless hours) is correctly referenced through Bromite.

See https://github.com/bromite/bromite/blob/master/README.md

Yes, I am aware of the repository.

> Have you already asked them to add a reference to Bromite somewhere in the about screen?

I have not; I was expecting it, given the amount of modifications from Bromite patches (which is zero, as far as I understood).

> I think /e/ is different from MS or Google in that it's possible to swap out most of the integrations with your own servers (it's all a bunch of glued-together open source services, after all).

It's that "most" that corrupts the intent.

> Without cloud integration, I doubt /e/ would reach any sort of mainstream or non-technical cult status at all.

Sorry, I will avoid discussing this, it has all the clues to become an endless and inconclusive talk :)

In short: yes, I agree with you, and still do not care about "mainstream or non-technical cult status" at all.

You're welcome :)

Thanks, fixed that by adding a space.

There is also https://grapheneos.org but I haven't tried it myself yet; I have spoken with the author a few times and it looks like an interesting project.

To be honest, '/e/' is also not that easy to search for.