Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Resurrecting the Dillo browser

dillo-browser.github.io

Post reply on HN
Print view View original

171–179 of 179 posts

Re: Show HN: Resurrecting the Dillo browser

#171

Post by n3storm »

rodarima wrote: post #135
n3storm wrote: post #112

I suggest contacting this guy Renato Bravo https://www.youtube.com/channel/UCuklruLsO-CFoKK_rjNXrXg https://www.youtube.com/watch?v=A6mb9qt2-3o At video above Renato comments " ese es mi compañero Jorge " translated "that's my mate Jorge" I found a Renato Bravo at Linkedin but I don't think is the same person.

Good idea. I think it may be this one[1] as it is also from the same region Valparaíso in Chile as Jorge. I don't use LinkedIn, but if someone can message him that would be great, thanks! [1]: https://cl.linkedin.com/in/renatobravo

I found that "Renato Bravo" you link, but based on photo ressemblance I don't think they are the same person.

Re: Show HN: Resurrecting the Dillo browser

#172

Post by SuperHeavy256 »

Dillo? I haven't heard that name in years!

I remember growing up I used the Dillo browser almost daily on my Raspberry Pi(2012). It was faster than Midori, and got me just enough information so that I could learn python from tutorials on the Raspberry Pi website.

It felt a bit strange then, when everyone around me was using Chrome. But looking back, it taught me a big lesson in how to maximize the use of minimal resources.

Thank you for picking up this project and maintaining it. Till date, there has been no true successor to Dillo that manages graphical web browsing with such little resources.

Re: Show HN: Resurrecting the Dillo browser

#173

Post by rjzzleep »

rubymamis wrote: post #165
rjzzleep wrote: post #103

Earlier quoted context omitted.

When you run a chromium in headless mode it doesn't make the browser any lighter. I think what the OP means is that you need to have a browser with the most important JS and CSS functionality to render modern websites, but without all the junk on top of it. qutebrowser and nyxt would fit the bill better. to be honest I feel like nyxt is really cool, but I'm not sure if choosing a lisp was the right idea.

qutebrowser binary is 424MB (on macOS, at least). Is that considered light?

qutebrowser uses a qt-webengine library in the background, which is also basically a full chromium rendering engine, where not all features are exposed to the UI. It's only light in terms of UI. Just like a headless Chromium is only light on the UI side of things.

Re: Show HN: Resurrecting the Dillo browser

#174

Post by boomlinde »

shiomiru wrote: post #32

The extension system[0] seems interesting; it reminds me of w3m's local CGI scripts. (From what I can tell, w3m's local CGI came first, but I don't know if it influenced DPI and/or if w3m's system had a predecessor too...) For a short description of what w3m local CGI scripts can do: * They can be used for implementing a man page viewer, as in w3mman. It seems Dillo has a similar plugin[1]. * w3m's bookmark system is…

I can confirm that the extension system is simple and nice to work with. I implemented a thin Go library for writing Dillo plugins (https://github.com/boomlinde/dpi) and made a plugin for the Gemini protocol (https://github.com/boomlinde/gemini.filter.dpi). I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

Re: Show HN: Resurrecting the Dillo browser

#175

Post by rodarima »

boomlinde wrote: post #174
shiomiru wrote: post #32

The extension system[0] seems interesting; it reminds me of w3m's local CGI scripts. (From what I can tell, w3m's local CGI came first, but I don't know if it influenced DPI and/or if w3m's system had a predecessor too...) For a short description of what w3m local CGI scripts can do: * They can be used for implementing a man page viewer, as in w3mman. It seems Dillo has a similar plugin[1]. * w3m's bookmark system is…

