Thanks! I noticed on one of my phones that RCS breaks once the Messages app is out of date by a certain amount of revisions. I hope this is an arbitrary decision by Google to invalidate older versions, given that the RCS protocol hasn't changed. I wouldn't want the Graphene team to have to keep up with each change Google makes with their Messages app, and instead is a security oversight Google has found in their own app.
We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.
Unbound is caching, not authoritative. Zones with dns records are served from authoritative DNS servers such as bind. Unbound asks authoritative servers for records and caches them locally, giving faster response and reducing load on authoritative servers.
I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal
I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
To be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
Strava doesn't have complete coverage, especially on newer trails, but more importantly: doing the trace via Street Complete attaches it to an OSM note with an optional (but encouraged) photo. This additional context makes it a lot more useful for editors than an ordinary trace, which can just as easily be an actual trail, a desire path, or someone deciding to improvise a shortcut through some brush. Even if the note just contains the word "trail", that helps us (though more detail is greatly appreciated, of course).
FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
I actually did that on purpose since all browsers support brotli I risked the possibility someone might have disabled it with an add-on. I wanted to see how many bots that would break. It may not be the most logical process but I just use CanIUse [1] to see what supports Brotli. I ignore the Opera Mini block as they seem to support almost nothing.
Nothing wrong with that. I think people should be able to disable anything they want. I doubt any commercial sites will do what I am doing. I use that little blog to test all manor of unorthodox things. That's why I listed the archive mirror, just in case.
I've seen commercial sites hard-code gzip content in all their responses regardless of the Accept headings. Probably just as fair to use Brotli these days.
Similarly, I've been using zopfli (gzip/unzip compatible) for png compression after quantization for db storage from 2-color (B/W) scans as it's directly compatible to the browser but winds up about 1/6 the original sized tiff. Not the best compression, had a discussion for a better compression, but required a wasm renderer to decompress as it isn't in the browser box.
[1]: https://learnosm.org/en/beginner/id-editor/
reply