1. 34

    I don’t really agree with a lot of the claims in the article (and I say this as someone who was very actively involved with XMPP when it was going through the IETF process and who wrote two clients and continued to use it actively until 2014 or so):

    Truly Decentralized and Federated (meaning people from different servers can talk to each other while no central authority can have influence on another server unlike Matrix)

    This is true. It also means that you need to do server reputation things if your server is public and you don’t want spam (well, it did for a while - now no one uses XMPP so no one bothers spamming the network). XMPP, unlike email, validates that a message really comes from the originating domain, but that doesn’t stop spammers from registering millions of domains and sending spam from any of them. Google turned off federation because of spam and the core problems remain unsolved.

    End-To-End Encryption (unlike Telegram, unless you’re using secret chats)

    This is completely untrue for the core protocol. End-to-end encryption is (as is typical in the XMPP world) multiple, incompatible, extensions to the core protocol and most clients don’t support any of them. Looking at the list of clients almost none of them support the end-to-end encryption XEP that the article recommends. I’d not looked at XEP-0384 before, but a few things spring to mind:

    • It’s not encrypting any metadata (i.e. the stuff that the NSA thinks is the most valuable bit to intercept), this is visible to the operators of both party’s servers.
    • You can’t encrypt presence stanzas (so anything in your status message is plaintext) without breaking the core protocol.
    • Most info-query stanzas will need to be plain-text as well, so this only affects direct messages, but some client-to-client communication is via pub-sub. This is not necessarily encrypted and clients may or may not expose which things are and aren’t encrypted to the user.
    • The bootstrapping thing involves asking people to trust new fingerprints that exist. This is a security-usability disaster: users will click ‘yes’. Signal does a good job of ensuring that fingerprints don’t change across devices and manages key exchange between clients so that all clients can decrypt a message encrypted with a key assigned to a stable identity. OMEMO requires a wrapped key for every client.
    • The only protection against MITM attacks is the user noticing that a fingerprint has changed. If you don’t validate fingerprints out-of-band (again, Signal gives you a nice mechanism for doing this with a QR code that you can scan on the other person’s phone if you see them in person) then a malicious server can just advertise a new fingerprint once and now you will encrypt all messages with a key that it can decrypt.
    • There’s no revocation story in the case of the above. If a malicious fingerprint is added, you can remove it from the advertised set, but there’s no guarantee that clients will stop sending things encrypted with it.
    • The XEP says that forward secrecy is a requirement and then doesn’t mention it again at all.
    • There’s no sequence counter or equivalent so a server can drop messages without your being aware (or can reorder them, or can send the same message twice - no protection against replay attacks, so if you can make someone send a ‘yes it’s fine’ message once then you can send it in response to a request to a different question).
    • There’s no padding, so message length (which provides a lot of information) is available.

    This is without digging into the protocol. I’d love to read @soatok’s take on it. From a quick skim, my view is that it’s probably fine if your threat model is bored teenagers.

    They recommend looking for servers that support HTTP upload, but this means any file you transfer is stored in plain text on the server.

    Cross-Platform Applications (Desktop, Web, and Mobile)

    True, with the caveat that they have different feature sets. For example, I tried using XMPP again a couple of years ago and needed to have two clients installed on Android because one could send images to someone using a particular iOS client and the other supported persistent messaging. This may be better now.

    Multi-Device Synchronization (available on some servers)

    This, at least, is fairly mature. There are some interesting interactions between it and the security gurantees claimed by OMEMO.

    Voice and Video Calling (available on most servers)

    Servers are the easy part (mostly they do STUN or fall back to relaying if they need to). There are multiple incompatible standards for voice and video calling on top of XMPP. The most widely supported is Jingle which is, in truly fractal fashion, a family of incompatible standards for establishing streams between clients and negotiating a CODEC that both support. It sounds as if clients can now do encrypted Jingle sessions from their article. This didn’t work at all last time I tried, but maybe clients have improved since then.

    1. 8

      Strongly agree – claiming that XMPP is secure and/or private without mentioning all the caveats is surprising! There’s also this article from infosec-handbook.eu outlining some of the downsides: XMPP: Admin-in-the-middle

      The state of XMPP security is a strong argument against decentralization in messengers, in my opinion.

      1. 7

        Spam in XMPP is largely a solved problem today. Operators of open relays, servers where anyone can create an account, police themselves and each other. Anyone running a server that originates spam without dealing with it gets booted off the open federation eventually.

        Another part of the solution is ensuring smaller server operators don’t act as open relays, but instead use invites (like Lobste.rs itself). Snikket is a great example of that.

        but that doesn’t stop spammers from registering millions of domains and sending spam from any of them.

        Bold claim. Citation needed. Where do you register millions of domains cheaply enough for the economics of spam to work out?

        Domains tend to be relatively expensive and are easy to block, just like the IP addresses running any such servers. All I hear from server operators is that spammers slowly register lots of normal accounts on public servers with open registration, which are then used once for spam campaigns. They tend to be deleted by proactive operators, if not before, at least after they are used for spam.

        Google turned off federation because of spam and the core problems remain unsolved.

        That’s what they claim. Does it really seem plausible that Google could not manage spam? It’s not like they have any experience from another federated communications network… Easier for me to believe that there wasn’t much in the way of promotion to be gained from doing anything more with GTalk, so they shut it down and blamed whatever they couldn’t be bothered dealing with at the time.

        1. 3

          Your reasonning about most clients not supporting OMEMO is invalid because noone cares about most clients: it’s all about the marketshare. Most XMPP clients probably don’t support images but that doesn’t matter.

          For replays, this may be dealt with the double ratchet algorithm since the keys change fairly often. Your unknown replay would also have to make sense in an unknown conversation.

          Forward secrecy could be done with the double ratchet algorithm too.

          Overall OMEMO should be very similar to Signal’s protocol, which means that it’s quite likely the features and flaws of one are in the other.

          Conversations on Android also offers showing and scanning QR codes for validation.

          As for HTTP upload, that’s maybe another XEP but there’s encrypted upload with an AES key and a link using the aesgcm:// scheme (as you can guess: where to retrieve the file plus the key).

          I concur that bootstrapping is often painful. I’m not sure it’s possible to do much better without a centralized system however.

          Finally, self-hosting leads to leaking quite a lot of metadata because your network activity is not hidden in large amounts of network activity coming from others. I’m not sure that there’s really much more that is available by reading the XMPP metadata. Battery saving on mobile means the device needs to tell the server that it doesn’t care about status messages and presence from others but who cares if it’s unencrypted to the server (on the wire, there’s TLS) since a) it’s meant for the server, b) even if for clients instead, you could easily spot the change in network traffic frequency. I mean, I’m not sure there’s a lot more that is accessible that way (not even mentionning that if you’re privacy-minded, you avoid stuff like typing notifications and if you don’t, traffic patterns probably leak that anyway). And I’m fairly sure that’s the same with Signal for many of these.

          1. 3

            now no one uses XMPP so no one bothers spamming the network

            I guess you’ve been away for awhile :) there is definitely spam, and we have several community groups working hard to combat it (and trying to avoid the mistakes of email, not doing server/ip rep and blocking and all that)

            1. 3
              Cross-Platform Applications (Desktop, Web, and Mobile)
              

              True, with the caveat that they have different feature sets. For example, I tried using XMPP again a couple of years ago and needed to have two clients installed on Android because one could send images to someone using a particular iOS client and the other supported persistent messaging. This may be better now.

              Or they’ve also calcified (see: Pidgin). Last time I tried XMPP a few years ago, Conversations on Android was the only tolerable one, and Gajim was janky as hell normally, let alone on Windows.

              1. 3

                True, with the caveat that they have different feature sets. For example, I tried using XMPP again a couple of years ago and needed to have two clients installed on Android because one could send images to someone using a particular iOS client and the other supported persistent messaging. This may be better now.

                This was the reason I couldn’t get on with XMPP. When I tried it a few years ago, you really needed quite a lot of extensions to make a good replacement for something like WhatsApp, but all of the different servers and clients supported different subsets of the features.

                1. 3

                  I don’t know enough about all the details of XMPP to pass technical judgement, but the main problems never were the technical decisions like XML or not.

                  XMPP had a chance, 10-15 years ago, but either because of poor messaging (pun not intended) or not enough guided activism the XEP thing completely backfired and no two parties really had a proper interaction with all parts working. XMPP wanted to do too much and be too flexible. Even people who wanted it to succeed and run their own server and championed for use in the companies they worked for… it was simply a big mess. And then the mobile disaster with undelivered messages to several clients (originally a feature) and apps using up to much battery, etc.pp.

                  Jitsi also came a few years too late, sadly, and wasn’t exactly user friendly either at the start. (Good people though, they really tried).

                  1. 5

                    I don’t know enough about all the details of XMPP to pass technical judgement, but the main problems never were the technical decisions like XML or not.

                    XML was a problem early on because it made the protocol very verbose. Back when I started working on XMPP, I had a £10/month plan for my phone that came with 40 MB of data per month. A few extra bytes per message added up a lot. A plain text ‘hi’ in XMPP was well over a hundred bytes, with proprietary messengers it was closer to 10-20 bytes. That much protocol overhead is completely irrelevant now that phone plans measure their data allowances in GB and that folks send images in messages (though the requirement to base64-encode images if you’re using in-band bytestreams and not Jingle still matters) but back then it was incredibly important.

                    XMPP was also difficult to integrate with push notifications. It was built on the assumption that you’d keep the connection open, whereas modern push notifications expect a single entity in the phone to poll a global notification source periodically and then prod other apps to make shorter-lived connections. XMPP requires a full roster sync on each connection, so will send a couple of megs of data if you’ve got a moderately large contact list (first download and sync the roster, then get a presence stanza back from everyone once you’re connected). The vcard-based avatar mechanism meant that every presence stanza contained the base64-encoded hash of the current avatar, even if the client didn’t care, which made this worse.

                    A lot of these problems could have been solved by moving to a PubSub-based mechanism, but PubSub and Personal Eventing over PubSub (PEP) weren’t standardised for years and were incredibly complex (much more complex than the core spec) and so took even longer to get consistent implementations.

                    The main lessons I learned from XMPP were:

                    • Federation is not a goal. Avoiding having an untrusted admin being able to intercept / modify my messages is a goal, federation is potentially a technique to limit that.
                    • The client and server must have a single reference implementation that supports anything that is even close to standards track, ideally two. If you want to propose a new extension then you must implement it at least once.
                    • Most users don’t know the difference between a client, a protocol, and a service. They will conflate them, they don’t care about XMPP, they care about Psi or Pidgin - if the experience isn’t good with whatever client you recommend that’s the end.
                    1. 2

                      XMPP requires a full roster sync on each connection, so will send a couple of megs of data if you’ve got a moderately large contact list (first download and sync the roster, then get a presence stanza back from everyone once you’re connected).

                      This is not accurate. Roster versioning, which means that only roster deltas, which are seldom, are transferred, is used widely and also specified in RFC 6121 (even though, not mandatory to implement, but given that it’s easy to implement, I am not aware of any mobile client that doesn’t use it)

                      1. 1

                        Also important to remember that with smacks people are rarely fully disconnected and doing a resync.

                        Also, the roster itself is fully optional. I consider it one of the selling points and would not use it for IM without, but nothing prevents you.

                        1. 1

                          Correct.

                          I want to add that, it may be a good idea to avoid using XMPP jargon to make the test more accessible to a wider audience. Here ‘smacks’ stands for XEP-198: Stream Management.

                    2. 2

                      XMPP had a chance, 10-15 years ago, but either because of poor messaging (pun not intended) or not enough guided activism the XEP thing completely backfired and no two parties really had a proper interaction with all parts working. XMPP wanted to do too much and be too flexible.

                      I’d argue there is at least one other reason. XMPP on smartohones was really bad for a very long time, also due to limitations on those platforms. This only got better later. For this reason having proper messaging used to require spending money.

                      Nowadays so you “only” need is too pay a fee to put stuff into the app store and in case of iOS development buy an overpriced piece of hardware to develop on. Oh and of course deal with a horrible experience there and be at the risk of your app being banned from the store, when they feel like. But I’m drifting off. In short: Doing what the Conversation does used to be harder/impossible on both Android and iOS until certain APIs were added.

                      I think that gave it a pretty big downturn when it started to do okay on the desktop.

                      I agree with the rest though.

                    3. 2

                      I saw a lot of those same issues in the article. Most people don’t realize (myself included until a few weeks ago) that when you stand up Matrix, it still uses matrix.org’s keyserver. I know a few admins who are considering standing up their own keyservers and what that would entail.

                      And the encryption thing too. I remember OTR back in the day (which was terrible) and now we have OMEMO (which is ….. still terrible).

                      This is a great reply. You really detailed a lot of problems with the article and also provided a lot of information about XMPP. Thanks for this.

                      1. 2

                        It’s not encrypting any metadata (i.e. the stuff that the NSA thinks is the most valuable bit to intercept), this is visible to the operators of both party’s servers. You can’t encrypt presence stanzas (so anything in your status message is plaintext) without breaking the core protocol.

                        Do you know if this situation is any better on Matrix? Completely honest question (I use both and run servers for both). Naively it seems to me that at least some important metadata needs to be unencrypted in order to route messages, but maybe they’re doing something clever?

                        1. 3

                          I haven’t looked at Matrix but it’s typically a problem with any Federated system: you need at least an envelope that tells you the server that a message needs to be routed to to be public. Signal avoids this by not having federation and by using their sealed-sender mechanism to avoid the single centralised component from knowing who the sender of a message is.

                          1. 1

                            Thanks.

                          2. 1

                            There is a bit of metadata leaking in matrix, because of federation. But it’s something the team is working to improve.

                          3. 2

                            Fellow active XMPP developer here.

                            I am sure you know that some of your points, like Metadata encryption, are a deliberate design tradeoff. Systems that provide full metadata encryption have other drawbacks. Other “issues” you mention to be generic and apply to most (all?) cryptographic systems. I am not sure why XEP-0384 needs to mention forward secrecy again, given that forward secrecy is provided by the building blocks the XEP uses and discussed there, i.e., https://www.signal.org/docs/specifications/x3dh/. Some points of yous are also outdated and no longer correct. For example, since the newest version of XEP-0384 uses XEP-0420, there is now padding to disguise the actual message length (XEP-0420 borrows this again from XEP-0373: OpenPGP for XMPP).

                            From a quick skim, my view is that it’s probably fine if your threat model is bored teenagers.

                            That makes it sound like your threat model shouldn’t be bored teenagers. But I believe that we should also raise the floor for encryption so that everyone is able to use a sufficiently secured connection. Of course, this does not mean that raising the ceiling shouldn’t be researched and tried also. But we, that is, the XMPP community of volunteers and unpaid spare time developers, don’t have the resources to accomplish everything in one strike. And, as I said before, if you need full metadata encryption, e.g., because you are a journalist in a suppressive regime, then the currently deployed encryption solutions in XMPP are probably not what you want to use. But for my friends, my family, and me, it’s perfectly fine.

                            They recommend looking for servers that support HTTP upload, but this means any file you transfer is stored in plain text on the server.

                            That depends on the server configuration, doesn’t it? I imagine at least some servers use disk or filesystem-level encryption for user-data storage.

                            For example, I tried using XMPP again a couple of years ago and needed to have two clients installed on Android because one could send images to someone using a particular iOS client and the other supported persistent messaging. This may be better now.

                            It got better. But yes, this is the price we pay for the modularity of XMPP due to its extensibility. I also believe it isn’t possible to have it any other way. Unlike other competitors, most XMPP developers are not “controlled” by a central entity, so they are free to implement what they believe is best for their project. But there is also a strong incentive to implement extensions that the leading Implementations support for compatibility. So there are some checks and balances in the system.

                          1. 6

                            What would an ideal JavaScript dependency management system look like?

                            1. 6

                              It’s a good question. I’m not sure that npm is all that different from most other dependency managers. My feeling is that it’s more cultural than anything – why do JS developers like to create such small packages, and why do they use so many of them? The install script problem is exacerbated because of this, but really the same issue applies to RubyGems, PyPI, etc.

                              There are some interesting statistics in Veracode’s State of Software Security - Open Source Edition report (PDF link). Especially the chart on page 15!

                              Deno’s use of permissions looks very interesting too, but I haven’t tried it myself.

                              1. 9

                                I’m not sure that npm is all that different from most other dependency managers. My feeling is that it’s more cultural than anything – why do JS developers like to create such small packages, and why do they use so many of them?

                                I thought this was fairly-well understood, certainly it’s been discussed plenty: JS has no standard library, and so it has been filled-in over many years by various people. Some of these libraries are really quite tiny, because someone was scratching their own itch and published the thing to npm to help others. Sometimes there are multiple packages doing essentially the same thing, because people had different opinions about how to do it, and no canonical std lib to refer to. Sometimes it’s just the original maintainers gave up, or evolved their package in a way that people didn’t like, and other packages moved in to fill the void.

                                I’m also pretty sure most people developing applications rather than libraries aren’t directly using massive numbers of dependencies, and the ones they pulling in aren’t “small”. Looking around at some projects I’m involved with, the common themes are libraries like react, lodash, typescript, tailwind, material-ui, ORMs, testing libraries like Cypress, or enzyme, client libraries eg for Elasticsearch or AWS, etc… The same stuff you find in any language.

                                1. 4

                                  It’s more than just library maintainers wanting to “scratch their own itch.” Users must download the js code over the wire everytime they navigate to a website. Small bundle sizes is a unique problem that only JS and embedded systems need to worry about. Large utility libraries like lodash are not preferred without treeshaking — which is easy to mess up and non-trivial.

                                  People writing python code don’t have to worry about numpy being 30MB, they just install it an move on with their lives. Can you imagine if a website required 30MB for a single library? There would be riots.

                                  I wrote more about it in blog article:

                                  https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html

                                  1. 1

                                    Sure, but that’s just the way it is? There is no standard library available in the browser, so you have to download all the stuff. It’s not the fault of JS devs, and it’s not a cultural thing. At first people tried to solve it with common CDNs and caching. Now people use tree-shaking, minification, compression etc, and many try pretty hard to reduce their bundle size.

                                2. 3

                                  I was thinking about Deno as well. The permission model is great. I’m less sure about URL-based dependencies. They’ve been intentionally avoiding package management altogether.

                                3. 2

                                  It’s at least interesting to consider that with deno, a package might opt to require limited access - and the installer/user might opt to invoke (a hypothetical js/deno powered dependency resolver/build system) with limited permissions. It won’t fix everything, but might at least make it easier for a package to avoid permissions it does not need?

                                  1. 0

                                    hideous, I assume

                                    1. 1

                                      What would an ideal JavaScript dependency management system look like?

                                      apt

                                      1. 4

                                        apt also has install scripts

                                        1. 1

                                          with restrictions to ensure they are from a trusted source

                                          1. 4

                                            You mean policy restrictions? Because that only applies if you don’t add any repos or install random downloaded Debs, both of which many routinely do

                                            1. 1

                                              yeah

                                    1. 5

                                      I’ve had the same problem, so I’ve been working on a side project to help with this: xray.computer. It lets you view the published code of any npm package, and supports auto-formatting with Prettier for minified code. It’s not a panacea (sometimes, the published code is still unreadable, even when formatted) but it helps.

                                      I also like to look up packages on Snyk Advisor to ensure that they get timely updates when vulnerabilities are found.

                                      (Hopefully it’s okay to promote your own side projects here; please let me know if not.)

                                      1. 3

                                        It is absolutely acceptable to mention your own side projects here, so long as it’s not spammy. We have the “show” tag for a reason. :)

                                        1. 1

                                          Thanks for sharing your side-project! It is helpful to see the differences between versions. I can use it to see if a security issue was indeed solved between versions of a package. I’m also using Snyk to get an idea of certain packages.

                                          However, I think my problem is a bit more complex: a WordPress plugin may contain hundreds of interdependent npm packages all neatly bundled and minified. Without access to a package.json or package-lock.json it is quite hard to find out which individual packages have been used. Quite often there is also no public repo available of the development files.

                                          To give an example of my process thus far:

                                          Someone in my team wants to see if we can use plugin X. I’m downloading the plugin to have a look at the code. Luckily this plugin has included a non-minified version of the js file. I can derive the use of npm packages from this file. Using Snyk I have a look at the first package mentioned. It’s axios. The included version is vulnerable (high & medium severity) and has been for almost a year (Note: the last version of the plugin is 3 months old and does not exclude this vulnerable version in it’s package.json which I found in a Github repo later on).

                                          Since I have no package.json nor package-lock.json (all I have is the distributed build) I can’t easily update the npm package. I have no clue as to how this package relates to the other packages and how their version might depend on each other. Even if I would update the package, all other users of this plugin are still vulnerable. I contacted the plugin author. He tells me he will update the plugin as soon as possible. The plugin is (as of today) still not updated & has not released a new version. In the meantime there have been two new versions of the axios package released.

                                          Every user of plugin X is still vulnerable to the issues mentioned on Snyk, but is this a real problem in this specific WordPress plugin context? I’m not sure how to interpret the high & medium severity in the context of this plugin. How exploitable are these issues & what is the impact of the exploits in the context of this plugin? Do I need to be a logged in user? Is this something which can be triggered by any visitor? What am I able to do when I can exploit these vulnerabilities? I can only try to find answers to these questions if I’m willing to invest a lot more time into this, which more or less beats the purpose of using a ‘ready-made’ WordPress plugin. And this is just one package of multiple npm packages used in this plugin. Packages which also have their own dependencies as well….

                                          At this moment I’m wondering if any WordPress plugin using npm packages can be trusted at all.

                                          ps: The way the npm ecosystem is structured is, in my view at least, problematic. Often packages are not like libraries as I’d expect, but look more like a function call or method call. I’d prefer to write these short pieces of code myself instead of depending on external code which also includes extra risks. The very rapid release schedules makes it even harder to trust external software (like a WordPress plugin) using npm packages as it seems they cannot keep up with it.

                                          I’m sorry if this seems like a npm rant, but I’m seriously looking for methods on how to deal with these issues so we can use external software (like WordPress plugins) built with npm packages.

                                          1. 3

                                            I think it’s perfectly reasonable to say no to this plugin.

                                            A WordPress plugin may contain hundreds of interdependent npm packages all neatly bundled and minified. Without access to a package.json or package-lock.json it is quite hard to find out which individual packages have been used. Quite often there is also no public repo available of the development files… At this moment I’m wondering if any WordPress plugin using npm packages can be trusted at all.

                                            I’d be pretty skeptical of any proprietary software that has npm dependencies but doesn’t include its package files. Just taking woocommerce (one of the more popular plugins) for example, they do include their package files in their source code. That ought to be the norm. When you have access to the package files, you can run the following to automatically install patches to vulnerable dependencies and subdependencies.

                                            npm audit fix
                                            

                                            Without the package files, the plugin developer left you up a creek.

                                            The included version [of axios] is vulnerable (high & medium severity) and has been for almost a year… I’m not sure how to interpret the high & medium severity in the context of this plugin. How exploitable are these issues & what is the impact of the exploits in the context of this plugin?

                                            It really depends on the context. Some subdependencies are only used in the development or build of the dependency. If the vulnerability assumes the subdependency is running in a public node server, it’s probably not relevant to you. The hard part is knowing the difference. Take this vulnerability in glob-parent for example. I see it a lot in single page apps that have a webpack dev server. It’s hard to imagine how a DoS vulnerability is relevant when the only place the code is going to be run is your local development environment. In your case, it’s worth asking, is the axios vulnerability in the HTTP client or the server? If the vulnerability is just in the server and you’re not running a node server, you might be able to ignore it.

                                            The way the npm ecosystem is structured is, in my view at least, problematic. Often packages are not like libraries as I’d expect, but look more like a function call or method call. I’d prefer to write these short pieces of code myself instead of depending on external code which also includes extra risks. The very rapid release schedules makes it even harder to trust external software (like a WordPress plugin) using npm packages as it seems they cannot keep up with it.

                                            I agree that npm is problematic, but I have a slightly different take on it. There was a time when it was popular to mock projects like Bower for keeping front-end dependencies separate from node.js dependencies. The thinking was, why use two package managers when there’s one perfectly decent one? As it turns out, security vulnerabilities are impossible to assess without knowing in what environment the code is going to be run. I’m not suggesting we all go back to using Bower, but it would be nice if npm and its auditing tools would better distinguish between back-end, front-end, and build dependencies. As it is now, most npm users are being blasted with vulnerability warnings that probably aren’t relevant to what they’re doing.

                                            1. 1

                                              I’d be pretty skeptical of any proprietary software that has npm dependencies but doesn’t include its package files.

                                              I agree. I think this will be one of the main ‘rules’ for deciding if we want to use a particular WordPress plugin. Without the package.json or package-lock.json and npm audit it is near impossible to audit or update (fork) a plugin

                                              It really depends on the context. Some subdependencies are only used in the development or build of the dependency.

                                              You’ve hit the nail right on the head! And that’s what makes it hard to determine the impact: context.

                                              As far as I can tell, determining context can only be done with (extensive) knowledge on how the npm package has been implemented in the WordPress plugin. It requires knowledge of the WordPress plugin, WordPress, the specific npm package, its dependencies and how all these relate to each other. Just like you said with the axios package.

                                              Creating this context thus requires quite some time & skills, which would be fine if we would deal with just a few npm packages. However due to npm’s nature we usually have to deal with way more interdependent packages, which makes manually creating context near impossible. So even though there’s npm audit we’re still left with how to determine the context of the vulnerabilities found by npm audit. And for this I have yet to find a solution.

                                              PS: npm audit fix is in my view not the solution to solve this. It just hides the problems a bit better ;)

                                        1. 10

                                          Why not use a robots.txt? I am not a big fan of using meta-tags for this, and in the author’s sense, wasting my users’ bandwidth for such redundant tags. It also saves you from accidentally forgetting to add it to a document.

                                          1. 25

                                            Hi, author here – Google stopped respecting robots.txt noindex a few years ago: https://developers.google.com/search/blog/2019/07/a-note-on-unsupported-rules-in-robotstxt

                                            Combined with the fact that Google might list your site based only on third-party links, robots.txt isn’t an effective way to remove your site from Google’s results.

                                            1. 13

                                              https://developers.google.com/search/docs/advanced/crawling/block-indexing#http-response-header indicates that X-Robots-Tag: noindex as a HTTP header should have the same effect as the meta tag. It’s relatively easy to manage that per-server in the webserver config.

                                              That doesn’t save much on bandwidth but at least the “accidentally forgetting” issue is averted.

                                              1. 9

                                                Today I learned. Thank you very much, Sir!

                                            1. 5

                                              This is a useful distinction that helps clarify why we have faulty security expectations from module managers, IMO. We’re used to packages being vetted (to some extent) before they’re included in a program manager — you don’t run any great risks by running apt-get install libxyz. In contrast, running npm install xyz is about as (in)secure as running curl randomdomain.com | bash, but most of us aren’t as cautious as we maybe should be when installing new/unknown modules.

                                              1. 41

                                                This take comes up every so often, e.g. in some of the linked articles. I’m sympathetic to many of the concerns raised, but I’ve yet to see serious engagement with some of the deeper issues raised. For example:

                                                • A significant number of security and privacy-enhancing technologies (PET) have received US military funding or other support. See: Tor from the Naval Research Lab, OpenBSD from DARPA. SELinux comes from the NSA. The Open Technology Fund has also support Ricochet, WireGuard, Delta.chat, and Briar (that the author recommends), etc. (link). Are all these tools suspect?
                                                  • As an aside, the EU also funds a significant number of PETs. While not as egregious as the US, the EU is no enemy of mass surveillance, either.
                                                • One reason for Signal’s centralization is, in short, that it’s hard to update federated protocols, including their security features. E2E encryption in XMPP or email is still a pain, and far from usable for most people. I hope that e.g. Matrix can pull it off, but they face challenges that centralized services don’t. With a centralized service, you know that you can handle unforeseen security developments quickly. Shouldn’t this be a key priority for a security tool?
                                                • Using phone numbers as identifiers has its benefits: you don’t need to store users’ contacts on your servers. A service like Wire, that does allow you to sign up without a phone number, has to store your full social graph on their end. Avoiding this sort of metadata is a hard problem — Signal has opted for minimizing the amount they store.
                                                • It’s hard to overstate how much ease of use matters when it comes to gaining mass adoption for these tools. For a long time, privacy & security tools were super user-unfriendly, reserved only for a small technical elite (see PGP). If we want to combat mass surveillance, we need tools that the masses want to install (in my experience, it’s hard enough to convince activist groups to migrate off Discord or Slack — the alternatives need to be similarly easy to use).

                                                Not trying to shill for Signal — I share many frustrations with the author, e.g. on Signal’s approach to open source — but I’d like to see a little more nuance in articles like this one.

                                                1. 16

                                                  Using phone numbers as identifiers has its benefits

                                                  Indeed. This was WhatsApp’s big innovation, and is how WhatsApp basically took the ball away from the phone companies and made them into wireless Internet carriers. Signal is a WhatsApp alternative, and to be that it has to play in the same ballpark.

                                                  1. 5

                                                    And $50M of Signal’s funding (which is the majority of its funding) comes from one of WhatsApp’s founders. He probably has a lot more influence on the direction of Signal than the CIA and his motivation is to have something like WhatsApp that isn’t under Facebook’s control.

                                                  2. 8

                                                    A significant number of security and privacy-enhancing technologies (PET) have received US military funding [tor, OpenBSD, SELinux, etc]

                                                    Not to mention the fact that the development of Internet itself was funded by the US military (DARPA).

                                                    1. 5

                                                      My take on the military-industrial-intelligence complex funding is that the NSA does it to provide communication security for US-backed dissidents in rival countries, to support “color revolutions” there. The fact that they may benefit activists and/or criminals in the US is considered an acceptable cost.

                                                      I think that in principle, using phone numbers as identifiers is bad, and ignores realistic threat models for people like abused spouses. But in practice, it makes it much easier to get people to adopt it, because they don’t need to create a login and password, and you can use the Signal app as a simple drop-in replacement for your SMS app on Android, and get added security incrementally as your contacts adopt it. The frivolous stuff like stickers and gifs helps with this, and OWS have bent over backward to provide secure implementations that actually meet people’s needs.

                                                      Centralized and federated protocols both have challenges (different ones) from security perspectives. In practice, Matrix is a little over-centralized right now, anyway.

                                                      For me, adding a cryptocurrency for payments is Signal’s “jump the shark” moment, but I’m still using it for friends and family.

                                                      1. 3

                                                        A service like Wire, that does allow you to sign up without a phone number, has to store your full social graph on their end.

                                                        There’s no need to do this. For example in Peergos you can sign up with just a username and password, but your server can’t see your social graph (short of doing timing + IP address attacks that also apply to Signal, even with sealed sender - and even these will go away once we have onion routing). You store your own social graph in your own encrypted data, without any visibility to the server. Of course this means that you can only add new friends by their username, but this becomes less of a problem when you allow discovering friends of friends via comments in your news feed.

                                                        1. 2

                                                          As an aside, the EU also funds a significant number of PETs. While not as egregious as the US, the EU is no enemy of mass surveillance, either.

                                                          The OP also has articles called “list of US hate crimes” and “list of US atrocities”, and he praises the Chinese for not using signal. I think being anti-US is as important to him as being pro-privacy.

                                                          1. 1

                                                            Adding Tor to the list of government funded PETs.