5 ms·

> Sadly, because of the nature of the web, one can never be sure that the image actually stays within the browser. There's no way to prevent it from secretly se

> Sadly, because of the nature of the web, one can never be sure that the image actually stays within the browser. There's no way to prevent it from secretly sending everything you convert with this to some shady website because it runs in the browser. The thing is, that logic applies just as well to desktop apps. There's never any guarantee on either desktop or web unless you have very specific counter-measures in place (firewalls, airgapping, ...). It's just "closer to the web" when it runs in the browser, but if malice is the intent, it's as likely on either. Desktop apps are just "harder" to install.

b112 5y ago
This is why one reason why sensible Linux distros go though a multi-year process of release stabilization, assessment and testing. While not impossible, the likelihood of, say, imagemagick doing this, while going through this process, is extremely improbable. I agree that just downloading apps off random websites is every bit as risky as a browser app. But who does that?! (The last statement was sarcastic, and aimed at the curl | bash crowd, the nodejs crowd, the composer crowd... these things are the polar opposite of trusted, secured, audited, safe, sensible.)
- dahart 5y ago
  Seems like you’ve conflated a lot of things here. Binaries in the Ubuntu Snap store are not reviewed for years, it’s days at best (and that’s only for classic mode, the confined apps are released without human review). Software you get from NPM isn’t a random website nor is it a desktop binary, it’s source code you can read. I trust random web pages much more than I trust Linux Desktop apps, because the browsers are far more audited and safe than applications, and I have complete control over what data I put in the browser.
  - b112 5y ago
    So you pick one linux variant which doesn't follow my statements, then presume I'm conflating? Just because ubuntu is terrible, and uses snaps, does not mean all distros do. You should have taken the high road, and debated what I was discussing here. In Debian proper, you can read the source code of everything too. After all, old school distros like debian are they very reason you have such freedoms. They've been fighting the good fight for decades, working to keep OSS running pure, untarnished from closed licenses! The very idea that you think Linix distros are less audited than npm, and have less accessible source code, is, to me, incomprehensible. It also shows how little you know about OSS, while you use the very tools giants crafted for you. This doesn't make me mad, it makes me very, very sad.
    - dahart 5y ago
      > It also shows how little you know about OSS Snaps seemed like a fair example since you didn’t specify, and Ubuntu is one of the largest distros by market share. I don’t know what licensing has to do with your original point. I don’t know what vanishingly small linux distros used by a tiny minority of technical people has to do with @scrollaway’s point. I don’t know how making assumptions about what I know to slide in an ad-hom zinger has to do with taking the high road. The point that you bypassed with your straw man in the first place is that once a software distribution ecosystem gets large enough, it’s guaranteed to run on some amount of trust and gets too large to be auditable. This is why we have sandboxing, but ultimately even sandboxed apps when they get popular are a privacy threat, this is a problem Debian hasn’t even remotely solved.
  - pjerem 5y ago
    > Software you get from NPM isn’t a random website nor is it a desktop binary, it’s source code you can read. Most NPM libraries (even open source) are compiled and / or minified before they are uploaded to npm so it’s actually pretty common to get unreadable source code from npm. Nothing in NPM ensures that the package code is the same thing you see on GitHub. This would require NPM to checkout and build all the packages by themselves. So no, with NPM, you are totally running random code on your company’s computer. But surprisingly the world seems to be ok with that.
    - dahart 5y ago
      That’s a fair point, though are you sure about most? And are you saying most code only comes in minified form, or are you referring to libraries that come with a pre-minified option in addition to readable source? I’ve used NPM a bunch and rarely seen minified code only, and usually minification happens on my end as part of my site’s build, not to obscure JS library source code. It’s true that use of NPM requires trust. At least NPM projects have a name attached to them and some accountability. It is by no means foolproof, but malicious projects lose their accounts along with the reputation that takes time to earn. The world does seem to be okay with a certain amount of trust. This is really true of any software distribution system, even and including all distros of Linux. The point at the top of the thread is that we don’t have a way to know what happens when we download any software, or when we give our data to an application. We can protect our computers by auditing software and sandboxing systems, but the system still requires trust. Open source and auditing is still just a narrative that I have to trust from my point of view, unless I’m the person doing the auditing myself. It might help to clarify the threat model. The poster I replied to confused a security model with a privacy model. The thread above it was about privacy, not about security. There is no software distribution model anywhere that addresses what happens with my data on somebody’s backend once sent, nor whether they can share data that I enter into an application over the internet, right?
