Ask HN: Has software hacking gotten more easier? - <AUTHOR> I'm a college student and I don't know what the hacking scene was like 20, 30 years ago so please correct me if I'm wrong. I recently watched Mr. Robot and did some research on the tools and exploits used in the show. I know the show features quite advanced hacks but what surprised me was this:<p>These days we have tool suites that anyone can find and download from the web (SET, Metasploit, etc) and extensive guides & tutorials on how to use them. Almost anyone can follow a guide and do basic stuff like WiFi hacking and phishing scams. We even have ready-made hardware like USB Rubber Ducky and Pwn Phone which doesn't take a lot of time and knowledge to get started with (tutorials do just fine). While we may have developed advanced security standards and protocols, the percentage of mediocre developers which ignore those practices and the sub-par software they develop is always increasing. This is the software which will never be updated once vulnerabilities are found and will be exploited by script kiddies (Mirai). <comment><USER2> Your question is rather more complex than simply "easier" or "harder." There are a number of axes which have shifted over time.

I would say that it has become cheaper, faster and easier to identify software vulnerabilities that are low-hanging fruit, and conversely more difficult, time-consuming and expensive to identify software vulnerabilities in higher levels of abstraction or complexity; by way of association, overall exploitation ease ("hacking") for respective complexity classes has shifted commensurately.

Overall, I would say that it has become _easier_ to find and exploit software vulnerabilities in websites in the _aggregate_ , and that it is significantly more difficult than it has been in the past to find and exploit vulnerabilities in _specific, individual websites._ I view this as being the result of a confluence of factors, some of which have to do with the commoditization of many parts of the security industry (including human skillsets), and some of which have to do with the proliferation of ever- increasing amounts of software:

1\. As you mentioned, there are many sophisticated tools for quickly identifying and exploiting vulnerabilities, especially low-hanging fruit. This makes it easy to find vulnerabilities in websites with no attention, and significantly more difficult to find vulnerabilities in websites with previous attention.

2\. New software is constantly produced, and existing software is constantly augments, both in sheer lines of code and overall feature complexity. This makes the overall number of vulnerabilities increase, and makes vulnerabilities easier to find overall.

3\. Software continually undergoes changes in abstraction across the industry. There are entire categories of software developers who know nothing about compiled languages and who have never developed in them. This makes it both easier to produce vulnerabilities due to poor understanding of what a code is doing "under the hood" and harder to find someone capable of exploiting or patching those vulnerabilities once they are introduced.

4\. The rise of bug bounties has introduced a gold rush for being the first person to identify security vulnerabilities, which has significantly raised the competition. This has made it harder overall to find vulnerabilities in applications that have received previous attention.

5\. The automated prevention or identification of vulnerabilities has made it easier to prevent them before they appear. Simple SQL injection flaws or cross-site scripting errors can be found with fully automated software. Even complex cross-site scripting in the DOM can be reasonably identified through automated means. Cross-site request forgery may no longer be a serious threat in the next five years due to simple browser changes. This has made it harder to find vulnerabilities, but mostly because fewer of these vulnerabilities are being introduced.

6\. Security has become increasingly mainstream, which means that, (much like bug bounties), there are teams constantly trawling through monolithic, open source code to find serious deficiencies. As technical debt from outdated, insecure modes of software development is reduced, it becomes harder to find vulnerabilities, though it certainly appears as though vulnerabilities are _increasing_ due to how mainstream findings are these days.

I still find things like cross-site scripting when I'm on security assessments, but it's frankly harder than it used to be. In contrast, things like insecure crypto, insecure direct object references and API auth logic errors are on the rise and have been for a few years now.

Net competition to find vulnerabilities has increased across every sector of the industry, from the work bug bounty hunters are doing, to the work I do in consulting, to the work Google's Project Zero does. The tools you mention have been disproportionately developed for the more competitive areas of security (bug bounties and web/mobile app sec), while the more complex and specialized vulnerabilities of the sort Tavis Ormandy finds still require a phenomenal level of manual research and discovery work before they can be found.

<comment><AUTHOR> Great reply.</comment></comment>


Dear American. Consider Eastern Germany - <AUTHOR> https://www.yours.org/content/dear-american-consider-eastern-germany-0f9b8e3e3f57 <comment><USER2> This skips from idea to idea kind of abruptly without clear linkage but the core idea definitely rings true: freedom cannot exist if all economic transactions are controlled and monitored by a centralized entity. People have to be able to privately enter into exchanges of value. It greases the wheels of the entire economy and prevents things like the State Dept. saying, "No, you can't donate to this journalist."

As cash becomes more and more marginalized and moves from the majority of transaction to something seen as inherently shady and criminal some alternate is going to be needed. Cryptocurrencies that are (mostly) private like Monero can fill part of the void but none of them really scale like cash does nor are they as convenient. They have a role to play in preventing an East Germany like situation but they aren't sufficient.

We still _need_ cash. But go ahead, try buying, say ... a multi-hundred dollar bike with cash. Or even paying for groceries with it, they'll swipe every bill over $5 with the test marker and look at you quite suspiciously. And countries like India and Sweden are moving aggressively to eliminate it. Even in the USA having large amounts of cash is considered intrinsically illegal by both the police (who will seize the cash claiming it's mere existence is proof that it is to be used for or is from, crimes) and the IRS which makes transfering large amounts of cash something you have to report and be scrutinized for. And if you don't they'll throw you in jail for violating either the Bank Secrecy Act or for "structuring", ie, not triggering the automatic reporting provisions.

And people, on a whole, love it. They love the convenience of never actually paying with or holding their own money. A giant multi-national corporation will promise to pay for them and it's reputation is so pristine no business will balk.

It's a brave new world. Just like the old (east german) world.</comment>


Ask HN: (Self hosted) App Hosting platform for developers? - <AUTHOR>

I'm a developer who writes prototype apps for various clients in various languages. While there are some great PaaS hosts around, I find that the best option for me is usually self hosting. So that's fine I know how to configure and setup a VPS on rackspace or whatever, but what I really need is something that I can type the domain I want to setup, chose the type of app I want to deploy (djano, RoR, Scala, PHP, whatever) and have it take care of all the web app boilerplate stuff for me (creating nginx reverse proxy configs, DNS setup, installation of language libraries and requirements etc)<p>Does something like this exist? <comment><USER2> Have you seen Red Hat's OpenShift?

<https://openshift.redhat.com/app/>

It's a Heroku competitor which became open source last month.

[https://openshift.redhat.com/community/blogs/announcing- open...](https://openshift.redhat.com/community/blogs/announcing-openshift- origin-the-open-source-platform-as-a-service-paas)

There is a live CD which has all the components of Openshift already set up.

<https://openshift.redhat.com/app/opensource/download>

</comment><comment><USER3> Why can't you set up a virtual server with your default setting and applications and then clone it? (I'm really asking for more details, not making a suggestion in the form of a question.) You also get little benefits like having your .vimrc and ssh keys copied over.

That's pretty much what I do, and I wouldn't want to have to maintain an additional "personal heroku server" that would automate the deployments in the way you're talking about.

<comment><AUTHOR> This is sort of what I do, but the problem for me right now is keeping the machines up to date. Because I sometimes don't use a specific stack for awhile it becomes stagnant and I end up just rebuilding the image. Other than ssh keys nothing really transfers over well between configurations. That said what would be nice is if I had a way to setup a 'beacon' on each machine so that I could write a fab script (or something) that when I type fab deploy -django it would find y newly created django ready VM or whatever.

</comment></comment><comment><USER4> I've also been interested in something similar, Heroku is great but just too expensive for some of the stuff I want to play around with, when I can run all of this on a single Linode box for $20/month. I've now created Puppet scripts to automate the setup of new boxes but it still isn't as easy as PaaS.

Has anyone got any good tutorials for OpenShift and Cloud Foundry on EC2 or the like? I found this, however it is 6 months old so I'm not sure how relavent it is any more (I might give it a shot later...): [http://www.cloudsoftcorp.com/blog/first-steps-with-cloud- fou...](http://www.cloudsoftcorp.com/blog/first-steps-with-cloud-foundry-on- amazon-ec2)

<comment><USER5> Here's my post on deploying a PaaS layer on EC2 [http://www.activestate.com/blog/2012/04/getting-started- priv...](http://www.activestate.com/blog/2012/04/getting-started-private-paas- amazon-ec2) and a link to the documenation <http://docs.stackato.com/>

that ought to get you started pretty quickly if you run into trouble, come to the irc #stackato on freenode

</comment></comment><comment><USER6> You can make your own pretty easily with a bash script.

You basically just need to clone from git, setup a VirtualHost, and restart Apache/nginx. I don't have experience setting up Scala, Ruby, etc, but I've done this for PHP and its trivial.

Start by writing a list of commands you issue to start a new project on your dev server. Then add variables, a web form, and you're done.

