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

From Markdown to remote code execution in Atom

statuscode.ch

Post reply on HN
Print view View original

101–110 of 152 posts

Re: From Markdown to remote code execution in Atom

#101

Post by twoodfin »

jeswin wrote: post #12
cabalamat wrote: post #8

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

I understand the sentiment and dislike laggy UIs, but browsers have been running millions of apps securely on billions of computers for ages. No browser exploit has led to worldwide data compromise. In fact, being able to run untrusted code at this scale represents the pinnacle of security engineering feats. There have also been plenty of exploits in applications written entirely with native code.

It seems to me that the one of the challenges in reaching that pinnacle was adequately quarantining browser-hosted code from local resources and capabilities. But frameworks like Electron are designed to expose the latter to the former, otherwise they’d just be WebKit in a window.

Re: From Markdown to remote code execution in Atom

#102

Post by pvg »

rootlocus wrote: post #92
pvg wrote: post #87

Earlier quoted context omitted.

Your argument was that Qt and Swing apps looking like shit 'could not be further than the truth'. Your counter-examples are a pair of apps that do next to nothing and a really bad app.

My argument is that it takes a few hours to make a look and feel for swing that mimics the appearance of modern electron apps. Also that Qt has plenty of styling power. Blizzard's app is a "really bad app" just because you have a personal problem against it. It works pretty well on my PC (0.5% CPU and 130Mb ram) and I think it looks pretty nice.

Lots of people dislike the Blizzard app but if you like the Blizzard app or spent 5 hours beating a single Swing frame into looking like a web app with questionable typography, we probably have very different (subjective) notions of what a decent-looking app is.

What you did say is that Qt or Swing apps looking bad cannot be further from the truth. If that were the case, you should be able to rattle off dozens of beloved, beautiful, complex Qt or Swing apps. Most cross-platform UIs (including those based on Electron) look and behaves poopily. The few that don't are the result of exceptional effort and focus.

Re: From Markdown to remote code execution in Atom

#103

Post by AgentME »

sigzero wrote: post #46
megous wrote: post #11

Earlier quoted context omitted.

As long as you don't load untrusted code or content... I guess many of the issues are moot if untrusted code can't get access to javascript and is only exposed to HTML parser (DOMParser). The way I'm using electron for my pet projects is only passing untrusted HTML to DOMParser and then sanitizing with strict whitelist of attributes/html elements. Only then will any HTML code get interpreted by the browser engine. Fe…

"As long as you don't load untrusted code or content..." Because end users are soooo good at that?

They're referring to the application developer.

If the developer uses Electron only to open the application's own html files and doesn't render user-provided HTML anywhere, then there won't be any XSS vulnerabilities.

Re: From Markdown to remote code execution in Atom

#105

Post by avhon1 »

Tehnix wrote: post #80
cabalamat wrote: post #8

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

> I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Great idea! Now show me an application that can be extended in the same way Atom can, that didn't have 30-40 development behind it...

30-40 whats? Years? Developer-years?

Re: From Markdown to remote code execution in Atom

#107

Post by Tehnix »

avhon1 wrote: post #105
Tehnix wrote: post #80

Earlier quoted context omitted.

> I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Great idea! Now show me an application that can be extended in the same way Atom can, that didn't have 30-40 development behind it...

30-40 whats? Years? Developer-years?

30-40 years of development. I was alluding to VIM or emacs, and even they still suck immensely on the GUI front. The emacs TUI and GUI is embarrassing for something that had access to async features for so long, and VIM frontends are only progressing in the immense speed their are because of Neovim and the clean separation they made of the logic and the UI.

Re: From Markdown to remote code execution in Atom

#108

Post by blub »

qudat wrote: post #16
zx2c4 wrote: post #10

This is why I don't run any Electron apps on my computers at all, ever. That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron. I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's be…

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…

Electron is not really fast, nor does it generate great GUIs. It's much younger than Qt, only four years old. It's not frequently updated, it uses an insecure version of the Chromium browser. So... not all positives can be applied.

In fact none can be applied except ease of use and it's about the same, until the app grows and one realizes that the typical JS architecture is as easy to structure as a pile of mush.

Electron supporters are really taking the piss in this thread. Slapping together a bunch of statements which can be easily disproved doesn't qualify as an argument.

Re: From Markdown to remote code execution in Atom

#109

Post by anonfunction »

syn_rst wrote: post #69
scotty79 wrote: post #59

Earlier quoted context omitted.

Apparently there's a reason because VS Code (and Atom) is way more useful than any other editor built over last few decades.

And yet somehow neither of them can compare to text-mode editors built more than 30 years ago.

I like to use both, depending on what I'm working on. If I'm writing code then a vim / tmux combo can be great but if you're editing markdown or an html / css website having the live preview and same developer tools as the browser is really nice.

Re: From Markdown to remote code execution in Atom

#110

Post by blub »

jeswin wrote: post #12
cabalamat wrote: post #8

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

I understand the sentiment and dislike laggy UIs, but browsers have been running millions of apps securely on billions of computers for ages. No browser exploit has led to worldwide data compromise. In fact, being able to run untrusted code at this scale represents the pinnacle of security engineering feats. There have also been plenty of exploits in applications written entirely with native code.

Browsers can barely open a simple web page without getting owned. They're probably the number one infection vector nowadays...

This has lead to some pretty bad hacks. I'm not sure what more you could want really, a vulnerability where people can be punched in the face over the internet?

Post reply on HN