Konform Browser and other bits and bobs.
Thanks for checking in! Did you try importing the Release PGP Key listed under the release already? ^^ Maybe it’s a bit easy to overlook in the release notes but it’s right above the debian installation. There should be a pinned comment on that on the AUR package pages already.
If you save key to file on disk:
$ gpg --import ./konform-cb-ci.pgp
Then it should show up with that Key fingerprint when doing gpg -k after.
Please let me know still having issues
Someone asked me about donations. There is no way to directly fund the project today (TBD) but if you have cash to spare then:
Nice, I hope it lives up to expectations!
Oh and one more thing on the overrides: There are a couple of prefs flags that exist in one of Konform/LibreWolf but not the other mostly due to being based on different FF versions - so in case you have some particular override not being effective, I’d first check that it’s not just a case of differences between FF versions 140-147. Not expecting that to come up in practice and setting non-recognized prefs should be harmless, but knowing this might save some head scratching in case you have an extensive overrides config with recent additions.
Looking forward to any feedback you may have <3
Low-effort snark.
Yes! In fact while the browser otherwise has its own branding, it does recognize override config as librewolf.overrides.cfg so you can literally just drop your existing LibreWolf overrides file into ~/.konform and it should pick it up. Figured this would make it smoother for people migrating from LW or switching between the two.
Not personally daily-driving or actively recommending it but I’ve had to look closely at Brave as part of browser security work.
Most of the posts, articles and videos I’ve seen that don’t apply approximately equally to the other big names are mostly backed by arguments like “I don’t approve of BE behavior and BE made Brave therefore Brave bad”, “crypto scammers bad therefore crypto bad and Brave uses crypto therefore Brave bad” or “it’s being promoted by bad people and therefore bad”. I think such arguments are in themselves without merit, should be dismissed and are not sufficient to tell others they shouldn’t use it. Tribalism isn’t healthy. An opinion being widely shared doesn’t make it true. Your trusted influencer being upset doesn’t mean you need to be.
Valid criticisms of Brave and valid reasons for not using the browser exist but that’s rare to see written out but buried deep under the bulk of FUD, groupthink and uninformed meme-takes we find all over the stuff shared on socials. On the privacy and security sides it’s very much a mixed bag. Scrolling through Brave flags I note more than one thing I think we can take inspiration from. For people locked into corpware and limited to what’s on the major app stores, you can certainly do worse. Yet I see little concern-blogging over Copilot 365 .NET Live Edge or Samsung Internet Browser, for example.
Of course I’d personally love if you used Konform Browser (or any other non-chromium browser) instead but I mostly see people bashing Brave for completely confused reasons. Yes there’s bloat and ads and telemetry and problematic trust and outbound networking going on out of the box. Yes they inject their own monetization into the user experience if you blindly click “Next, Next, I agree, Next” and run with defaults. All just like for Firefox these days. And just like Firefox, user configuration exists to improve on much of that while the software license and open source code afford fixing the rest for the willing. The differences I’ve seen when it comes to the browsers are mostly in degrees, not fundamental. Maybe we should have a Brave fork too.
I hope I’m not canceling myself, here…
IronFox: Exists. Currently mostly due to hard thankless work of one or two individuals.
somerandomperson: OK they got this; everyone else stop trying and go home now
I don’t think dismissing the issue so quickly is fair to either the IronFox maintainer, the state of Android web security, or browser diversity. It is also discouraging for anyone else considering exploring this and sharing their work in public. We need more people working on an open and free mobile browser ecosystem, not less.
I mean technically Android is still somehow Linux so ^^. But it does feel funny when the first (and only?) follow-up comment on the Linux community of this Linux software is about needing an Android version instead :p
The more interested people we have checking it out and poking at the code, the higher chance we can ship Android builds Soontm. Feel free to swing by and stay tuned ;)
deleted by creator
You were literally asking for “trustworthy websites with recommendations”. GP is telling you to stop looking or even believing in such things existing. I’d agree.
The harder you search for just that, the more targeted you will be be scammers and cybercriminals. Whatever is a credible resource today may turn bad next month and public perception taking years to catch up. It’s not like that’d be a first.
That said, lots of good stuff and leads in codeberg.org/pluja/awesome-privacy. And +1 on EFF.
Grumpy ken thinks “Just use Foo” meming is promoting mindless use and I think should therefore be discouraged. Even in jest I think this affects us subconsciously to feel more comfortable with not thinking deeper for ourselves. Even if X is the right one. “Use Foo already!” is nicer~!
If I may illustrate:
Use Konform Browser1 already!
1: Disclosures: Am dev; is LibreWolf fork
DM me if you’d like to discuss further consulting on this project. I do think I could help you. However, reaching a proper design for this that is actually appropriate for your situation is non-trivial, goes beyond the scope of lemmy thread and would likely be paid.
I would also like these things to be easier and just be able to point you to something existing but the reality is they currently aren’t and such solution isn’t. But if you do push ahead and are open to sharing (potential security tradeoffs there too), maybe you’re in a position to be part of improving that situation.
Because it’s not something people commonly do. Because the GPG authors wanted to design for and encourage what they consider appropriate use and discourage and make difficult (but not impossible) what they consider inappropriate use. Removing a footgun for people not fully understanding the trust model of PGP or just slipping up doing that and then ending up in situations they didn’t account for. In general I could have a lot of criticism of the UI/UX of GPG but in this case I can see where they’re coming from and find this thread supporting it as working as intended so far.
That you need to have deep knowledge of obscure GPG internals to pull this off is by design. It’s not considered part of intended use. Similar thinking to why in Chromium you don’t have a button to bypass HSTS validation error but need to type in the cheat code “thisisunsafe”. It nudges users to stop and think more consciously about what’s going on.
The trust comes from the association. You can’t remove (or keep private) the association and expect to not have to separately rebuild the trust as a consequence. That what you are trying to do is made is inconvenient in GPG is quite intentional I believe. Or maybe I misunderstand your motivations, it’s a bit ambiguous and you leave a lot open for interpretation.
What I hear you say is: This would be convenient and easy for the user. Doing it differently, in a safer way that’s not problematically under scope for data protection regulations, would be more effort, not what you’re used to and “messy”. Certain useful features seem like they’d require more upfront work and the while system would be more complex and unfamiliar.
How is that relevant? None of that changes what you’re actually asking about or makes it a good approach. I don’t see how it’d make it either safer or less legally problematic?
What purpose does (certifying with) the primary key serve there if you don’t disclose it prior to rotation? What do you gain by not disclosing it when its only used in this context? It may be you haven’t thought it through fully but otherwise sounds like you can get what you want by separate primary keys which you then manually --sign-key between on demand.
The mention of Meta in the summary doesn’t fit. The article only mentions them in passing in reference to WhatsApp backups. Misleading and not relevant at all when talking about BitLocker. I think this is an editorial mistake but makes it read like subvertising, which is a shame for reporting on such a serious issue. How Google does keys for ChromeOS and Android would have been much more appropriate to compare with but for some reason this isn’t even mentioned.
There’s a lot to unpack here but just one thing:
Also potentially thinking may get some free webserver (basically like <20 api calls a days max and small dB with maybe 1000 rows) not for security of the data but more just not having open network ports to the internet without having the security infrastructure.
This sounds like the kind of data you really want to keep locally and I wouldn’t trust any free (or even affordable) webhosting business with it. I think it’s wise to keep the db and app server local and terminate the TLS locally too. You can still get a cheap VPS or two that you open a secure VPN (like wireguard) and/or SSH tunnel to. Then on the VPS you run can a second, outer, reverse proxy that forwards requests to your internal one over the gateway link. This way you get to keep the data local and safe without having to expose your home net online.
Many people enjoy Tailscale for this. There are full self-hosted options for that too but it sounds like their solution might fit your situation and requirements.
If even that feels unsafe, I really think you need to step up a bit on segregating and isolating your stuff, maybe do some homework on security, before putting sensitive stuff like this on shared infra…
I don’t want to deal with hippa or be responsible for medical data so I specifically don’t want to host the data
The only (legal) way to not deal with HIPPA is to make sure you’re not in scope for HIPPA. IANAL but it sounds like you (or worse, somebody else) will retain control and management of medical data with your intended approach no matter where you host it and how other users authorize?
You can’t architect, outsource, or encrypt your way out of that. A fully peer-to-peer solution which keeps the data on user devices and under their control and utilizes external server for signalling only but not for relaying or auth might get you there though.
GrapheneOS is as I understand it much less of a one-man party and in a healthier place these days compared to not that long ago. Good to keep in mind when digging up older material.
And whenever Graphene OS is mentioned, one must also mention its leader
Absolutely disagree with that you must do that whenever it is mentioned. That sounds like some unhealthy obsession if anything. There are more interesting conversations to be had. Don’t we have bigger fish to fry? Move on, dude.
Oh and I forgot to mention, we have an Arch repo now with prebuilt bin package too. If you add the repo and
pacman -Sy konform-browser-bin, then it will upgrade for you on futurepacman -Syuwhen there are new versions published.For trying out such a new project I guess you might still want to do the more manual route in the beginning but if/when you feel it’s earned your trust now you know <3