</comment><comment><USER7> Try out Stackato (<http://www.activestate.com/stackato>) [note: I work for ActiveState]. It's a commercial fork of Cloud Foundry that adds a lot more functionality. You can download an image for your hypervisor of choice (vSphere, fusion, vbox, ...), or provision one on EC2 or HP CS (no download necessary).

ActiveState is the Python community lead for Cloud Foundry (we added and maintain the support), but Stackato is much more than wrapping CF. It improves security (all user code is staged and run in linux containers), adds much more flexibility (hooks at staging or runtime, cron support, etc.), better manageability (web based console, user/group management), persistent file system, and more.

Also, if you like extensibility, a new experimental feature in 1.2 is Heroku buildpack support. Basically you get Heroku-in-a-box.

<comment><USER5> The Heroku Buildpack support makes it wickedly easy to move your apps from Heroku to your own Private Clouds

</comment></comment><comment><USER8> There's Cloud Foundry <https://github.com/cloudfoundry/vcap>, but it may be slightly too magical for you. We've been able to modify the it and integrate new services into it fairly painlessly once we got over the initial hurdle.

</comment><comment><USER9> You might check out VMware's Cloud Foundry <https://github.com/cloudfoundry> and RedHat's OpenShift <https://github.com/openshift>

</comment><comment><USER10> Sort of. Ari Lerner (@auser) was working on a project like this sponsored by AT&T. It was going to be an open-source heroku for your datacenter.

The code is here: <https://github.com/auser/beehive> though I'm not sure how active it is.

</comment><comment><AUTHOR> Thanks for all the links guys, I'm going to give Cloudfoundary and OpenShift a shot, OS looks a bit more feature filled but some of the blogs I've read say OS is all marketing. I'll give both a shot and write a blog post which you'll see soon here on HN (hopefully).

</comment><comment><USER11> AppFog is another service (still in beta) using cloudfoundry and supporting it.

More generally, and potentially more cross-host compatible, this sounds like a good opportunity for Puppet or Chef and a short config selection script.

</comment><comment><USER12> There is now a commercial version of Cloud Foundry, ActiveState Stackato. There are some features they added to Cloud Foundry plus they offer support. They have an EC2 AMI that you can just boot right up.

</comment><comment><USER13> You can write a bash script to edit the server configuration files to add a new virtualhost, copy the required files depending on the platform, and restart the server. It really shouldn't be too hard.

</comment><comment><USER14> Yeah, kind of like your own private Heroku. I want this too.

</comment><comment><USER15> You just described webfaction, it's not a vps but you can deploy any kind of apps very easily and you got ssh access

</comment><comment><USER16> You can have boilerplate features with Ubuntu juju, puppet or chef. But it isn't as easy as hosting on a PaaS.

</comment><comment><USER17> That's exactly what I was looking for and couldn't find.

</comment><comment><USER18> +1

<comment><USER19> As others have said, I would check out CloudFoundry. It is open-source & extensible.

I do exactly what you describe on a VPS in the cloud. I host my own prototype projects on a CloudFoundry instance. So far I've deployed these types of projects: Rails, Grails (JVM + Servlet), node.js, and Clojure(script). I also run production apps on CloudFoundry.

Setting up the instance(s) is easy, as there are plugins for most web frameworks already out there. I'm doing a session at Uberconf where I walk through my usage, process, and scripts for CloudFoundry. If there's enough interest, I could be convinced to screencast it.

PS: I do not work for CloudFoundry. Just a happy user.</comment></comment>


First iPad Video Review - <AUTHOR> http://blog.appboy.com/2010/04/first-ipad-video-review/ OK, Apple has done it again. The entire tech and Web communities are talking about the iPad.  There is no doubt that it is an exciting product, and with its astounding pre order numbers, it is most definitely a game-changer, even Hollywood is in on it. Check out this guest appearance by the iPad on one of TV's hottest shows, Modern Family. <comment><USER2> Direct link: <http://vimeo.com/10595371> (without the useless bla)

The PCMag review is quite good. That's the way video reviews should be done. It's also without surprises.

<comment><USER3> This review was so good that I was able to watch it with the sound off and yet it left me with no additional questions.

The reviewer flipped through most of the out of the box functionality of the iPad in real time with decent editing and no flashy graphics or bulleted lists.

Thanks, PCMag!

</comment></comment><comment><USER4> TBH I, like most techy-people was not excited about the iPad at launch. However, the more I see about it, the more excited I get.

Although it is a simple device, I think it is becoming quite obvious that the apps are going to make this device (unlike the iPhone which _was_ groundbreaking before the apps), I think the small amount of extra screen real estate you get with the iPad is going to make a huge difference.

I think there is also just something overtly natural about not having an intermediary device to interact with it like a mouse. Just my thoughts...

<comment><USER5> I wouldn't call it a small amount of extra screen real estate, it has more than 5x the number of pixels that the iPhone has.

Heh heh. That would make for a funny "multi-tasking" experience. Four original-sized iPhone app tiled beside each other.

<comment><USER4> Good point! :-)

</comment></comment></comment><comment><USER6> Is Apple already shipping iPads? I've seen a lot of people on Twitter talking about apps, and I have no idea how they're using them.

</comment><comment><USER7> Could someone please tell me how this device possibly can be an success once people figure out that they cant watch free online porn with it? A statistic I just made up proves that 37.8% of all internet activity is devoted to consumption of nudity for recreational purposes. (non-recreational is only 12.2%)

<comment><USER8> I suppose it'll work much like BBC iPlayer or whatnot with streaming H.264 to the device (If that's even how it works, I am not knowledgeable on the subject). Many porn sites claim to have iPhone versions, not that I know anything about that or have ever tried,

<comment><USER5> I'd love it if the live BBC channel streams would also supply a Flash alternative. Though I'm not too hopeful as they seem to be a lesser-known sideshow at the moment.

<http://www.bbc.co.uk/bbcone/watchlive/>

<http://www.bbc.co.uk/bbctwo/watchlive/></comment></comment></comment>


Peermaps – Decentralized Maps - <AUTHOR> https://peermaps.github.io/ <comment><USER2> Weird that it only mentions OSM in passing, in one or two places Seems like the source of your map data would be something you'd want to put out front

<comment><USER3> As an OSMer, I kind of took it as a compliment: "of course it's OSM... what else would you use?"

<comment><USER4> That was my interpretation as well, but not as an active OSMer.

</comment></comment></comment><comment><USER5> Vector map tiles are a very intriguing technology given the latest tools from Mapzen, Mapbox etc., so sharing tiles over p2p is welcome. However, this seems to use a K-D-B-tree which is similar but different. Why? [https://en.wikipedia.org/wiki/K-D-B-tree](https://en.wikipedia.org/wiki/K-D- B-tree)

Vector map tiles solve multiple problems in keeping the data transfers reasonable: independence from data outside of viewport, caching by tile, simplification by zoom level. Does this provide the same?

<comment><USER6> Free Vector map tiles : [http://osm2vectortiles.org/downloads/](http://osm2vectortiles.org/downloads/)</comment></comment>


Building SEO optimised Django web applications - <AUTHOR> http://uswaretech.com/blog/2008/10/building-seo-optimised-django-web-applications/

<comment><USER2> How did this make the front page? A list of mostly basic advice (Semantic URLs? Really?), riddled with spelling mistakes, and a smattering of django- specific stuff thrown in for padding?

</comment><comment><USER3> how do companies like django make money?

<comment><USER2> maybe the answer lies in the facts that a) django isn't a company, and b) the DSF has these members: <http://www.djangoproject.com/foundation/></comment></comment>


Modes in UI are bad; even worse are timed modes - <AUTHOR> http://ilyabirman.net/meanwhile/all/timed-modes/ <comment><USER2> I can't get past the first part. Modes aren't bad. Indeed, modes can be used to great benefit. The only problem with modes is one of discoverability. It can be difficult to know what mode you are in at times, as well knowing of the different modes available.

Of course, this is essentially true of the entire god damned computer experience. Knowing what programs, or modes, available is not an easy task for many to undertake.

To think that you can simplify your model of computers to the point that you can eliminate modes is to simplify your model to the point that it is useless for a great many things.

And to think that timed modes is bad misses an essential point. The vast majority of users do not want to be in these extra modes. Returning to a "default covers 99.999% of the users" is far from a bad thing. Of course, the first lesson many should be taught, but aren't, is _not_ how to find these modes. Rather, it is how to completely reset the system to defaults.

And yes.... I'm a vim user.

<comment><USER3> >And yes.... I'm a vim user.

Yes, it was that obvious.

But there are piles of UI design research studies that show modal interfaces are, in fact, bad.

Objectively bad. _Measurably_ bad.

I get sick of the vim apologists who try to claim that vim has a good UI. It is objectively, measurably, terrible.

Granted, _once you've learned it_ , you can be amazingly productive. But the _power_ of a program is completely orthogonal to how good of a UI design it has; the latter pretty much _has to include discoverability._ In the words of one of the current foremost user interface design experts, a "good user interface shouldn't require instructions." (-- Donald Norman)

I use vim when I'm doing editing on terminals. I'm _not_ a vim expert, and I don't intend to ever become one. It's _far_ more efficient to get my file locally and edit it in my flashy GUI editor if I have to do serious development on it, than it would be to become that level of expert at vim.

And I'm basing this on the many stories I've heard, written by vim experts, about how much _work_ it is to get good at vim.

Continue to use vim, by all means; you've climbed the hill and you know it, so it will be more productive for you than anything I could point you at to compare it to.

But please, please stop trying to claim it has a "good" user interface. Both vim and Emacs have interfaces designed before _any_ serious work was done on human interface design, and like the microwaves and VCRs designed back then, their interfaces are measurably, objectively terrible.

Modern editors can do 99% of what a 3+ year expert in vim can do, but you can get to that 99% in a month or less. Just because you had to spend three years of your life to get to your current level of productivity doesn't mean you should haze new developers the same way.

<comment><USER4> > Modern editors can do 99% of what a 3+ year expert in vim can do, but you > can get to that 99% in a month or less. Just because you had to spend three > years of your life to get to your current level of productivity doesn't mean > you should haze new developers the same way.

I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.

<comment><USER3> >I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.

Every single "modern editor" I'm talking about is scriptable, and they're scriptable in languages that are easier to code in than vimscript (which is _infamously awful_ ) or Lisp. Some are even scriptable in positively awesome languages.

Not sure what "modern editor" you're talking about. See:

Notepad++:

<http://sourceforge.net/p/notepad-plus/discussion/1290590>

Visual Studio: You can record a macro and get code that you can then edit, adding loops and logic and such, and then play back the macro. Or you can extend it in an arbitrary way:

<http://msdn.microsoft.com/en-us/vstudio/ff718165.aspx>

Visual Slickedit: Half of the app is written in its own custom C-like scripting language. Similar to Visual Studio, you can record a macro and edit the resulting source code, so you don't have to guess how to start creating a script.

TextAdept: Scriptable in Lua.

<http://foicica.com/textadept/>

TextMate: "Plug-able Through Your Favorite Scripting Language"

<http://macromates.com/>

Sublime Text: "Sublime Text has a powerful, Python based plugin API. Along with the API, it comes with a built in Python console to interactively experiment in real time." -- This one I haven't used, so I can't be CERTAIN that you can write-and-use scripts immediately and trivially, but it certainly sounds like it.

<http://www.sublimetext.com/>

NEdit: "NEdit is extensible through a C-like macro language"

<https://en.wikipedia.org/wiki/NEdit>

SCIte: "In addition, the Lua programming language is embedded in SciTE, allowing the user further customization. One can write Lua scripts that have access to the contents of the buffer and the Scintilla API."

<https://en.wikipedia.org/wiki/SciTE>

I've been clicking on random ones in the WikiPedia article on text editors [1], and except for the editors that "come with the OS" (Notepad, etc.), every one I checked had scripting. I actually clicked on SciTE to give a counter- example, since SciTE is mostly a proof-of-concept for the Scintilla editor library.

I would have to say, given the ubiquity of scripting languages in editors, that you haven't LOOKED for scripting in other editors. Which is FINE, but You Do Not Know Of What You Speak (TM).

Even if you can point to some that don't have scripting, it doesn't matter. Plenty do, and scripting is important to me as well. The crucial thing for me is the ability to quickly record and play back a macro; I wouldn't use any editor long term without that feature.

You really can't win this argument. I've traded blows with many extremely experienced vim users, and for every transform that's easier in vim than in another editor, I can come up with three more transforms easier in one or more editors I know. And the real win of using a modern editor is that the core keys (arrows, shift-arrow to select, control-arrow to jump by word, etc.) also work in thousands of other GUI apps, so you don't have to mode shift to be reasonably productive in a Firefox text box, for example.

[1] <https://en.wikipedia.org/wiki/List_of_text_editors>

<comment><USER5> > And the real win of using a modern editor is that the core keys (arrows, > shift-arrow to select, control-arrow to jump by word, etc.) also work in > thousands of other GUI apps, so you don't have to mode shift to be > reasonably productive in a Firefox text box, for example.

That's key to how I work. In a typical day I jump around between Komodo, IntelliJ IDEA, Visual Studio, UltraEdit, XML Marker, MarkdownPad, Araxis Merge, Word, Google Docs, Notepad, Evernote, and a few other editors. Thank goodness basic editing works the same in all of them!

Quite often I'll have the same file open in more than one editor and do some of my editing in one and some in another. I can save changes in one of the editors, switch to another, and it loads my changes and I pick up right from where I left off in the other editor.

Why would I do this crazy thing? One example: if I've got a file open in Komodo or IDEA or whatever and I'm ready to commit it, I always diff it first in Araxis Merge. I'm likely to make some final changes to the file at that point. (Left in a console.log, anyone?) I can make those changes in Araxis or in the other editor I'm working in - and it doesn't matter which, they both work the same and pick up each other's changes.

So, I don't have to take sides in any editor wars: I use a bunch of 'em! :-)

