provide component updates via a GrapheneOS server about vanadium HOT 14 CLOSED

CRLSets are important since it's how certificate revocation is implemented. Chrome supports OCSP stapling but doesn't yet support Must-Staple. Must-Staple isn't properly supported by web servers since they don't have proper stapling support for it: https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/. That means it's essentially only adopted by people either not realizing or not caring that it's broken, unless they use an uncommon web server like Caddy where it works.

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#what_s-the-story-with-certificate-revocation

The Certificate Error Assistant component may also be important for providing good security UX.

CrowdDeny is part of Safe Browsing which isn't currently supported, but I'd like to get the local database mode working in which case this would probably be relevant.

I don't know what Safety Tips and File Type Policies do exactly.

In general, these things are components because they need faster out-of-band security updates than the regular browser updates.

from vanadium.

We added a component updates proxy via update.vanadium.app and dl.vanadium.app in the mean time, and might consider an Omaha server

from vanadium.

The most recent interaction I had with components is explained in the conversation of #42 but I opted to not use components there to download filters. You can look at a list of internal components via chrome://components/

from vanadium.

The amount of stuff that's going to need to be done is quite overwhelming, honestly. I wish there was much better documentation and a lot more useful compilation options. Despite there being a lot of other browsers based on Chromium, it's not currently being maintained as a shared base like LLVM, which is frustrating. Hopefully that can change.

from vanadium.

In general, these things are components because they need faster out-of-band security updates than the regular browser updates.

For all these features I would be inclined to use simple HTTP GET and the Last-Modified header as I did for the subresource filters because it makes it much easier for anyone to host the server-side part. Not much churn on the patch maintenance to report either.

I wish there was much better documentation and a lot more useful compilation options.

I have seen compilation options being reduced over time, but I understand it's a cost to maintain them and upstream wants to reduce it.

The amount of stuff that's going to need to be done is quite overwhelming, honestly.

I assume you are talking about the client aspect; if you wonder about the server aspect, @kiwibrowser might provide some pointers as I assume he did all of that already for the extensions (which are delivered in the same way as components).

from vanadium.

These should have more than just online HTTPS verification though and CRLSets itself is also involved in TLS verification.

from vanadium.

Other references about internal components/extensions:

• https://github.com/bromite/bromite/blob/67.0.3396.101/patches/BRM074_extensions-always-show-component-extensions-in-the-ext-list.patch (this patch is not included anymore because regular extensions are not in use in Android)
• https://bugs.chromium.org/p/chromium/issues/detail?id=768486 (about CryptoToken)

These should have more than just online HTTPS verification though and CRLSets itself is also involved in TLS verification.

I see; the downloaded content should contain an integrity signature then? In my scenario it would require some UI in settings to view and edit the public key signature as well, so that if one wants to replace the server side part he/she can change both URL and expected public key. I remember existing components/extensions do something like that already with PKI.

from vanadium.

An extensions support patch has recently surfaced, see bromite/bromite#533

I have not tried to use it but it might be useful for the implementation of this feature.

from vanadium.

Continuing from duplicate issue #118:

1. Is there a way to disable component updates until the updates come from a GraphenOS server?
2. Would a pull-request be entertained that specifically mentions the hosts that the Component Updates make connections to? I missed this in #118 because individual hosts were pointed out in the FAQ, but not for Vanadium.
   • update.googleapis.com
   • edgedl.gvt1.com
   • storage.googleapis.com

The component updates (13) observed in Vanadium 93.0.4577.82:

1. Federated Learning of Cohorts
2. Autofill States Data
3. Subresource Filter Rules
4. Crowd Deny
5. Certificate Error Assistant
6. CRLSet
7. Client Side Phishing Detection
8. Safety Tips
9. File Type Policies
10. Origin Trials
11. Optimization Hints
12. OnDeviceHeadSuggest
13. Autofill Regex Data

Screen shot: -------

from vanadium.

This thread should be used for discussion of the implementation of the feature. The issue tracker isn't a discussion or support platform. Please use the community support platform #grapheneos:grapheneos.org for discussing GrapheneOS and asking questions about it. We're aware of what's involved and don't need posts describing what this does and which components exist. What's needed is an implementation of the feature. Our focus is on Android 12 right now and anything like this is not going to happen for at least a month or more. It's not a good time for stuff like this.

from vanadium.

This thread is strictly about the component updater. Topics like dictionary updates are separate from this.

#88

It needs to be determined if we need the component updates and if we do we need to host our own component update server and mirror the updates. Ideally, we'd generate the data we need ourselves. That's a substantial task and ideally we won't need to do it. An alternative is simply disabling this, but it has to be done properly in a way that actually fully disables it and doesn't cause any problems. It shouldn't be causing it to repeatedly try/fail to download the updates. If it's going to be disabled, it should actually be disabled rather than just made non-functional.

I think this has all been adequately covered already. No one has stepped up to do the work on looking into each of the components and whether we need to have out-of-band updates, followed by writing a clean uninvasive patch fully disabling the component updater rather than simply breaking it and having it keep trying and failing to run. That's not going to be our approach in Vanadium. Simply reusing patches from elsewhere isn't satisfactory unless they're a proper implementation of what we want to have and are fully understood, verified to work and are something we can maintain properly going forward.

Please use the Matrix rooms for discussions, questions and support going forward. I've taken substantial time away from development to reply on these threads and I don't expect that it's going to result in any progress on this. Unless there's something unclear about the plan that has been laid out for this to someone that wants to work on it, it's unnecessary to post in the thread. Don't need confirmations and information on what we already know and have documented.

from vanadium.

We aren't interested in having more detailed documentation on things that we plan to change in Vanadium. Pull requests expanding the documentation will be closed. The work that needs to be done is implementing this feature, the dictionary feature and potentially one or two more similar ones involving downloads of static assets. Most of it has already been handled and we already have documentation on it explaining that the work is finished for the WebView but not the browser app. It's unclear why you're so concerned about private downloads of unprivileged static assets from Chromium's hosting rather than ours. You probably wouldn't care if we had simply reverse proxied it through our servers like Brave but that doesn't accomplish what we want to do. What needs to happen is someone spending the time on doing the small amount of work required to get these things done. These aren't large features. It would take someone unfamiliar with this a day of work to get done 4-5 of these small features via incremental builds + testing.

from vanadium.

Please consider the substantial time I've taken away from development work to respond here. I've done that in the hope that it results in someone outside our core development team stepping up to work on this whether it's you or someone else. It usually doesn't happen, which why small features like this we tend to leave for new contributors often don't get implemented for such long periods of time. We try to focus on the meatier issues and leave these ones for people to have something productive they can do to start getting into development. If we did all these easy issues first, we would be raising the barrier to getting involved and not ever getting done the important features.

from vanadium.

Please consider the substantial time I've taken away from development work to respond here.

My apologies, that was not my intention.

I'm evaluating GrapheneOS for the first time and #118 was simply an observation regarding downloading binary code from Google which seemed like a potential bug based on what I've read about GrapheneOS.

I had no idea what they were and my searches in Github issues didn't yield any matches for the domains in question. Thank you for explaining, but the issue descriptions in Github are very sparse or nonexistent so I'm sorry if things are already known and I'm only adding noise.

I don't have Chromium experience or the abilities to work on the issue at hand, so anything more from me is noise; I'll refrain from adding more. Sorry.

from vanadium.