I can confirm that the extension system is simple and nice to work with. I implemented a thin Go library for writing Dillo plugins ( https://github.com/boomlinde/dpi ) and made a plugin for the Gemini protocol ( https://github.com/boomlinde/gemini.filter.dpi ). I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

Thanks for your DPI work. I tested the gemini plugin and works very well.

My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that.

For now I uploaded Charles plugin written in shell script[1], which always trusts the certificate.

[1]: https://github.com/dillo-browser/dillo-plugin-gemini/

But I'm considering switching to the Go version if I can find a way to improve the UX.

Also, I kindly ask you to add the tag "dillo-plugin" so you can make Dillo plugins easily discoverable by searching for the tag in GitHub[2].

[2]: https://github.com/topics/dillo-plugin

> I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

This was done initially[3] (before 2007) but it was moved to the browser itself[4] in 2016.

[3]: https://github.com/dillo-browser/dillo/commits/afd2763caa56d...

[4]: https://github.com/dillo-browser/dillo/commit/bf5a7783f4a192...

Re: Show HN: Resurrecting the Dillo browser

#176

Post by boomlinde »

rodarima wrote: post #175
boomlinde wrote: post #174

Earlier quoted context omitted.

I can confirm that the extension system is simple and nice to work with. I implemented a thin Go library for writing Dillo plugins ( https://github.com/boomlinde/dpi ) and made a plugin for the Gemini protocol ( https://github.com/boomlinde/gemini.filter.dpi ). I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

Thanks for your DPI work. I tested the gemini plugin and works very well. My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that. For now I uploaded Charles plugin written in shell script[1], which al…

> My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers.

Hmm, yeah, it's a trade off. It never annoyed me personally so I haven't given it much thought, but I could add some means to configure this behavior. There should be a commit shortly.

I've been meaning to change how it behaves when the certificate differs from the pinned one as well, because as it is now you manually have to remove the old pinned certificate from the file system when a certificate is replaced, which isn't great but at least should happen much less often.

> Also, I kindly ask you to add the tag "dillo-plugin" so you can make Dillo plugins easily discoverable by searching for the tag in GitHub[2].

Thanks for the heads up! Done.

> This was done initially[3] (before 2007) but it was moved to the browser itself[4] in 2016.

I see, so I had the chronology mixed up :).

Re: Show HN: Resurrecting the Dillo browser

#177

Post by boomlinde »

rodarima wrote: post #175
boomlinde wrote: post #174

Earlier quoted context omitted.

I can confirm that the extension system is simple and nice to work with. I implemented a thin Go library for writing Dillo plugins ( https://github.com/boomlinde/dpi ) and made a plugin for the Gemini protocol ( https://github.com/boomlinde/gemini.filter.dpi ). I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

Thanks for your DPI work. I tested the gemini plugin and works very well. My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that. For now I uploaded Charles plugin written in shell script[1], which al…

I've updated the plugin so that you can switch between auto pinning and confirmation now, via a configuration file!

Re: Show HN: Resurrecting the Dillo browser

#178

Post by rodarima »

boomlinde wrote: post #177
rodarima wrote: post #175

Earlier quoted context omitted.

Thanks for your DPI work. I tested the gemini plugin and works very well. My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that. For now I uploaded Charles plugin written in shell script[1], which al…

I've updated the plugin so that you can switch between auto pinning and confirmation now, via a configuration file!

Thank you! :-)

Re: Show HN: Resurrecting the Dillo browser

#179

Post by rodarima »

badsectoracula wrote: post #92
rodarima wrote: post #87

Earlier quoted context omitted.

> The default site is still dillo.org which crashed the browser when it tried to visit it. Same with duckduckgo.com (crashed). Actually the crash seems to be related to some assert failure with OpenSSL as recompiling Dillo with mbedSSL lets me visit these sites. Thanks for testing! I need to replace that with the new website. Could you open an issue on GitHub with some details of your system and OpenSSL version so I…

Here[0], i submitted a bug report. The issue seems to be that some OpenSSL error isn't handled elsewhere, isn't removed from the error queue and the function with the assertion assumes the queue is empty. I put a breakpoint in ERR_put_error in the version that comes with openSUSE though there isn't much debug info there to be had so i don't know what the error is (perhaps building OpenSSL from source code with debug…

The problem is fixed now in master. It was caused by an attempt to shutdown the SSL session (which requires sending data) in a closed file descriptor, which is handled different between OpenSSL (no thread error queued) and LibreSSL (badsectoracula was using LibreSSL, which queues a thread error), and later causes an assert to trigger as it was not expecting any error in the queue. See[1] for more details.

[1]: https://github.com/dillo-browser/dillo/pull/59

Thanks again for the report, these type of issues are hard to reproduce without using different environments.

Post reply on HN