To add to your scripting list, Komodo is scriptable in Python and JavaScript, with a pretty thorough object model you can use from either language.

</comment></comment></comment></comment></comment><comment><USER6> It's a recurring rage of mine how bad and even dangerous many appliance and real-world UIs are. The car stereo with timed modes is only one example, stove-tops with unfriendly touch screen interfaces that make it hard to tell if the stove is on or not is another.

That said, I'm not sure I'm prepared to categorically dismiss modes in interfaces. Photoshop is an interesting example where I actually think the moded interface is helpful, given that the interface makes it clear what mode is active right now.

Another example that may divide readers of this humble comment is vim, where some may argue that its mode-based interface is core to its strengths.

</comment><comment><USER7> I'm not really convinced by the examples given. I'd like to see the author come up with some suggestions on how you'd be able to use Photoshop without "modes" since to me it seems pretty much impossible.

In regards to the TV remote I don't see why buttons should be dedicated to functions that you are not going to use 99% of the time. Personally I'd prefer a smaller remote because I'm not going to be wanting to change the aspect ratio every half an hour.

Also who adjusts the Bass EQ while waiting at a traffic light anyway? You're most likely in the minority if you adjust the EQ on your car stereo at all, let alone adjusting it so often you find yourself trying to adjust it while at a traffic light.

I think really it comes down to simplicity. Sure, the user might, once, when setting up their TV get annoyed that the settings disappeared while they were trying to alter something but I'd much rather have a more convenient and simpler remote then having a billion buttons on it for every single possible operation. Plus I'm sure many of us have experienced the classic "I pressed some unknown button on the remote now x has screwed up" from family/friends who are less technically inclined.

<comment><USER8> Raskin makes a special exception to his "No Modes" rule when it comes to paint and drawing programs, as he admits this is an obvious case where modes are needed. He does provide a mechanism though, that could be used to make photoshop modeless: Quasimodes.

A quasimode is a mode that is active only as long as a particular key is being held down. The pressure of the key on the user's finger is what makes the user constantly aware of the mode.

Caps-lock is a mode. The shift-key is the quasimodal version of that same function.

quite a lot of photoshops toolbar buttons are assigned keys already. M for marquee for instance. Modal keys. like caps-lock. Those modal keys could be switched to quasimodal keys that act essentially like extra mouse keys.

Photoshop already has 3 modal quasi-modal "modifiers" keys, in shift, alt, and (command/control), whose quasi mode changes depending on which mode you are in. So imaging a modeless photoshop where each tool and function is invoked by holding down a chord on the keyboard. Ta-da. Modeless photoshop.

Of course, Such a photoshop would be much more difficult to learn-as we are sacrificing discoverability. but it it would be easier to use for an expert.

and discoverability could probably be recovered using another of raskin's ideas: an dynamic displayed list of commands. Say you hold down the "m" key, and it lists in large type on screen what function that is, and what other keys you can hold down to modify it, and what functions those do.

This would be pretty awesome. But it will never happen because grumpy coders like vim and think it's great, and thus stand in the way of UI progress.

<comment><USER9> It wouldn't be "pretty awesome". It would be almost entirely unusable.

At the moment, Photoshop is difficult to use, but has thousands of features (I have no idea exactly how many) that presumably professionals make use of, at least to some degree or another.

Try making a modeless version of Photoshop like you describe and most people would have to look up the key combination before doing anything, at least until they've learned all the modifier keys (which sounds remarkably like emacs). Not exactly the paragon of usability.

As with almost everything, UI is a tradeoff between several different factors. In the case of modes, the applications that people like them in tend to be used by professionals or experts for a very specific purpose. In such a case, the utility, power and expressiveness is much more important than the initial ease of use.

If your aim is to create something that doesn't have thousands of features and should be usability immediately (or relatively so) by new users, then modes are likely a bad idea; if your aim is to create something powerful for experts who will be using it 8 hours a day for the next 5 years, modes may be worth considering.

<comment><USER8> "It wouldn't be "pretty awesome". It would be almost entirely unusable." Compared to the paragon of usability that photoshop represents today?

On its own, chords would hurt discoverability. But as I wrote originally, discoverability can be restored using another of raskin's ideas, a dynamic style of command line demonstrated by his son Aza in the Ubiquity and Enso projects, and also present in the Sublime Text 2 text editor (called the command palette there)-- In essence, if your program has thousands of features, then make them invokable from an efficient specialised search engine. If we are using chords, make the available chords discoverable and visible in the UI.

You can entirely avoid modes AND have an efficient and powerful interface for experts to use day in and day out. They are not opposing forces.

</comment></comment></comment></comment><comment><USER10> Modal/modeless, stateless/stateful, functional/imperative, declarative/procedural, schemaless, distributed, asynchronous.

Yammer yammer yammer namedropping and proselytizing buzzwords like gospel.

Modal interfaces are bad? Man, what the hell does modal interface even mean anymore? Like when I'm drawing vectors and my cursor changes to a selection tool instead of an "add point tool" when I hover over an existing point. That's bad now? Even though it's really annoying to create a duplicate points in a small area?

Restricting functionality to a relevant subset of behaviours based on the task you're doing can be a great idea. Yes, it can also be annoying. E.g. in the case of file explorers that don't let me create folders when I'm opening a file.

But that's just it. Spend some time thinking about how people interact with your application rather than making some thoughtless generalization. Otherwise you get Metro.

</comment><comment><USER8> Of course a forum full of VIM users is going to disagree with the notion that modes are bad. You guys stand in the way of UI progress. It's interesting too, because the software we are use to, the software we like, changes us and affects the way we think. But it's also a jail, preventing us from seeing new possibilities. Computers are capable of modeling and simulating ANYTHING and producing virtually any kind of interface, and yet we only ever use it with one or two different kinds of interface (typewriter-like, and desk-like). Not even very good interfaces.

Please do you us all a favor, I beg of you, read "The Humane Interface" by Jef Raskin, and have an open mind about it. Actually read it. If you've done that, and still disagree that modes are bad, you're going to have to give a really good reason. With evidence.

<comment><USER11>
        You guys stand in the way of UI progress.

Progress from whose perspective? The masses or the elite? Is a UI that's optimal for Joe Average also optimal for tech geniuses?

<comment><USER8> I could write an essay here, or you could take responsibility for your own curiosity and read a book. I suggest "The Humane Interface" by Jef Raskin and "The Design of Every Day Things" by Donald Norman. I consider these essential reading for those interested in UI concerns.

Of course if you aren't interested, perhaps you are better off with a vt100 using VIM while modemed into a unix system V mainframe?

