As soon as I saw the title I suspected the exploit was probably markdown related, as I had fixed pretty much the exact same issues in VS Code. Two things to keep in mind when developing electron apps:
- The potential impact of an XSS or other security exploits is much higher. You can limit the impact of most of these with additional layers of security, such as running untrusted html in isolated environments with node integration disabled. However, also remember that...
- Many security features are opt-in. Content security policies (CSP) are a good example. Pages without a CPS default to allowing anything, which sort of makes sense in browser world for backwards compatibility, but is not a good idea for desktop apps.
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.
Whilst there haven't been that many data breaches, I'd argue that's because the browser is operating at the edges of your architecture, not in the centre, where the data lies.
However, to say that browsers are secure is pure nonsense. Browsers get exploited all of the time, I'd argue that this is not as big of an issue as it could be because browser vendors respond to new vulnerabilities very quickly. WebGL, for instance, is still a massive mess in terms of security.
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?
Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.
Cross-platform GUI development in general is a dumb idea. The user chose a specific platform and expect applications to follow that platforms UX guidelines. Building a cross-platform app is basically saying you don't give a fuck about your customers. It's an insult to your users.
That's easy to say for a file picker on desktop OSs, but what happens when you need to layout a page on all 3 desktop plus Android and iOS?
Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc...
Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept of "files" like iOS or up to recently Android (at least in what is normally exposed to the user)
Roll in various versions of each OS and you are up to needing 10+ ways of doing most things. How are you supposed to create anything even remotely complicated?
I agree; if you build a system that completely covers specifying layouts for all widget needs and a DSL that handles wiring views into models, for all operating systems and device formfactors, you will have invented HTML, CSS, and JavaScript, with the DOM api and a browser as the default interface.
Not sure I agree here. There are a great many browser features (e.g. web speech api for recognition and tts, webrtc, etc) that are just not lowest common denominator. Even if we stick with UI only, features like cross platform vector graphics are not trivial. Of course some libs like qt abstract it, but you're back to your same complaint except it's qml, css, and js (or often times worse, c++ if using widgets)
"lowest common denominator" is kind of a feature, when it comes to something used on a ton of different platforms. The rest can be built up out of those. I'm not saying that html et. al are amazing, just that I am doubtful something could be built that spans such a large vector space, so to speak, so expressively, without being subject to the same complaints.
Desktop and laptop systems tend to be in portrait orientation; phones and tablets tend to be in portrait. So you already have to either make two layout styles or accept a mediocre general solution.
Cursors and styluses are accurate, but fingers are not. So, if you make buttons sized for fingers, they feel awkwardly large (takes large hand movements to change between UI components, and the spacing means more scrolling or pages of UI), but if you size them for cursors/styluses, they are frustratingly small targets for touchscreens.
You can probably assume that most devices in portrait orientation are that way so they can be held in one hand leaving the other free to work a touchscreen, so you only need to handle three of the four combinations for a comfortable user experience in those regards.
However, there's more to it than that. Desktop users often run apps windowed, while phones tend to omit that option entirely. Mac puts the menu bar at the screen edge regardless of the window size/position, but other desktop/laptop OSs usually put the menu bar within the window border. You can remove the menu bar entirely and draw a hamburger button into your UI, but desktop users have the expectation of a menu bar and the change in convention will make the app feel like an outsider.
A desktop/laptop user will never try a long press and don't have a menu button, both of which have been used to hide extra functionality on phones, but they often do have a keyboard, and there is a massive list of keyboard shortcuts that they will automatically use. Desktop UIs have a logical tab order and that selection can be moved with the arrow keys. Cut, copy, and paste function as expected. On windows, F2 almost always means "rename selected item", F1 for help, alt-enter to toggle full screen, and so on. What about the multitude of multi-finger phone/tablet gestures? You have two very different modes on input, and users' muscle memory expects your app to fully support whichever one they are using. As an anecdote, I tried writing something in an Electron app's text box, then went for ctrl-left to jump back a word, but instead it caused a page navigation and lost the entire message I was typing. That was a frustrating "this app is an outsider on desktop" experience to me.
Your decision is effectively mediocre everywhere or customized to fit the conventions for each platform.
I'd love to be shown an example, because I honestly don't believe it is doable, let alone doable easier than just making several different applications.
Non UI code lives in a static/shared lib that gets called from UI code. The non-UI code shouldn’t be coupled to a UI at all, instead reporting progress/completion via callbacks or other notification mechanisms.
If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.
That's a valid architecture, but it's not a cross platform UI library that uses fully native looking UI on every platform which is what I'm skeptical of working.
I don't think that fully native-looking UI is a very important thing. Not all of the software has a fully native UI on my computer, and it doesn't matter at all.
I completely agree, but the conversation above was speaking to native UIs being a benefit, and there being alternatives that allow you to "write once run anywhere" with native UIs (which I disagree that this even exists in any usable form)
I'm late, but I think wxWidgets tried this. It was OK, I wrote some stuff with it, but mainly targeted Linux. There were definitely some differences in widgets between platforms, but it looked pretty good for not much effort.
Yes, it takes some initial effort, but it only needs to be done once.
It needs to be redone for each platform every few years as apis and visual styles change. Cross platform libraries are notoriously hard and usually end up in the uncanny valley (qt, swing etc).
Platform vendors of course any devs to buy into just one platform, they want and need the lock-in. Using web UI is a way to sidestep that.
Web browsers like the one used by Electron do this as well. The styles of buttons, inputs, etc. vary from platform to platform. They can be overridden, of course, but that’s true of any native GUI framework as well.
See the Office related talks at CppCon 2015 about how to write portable code using what Microsoft calls the hamburger model, as part of their migration to a common codebase.
Basic a shim layer for low level OS APIs, the middle layer with the majority of code and another shim layer for UI APIs.
Which is exactly my point, the application architecture has to be done in proper modular layers to separate UI specific code that makes use of the UI elements that provide a good UX, from the common code.
Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.
You misunderstand. Even forgetting the UI, the Office programs are different between platforms. One know this, because functionality differs between platforms.
As a user of those apps, that’s a clear indication they are probably shit.
If you didn’t even take the effort to get your interface with your user (read: customer) right, how lazy did you get with the parts of the app I can’t see ?
The UI of your app is the one highly visible point where 99,999% of the interaction with your customers takes place. If you can't be bothered to have a good UI, how shit is the stuff I can't see as a user ?
A bad UI is a huge smell. In my experience there is a 1:1 relationship between the quality of the UI and the quality of the software as a whole.
Was it ever really hard to make cross postform applications that look identical on all platforms? If application looks identical on every platform is it really cross platform?
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.
You couldn't be further from the truth. Have you seen the Blizzard app (Qt) [0]? The JetBrains Toolbox app(Qt) [1]?
Also, here's a small app I wrote in kotlin and swing for my GF who wanted to download music from youtube without installing crapware downloaders [2]. You'll notice it has a custom window frame, support for drag and drop, and fully customized table and buttons. I spent about 5 hours styling the UI, and half a weekend writing the entire app.
Yes, I agree, dowloading music from youtube is immoral and illegal, but I'm showcasing the UI so please ignore the underlying purpose of the app.
The Jetbrains toolbox UI (and your downloader) do very little. Blizzard's app does a great deal more but is a terrible, sluggish, battery-hogging mess, which also includes web UI elements of some sort. Even Blizzard knows this which is why the app has a setting to hide its windows after launching a game. It doesn't feel like an example of a quality Qt app at all, if such a thing exists.
> The Jetbrains toolbox UI (and your downloader) do very little.
That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs.
Not to mention the irony of complaining about performance, when the promoted alternative is electron...
Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion. The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.
> Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion
Well, it wasn't about being "better", it was about not looking like shit.
> The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.
Well, Visual Studio Code used to drain battery life for blinking the cursor in the background. But again, it was never about performance. My original argument was that newer 'native' applications written using Qt or swing can look just as good as web based UIs
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.
Consistent? Where? Windows changes its style with each version. Macs may be more consistent, but they're the exception and I never owned a mac. Linux is a rainbow of diversity.
Unless someone puts in the extra effort to style the application, nothing will look consistent cross platform.
And if you want "native, consistent, desktop applications" (for the current platform), Qt has that out of the box and Swing had a native look and feel that looked pretty consistent on Windows 7 at least.
Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!
Qt [1], bindings in: JS, Python, C++, and others. Also has QML to make things easier.
Tk [2], bindings in just about everything. Included in most Python distributions.
Kivy [3], Python only.
Java/FX [4] Java and other JVM languages.
If your main problem is the duplication effort between the web and an application: Qt is the simple path. Qt includes WebKit. Everything Electron can do, Qt can do, but faster and smaller.
If you consider web to be "high quality UI paradigm", then you might be seriously interested in learning other UI tools. You know like literary any other UI library on Earth where vertical centering of one element in another is just a basic functionality not a task that requires a hack.
I wish there was a dead-simple, you-cannot-get-it-wrong, step-by-step, nothing-left-out, no-knowledge-assumed, all-in-one-document, not-spread-out-over-various-pages, tutorial/checklist on how to ensure your Electron app is as secure as possible.
It shits me that it is a research task with all the attendant uncertainty about whether or not I did in fact make it secure.
I do appreciate that security is complex and even such a document would not guarantee security, or that you had not somehow created your own security hole, but I just want to do the very best possible effort at security and currently that is too hard with Electron.
UPDATE: this post has led me to attempt to redesign my application to not use Electron. I just can't afford some misconfiguration or coding error leading to user machines being cracked.
My impression is that making everything formally verified is a lot of work and it would be very hard to make formally verified code as easy to write as non-verified code.
Electron makes things worse: it is not secure. Electron has many security vulnerabilities. The latest version is still based on old Chromium (58 & 59) so it inherits many of the security vulnerabilities published in Chromium 60, 61 and 62
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.
Feels somewhat safe, but I haven't read the bug list. :)
Image format decoding and HTTP/TLS/request processing layer bugs may be other source of issues in any case. But hopefully that runs in some restricted environment.
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.
Whilst it's very hard to write a secure C application because writing C is hard, it seems it's very hard to write a secure application in javascript because javascript is too easy. Maybe we should stop blaming language complexity and start blaming the complexity (or lack thereof) of the designs that fail us?
Neither of those is about "hard" versus "easy". C pre-dates a modern understanding of security boundaries and tries a little bit too hard to be "close to the machine" (so long as the machine looks a lot like a PDP-11). Javascript-the-language is not the problem, but having the whole browser infrastructure present in order to render a document is the problem here in Electron.
The challenge in language design is to erect the right number of boundaries and barriers, in the right places. Too many, and you get people complaining that they can't write Rust because of the borrow checker. Too few, and you get people vaporising multi-million-dollar Etherum contracts by mistake.
I don't think you understand. I am not blaming languages, or indeed making a statement about how hard or simple they are to use. I'm just trying to point out that application design is hard - and in fact I do consider the fact that a text editor has pulled in the whole browser infrastructure to render a document a design error.
> having the whole browser infrastructure present in order to render a document
This is disingenuous; the whole browser infrastructure is present to run an application. This shouldn't be surprising because that is exactly what a browser is: an application execution environment.
C isn't hard. C is easy, in fact. This is the main impetus behind its popularity: people liked it, in part because it was easy. Security is hard in c, in part because c tries to make things easy for the developer at the detriment if security. Javascript is in the exact same posistion. Why is javascript popular? Because its easy. Why is javascript easy? Because none of its features are focused on security.
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 been around for ages and continually sees updates. Usually people who see the Qt light are pretty satisfied. It can also be used from a wide variety of languages, in case you're not into writing C++.
I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers who otherwise wouldn't have had any clue how to make desktop/native applications. However, do I really want to be running unsandboxed xss==>rce code written by clueless devs? No, no I do not. So, in the end, refusing to run Electron apps turns out to be a somewhat reasonable security posture.
Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes.
But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS.
I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen.
I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment.
There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app?
You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core.
Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.
"Web on desktop"
Reminds me of Win98 and how Microsoft tried to push that back then. It's just a bad security model. Technologies were different, but the security implications that lead to exploits stayed the same.
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 would need to offer more than a cross platform desktop app.
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.
There are many viable compile-to-js languages out there to pick from:
* clojurescript
* f# via fable
* c# via different means(even an MSIL compiler)
* Golang
* etc
I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bit of extra work that's probably small beans compared to the work required to get all of what parent described with completely separate languages and platforms.
Adding this[0] list of languages that compile to JavaScript to the list. There seem so many that no matter your taste in syntactical sugar there should be something for you.
Would like to clarify that it's not about "syntactical sugar" more like different semantics and/or safety(they treat js as machine code), hardly anyone would claim they are using these languages because of js syntax.
And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?
Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.
> It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.
You might wanna read that back to yourself. Now replace it with any language you hate, and then tell me how that statement makes any form of argument at all (it doesn't...).
To be fair, JavaScript hardly deserves being compared to Linux. People don't loathe JavaScript for no reason. The language itself is pretty rough around the edges.
I not a fan of javascript either, although I write js almost evey day and use Atom mainly because I could not find a better open source desktop editor that looks and works like Sublime Text. If anyone cares to write one in C++, D, Rust or Go, I'll happily use it.
> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers
Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible".
Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.
I'm really surprised we haven't seen the functional style of elm, react and friends backported into modern gui frameworks. A react-like framework for native apps written entirely in swift would be killer - swift is a much better language than JS, and the resulting apps would be much smaller and snappier than what we get with electron or react native.
C#/F# would be a great candidate for this kind of thing too.
Qt QML is JS with a declarative UI language and C++ when you need it.
On the other hand you have JS with a document markup language combined with style sheets.
And the first one is embarassing you say. And declaring UIs in HTML and CSS is easier than in QML.
Why do you even post this. I mean... it's trivial to disprove it. Do you subscribe to the idea that if one makes enough noise their arguments will win out?
it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs.
I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries.
then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images!
The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.
It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code...
Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.
And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).
> it is a very known fact for all unix grey beards ...
It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.
As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.
The solution, is to bump the version in the dockerfile, rebuild, and deploy.
This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.
Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.
Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.
Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.
I would argue that container orchestration infrastructure is objectively more secure than plain old servers;
I get where you are coming from, but this tech is solving real problems, the cool aid is good
On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.
Even whitelisting is dangerous for web/html. Given any tag, there's probably a large number of things you can do with them that boggles the mind as in "whoa I didn't know you could do that..." including things that are not in the w3c specs but are coded into the interpreters.
Basically the experience of a web developer every day, no matter how experienced you are.
I you whitelist tags and then whitelist attributes and then whitelist attribute values and for attributes that have values with its own structure, like style whitelist allowed things in that structure, you should be fine.
But it's hard to restrain yourself from doing: allow any (possibly except some) at any stage of whitelisting.
Even to a point of not allowing string of any characters as attribute value.
Unsure how to quantify this kind of hyperbole. Compared to SublimeText 2 which is outdated at this point, VS Code and Atom are only getting back to the standard of fast code editors from the last few years ...
If you go back a few decades, you're competing against vi/vim and emacs, and there's no way you can say VS Code (and atom) can go against the "usefulness" or even productivity of either of those editors and their development environments.
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.
Not really, except when you are first adding a CSP to an older site that relies on eval (probably in a some crazy old jquery library). The name 'unsafe-eval' and the fact that 'unsafe-eval' has to be explicitly enabled are strong hints that you should move off of it as soon as possible
Unrelated: the article kept sending blurry low-res images and downloading the full version as I scrolled past them. I found this very annoying since I have a poor internet connection and had to wait for each image to load. I’d much rather prefer a slightly longer initial page load than waiting for each image.
The author suggests a malicious attacker might typosquat common packages and embed the exploit in a readme.
But if the user is already downloading your package, why bother with an exploit? You’ve got all the permissions allocated to packages (which I imagine are most permissions). You can just execute the malicious code directly from the package.
> So a malicious attacker would just have to register a bunch of malicious packages for every letter or offer a few packages with similar names to existing ones. As soon as someone clicked on the name to see the full entry (not installing it!), the malicious code would already be executed.
- The potential impact of an XSS or other security exploits is much higher. You can limit the impact of most of these with additional layers of security, such as running untrusted html in isolated environments with node integration disabled. However, also remember that...
- Many security features are opt-in. Content security policies (CSP) are a good example. Pages without a CPS default to allowing anything, which sort of makes sense in browser world for backwards compatibility, but is not a good idea for desktop apps.