justin66 5y ago
> There's never any guarantee on either desktop or web unless you have very specific counter-measures in place (firewalls, airgapping, ...). Windows Firewall commonly serves this purpose even among users who are not familiar with terms like “countermeasures.” The only problem with their system is, the warnings are so common that clicking through them becomes a reflex action.
- teawrecks 5y ago
  Also, how many times have you launched an app for the first time on windows, use it flawlessly online for hours, and then close it only to find out that there was a firewall access request in the background the whole time. Failing to allow the app didn't make any difference at all.
  - pjerem 5y ago
    Ah this ! I always wondered what this window is asking me to authorize when the app is already downloading tons of things. I can’t imagine it’s just so flawed because it’s been like that for years. There must be another reason I don’t get.
    - zamadatix 5y ago
      You get a Windows Firewall prompt when an app wants to allow inbound connections, not outbound. This can include p2p technologies, most commonly things trying to register their own local discovery mechanism. If you don't use such inbound-initiated functionality it won't affect your outbound-initiated download requests.
      - pjerem 5y ago
        Thank you for the explanation. TIL !
- zamadatix 5y ago
  It's a rare breed that runs Windows Firewall (or any firewall) in default deny outbound mode, I can't see more than 0.01% of users (i.e. no more than 1 in 10,000) being protected from this scenario with their current Windows Firewall setup.
rom1v 5y ago
> The thing is, that logic applies just as well to desktop apps. A website might serve a different code every time you use it. It might even serve a malicious code specifically for some users.
- mattl 5y ago
  A desktop app could do the same. It would be trivial to run a little bit of extra code if the person running the app’s username is yours.
- tuyiown 5y ago
  If you consider arbitrary code execution for desktop apps you'll see that there's no much difference at a conceptual level.
- indymike 5y ago
  > A website might serve a different code every time you use it. It might even serve a malicious code specifically for some users. Desktop apps can do this little trick, too. Also, many desktop apps can enlist the help of other desktop apps using the three decades or so of various ways our OSes have made to lett apps talk to each other. Bad actors were using macro languages in desktop apps long before the invention of the web browser. Now, it's just as easy for a desktop app to hit an endpoint, grab a script (shell or macro language) and then execute it. The browser is just another desktop app - one with much more scrutiny than that MP3 tagging thing with a built in Lua interpreter that Bob in sales just gave local admin privileges to... Oh, and most desktop apps have some level of access to your identity - or outright have you confirm your identity when you activate your license.
bserge 5y ago

b112 5y ago

This is why one reason why sensible Linux distros go though a multi-year process of release stabilization, assessment and testing. While not impossible, the likelihood of, say, imagemagick doing this, while going through this process, is extremely improbable. I agree that just downloading apps off random websites is every bit as risky as a browser app. But who does that?! (The last statement was sarcastic, and aimed at the curl | bash crowd, the nodejs crowd, the composer crowd... these things are the polar opposite of trusted, secured, audited, safe, sensible.)

dahart 5y ago
Seems like you’ve conflated a lot of things here. Binaries in the Ubuntu Snap store are not reviewed for years, it’s days at best (and that’s only for classic mode, the confined apps are released without human review). Software you get from NPM isn’t a random website nor is it a desktop binary, it’s source code you can read. I trust random web pages much more than I trust Linux Desktop apps, because the browsers are far more audited and safe than applications, and I have complete control over what data I put in the browser.
- b112 5y ago
  So you pick one linux variant which doesn't follow my statements, then presume I'm conflating? Just because ubuntu is terrible, and uses snaps, does not mean all distros do. You should have taken the high road, and debated what I was discussing here. In Debian proper, you can read the source code of everything too. After all, old school distros like debian are they very reason you have such freedoms. They've been fighting the good fight for decades, working to keep OSS running pure, untarnished from closed licenses! The very idea that you think Linix distros are less audited than npm, and have less accessible source code, is, to me, incomprehensible. It also shows how little you know about OSS, while you use the very tools giants crafted for you. This doesn't make me mad, it makes me very, very sad.
  - dahart 5y ago
    > It also shows how little you know about OSS Snaps seemed like a fair example since you didn’t specify, and Ubuntu is one of the largest distros by market share. I don’t know what licensing has to do with your original point. I don’t know what vanishingly small linux distros used by a tiny minority of technical people has to do with @scrollaway’s point. I don’t know how making assumptions about what I know to slide in an ad-hom zinger has to do with taking the high road. The point that you bypassed with your straw man in the first place is that once a software distribution ecosystem gets large enough, it’s guaranteed to run on some amount of trust and gets too large to be auditable. This is why we have sandboxing, but ultimately even sandboxed apps when they get popular are a privacy threat, this is a problem Debian hasn’t even remotely solved.