<comment><USER12> > "The Humane Interface" by Jef Raskin

Thoroughly debunked. The fact you keep citing to it shows the depth of your ignorance.

Now do your own research instead of citing to debunked nonsense.

<comment><USER8> debunked by who? [citation needed]

</comment></comment></comment></comment></comment><comment><USER13> Don't agree entirely with this article.

It all depends on how complex the UI has to be. As long as you don't punish a user by making the same button do something "irreversible" or do something which takes a fair amount of effort to undo ("fair amount" is relative here) then modes can be very useful.

Also, Photoshop is a prime example of a piece of software that's been around for over a decade, and has grown to such an extend that it's probably impossible to not have modes.

Modes are a great way to expand a UI. You just have to be very careful that ctrl+z doesn't turn into "quit without saving". They're one of those tools that every UI/UX person should have in their pocket, to pull out - _at the right time_.

As for timed modes; I reckon it's all about feedback. Letting someone know what's happening, what's going to happen, and _when_ it will happen.

</comment><comment><USER14> <sarcasm>Yeah, emacs and vim - how shit are they? I'd rather nano any day.</sarcasm>

In my opinion, you can't make a blanket statement like "Modes in UI are bad". It depends entirely on context.

<comment><USER15> I completely agree. It depends entirely on what mode you're in.

</comment></comment><comment><USER16> Obligatory Larry Tesler reference.

"... who made it his personal crusade to "eliminate modes from software design" during his work on the early desktop user interface at Xerox PARC. The cause became so central to his life that his license plate read "NO MODES", and he reportedly wore the slogan "Don't Mode Me In" on a t-shirt."

</comment><comment><USER17> It's more complicated than that.

Bad mode: I use an awesome car service when I'm in Seattle called Car2Go. They have a really bad touch screen in the car. Pushing the physical volume button only turns off the radio if the touch screen is in radio mode. If you're in navigation mode, it mutes the volume of the turn-by-turn directions. It's distracting and confusing at the worst possible time.

Good mode: The Apple TV remote is so simple. It's just four arrows and a select button. The arrows may change your selection, fast forward, or change volume all depending on what mode the software is in. It's so natural, you don't even think of it as a "mode" -- it just works.

<comment><USER18> The key being that the entire context of the mode is staring you in the face the whole time.

</comment></comment><comment><USER19> Modes in UI are not bad. Unexpected behaviour is bad. Don't confuse the two.

</comment><comment><USER20> The problem with modes is fundamentally that people make mode-errors; they're not sure what mode they're in. If you've got users who aren't looking at the device, then yes, they'll make mode errors, because they have no clue what they're doing. If it's an unambiguous mode, and people understand the ways into and out of the mode, sure, you've got no problem, but those conditions are typically only met by system-level conventions.

</comment><comment><USER21> I disagree with the car stereo timed mode example. Imagine someone doesn't know beforehand how to cancel out of the settings. Now, they either have to figure that out _while driving_ or they have to sit with their stereo on a useless menu screen until they stop. This is exacerbated by the fact that your average driver isn't familiar with computer menus in the first place, so they have no idea what they're supposed to do unless it's plainly spelled out for them.

I suppose my grievance is with this:

 _> If I have changed my mind and don't want to set up the TV or adjust the bass, I will just press cancel myself._

Sure, the über hacker would just press cancel because they know that's what they should do. The rest of the world, who doesn't have nearly as much experience with computer interfaces as you do? They might not even know what a cancel button _is_ , let alone that they should look for it.

<comment><USER22> If you are unable to read the button that says "cancel" how were you able to read the button that got you into the settings mode in the first place?

<comment><USER23> Who says you read the button or intended to push it at all?

<comment><USER22> Yah, I don't think we can make a user interface for people who flail wildly and press random buttons.

<comment><USER21> Because it's inconceivable that someone would reach for the volume button and accidentally hit the settings button, right? It's not like stereos ever have buttons next to each other, and it's not like cars ever go over bumps or anything.

<comment><USER22> Your cure is worse than the disease.

So, in order to protect against the rare case of someone bumping into a button you want to annoy everyone else with timed modes?

<comment><USER21> It's not really rare. I've done it a few times, what with trying to reach the station dial while also concentrating on the road and accidentally pressing it in, causing the settings mode to activate.

And honestly, how often are you in the settings that it would annoy you? So you go in there maybe two times a year to adjust your bass when you stop liking house music and start liking indie rock, and that only takes a few seconds, so what are you doing in there that requires an extended period of time and enough contemplation that you wouldn't be able to immediately alter the settings and instead would have to pause for >10 seconds?

<comment><USER22> I change the front-back fader all the time depending on what I'm listening to and who in the car wants to hear it.

I don't consider it a big problem, but you did ask. You can't do it while driving since depending on the mode the same control does a while bunch of different things.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> The authors example of a car stereo struck a particular chord with me as I was so fed up with counter-intuitive interface on my car stereo that I actually built my own one using a Raspberry Pi.

My stereo is far from pretty, but I now have tactile buttons laid out in a logical fashion and instead of an LCD screen, it gives vocal feedback (via voice synthesis). So I no longer need to take my eyes off the road to switch music.

As an added bonus, I'm about to hook a 500GB laptop HDD into the device so that I can have my complete music collection on the road.

</comment><comment><USER25> Oh yes, PhotoShop has way too many modes. Adobe should kill them all. When you drag a line across an image, PhotoShop should utilize its psychic power to figure out your real intention.

</comment><comment><USER26> And even worse is removing all buttons, settings and flexibility in the name of "simplicity for consumer users", like seems to be the trend lately.

</comment><comment><USER27> Reusing modes can actually be quite good if you're concerned about space efficiency.

For example, having excessive controls in the car stereo might be a bad idea since drivers could potentially be distracted. So having the big volume knob to fine tune the bass level for example would be much more preferable to having six individual knobs that the user would have to look through and find.

<comment><USER28> But you only learn the interface once (and that doesn't have to happen while driving, either); then you use it again and again. So I would argue making it slightly harder to learn, but better to use in the long run (in the cases where you cannot have it both ways), makes the difference between a tool built to last, and a product made to sell.

Then there is the fact that if you only have one knob, you still have to learn how to put it in the mode you want (via secondary buttons, or even worse, just one you have to keep pressing); you gained nothing.

Also, compare typing an a cell phone "keyboard" and a PC keyboard. While you wouldn't want to have a single button for _every_ little function (like upper- case letters), it generally makes for better usability to have a dedicated button for _most_ of them, because while I press one key, my other fingers can already get into position to press the next in sequence.

</comment></comment><comment><USER29> Wait, isn't vim built entirely on the concept of modes?

<comment><USER30> That's why some people do not like it. It's more complex to learn. Vim is a good example of how modes can make UI confusing.

I think the "shaking icons" mode in iPhone is complex too. Your average iPhone user probably do not know it but she/he wouldn't miss a big part of their device.

<comment><USER29> I can understand that, but calling them 'bad' right off the bat is not necessarily true. Let's use a digital watch as an example. Digital watches are designed to be small enough to fit on your wrist. As a consequence, there are physical constraints on the number of buttons you can put on the side whilst maintaining usability. If you allow the use of a modal user interface, you can use fewer buttons. The downside is you have to read the manual to configure your watch.

My point may be moot, though; who uses a watch in the 21st century? I use my phone to tell the time.

<comment><USER31> Since I got my Pebble, I wear a watch almost all the time

</comment></comment></comment></comment><comment><USER32> "you want to draw a line, but accidentally create a gradient fill."

If you pay attention , you always know what tool you've selected ,so it is not really an issue. And just stating something is bad without proposing an alternative is just bashing for the sake of bashing. That's not interesting.

Complex tools require complexe interfaces. Not everything should or need to be simple. I dont like ergonomists/designers that just say something is bad without thinking about context. We are not talking about PAINT, but a professional software that needs to do many things. Photoshop has issues , but mode in photoshops are not a problem. Photoshop is supposed to be used by an audience that will take the time to learn it and understand it. It is not a tv or a car stereo where nobody bother read the doc. You cant master photoshop without learning it , it's interface has its own logic one needs to learn.

</comment><comment><USER33> Hmm... Timed modes are bad?

I toyed with the idea of a timed keyboard for mobiles/pads; a variant of the Hexagon game controls -- basically left and right buttons, turning a wheel of chars really quickly. (After a while with Hexagon, you get really good timing.)

The keyboard would need some additional way to fine tune the last selected char a few steps up/down on the wheel.

I assumed that similar models have been tried and found too slow. Or too demanding on concentration.</comment>


Faroo: a p2p search engine with 2m users - <AUTHOR> http://www.faroo.com

<comment><USER2> Interesting idea. Too bad it doesn't support Chrome...

<comment><USER2> Well, in the Help page Chrome is not included in the supported browsers, but in the download page it is.

Only for Windows though, no MacOS or Linux version...

<comment><AUTHOR> > Only for Windows though

All written in C# unfortunately.</comment></comment></comment>


Messenger systems compared by security, privacy, compatibility, and features - <AUTHOR> https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHalWVztqZo7uxlCeKPQ-8uoFOU/edit <comment><USER2> This is neat but it has plenty of flaws.

I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand how those are different. None of them implement double ratchets. None of them implement even close to the privacy features Signal has implemented. But on this diagram it is clearly better because there is more green and less red.

Another example: "open server" and "on-premise" says nothing about whether or not you really want to run one of those instances. It just says that hypothetically one could.

In terms of errors: the linked "E2E audit" for Telegram did not audit E2E at all, and in fact only cites sources saying that it's probably fucked. Wire has a real audit that isn't listed. WhatsApp uses Signal, just with fewer of the.

Use WhatsApp to talk to normal people. Use Signal for nerds, and... probably Matrix for group collab? Or maybe stop caring about secure messages for group collab so much :-)

