Purism repository includes an old version of epiphany browser that hasn’t seen an update in a very long time and is suffering from some security vulnerabilities.
My suggestion if you are using epiphany browser is to use the flatpak version.
btw firefox-esr 115.7.0esr-1 is also suffering from some security vulnerabilities that have been fixed in debian since February 21.
Thanks for the note. Ever since the forum thread indicating that Firefox is funded by Google and keeps an always-on TCP connection to Google infrastructure even when no web page is open, I’ll admit I sometimes just flip open Epiphany and hope for some security through obscurity.
Also, it uses a mobile user agent by default, which can be nice.
Is there any libre browser available whose code is sufficiently simple and free of feature creep that it rarely or never has security vulnerabilities discovered, and accordingly needs no updates? I mean, human society has had 20+ years to make a web browser. If we can’t make a browser build that works flawlessly and requires no future updates, does that mean we’re somehow under attack by infiltrators causing us to mess up?
lynx. It was the first browser I used on Linux and really helped people move from gopher to http. The last CVE was 2016. There have been only 5 CVE’s in the last 17 years.
And, for better or worse, lynx does not support javascript.
lynx also often renders all the text just fine on many sites that only show a blank page or a bit of teaser text with javascript disabled. It’s also great for sites that set text to be slightly dark gray on a slightly light gray background or vice versa.
Thanks. 
No. I will use what I want. LUL
Updates aren’t there just to fix some security vulnerabilities, they can provide other things like better wayland support or better performance.
it is not like you have to update epiphany browser weekly or even monthly, debian shipped epiphany-browser version 43.1 which have all of those security vulnerabilities fixed to bookworm which crimson is based on a year ago.
The epiphany browser package that purism is shipping is based on a source code that hasn’t seen an update since may 2021.
you can say the same thing about the linux kernel or any other piece of software.
My GameBoy Advance from the year 2001 still runs flawlessly because it uses AA batteries and doesn’t interact with other peoples’ tech. Its software ran fine in 2001, and it ran fine in 2011, and it ran fine in 2021, and it runs fine today. And I have never performed an “update” to it. The laws of nature and the laws of physics have not changed since then, and so the software on that device had no need to change.
The necessity for updates only arises when (1) the original was done wrong and needs a fix, or (2) somebody wants a new feature.
If I want my browser to use HTTP to download and display HTML files, or even if I want it to execute JavaScript from within those files, these would not be new features versus how my browser operated in 2011 or 2021. So, the logical conclusion for why it was necessary for me to do updates since then is that the software was done wrong. Namely, software vulnerabilities.
And having vulnerabilities in this incredibly important software, for 10 years, seems bad. It just seems like someone didn’t do their best work, and it makes me want to go write my own browser that is absent any vulnerabilities so that I would no longer to deal with my important technology being infiltrated by operatives working against good tech.
no offense but it is clear to me that you don’t understand anything about software development.
if you think you can write your own browser that “is absent any vulnerabilities” then maybe you can help purism and write a browser for them.
Wayland is about to bye by on my L5. LOL
Everyone starts somewhere.
I understand quite a lot about software development. A wise developer who does everything right is often more valuable than a horde of ignorant developers creating a mosaic that almost solves many different problems, but doesn’t do anything right.
But as I age, I am aware that I am at risk of becoming less of a wise developer.
I would imagine, however, that if I found the time to create a browser built to have no security holes by being simple and being “done correctly,” that inevitably this would be unsuitable for Purism to distribute to general customers because customers would always ask for an ever-increasing feature set to meet their evolving demands. And I would see that as contrary to the beauty of my creation.
So, I will probably not do that. But I suppose my information is bad. It is a failure on my part that I haven’t sought out others who did do that, because it seems unlikely to me that no one has tried.
if that is the case you wouldn’t have said this “it makes me want to go write my own browser that is absent any vulnerabilities”, if you can do such a thing you would be the best programmer of all time.
modern browsers have millions lines of code, there is a review process, there are different types of tests that are being run against new code, there are stuff like fuzzing and even with all of that you still get issues.
if you think you can write a browser “absent any vulnerabilities” then you are quite delusional.
here are some articles explaining some aspects related to browsers development
I tried installing surf with apt on PureOS, but it seems that whenever I open it, it shows a title loaded from the target URL but the actual window showing is solid white. Maybe an issue with the byzantium version?
What if that is where they went wrong? It’s difficult to escape the social pressure to use JavaScript, but when I think about it some of the smartest folks I’ve encountered with regards to computer technology/security tended to suggest blocking or turning off JavaScript, almost entirely, even when using these millions-of-lines modern bloated browsers.
If we build a browser where JavaScript is not implemented at all, shouldn’t it be more possible to keep the code simple? That could be a possible starting point. Additionally, I would write my browser in a language like Java or maybe Rust (I don’t have rust experience) where the language makes it impossible to have memory errors. Instead of memory corruption that leads to arbitrary code execution, a bad input/stack overflow causes IndexOfOutBoundsException. Then, I would have computer security at the cost of performance. Why does my browser need performance? We have web browsers that run fine on Raspberry Pis at this point.
By creating a circumstance where bad inputs never corrupt program memory, fuzzing the inputs would become less of an issue. Security issues would be constrained to near-zero-size divs being used as trackers, and that could presumably be avoided by having a user control to give a page permission to load contents from other domains and starting from the premise that having one domain load content into the page from a different domain is a stupid idea because it’s not obvious to the end user. Instead of “Access-Control-Allow-Origin” where the browser is allowed to reach out to that other domain but maybe once it downloads content the other domain says “hey don’t use this,” instead we put the user in control in a more logical way and don’t contact other domains until the user approves it.
While you are developing your browser that lacks vulnerabilities and does not support javascript for security reasons, etc., the memory-safe language you should use to create the browser is… javascript! 
jk, but it would be funny!
It might make it easier to run your browser in chrome 
This is misleading. Epiphany is an interface around WebKit-GTK which gets security updates from Debian in PureOS.
This confusion could be avoided by Purism also tracking the browset from debian since there are security updates for epiphany-browser separate from WebKit-GTK and how is an end user to reasonably distinguish that the issue is resolved in this other package with a completely different name?
To claim that user confusion caused by poor Purism communication is missleading is… disingenuous at best. The root of the issue is on Purism not the user.
Then please check this CVE-2023-26081 : In Epiphany (aka GNOME Web) through 43.0, untrusted web content can trick users into exfiltrating passwords, because aut
and here is a proof of concept Unsandboxed Password Manager · Advisory · google/security-research · GitHub
and here is another one CVE-2022-29536 : In GNOME Epiphany before 41.4 and 42.x before 42.2, an HTML document can trigger a client buffer overflow (in ephy_strin
it is easy to write a proof of concept for it.
before i made my post i tested both of them and i was able to replicate them, then i used the flatpak version and i wasn’t able to replicate them.
and yes i am aware that Epiphany is using WebKitGTK.
Also here is Guido Gunther who reported CVE-2022-29536 CVE-2022-29536 (#39) · Issues · Librem5 / debs / Epiphany · GitLab in Jun 2022.
and you also have CVE-2021-45085, CVE-2021-45086, CVE-2021-45087, CVE-2021-45088 which from checking the code i wasn’t able to find the fixes that were implemented here Various XSS, including via page titles in about:overview (CVE-2021-45085, CVE-2021-45086, CVE-2021-45087, CVE-2021-45088) (#1612) · Issues · GNOME / Epiphany · GitLab
These seem like exactly the kind of vulnerabilities that I was saying earlier we should write software in a manner such that these cannot exist. The idea that a password manager dumps passwords into unsafe places on the screen is the result of the feature bloat concept of password managers which probably shouldn’t exist. My browser should never remember my password. If I don’t remember my password, that’s user error.
Similarly, the idea that "My... Title..." might report a string length of 10 instead of 14 and then write 4 characters out of bounds and give a maliciously crafted title access to malicious arbitrary code execution… is an example of software being developed in an egregiously incorrect manner or by someone who was being non-professional.
That’s why, I know it’s just my speculation, but I feel that people can do better. We could either only allow our software to be written by folks who know how to calculate the length of a string or thus failing, not allow those fallible developers who cannot compute the length of a string to write low level code. For example, people who can’t figure out string lengths probably should constrain themselves to Java or similar languages. Then, within the safety of a sandbox, they could implement systems like page viewing without fear for memory corruption regardless of how badly they write the code.