- pjerem 5y ago
  > Software you get from NPM isn’t a random website nor is it a desktop binary, it’s source code you can read. Most NPM libraries (even open source) are compiled and / or minified before they are uploaded to npm so it’s actually pretty common to get unreadable source code from npm. Nothing in NPM ensures that the package code is the same thing you see on GitHub. This would require NPM to checkout and build all the packages by themselves. So no, with NPM, you are totally running random code on your company’s computer. But surprisingly the world seems to be ok with that.
  - dahart 5y ago
    That’s a fair point, though are you sure about most? And are you saying most code only comes in minified form, or are you referring to libraries that come with a pre-minified option in addition to readable source? I’ve used NPM a bunch and rarely seen minified code only, and usually minification happens on my end as part of my site’s build, not to obscure JS library source code. It’s true that use of NPM requires trust. At least NPM projects have a name attached to them and some accountability. It is by no means foolproof, but malicious projects lose their accounts along with the reputation that takes time to earn. The world does seem to be okay with a certain amount of trust. This is really true of any software distribution system, even and including all distros of Linux. The point at the top of the thread is that we don’t have a way to know what happens when we download any software, or when we give our data to an application. We can protect our computers by auditing software and sandboxing systems, but the system still requires trust. Open source and auditing is still just a narrative that I have to trust from my point of view, unless I’m the person doing the auditing myself. It might help to clarify the threat model. The poster I replied to confused a security model with a privacy model. The thread above it was about privacy, not about security. There is no software distribution model anywhere that addresses what happens with my data on somebody’s backend once sent, nor whether they can share data that I enter into an application over the internet, right?

justin66 5y ago

> There's never any guarantee on either desktop or web unless you have very specific counter-measures in place (firewalls, airgapping, ...). Windows Firewall commonly serves this purpose even among users who are not familiar with terms like “countermeasures.” The only problem with their system is, the warnings are so common that clicking through them becomes a reflex action.

teawrecks 5y ago
Also, how many times have you launched an app for the first time on windows, use it flawlessly online for hours, and then close it only to find out that there was a firewall access request in the background the whole time. Failing to allow the app didn't make any difference at all.
- pjerem 5y ago
  Ah this ! I always wondered what this window is asking me to authorize when the app is already downloading tons of things. I can’t imagine it’s just so flawed because it’s been like that for years. There must be another reason I don’t get.
  - zamadatix 5y ago
    You get a Windows Firewall prompt when an app wants to allow inbound connections, not outbound. This can include p2p technologies, most commonly things trying to register their own local discovery mechanism. If you don't use such inbound-initiated functionality it won't affect your outbound-initiated download requests.
    - pjerem 5y ago
      Thank you for the explanation. TIL !
zamadatix 5y ago
It's a rare breed that runs Windows Firewall (or any firewall) in default deny outbound mode, I can't see more than 0.01% of users (i.e. no more than 1 in 10,000) being protected from this scenario with their current Windows Firewall setup.

rom1v 5y ago

> The thing is, that logic applies just as well to desktop apps. A website might serve a different code every time you use it. It might even serve a malicious code specifically for some users.

mattl 5y ago
A desktop app could do the same. It would be trivial to run a little bit of extra code if the person running the app’s username is yours.
tuyiown 5y ago
If you consider arbitrary code execution for desktop apps you'll see that there's no much difference at a conceptual level.
indymike 5y ago
> A website might serve a different code every time you use it. It might even serve a malicious code specifically for some users. Desktop apps can do this little trick, too. Also, many desktop apps can enlist the help of other desktop apps using the three decades or so of various ways our OSes have made to lett apps talk to each other. Bad actors were using macro languages in desktop apps long before the invention of the web browser. Now, it's just as easy for a desktop app to hit an endpoint, grab a script (shell or macro language) and then execute it. The browser is just another desktop app - one with much more scrutiny than that MP3 tagging thing with a built in Lua interpreter that Bob in sales just gave local admin privileges to... Oh, and most desktop apps have some level of access to your identity - or outright have you confirm your identity when you activate your license.

bserge 5y ago