<comment><AUTHOR> Please make comments on individual cells for improvements to be seen/added more easily. This is obviously big research undertaking that got thrown together last weekend :)

> Another example: "open server" and "on-premise" says nothing about whether > or not you really want to run one of those instances. It just says that > hypothetically one could.

I know a number of people that run matrix.org servers for personal use and companies. The entire French government runs on riot.im/matrix.org.

When security and really privacy matters, you don't want a third party being able to push updates to your clients/servers at any time without warning.

> None of them implement even close to the privacy features Signal has > implemented. But on this diagram it is clearly better because there is more > green and less red.

What features specifically? Happy to add more columns if signal really has anything unique to offer here.

The things Signal gets red marks on are pretty fair though imo, and things others do better.

> Use WhatsApp to talk to normal people.

I think you will find many options above WhatsApp on the list in terms of security and privacy that have clients that are every bit as simple to use.

Other than their (very) effective marketing advantage, -why- would you encourage people towards these respective walled gardens instead of more open alternatives listed?

<comment><USER2> In order to comment on individual cells, we appear to first have to have an argument about how audits work. You say WhatsApp can only "claim" certain features as a consequence of it being closed source, but that's because of a misunderstanding about how audits work.

In a backchannel, as a consequence of this HN article, someone (names withheld to protect the guilty, they can identify themselves if they'd like) started looking at Dust and figured out the key store password is a hardcoded, short, ASCII string and the messages are encrypted with unauthenticated AES-CBC. They did not need the source code to do that.

JP Aumasson phrased it more eloquently than I could: [https://research.kudelskisecurity.com/2018/10/02/open- source...](https://research.kudelskisecurity.com/2018/10/02/open-source- crypto-is-no-better-than-closed-source-crypto/)

<comment><AUTHOR> Even if they release all their code at this moment to a dozen third party code auditing firms, they can then undermine all the verified security with the next closed binary they release.

I will never use Signal with their current direction and don't recommend anyone use it, but they get credit where it is due. They actually offer source code for their walled garden and allow that their basic crypto can -generally- be verified except for extreme cases like my other comment.

Allo, Whatsapp and other closed systems that give you no reason to trust them other than faith in the people advocating them and that their engineers got it 100% right. Their claims can't be verified so they can only be marked as just that, claims.

Sure, plenty of obvious flaws can be spotted without source code access, but many are hard to find even if you -do- have source code to the point they would probably have never been found were they not open to allow the right set of eyes to eventually read the right section of code (Heartbleed etc).

I found random number generation flaws in Terraform I would of -never- found without source code access. It is for this reason I trust Terraform and Hashicorp quite a bit. They normally get it right, but are not afraid to have other people audit and point out flaws because they don't have this arrogant idea their engineers will get everything right 100% of the time.

Security is -hard- and anyone that thinks they can get it right with a SPOF closed source approach is more interested in marketshare than security.

Trust, but verify. Likewise if you are not even allowed to verify, you should instantly distrust.

<comment><USER2> > Allo, whatsapp and other closed systems that give you no resaon to trust > them other than faith in the people shilling them. Their claims can't be > verified so they can only be marked as just that, claims.

I have repeatedly refuted that point and you have repeatedly ignored it.

> Sure, plenty of obvious flaws can be spotted without source code access, but > many are hard to find even if you -do- have source code to the point they > would probably have never been found were they not open to allow the right > set of eyes to eventually read the right section of code (Heartbleed etc).

You are implying that no source code prevents you from finding obvious flaws, and I have given you two counterexamples in a messaging service that came up in this thread that I had never heard of before. That was casual peeking, not even a serious audit.

> I found random number generation flaws in Terraform I would of -never- found > without source code access.

Do you professionally audit software? The fact that you can't find a bug without source does not mean that no-one can. Project Zero finds bugs in Windows and Edge every other day that are a lot more complicated than figuring out what RNG Terraform uses and how Terraform uses it.

> Security is -hard- and anyone that thinks they can get it right with a SPOF > closed source approach is more interested in marketshare than security.

Since you've impugned my motives in two separate places in that post (referring to me as a "shill"), I am no longer interested in discussing this with you. I'm sure people can make up their minds from the thread.

<comment><AUTHOR> I changed the word "shill" in an edit right after I posted as that was unfair/unhelpful and realized you might think it was directed at you. It was not. I welcome this type of debate personally.

> Do you professionally audit software?

I do as a matter of fact. I'll be honest it is normally much easier in closed products as I know what to look for. It is generally much harder to find flaws in popular open source systems as someone else has usally long beaten me to the low hanging fruit in critical codepaths.

I have been burned and seen others burned so many times by closed software and teams that ship security regressions that I now personally use only open tools I can audit at some level, or can audit the auditing and reproducible build process. I have seen "security" companies cut corners too many times in order to feature farm to trust anything that won't let me see the source code.

I have even professionally audited multiple systems on the spreadsheet myself, some of which I am aware of vulnerabilities for currently under embargo.

So far you have cited examples which I not only didn't ignore but responded to in the form of counter examples.

This is however turning into a open source vs closed source debate with subjective evidence, which in the end always boils down to if you have blind faith in a small group of people or not.

In the spreadsheet I tried to only include things that could be fairly objective, but when we get into concepts of trust of binaries and their authors, it gets muddy to be sure, and we will end up choosing paths based on our own threat profiles and experience.

This is why I tried to include -everything- in the spreadsheet I am aware of, so people with threat profiles different than mine can make informed choices.

<comment><USER3> You professionally audit secure messaging applications? For what kinds of vulnerabilities? I have turned down invitations to audit some of these applications because I didn't feel qualified to render an assessment (I've been doing professional software security assessment, of closed/open source applications, since 1996). Did you take money for those assessments? Which ones did you do? I'd like to take a closer look at some of them sometime.

<comment><AUTHOR> I audit tools myself, my employers, or partners consider and if I find obvious flaws then I file bugs for those products and generally we either don't use them or limit their use.

I feel qualified only to certify that a tool is obviously insecure, but I don't think -anyone- will ever be qualified to solo certify something as totally secure. (but sadly that is how clean audits are generally read). I have in the past hired 3-4 audit firms and each would find flaws the others did not, and that mine did not, but fail to spot flaws that mine did. No one has the full picture.

The only relevant one not under embargo atm was my recent casual 2-3 hour audit of Lifesize which I found right away had a number of alarming issues the company would not address. Some of these may of been found to be non issues under further inspection, but there was more than enough to assert security was not a major focus of the platform.

This cursory look was all it took for me to feel confident in ending any consideration of that product to protect the interests of the entity considering it.

I reported all these to the company and there was no response for over 90 days and made my findings public after due warning.

They are available here: [https://gist.github.com/lrvick/6e600d8484cfb415d1e2b06e8b345...](https://gist.github.com/lrvick/6e600d8484cfb415d1e2b06e8b3452c2)

(reminder: this was only 2-3 hours of work and by all means grain of salt)

<comment><USER3> I think you probably understand where I am coming from at this point. When I think about "audits" for secure messengers, I think about professional, specialized, contracted assessments with dedicated teams of experts (I'm a little biased, since that used to be my line of work). And my two objections to this discussion are:

1\. I think LVH is right to point out that "audit" doesn't have much meaning in the document you've produced; it gloms together assessments of wildly differing depth and quality and condenses them all to a single pass/fail.

2\. Secure messaging security is _hard_ , much harder than secure transports (which you alluded to in the other subthread when you mentioned TLS). There are in fact not that many people in the world who can do a proper cryptographic assessment of a messenger at this point (not because it's prohibitively difficult; it should be well within the reach of everyone with a graduate degree in cryptography who enjoys coding --- rather, just because it's a specialized skill set that not many people have an opportunity to get good at). Like I said: I wouldn't say I'm qualified to perform such an assessment (LVH, different story). And all that "just" gets you the cryptography! If your messenger gets popular, the framework it's built on becomes one of the most important targets on the Internet!

So I get itchy when people say things that amount to "I've audited things, I have an authoritative opinion about this stuff". Probably not? Maybe, but, like, if we were going to place a bet...?

You can turn that logic around on me. But I'm not the one making an extraordinary claim. You are. So: what _really_ bugs me is the idea that this is a problem domain you can reduce to a Wikipedia-style comparison chart. That kind of chart will get people hurt.

<comment><AUTHOR> I don't know that I made any extrodinary claims.

You did ask me if I audited things before and I answered honestly. I frequently report vulnerabilities in a range of open and closed systems and read a lot about those others find. I also don't consider myself an expert and generally distrust people that claim they are in this space because it is, as you say, really hard.

I initially started a spreadsheet to document the very high level objective traits of messengers I find useful and others found it interesting/useful and helped extend it.

It is far too much cognitive overhead to do deep dive evaluation of 75+ messengers, but what this list allows one to do is quickly eliminate services from consideration that lack features vital to address their use cases, platform targets, or threat profile: for instance the ability to self host, or end to end encryption.

From there once you have your short list, you can then make more effective use of time reading code, doing audits, reviewing audits of others.

If a list like this simply makes someone aware of new up and coming projects in the space, or old ones that have been quietly evolving in capability... then I feel justified in having shared it instead of having kept it as a private document of my personal notes.

I for one learned about a number of new projects when putting this sheet together, and interesting new approaches on solving these problems.

The thing that is pretty subjective about the list is how I sorted items based on my own research and threat profile.

I won't sit here and say Matrix or briar or any other items near the top are perfect, or lacks any security flaws. I personally place my bets on Matrix at this point based on my deep dive evaluation of it and similarly featured alternatives, but that is subject to change! Others are free to share your view that a well funded but closed source messenger like whatsapp is the general best bet.

To sober up on this topic a bit: Matrix has had glaring security flaws in the past, but also so have the options you personally recommend like Signal and Whatsapp.

At the end of the day all one can do is collect data, look over all the options, deep dive into the relative merits and claims of each to the extent one can, look at the research provided by others, and make a judgement call.

This list should be considered a starting point for research and a way to discover lesser known projects as it was for me.

It should -not- be seen as an end all "use this it is most secure" recommendation by any means. Anyone that looks at any one high level list of binary data points and makes an exclusive choice on that alone is doomed to shoot themselves in the foot with or without my help.

Hopefully that addresses your concerns about my intent here.

<comment><USER4> _I don 't know that I made any extrodinary claims._

You published a spreadsheet listing messaging apps 'ordered by security' in which Signal, Whatsapp and iMessage are shown as way less secure than IRC. It also still says, and you've repeatedly argued here, that things like whether, say, WhatsApp uses E2E encryption is essentially unknowable.

<comment><AUTHOR> IRC is lacking in features but setup correctly with modern OTR I stand by it having easy to reason about security advantages Whatsapp and iMessage do not. (Usability is another story)

Notably if there was a blackbox audit of Whatsapp or iMessage 6 months ago you have no path to easily check if a blatant backdoor was introduced in the build you installed last night. You also can't know if there were obvious flaws in the code the whole time that would be very hard spot in blackbox testing if you didn't know what to look for. Maybe the app build from last night leaks its key intentionally via very subtle steganography in metadata?

Compare to a binary I installed via F-Droid that I can confirm was built reproducibly from a given git head I can go see the code review for.

To use a simple analogy: I can see the exact ingredients of what went into -my- meal instead of what went into the meal of the food inspector.

This allows much deeper release accountability and -is- a major security feature iMessage and Whatsapp lack worth flagging.

Verifying security with source code is hard enough. Without source code it is substantially harder and I for one have no interest in using or recommending security tools that fail to be 100% transparent about how they work.

Without source code all we have are claims that can never be thoroughly verified.

<comment><USER3> You keep making this argument and ignoring experts who tell you it is bogus. The whole thread is there for everyone to read; you can pretend you haven't read the rebuttals, but you can't pretend for everyone else. The idea that "without source code we can't thoroughly verify things" is false, and at odds with basically all of modern software security.

<comment><AUTHOR> Oh, I read them. I simply firmly disagree with them and my personal experience of 15+ years finding and fixing security issues flys in the face of your statements. We clearly test software for bugs very differently.

I made specific arguments and use cases to justify my position and you have simply told me I am wrong without directly addressing them.

Once again, I find the term "expert" overrated. I for one admit I am not an expert on security, a field that is already hard enough on auditors like myself without withheld source code.

I have also worked with a half dozen or so security auditing firms all of which stated source code access would make their job much easier.

It didn't take me hours of blackbox testing for me to find CVE-2018-9057. It took me 20 minutes of reading code on Github half asleep at 4am because I was curious about an unrelated bug.

I remain convinced blackbox testing would of very probably never found that vuln, and even if it did, not in as short of a time period. I trust Terraform over closed alternatives because it was patched within a couple hours of me mentioning it on IRC by a peer who submitted the bug report and patch in one shot. I could verify the source code fix easily and compile the new binary myself to take advantage of the patch before Hashicorp even merged it.

I can also easily verify there are no regressions in future releases.

Tell me how you go about solving for this or other subtle cases like stego exfiltration more easily -without- source code. Also how you or your team could of patched the issue yourself without source code.

If I really solved this the hard way then I will by all means move my security engineering career to focus more on blackbox testing as you seem to be advocating for.

<comment><USER3> It sounds like you're arguing that you'd require source code to see whether something was using math/rand vs. crypto/rand, something that is literally evident in the control flow graph of a program. I do not doubt that source code makes it easier to review code when you're half-asleep at 4 in the morning.

For your particular example: go download a copy of radare and pull up any go build artifact and see for yourself how hard it is understand what's going on.

I don't know about your security engineering career, but if you intend to get serious about vulnerability research, yes, you should learn more about how researchers test shrink-wrap software. I spent years at a single stodgy midwest financial client doing IDA assessments to find vulnerabilities in everything from Windows management tools to storage appliances. It wasn't my IDA license; I was augmenting their in-house security team, which had 4 other licenses. This was in 2005.

<comment><AUTHOR> The primary vulnerability here was that the author used the current time as the sole random seed for generating passwords. From there the output of a PRNG -looks- random, but is in fact based on something that happens every day and thus not really random.

If you can understand a PRNG algorithim and how it was seeded without source code using nothing but radare faster than I could read the code... then you really do have some superhuman skill, and most of my arguments fall flat.

Subtle cryprography flaws like this could be introduced intentionally as well by a bad actor, or pressure from a state actor. They are very hard to see without source code in my experience.

You just kind of made my point for me, in that seeing the output in something like radare -is- often much harder to understand what is going on than just looking at the source code.

Don't get me wrong, I have a deep respect for people that are very good at finding bugs this way. When you -don't have source code then finding bugs via methods like this is the only thing you have on the table, and it is impressive.

What I am taking issue with is you trying to in effect claim that some people like yourself are so good at blackbox testing that you could find all potential bugs faster with those tactics than you could reading the relevant source code.

Consider though that not all researchers work this way. Many bugs have been found by myself and other researchers I know by simply reading source code, so your argument that a vendor releasing source code gives it no security advantage is just not true.

While I am no fan of Signal, the fact they make their source code public makes it much easier to audit and trust its e2e cryptography implementation than say Whatsapp. Even the two tools you favor are wildly unequal in transparency and auditability.

Perhaps the majority of my background working with FOSS software has made me undervalue blackbox testing and you have made a good argument for it. It would make me more well rounded and I intend to pursue it.

I think if there is anything you can take from my side of this discussion it is seeing the value of providing source code to the right eyeballs that know how to quickly spot certian classes of issues.

That source code in the hands of the right person is a faster way to find some bugs than one could in a binary reverse engineering environment.

<comment><USER3> Oh for God's sake, dude. Write a Go program with a function that seeds math/rand from time.Time, compile it, and then load it into radare. "aa", then find the symbol for your function, then switch to disasm view and look at the function.

(The Terraform function you found this problem in is literally called "generatePassword", in case you planned on writing 6 paragraphs on how hard it is to find the right symbol to start analysis at.)

This is such a silly, marginal bug, it's bizarre to see you kibbitzing on the "right" way to fix it (the bug is that they're using math/rand to generate a password instead of crypto/rand, not that they're seeding math/rand from time). But whatever! Either way: it's clear as day from literally just the call graph of the program what is happening.

Your example of a bug that is hard to spot from disassembly is a terrible, silly example, that I've trivially refuted in just a couple of Unix shell commands.

I don't think you understand the arguing you're trying to have. I get it: _you_ have a hard time looking for bugs in software. That's fine: auditing messengers is supposed to be hard. You don't have to be up to the task; others are.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> As there's pretty obvious bias showing in the values, some methodology would be good to accompany this sheet.

e.g.

\- Telegram: E2E Private: TRUE

\- WhatsApp: E2E Private: CLAIMED

These are either both "true", or both "claimed". Pick one.

In particular, what's the definition of the "Open Spec" column? Signal's GPL spec gets a FALSE here so I'm presuming the definition is something along the lines of "Spec produced by one ofa group of arbitrarily approved bodies of which Open Whisper is not a member"

<comment><USER6> The comments specify what "claimed" means:

> Not possible to verify as application is closed source. Maintainer could > compromise security at any time without detection.

I think it's useful to have this differentiation, even though technically you could say E2E is TRUE for both of these.

<comment><USER7> Telegram's state of source code availability (and whenever prebuilt binaries match that) is a total mess. I think only F-Droid build would qualify, but not the mainstream sources.

<comment><USER8> That argument goes for every floss app. If you download their binaries from a play store (that is not f-droid), there's no guarantee that what you get is the same as what the source code would produce. f-droid is not a 100% guarantee either (e.g. not all apps support reproducible builds), but it's certainly better than the mainstream play stores.

<comment><USER2> As I've mentioned elsewhere: this is why you audit the apk, not the claimed source.

<comment><USER8> This is why you only use app stores that support reproducible builds.

<comment><USER2> That only works if you trust the store, and you somehow only know how to audit from source. Neither is true for professional audits: you'd generally start from the APK anyway, even if it's minified, and in many cases you'd actually get the source (which is an optimization only, e.g. to make bug descriptions better/faster).

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> There is no mention of Mumble (client) or Murmur (server). [1] From a privacy perspective, I find it superior to everything else. End-to-end voice encryption with PFS. As much or little server logging as you wish. Super easy to set up and scales to large numbers of people. I have a few of them running on VM's with 1GB ram. Only downside for me: It is not as happy-clicky (frictionless) as discord, yet.

Authentication can be tied into 3rd party apps (LDAP, phpBB, etc) but I have not tested this yet. [2]

If you try it, use their latest snapshot for server and client. Incredible sound quality. Nice UI/UX experience. Decent support for game overlays. Very low CPU usage.

[1] - [https://wiki.mumble.info/wiki/Main_Page](https://wiki.mumble.info/wiki/Main_Page)

[2] - [https://wiki.mumble.info/wiki/3rd_Party_Applications#Authent...](https://wiki.mumble.info/wiki/3rd_Party_Applications#Authenticators)

<comment><AUTHOR> Added!

</comment></comment><comment><USER10> Well, that is a protocol comparison. A client comparison would be much closer to the real world user experience. Don't get me wrong, I am a huge fan (and daily user) of XMPP, but the best protocol will not be of any use if the clients are too complicated or buggy to use.

So yes, XMPP supports audio and video calls but finding two different clients which work on the first try together can be a challenge. Sometimes I wish there would be some compatibility XEP which defines a common set of supported XEPs including a test suite to run it against.

<comment><USER11> We have the XMPP Compliance Suites 2018[0] providing an overview of protocol- level specifications that a modern client or server should implement, and there was recently a nice article[1] for some example use cases.

What is still missing is everything above the wire protocol level. The XSF, being the XMPP Standards Foundation, is guarding the protocols, and things like UX and client interoperability are considered as off-scope. However, there are people interested in these topics as well looking for fresh collaborators.

[0] [https://xmpp.org/extensions/xep-0387.html](https://xmpp.org/extensions/xep-0387.html)

[1] [https://www.erlang-solutions.com/blog/21-xmpp-use-cases- and-...](https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-the-best- ways-to-achieve-them.html)

<comment><USER10> That looks pretty cool. Maybe I should ask SamWhited why they didn't include OMEMO, Audio and Video Calls as features as he is writing in this thread too :D

</comment></comment></comment><comment><USER12> Where's the "don't allocate 8 gigabytes and crash the system" feature?

(Yeah Slack, I'm looking at you.)

<comment><USER13> Indeed, and for "compatibility" it doesn't really say anything about the quality of the software for that system. Signal, for example, doesn't have a native iOS app and it shows.

<comment><USER14> Yes it does? [https://github.com/signalapp/Signal- iOS](https://github.com/signalapp/Signal-iOS)

</comment></comment></comment><comment><USER15> It's funny and sad that XMPP hits almost all of the points, has been around since 1999 and yet every year someone reinvents the wheel and makes another messenger system. There are what, about 60+ by now.

Granted XMPP is not a messenger it's a protocol and a bunch of standards but still it's hard not to laugh.

<comment><USER16> When Jan and I evaluated XMPP in 2009, we found that it was not very mobile friendly. To provide a couple of examples -- (1) The login path required an inordinate number of round trips (I think it was 4+). This slowed down login quite considerably. (2) XMPP is byte verbose and expensive on mobile networks.

We came to the conclusion that XMPP was built for desktop computers connected to strong internet via LAN connections not for mobile networks. We went on to invent our own protocol which was byte efficient and minimized roundtrips.

Now take all of this with a grain of salt. It is now 2018 and things have changed considerably.

<comment><USER17> > that XMPP was built for desktop computers connected to strong internet via > LAN connections not for mobile networks

Oh it definitely was. However, extending it to work well on mobile devices without throwing the whole protocol away turned out to be feasible.

</comment></comment></comment><comment><USER18> I would like to use Riot/Matrix but its UI (at least on Android) is terrible. I can't convince non-technical friends & family to switch.

Part of the problem is the inability to assign nicknames to contacts, so you have to remember everyone's Matrix ID.

<comment><USER19> For me, the problem is how _incredibly slow_ Riot is (and every other client I've tried has almost unusable bad UI, sometimes in combination with being slow).

IMO: Text chat with a few emojis and images here and there should not _ever_ be among the things that slows your computer to a crawl.

EDIT: I'm speaking of the UI, not the network connection; the latter is sometimes slow too, but that's understandable

<comment><USER20> It's very likely that what was slow there was not riot, but the server. The Matrix.org homeserver is notoriously overloaded.

<comment><USER17> Matrix.org is so slow it's borderline unusable, that's right. However, while switching to another homeserver (and avoiding federating with big rooms like Matrix HQ) helps a lot, Riot isn't exactly a lightweight client as well.

</comment></comment></comment></comment><comment><USER21> Are there any good XMPP clients that provide a "modern" messenger experience? For example seamlessly switching between online/offline mode, built in audio and video calls, sharing photos/videos.

<comment><USER22> Cross platform, closed source, including Jingle (audio/video): [http://astrachat.com/](http://astrachat.com/)

Android (no audio/video): [https://conversations.im/](https://conversations.im/)

Web: [https://conversejs.org/](https://conversejs.org/)

Web with extras: [https://movim.eu/](https://movim.eu/)

Desktop (Mac): [https://adium.im/](https://adium.im/)

Desktop (Win): [https://gajim.org/](https://gajim.org/) (not sure about this)

Desktop (Linux): [http://pidgin.im/](http://pidgin.im/) (needs extras: [https://petermolnar.net/instant-messenger-hell/#extra- plugin...](https://petermolnar.net/instant-messenger-hell/#extra-plugins-for- pidgin) )

<comment><USER23> Pidgin is barely maintained for the last couple of years and doesn't support most modern XMPP extensions. I'd definitely recommend Gajim on both Windows and Linux, which supports everything you need out of the box.

<comment><USER22> > doesn't support most modern XMPP extensions

Hence the link for extras, but it is a valid issue. Gajim is XMPP only, where Pidgin is multi-protocol, which is the main reason why I'm still using it.

</comment></comment></comment></comment><comment><USER24> > Signal --- Introduced: 2017

What [https://signal.org/blog/the-new- textsecure/](https://signal.org/blog/the-new-textsecure/)

</comment><comment><USER25> What is the data source for all of these? I'm particularly curious about a number of the "claimed" entries.

<comment><USER26> +1 It seems like someone just created a spreadsheet with no description of what methodology was used to test the assertions.

<comment><AUTHOR> If you click the cells you will see the rationale for columns or what "claimed" means etc.

</comment></comment></comment><comment><USER27> Here's another scorecard: [https://www.securemessagingapps.com/](https://www.securemessagingapps.com/)

The EFF doesn't do recommendations for all users - whether a messenger works for someone depends on their threat model. [https://www.eff.org/deeplinks/2018/03/why-we-cant-give- you-r...](https://www.eff.org/deeplinks/2018/03/why-we-cant-give-you- recommendation)

</comment><comment><USER28> A missing column among the Features is if a system allows automation (chatbots or other). Notable examples: Telegram and FB Messenger do, WhatsApp doesn't (there are workarounds but they're mostly against the Terms of Service.)

<comment><AUTHOR> Great suggestion. Will add this.

</comment></comment><comment><USER29> XMPP is a protocol meant for building chat services; some of these others are chat services themselves so eg. it doesn't make sense to say that XMPP is not e2e by default (of course it's not, it's a protocol which may or may not be used to build an e2e encrypted chat service). Maybe that should be changed to "Jabber" which is what a lot of people call the public, federated network of servers built on XMPP these days? (The term has all sorts of other historical baggage and some people use XMPP/Jabber as synonyms, but mostly I think people use Jabber to refer to the public network these days and XMPP to the protocol, rather like email and SMTP).

</comment><comment><USER30> Surprised public API availability is not listed.

<comment><USER31> This is a pretty important category for me. Users are actually pretty happy to migrate to new chat systems (with clear benefits) if you can pull off a gradual migration with seamless chat linking.

I did a gradual migration of our group chat from $LEGACY_CHAT_SYSTEM to Telegram because at the time, all the options with better crypto stories fell down; WhatsApp is very anti-bot, Wire's API was unusable on free accounts, Signal's group chats work differently / would've needed O(n) phone numbers, Rocketchat's IRC integration was incompatible, Matrix couldn't be simplified to hide the federation for standalone, etc etc.

</comment></comment><comment><USER32> There still isn't a popular messaging and voice call platform that supports private end-to-end encryption by default. How terrible is this? I mean it would be so trivial to establish a secure and private communications standard. Europe and North America has a population of almost a billion people combined. If 500 millions of those live in first-world conditions and only 1% cares about privacy, with $1/year worth of giving a fuck we could have a budget of $5M/year, or close to 50 top notch developers to pull this off. Obviously a lot more could be spend, but even with this minuscule spending we could still have a viable, standardized alternative to Facebook and Google.

We literally had better privacy when we had analog phone lines that anyone could tap into. That's just terrible.

<comment><USER5> WhatsApp does but the author of this sheet has chosen to list it as "claimed", despite other also-unverified clients like Telegram getting a "true" for their (non-default) e2e support.

FWIW I believe Riot/Matrix are planning e2e by default as soon as their implementation stabilises. Theirs is more complex/powerful than WhatsApp's though since they have multidevice support (which WhatsApp lacks). They've avoided making it default sofar due to bad UX and the possibility of losing access to conversations across devices, but it's improving rapidly.

<comment><USER33> Yup planning to get it on in the coming months. As a data point e2e by default is on for the French government deployment and we haven't seen huge drama, so we're mostly waiting to get the UX out. We'll be sharing our work for insights this week.

</comment></comment></comment><comment><USER34> Maybe we could add a section regarding Api's, developer features or available authentication methods?

</comment><comment><USER35> With categories emphasizing security, open standards, and audited code, I'm surprised SpiderOak's Semaphor isn't on this list: [https://spideroak.com/semaphor/](https://spideroak.com/semaphor/)

</comment><comment><USER36> There are two "Line" listed, is it a mistake or are there really two of the same name ?

Because LINE claims to support E2E by default ("Letter Sealing"), but only one of those two listing says "claimed" (the other say false).

</comment><comment><USER37> Kakao Talk has claimed to have E2E Encrypted chat at least since 2014; it is not on by default.

[https://www.pcworld.com/article/2856452/kakao-talk-adds- secr...](https://www.pcworld.com/article/2856452/kakao-talk-adds-secret-chat- feature-amid-privacy-worries.html)

[https://techcrunch.com/2014/12/07/chat-app-kakao-talk- begins...](https://techcrunch.com/2014/12/07/chat-app-kakao-talk-begins- offering-opt-in-encryption-following-recent-privacy-storm/)

<comment><USER38> Amended.

</comment></comment><comment><USER39> The spreadsheet seems to be missing e-mail.

</comment><comment><USER40> What's the difference behind TLS "true" or "claimed"? It's pretty straightforward to verify all outgoing requests the client is making without looking at source code.

</comment><comment><USER41> So, riot/matrix, nextcloud/talk, briar, and xmpp should merge together into a super-mega-awesome-protocol and transform into mega-message! ;-)

</comment><comment><USER42> Have your tried Grape (chatgrape.com)? On-Premises and Eurocloud, used by banks, telco providers, city departments, energy providers etc. in Europe

</comment><comment><USER43> Interesting comparison Irvick. Enjoying the resuling conversation too. More detail on meanings and methodology would be helpful as some other HN folks suggest.

Stealthy.im isn't mentioned (I develop that presently).

Stealthy makes use of decentralized identity in the blockchain and a decentralized storage system called GAIA. Regular chat is E2E encrypted using ECIES. Currently released for Android and iOS.

</comment><comment><USER44> I think Tox should be higher than Jabber. With Tox, there are no servers and contact list is stored on your device. With Jabber, it is stored on the server (and will be happily provided to NSA when needed). So unless you deploy your own Jabber server, it provides less privacy.

Regarding Wire, is not contact list stored on Wire's server? Then it is even less private than Jabber.

</comment><comment><USER45> LINE E2E are "Partial Claimed" their E2E encryption only encrypts text and GPS location and other are not encrypted.[0]

[0]: [https://engineering.linecorp.com/en/blog/detail/65](https://engineering.linecorp.com/en/blog/detail/65)

</comment><comment><USER46> I came across Tungsten Messenger the other day and it's supporting even multiple personas (public, private) and runs traffic via Tor. Pretty neat UI and the team is throwing out new features regularly: [http://tungstenapp.com/](http://tungstenapp.com/)

(Edit: typo)

</comment><comment><USER47> Nice. It's missing RetroShare (which is not only a messenger system but can be used as one) :).

</comment><comment><USER48> [https://forsta.io](https://forsta.io) is missing.

</comment><comment><USER49> This is great thank you!!

Would love if the decentralised/federated were two distinct columns. :D

</comment><comment><USER50> Is there any messenger that does end-to-end encryption with reliable, in-order delivery with decentralized group chat and conversation history syncing? Been looking for years but so far the double-ratchet is inadequate.

<comment><USER9> Mumble / Murmur are close to this, but without chat history syncing. End-To- End PFS encryption though. Very decentralized, but you can tie it into ldap and other authentication systems. I linked in another part of this thread.

</comment></comment><comment><USER51> Does anyone know what supports E2E encrypted video? (Great doc btw)

<comment><USER52> Wire [https://wire.com/](https://wire.com/)

<comment><USER53> Wire comes with a short-fall by virtue of the fact they store a lot of metadata about you.[1]

Obviously your threat model informs this.

[1]: [https://twitter.com/tqbf/status/862394778331361281](https://twitter.com/tqbf/status/862394778331361281)

</comment></comment></comment><comment><USER54> A flawed document like this does far more harm than it does good. I'd implore the author to take it down before they mislead people into drawing the wrong conclusions.

</comment><comment><USER55> What does "E2E Audit" mean? Or, why does Ricochet have a "false"? The Ricochet codebase has been audited, if that's what it's supposed to mean.

<comment><USER56> I think it means two parties can verify their public encryption keys with one another.

<comment><USER55> E.g. by comparing them in person? Ricochet can do that. The "Ricochet ID" is just a hash of the public key, so if you meet up in person and verify that you have added the correct ID for your counterparty, that sounds like you've verified the public keys, no?

</comment></comment></comment><comment><USER57> IRC is listed as "E2E Private" true?

<comment><USER49> I assume it depends on the client?

<comment><USER57> If you can communicate random text, you can layer E2E encryption over almost any communication medium. OTR is a great example of this. But it isn't a feature of the protocol.

Many irc servers listen on an ssl port, but this then only encrypts data between client and server. The data is decrypted on the server and sent to other clients. (Maybe encrypted)

Some ircd's support "encrypted only channels" where if you're not connected via ssl, you can't /join

</comment></comment></comment><comment><USER58> No mention of Semaphor by SpiderOak?

<comment><AUTHOR> looking into it and adding it.

</comment></comment><comment><USER59> So many competing, incompatible protocols. So, so many.

Also this is lacking a column for "stickers". Seriously they are one of the things that has my and my crowd using Telegram, especially since it's really easy to make your own custom sets instead of relying on whatever they pay someone to draw for you.

</comment><comment><USER60> iMessage is technically phoneless; you can sign up with your Apple ID on macOS.

</comment><comment><USER61> Would be nice to show some numbers as well, how much are these platforms used.

</comment><comment><USER62> Why is Signal scoring so bad?

<comment><USER63> I stopped using Signal due to being bitten by the the issue where a friend uninstalled Signal without going through a special process and then I couldn't send messages to them without changing my message type from encrypted to unencrypted every time. See report/references here[0].

[0] [https://github.com/signalapp/Signal- Android/issues/8181](https://github.com/signalapp/Signal-Android/issues/8181)

</comment></comment><comment><USER64> I can't see Jitsi there

<comment><USER64> also, what about 'blockchain messaging' apps like Dust, Echo etc. ?

<comment><USER2> Dust is woefully underspecified and uses an ancient design with no forward secrecy and no (specified) message or sender authentication of any kind.

Blockchain, as usual, purports to solve a problem nobody had. Dust doesn't try to address the simplest, best-understood problems we have for reputation systems on chained blocks.

</comment></comment></comment><comment><USER65> Needs to be updated to show which of my friends use which system

</comment><comment><USER66> nextcloud talk looks good. btw, telegram web has mobile support.

<comment><USER67> Just installed the Nextcloud Talk App. I'm toes deep, but it looks pretty neat so far.

</comment></comment><comment><USER68> No hipchat from atlassian ?

</comment><comment><USER69> It's amusing that this is hosted by a spyware vendor.

</comment><comment><USER70> look at that, XMPP is the future! /sarcasm</comment>


Free vulnerability sweeps for open-source projects - <AUTHOR> https://ossp.softwaresecured.com <comment><AUTHOR> Software Secured (www.softwarescured.com) launched the Open-Source Security Project ([https://ossp.softwaresecured.com](https://ossp.softwaresecured.com)) a project aimed at providing vulnerability sweeps to as many open-source projects as possible. Rules are simple, submit a project, the project with the most votes will be reviewed.</comment>


The fall of CMS and the rise of JavaScript frameworks. Bootstrap vs. Worpdress.  - <AUTHOR> http://www.scriptol.com/getting-started/cms-vs-javascript-framework.php

<comment><USER2> This article is gibberish and reads like the drug-addled ravings of someone who has no knowledge of web design. I don't even know where to START.

The author seems to have no idea what a CMS is, what a Javascript framework is, or what Bootstrap is. He's sort of trying to compare a blog engine to a blog template, which is kind of like answering the age old question: What's better: a house or wall?

We get insane gems like:

      The basic design of the blogging CMS has in fact always
      been deficient. This means putting the site content in a
      database, then generate a page from a SQL query. Then as
      we realize that it's too slow to display, a cache is used
      that creates for each page a HTML file locally.

That's not really true, and Wordpress has drop-in plugins which handle all that for you anyhow. And we don't get anything about how a Javascript framework might work; needless to say they are all database backed. Then we see:

      Why put the contents into a database and then copy it to
      a file on the local system, rather than store it directly
      in an HTML container?

Apparently he's advocating for static file generators like Jekyll? That...almost makes sense. Not that he names any such apps or frameworks, or gives any discussion why they're useful, and he apparently thinks they somehow are jQuery based...?!

What a trainwreck. The only purpose seems to be to try and drive page rank to www.xaml.fr which doesn't look like a real site to me. I think this is just some sort of blogspam/linkbait/SEO trick.

<comment><AUTHOR> Take note that the author has designed two Wordpress themes. The point of the article is not to advocate for frameworks against CMS, but to observe a trend among webmasters. It this trend real? What is the cause? The article tries to answer to the latter, but you may disagree. The link to the demo (that you name linkspam) has been removed. Apparently it was misunderstood.

</comment></comment><comment><USER3> I don't agree with this at all.

First off, he mentions Wordpress which is more of a blogging engine than a general CMS. Sure, if you have a blog then a static site generator is fine, but not all bloggers want to deal with static site generators. Wordpress isn't going anywhere.

"This means putting the site content in a database, then generate a page from a SQL query. Then as we realize that it's too slow to display, a cache is used that creates for each page a HTML file locally."

The problem isn't that queries are slow, it's that developers use too many queries when piecing their sites together in the CMS.

I don't deal with the OS / scaling side in my day job, but I imagine that static files don't always give you the best performance. Loading static files still hits the disk. A better option is probably to load the content from memory based storage / caching.

I have built a lot of client sites, and the blog is usually just one small part of the site. Static site generators wouldn't work for most of the sites I build.

<comment><USER2> Minor quibble: The difference between static files and memory based caching is minimal. Any server OS will cache "hot" files in RAM, so in day-to-day use the difference between nginx serving up static files from disk, or hitting memcached is pretty minimal - it's just a question of which part of the stack is caching your content in RAM. Caching, in general, is famously a very hard problem however, and prone to special corner cases. :)

Your larger point is correct.

</comment></comment><comment><USER4> This article is comparing apples to oranges really. Bootstrap is a CSS framework, which has nothing to do with content administration, it just defines look and feel - or better yet, lays some basics on which developers can build their layouts faster. My CMS of choice is TYPO3 and since Bootstrap was released I tend to include it on all the pages, because I'm more productive and thus faster that way.

<comment><AUTHOR> Of course you can use the two together. The article is aimed to beginners that have to decide how to build their website, using a CMS or a framework? The point is that it seems to be a trend to use only HTML 5 and no CMS. That is interesting.</comment></comment>


A website called voter records dot com to literally search voter records - <AUTHOR> https://voterrecords.com/ <comment><USER2> This link is spam--after clicking through the first few forms it heavily advertises and the scammy public records lookup site www.truthfinder.com .</comment>