Linux workstation security checklist - <AUTHOR> https://github.com/lfit/itpol/blob/master/linux-workstation-security.md <comment><USER7> Not the soundest security advice I've read recently:

> We recommend that you use the same passphrase for your root password as you > use for your LUKS encryption (unless you share your laptop with other > trusted people who should be able to unlock the drives, but shouldn't be > able to become root). If you are the sole user of the laptop, then having > your root password be different from your LUKS password has no meaningful > security advantages.

Your root password is much easier to steal than your disk encryption password. Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc, or sniff it from an unrelated X11 window, or use a microphone. A microphone is far more likely to pick up your root password than a password typed once at boot. If the root password is sniffed with a microphone, the attacker might not even have root access to your system over the network. If stolen with evil-sudo or via X11, you might realize you've been compromised before all of your data is exfiltrated. Neither scenario should let the attacker then steal your disks and be able to decrypt all of your data. Unless you follow the advice.

<comment><USER8> Not to mention this gem:

> it is fine to write down your passphrases and keep them in a safe place

<comment><USER9> Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.

<comment><USER10> Absolutely. I use a password manager for everything except a handful of ultra- critical sites, mostly things involving money or attack vectors to get access to my email. For those sites I don't trust to store in LastPass, I write the passwords down on paper. But I also do something I haven't seen others recommend:

 _Have a (logical) salt for all of the passwords. Don 't write down that salt._

So, if you found my piece of paper with passwords, you might see something like this:

Etrade - <USER2>

Gmail - <USER3>

But my actual passwords are something like this:

Etrade - <USER4>

Gmail - <USER5>

804WMainStreet is tacked on to the end of all of them, but you wouldn't know that from looking at the sheet of paper. Only my spouse knows the salt, and it's easy for us to remember, e.g., maybe 804WMainStreet is the address of the first place we lived together. In theory, this is reducing randomness, which might make it easier to crack one knowing the others, but I'm not super concerned about that.

The two most important elements of security for regular consumers are: 1) Use different passwords for everything. 2) Use multi-factor auth when available.

Whatever you have to do to achieve that is better than not doing it.

*And I actually use initialism for these passwords so I don't have to pull out the piece of paper often, only when I forget. In this example, the Etrade password might be derived from "In 1999 I bought my first stock as a young man. I wish I bought more of it."

<comment><USER11> > *And I actually use initialism for these passwords so I don't have to pull > out the piece of paper often, only when I forget. In this example, the > Etrade password might be derived from "In 1999 I bought my first stock as a > young man. I wish I bought more of it."

Ideally, you'd just set "In 1999 I bought my first stock as a young man. I wish I bought more of it." as your actual password :)

<comment><USER10> Can't really argue with that. I guess got this in habit of using initialisms, because a lot of sites had limits of 32 characters for passwords.

But that's probably less true these days. Since they should be hashing the password anyway, why not allow something huge, say up to 1000 characters.

</comment></comment></comment></comment></comment></comment><comment><USER12> To all those writing the critical comments: I'd love to read a rebuttal to this written by someone who is a Linux and security professional, and explaining not only what is wrong here but why in addition to best security practises. Thanks.

<comment><USER13> Encrypt the root emails instead of sending them cleartext, can easily write a small script to do this and not give away internal security information.

</comment></comment><comment><USER14> FireWire is a vulnerability for Linux only because the kernel maintainers want it to be. There's a register in FireWire controllers which controls the address range for which remote memory accesses are valid. It can be set to 0, which locks out that function. The last time I looked, years ago, it was set to allow access to the first 4GB of memory, because the code pre-dated 64 bit systems.

I once proposed setting it to 0. This was rejected because there are kernel debuggers which use it.

<comment><USER15> Linux has, in fact, supported a configuration option CONFIG_FIREWIRE_OHCI_REMOTE_DMA (default n) since 2.6.26 released 13 July 2008. [0][1] In kernel 3.14, this was changed into a module parameter (default n). [2] I did not further investigate the status of firewire modules before then.

I was unable to locate any relevant mailing list posts referencing "firewire" or "DMA" by the author "John Nagle". [3][4]

[0] [http://cateee.net/lkddb/web- lkddb/FIREWIRE_OHCI_REMOTE_DMA.h...](http://cateee.net/lkddb/web- lkddb/FIREWIRE_OHCI_REMOTE_DMA.html)

[1] [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=080de8c2c57e3199eee837fe8b6d35a43679f8c1)

[2] [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8bc588e0e585bc9085df75e84d4d5635f45cf360)

[3] [http://search.gmane.org/?query=firewire&author=John+Nagle](http://search.gmane.org/?query=firewire&author=John+Nagle)

[3] [http://search.gmane.org/?query=dma&author=John+Nagle](http://search.gmane.org/?query=dma&author=John+Nagle)

<comment><USER16> Are these protections active before the kernel has booted?

Does DMA default to be off until enabled?

If firewire (and thunderbolt, expresscard) aren't DMA-free by default, then there's a time window before/during boot in which an attack could happen.

Full disk encryption/TPM/Secure Boot could help mitigate this though.

<comment><USER17> I am wondering myselves too.

      The new module parameter "remote_dma" (default = N, enable
      unfiltered remote DMA = Y) replaces the former build-time
      option CONFIG_FIREWIRE_OHCI_REMOTE_DMA. (This kernel
      configuration option was located in the "Kernel hacking"
      menu, item "Remote debugging over FireWire with firewire-
      ohci".) It is therefore now possible to switch on RDMA at
      runtime on all kernels with firewire-ohci loaded or built-in,
      for example for remote debugging, without the need for a
      custom build option.

_from:[https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Lin...](https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Linux_3.14) _

I am not an expert in these matters, but could it be that OP is wrong with regarding to firewire? From what I am reading here is that dma is off by default, and can only be activated at runtime.

If the OP is right about the need to disable firewire, I hope someone could explain why so…

</comment></comment></comment></comment><comment><USER18> Nice checklist, signa11. But there are few moments which I should point:

1\. TPM on recent Intel hardware is controlled by Intel Management Engine ([http://libreboot.org/faq/#intelme](http://libreboot.org/faq/#intelme)) which basically acts as a hardware backdoor which cannot be disabled or controlled in most cases.

2\. About firewalling: It's good to filter out even ping from Internet (it's almost always fine to keep it enabled for lan segment) to make automatic detection slightly harder (LOW). BTW, installing coreboot instead of manufacturer-provided firmware (if possible) also could be good improvement (PARANOID).

3\. As for browser(and skype and all the rest of Internet applications) It's good thing to block and audit strange actions such as attempts to access ssh or pgp/gpg keys. By audit I mean set up quite visible and persistent notification. (MEDIUM)

4\. Also, It would be great to add links to NSA Linux Configuration guide ([http://www.nsa.gov/ia/mitigation_guidance/security_configura...](http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml#linux2)) and CIS Security Benchmarks ([http://benchmarks.cisecurity.org/downloads/browse/index.cfm?...](http://benchmarks.cisecurity.org/downloads/browse/index.cfm?category=benchmarks.os.linux)).

<comment><USER19> > 1\. TPM on recent Intel hardware is controlled by Intel Management Engine > ([http://libreboot.org/faq/#intelme](http://libreboot.org/faq/#intelme)) > which basically acts as a hardware backdoor which cannot be disabled or > controlled in most cases.

Seems kinda like this point is conceded: "plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design) ..."

Other than perhaps misplaced faith, you're no worse off than you would be without TPM?

<comment><USER18> So you mean that having device with unlimited network, memory and TPM data access with encrypted firmware and separate processor should not be considered as a huge risk factor?

Due to targeted attack or leak from Intel potential malware can use it to elevate privileges, hide from any type of audit, survive complete system reinstall and even be used to silently infect systems by remote entities.

And lack of TPM module allows to steal encryption password by application running with system privileges, which already have all required access anyway.

</comment></comment></comment><comment><USER20> Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. I like to keep things simple (which is why I use syslinux instead of GRUB as a bootloader. GRUB2 is ugly as sin to configure)

On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.

<comment><USER21> You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.

<comment><USER20> Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.

<comment><USER11> Historical reasons aside, some operating systems (like OpenBSD) are designed to be able to implement different security policies by filesystem. For example, you could mark a given filesystem as executable or non-executable, adding yet another layer of security (at least policy-wise) to a system. And really, with things like LVM and btrfs, there's little reason why this is a _bad_ idea anymore, since expanding subvolumes/LVs is generally trivial.

<comment><USER22> You can do that in linux by bind mounting a folder to itself with the more secure options. I have a couple systems where I do this to have directories noexec, nosuid, etc. Kinda hackish but useful.

</comment></comment></comment></comment></comment><comment><USER23> Any security checklist should start with a description both how the machine is to be used and the expected threats models. There are plenty of things in this list that I disagree with, but only because I am looking at different security needs.

For instance: I see no mention of Tor or VPNs. So this workstation isn't concerned with APT-style threats, or anyone else with the ability to manipulate network connections at a high level. And my quick read sees no talk of memory encryption or any of the physical measures for countering cold-boot scenarios.

This is not a workstation for international (China) travel or for protecting against surveillance. It has some good advice, but is certainly not comprehensive.

<comment><USER24> > Any security checklist should start with a description both how the machine > is to be used and the expected threats models.

It states right at the top that the target audience is Linux sysadmins and their workstations.

> It has some good advice, but is certainly not comprehensive.

"This, by no means, is an exhaustive "workstation hardening" document, but rather an attempt at a set of baseline recommendations to avoid most glaring security errors without introducing too much inconvenience."

<comment><USER23> Ya, all of a paragraph. Any security document, even something as basic as an internal policy statement about passwords, should begin with a thorough discussion of the threats that were in the minds of the drafters. Security is heavily a matter of opinion and perspective. The background on which those are based is therefore as important as the individual recommendations.

</comment></comment></comment><comment><USER25> Nice list, until... install a closed source product that sends backups offsite (SpiderOak). wtf?

<comment><USER26> I was using Wuala but they are closing it down later this year, starting from now. They recommend switching to Tresorit, Swiss based with end to end encryption and no keys held on the server (lose your password at your peril). Any recommendations for cloud storage that is secure and has a Linux GUI? Tresorit is not open source either as far as I can tell from the website.

<comment><USER27> Tarsnap now has a GUI: [https://github.com/Tarsnap/tarsnap- gui/wiki/Tarsnap](https://github.com/Tarsnap/tarsnap-gui/wiki/Tarsnap)

<comment><USER26> Nice, doesn't do Windows though which I am locked into at work, and is aimed solely at backups, not sharing and managing files over multiple computers and OSes which is what I was mainly using Wuala for. But you answered the question, so you get an Internet point.

</comment></comment></comment></comment><comment><USER28> I always install fail2ban so to prevent brute force ssh attacks from getting in. It's popular enough that's it's probably available in your distro's package repositories.

[http://www.fail2ban.org/](http://www.fail2ban.org/)

<comment><USER29> Why would you have sshd running on your workstation in the first place?

<comment><USER30> I've ssh'd into colleagues' machines to help them with system problems, and they've ssh'd into mine to retrieve their VPN keys. Not all of my colleagues have ssh access to a common server somewhere.

I've also remoted into my workstation from home to do emergency work.

<comment><USER11> Ideally, those colleagues would keep sshd disabled unless they actually do need your remote assistance, at which point they'd "service sshd start" or "systemctl sshd.service start" (or however it's normally done with systemd) or "/etc/init.d/ssh start" or "/etc/rc.d/rc.ssh start" or what have you. Minimization of attack surface is an important part of a comprehensive security strategy, and a remote login system - even one with a phenomenal track record like OpenSSH - contributes pretty heavily to that attack surface.

</comment></comment></comment></comment><comment><USER31> For my home computer, sshd is always on. It is configured to disable password authentification. On the firewall, I authorize only two things: ssh port and wakeonlan. If I need to access another port, it is generally enough to open temporarily a ssh tunnel.

I think that you lose most of the advantages of a unix computer if you can not access it remotely.

<comment><USER32> I have Linux on all my home machines, and none are configured to be accessed remotely. There are still plenty of advantages. Far less viruses / malware / crapware. Better performance on under powered machines. Better development environment (for the sort of development I do). No phoning home to MS / Apple (as far as I am aware).

<comment><USER33> > I have Linux on all my home machines, and none are configured to be accessed > remotely. There are still plenty of advantages. Far less viruses / malware / > crapware.

I don't think the 2 ideas are related. I can't think of a script kiddie that would brute force your SSH to install a virus on it. Join a botnet maybe - <USER6> probably not to just install a virus.

Also if you use something like SSH keys or OTP - it's pretty much guaranteed that no one but you can access it.

<comment><USER32> I think I would need to configure my router to port forward ssh before they could do that.(Or am I being dumb assuming that they can't get around that?)

Anyway my point was that Linux has plenty of advantage (for me) without being remotey accessed.

</comment></comment></comment></comment><comment><USER34> It may be silly to ask[1] but is there a similar list for Mac OS X?

[1] Silly because, you know, closed source

<comment><USER35> NSA [1] has pretty good list for major OSs.

[1] Yes, pretty ironic, isn't it?

<comment><USER21> No, it is not at all ironic that NSA provides STIGs for major operating systems. NSA is responsible for SIGINT _and_ Information Assurance.

<comment><USER11> If only the NSA knew that :)

</comment></comment></comment></comment><comment><USER36> Why can't someone simply make a security wizard for Linux. Like I run the program and it gives me options and changes the settings based on my selections. Why must everything be so manual everytime on Linux...

<comment><USER27> They have, it's called Bastille, and it's been around for quite a few years: [http://bastille-linux.sourceforge.net/](http://bastille- linux.sourceforge.net/)

<comment><USER36> Last update in 2012...is it still workable?

</comment></comment></comment><comment><USER37> SecureBoot!? Hahahah, Linux Foundation marks this as critical?

I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key.

But seriously, did anyone else laugh?

<comment><USER38> Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details:

[https://wiki.archlinux.org/index.php/Unified_Extensible_Firm...](https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Secure_Boot)

It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification.

So yeah. Laughing at this advice is at best uninformed.

A nice bonus-effect from using secure boot is that most UEFI implementations secure-boot _faster_. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.

<comment><USER37> I laugh, and get downvoted, because SecureBoot was a noble concept, and rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic.

I deal with computer deployment for a living. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs unless it is not seriously work-related stuff. The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot. Not to mention the numerous IT contractors I meet. It is embarassing.

UEFI is also a mess. I have recently read some good UEFI attack papers, and it scares me to no end, as the firmware extension capabilities make the B in BIOS increasingly seem more ironic. And the potential of having a FAT16/32 parttion of exploitable garbage from system vendors puts just back where we started.

I think this shit is great in theory, but in implementation I do not trust corporations with TPM devices, let alone SecureBoot. It works in principal, but only as long as you trust the US corporate and federal government interests.

For reasons long since expounded on HN and elsewhere, I do not.

<comment><USER38> _rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic._

And that was a good thing. It put pressure on getting the capability to add your own keys.

 _I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs_

Agreed. I guess it all depends on what you refer to as "security".

For me general internet security is about making it harder to get impacted by drive-by malware, portscans and similar.

I set as a general rule that I don't believe there exists _practical_ security-measures which can counter-act malicious activity if anyone has local access to my hardware. I don't try to guard against that.

If your definition of "security" involves guarding against possible systematic attacks from US government agencies using pre-installed (Microsoft) keys, obviously secure boot is not going to provide that for you.

My point was that laughing at secure boot as a measure of increased security because "lulz Microsoft" is a knee jerk reaction which is factually wrong.

 _The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot_

And are you really going to tell me they are not more vulnerable than if they had been using secure boot?

Secure boot can be used to increase security and I don't think that is debatable. I think the reason you're getting downvoted is because you seemingly dismiss this point.

 _UEFI is also a mess_

I think I'll have to agree with this one. With BIOS being clearly insufficient for modern hardware and software needs, UEFI was a pendulum move gone too far the other direction.

It's over-engineered, supports too many crazy things, and coupled with other "messy" features like Intel System Management mode (which also allows code outside the OS), the possible attack vectors (coupled with physical access) are getting increasingly crazy.

<comment><USER37> I thought there was a significant gap between our views, but I think you and I are of very similar viewpoints. Thanks for teasing something more detailed out of me, so I do not feel like so much of a troll.

</comment></comment></comment></comment></comment><comment><USER39> So.. mostly use SELinux and UEFI? This is NOT the advice I wanted to hear.

Maybe I needed to hear it, but both of these things (last I tried them) were a giant messy pain in the rear end. And from what little I understand, both have parties involved in their creation/promotion (MS, NSA) that might don't have stellar open source/privacy pedigrees.

Maybe worth another look.... IDK. But for now... I turn both off.

</comment><comment> vladimir-y I'm working on a fully encrypted laptop (LUKS, all partitions except boot/efi) and feel quite secure.

<comment><USER40> I have a fully airgaped and True-Crypt encrypted computer and don't feel secure at all. I guess it all depends on the attacker you envision and the trust (or lack thereof) you have in your encryption software.

<comment><USER41> What kind of breaches do you fear with your air-gapped setup?

<comment><USER40> The Police.

</comment></comment></comment></comment><comment><USER42> Shameless plug: a software "checklist" for desktop users - [https://github.com/FedericoCeratto/desktop-security- assistan...](https://github.com/FedericoCeratto/desktop-security-assistant)

</comment><comment><USER43> Wasn't the Linux Foundation supposed to be just an umbrella org that provided employment to key Linux devs? So that they could be independent from corporate influence and work indepently/freely without corporate interference.

<comment><USER44> IMO the Linux Foundation serves three functions:

1\. It manages assets: a. Linux intellectual property, like the Linux trademark. b. It secures funding and invests the proceeds to establish fellowships for kernel developers. c. It manages computer hardware for kernel developers.

You remember how [https://en.wikipedia.org/wiki/Kernel.org#2011_attack](https://en.wikipedia.org/wiki/Kernel.org#2011_attack) was a thing? It seems reasonable for the people who's job it is to operate computer hardware to publish guidelines on securing their own workstations, and those of kernel devs who randomly have root access on kernel.org.

</comment></comment><comment><USER45> I'm surprised that they left out Tomoyo as a MAC option. I thought it had a decent following.

[https://en.wikipedia.org/wiki/TOMOYO_Linux](https://en.wikipedia.org/wiki/TOMOYO_Linux)

</comment><comment><USER46> Setting SElinux on enforcing mode on a desktop is almost impossible.

<comment><USER47> Works for me. SELinux is enforcing by default on Fedora and I've never had to change it.

<comment><USER46> Do you add any software that you use into SElinux? Otherwise SElinux is useless.

</comment></comment></comment><comment><USER48> Maybe if you need this much security just use OpenBSD? :)

<comment><USER49> Can you enlighten the uninformed what would make OpenBSD more secure by default? It's my firm belief that the only secure system in the world is one that no one can use, biggest security hole you can add is a person...

</comment></comment><comment><USER50> PaX is not a MAC framework.

</comment><comment><USER51> This is an interesting list, and I don't see anything glaringly wrong ( a few personal preference subjects, but..), so here are my handful of extra tips on top:

1\. You can encrypt grub in order to prevent single user mode et al boot attacks. It can also make FDE systems recovery a pita though.

2\. They already said it, but GRSEC is where it's at. It's really the future of linux security enhancement, and while you can run it in tandem with SElinux et al, I find it's better to run GRSEC and just fine tune it. You will thank yourself for learning it.

3\. These days, you need a HIDS, full stop. What good do logs do if you never know what happens or only check your logs once a week/month/year/never? After spending time trying all the main ones out, OSSEC is my HIDS of choice.

4\. SSH: while fail2ban, denyh0sts, et al are all workable options along with the listed option tweaks, what I find to work the best in addition are two things. A) Obscure port. We all know security through obscurity isn't, but reducing scripties bogging stuff down and keeping your logs cleaner helps imho. (it's also the difference between a metric ton of log alert emails and only a few). B) Two factor all the things. I am using the Google pam module, "libpam-google-authenticator". I stopped trusting tor but some friends of mine swear by ssh over tor hidden service.

5\. The bottom line is that the linux kernel is out of control at >10mil loc, and 0-days/1-days are prevalent. If you have an internet facing system, it's probably going to get compromised, what you really need is the ability to find out as soon as possible when it happens. What this boils down to is you don't want to lose your data, so you need encrypted backups and verifiable checksums/hashes, so that once you've brought up a fresh system, you can restore data asap. Another thing that factors into this is configuration scripts and management stuff. I really like ansible since it works over ssh/powershell. Can really save a lot of time.

If you really want security, you also need to start and run minimal. I would say self compiled is the best (use flag changes often prevent sploits that otherwise work) so gentoo/slackware/arch would be the best nix distros for this. Beyond that, BSD is still king of the security world imho, especially OBSD, but please give DragonFlyBSD a look. While it's not touted as a "secure" distro, it has a ton of features that make it sexy as hell and it needs security contribs if you have the time. If I were starting a fresh ISP, I would be using DBSD.

For those of us stuck wanting to game and do more fun stuff though, who live in a debian/fedora/ubuntu world, just keeping an eye on logs is really the best you can do. Also keep in mind impact on perf that FDE may have if you are a linux gamer.

Those are my main tips/tricks, but I'm sure both the article and I are missing things, so take it all with a grain of salt.

<comment><USER52> You're leaving off two details in your otherwise nice list. First, the backups aren't going to help you in a targeted attack if the attacker can mess with them. For this reason, I always recommended write- or append-only storage for backups. Or a second copy on these made later (i.e. batch process). I used CD/DVD-R's.

Other thing is you've hit problem (0-days) without solution (isolation). There are numerous technologies, especially separation/MILS kernels, that can isolate damage inside one or more VM's. They can also run security-critical processes outside of them directly on the kernel or in their own VM. INTEGRITY Desktop, LynxSecure, and Turaya Desktop are commercial examples. QubesOS, GenodeOS, and Muen Separation Kernel are open-source examples.

So, there are two things. We also have all sorts of interesting tech for protecting kernels in the works in academia that might transfer to rest of us eventually. Better virtualization (esp I/O), DIFT, CPU obfuscation, tags, capabilities, automatic safety/security transforms... you name it, there's already prototypes. So, all is not lost yet. :)

<comment><USER51> Good point on the seperation kernels. I really like the team behind QubesOS, who have written some of the first evil maid articles I've read, but I haven't tried it yet. Have you used any of those systems and have an insights? Are they usable or still in the works?

Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes.

<comment><USER52> QubesOS founder and I got into it on their mailing list so I haven't tried it. Joanna updated her blog and FAQ to try to counter every point without mentioning my name or allowing replies lol. Anyway, my worries were: the Dom0 code in TCB, Xen kernel's complexity plus bug count, no covert channel analysis, that she was unaware of all similar research/issues in that area before Qubes, that she didn't know why user-mode drivers improved system robustness, and that she cited Mach/Darwin as why microkernels like L4 weren't good foundations (?!). All troubling traits if I'm to trust what they produce against High-Strength Attackers. However, my friends that have tried it like it, praise the usability, and say (with backups) you could use it day-to-day. So, I recommend it along the same vein as whitelisting and anti-virus: stops low to mid-grade attackers along with background radiation of Internet.

Plan to try all three again soon. Muen is a straight separation kernel with static configuration. So, will be limited but usable for simple setups: appliances, trusted + untrusted VM's, main stuff in Linux w/ crypto stuff in OBSD or native partition, maybe embedded on decent hardware, etc. GenodeOS is getting rapid development for a small project with a clever, resource- management architecture that needs further evaluation by pro's. Unlike QubesOS, they follow academic work producing best-of-breed components (eg Nitpicker GUI, seL4) and try to integrate them. Project itself was result of work to make more secure architecture. Both of prior have tiny TCB w/ GenodeOS having microkernel's performance advantages (Muen situation unknown). Finally, QubesOS builds some nice architecture, excellent usability, and hardening on top of mature Xen code-base with its risks/rewards. So, not really apples to apples here with any of them. QubesOS is definitely ahead in usability and features, though.

"Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes."

That's true. You have to pay to get the really good shit. OSS/FLOSS never do [1] high-assurance security, though: almost always companies or academia releasing it OSS after the fact. So, I've been investigating models that combine open-source, proprietary licensing, and review. If that's a shock, it's because almost all online discussions talk either proprietary/closed or free/open. However, that's barely relevant for security in practice and narrow thinking that misses other options [2]. So, my idea is to make the software proprietary, optionally a non-profit, have pro's build it for money, put an upper bounds on licensing cost, keep purchases perpetual, simple contract terms that won't change, source provided, extensions allowed with re- submission requirements yet to be determined, paid review by pro's, rewards to encourage others, and contractually to be released Apache/GPL if company tanks or product to be discontinued. This should cover extreme sophistication and labor required to build high-security, let people extend, let people fix stuff, and being more trustworthy. Your thoughts?

[1] [https://www.schneier.com/blog/archives/2014/04/reverse_heart...](https://www.schneier.com/blog/archives/2014/04/reverse_heartbl.html#c5581737)

[2] [https://www.schneier.com/blog/archives/2014/05/friday_squid_...](https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639)

</comment></comment></comment></comment><comment><USER53> This is very handy

</comment><comment><USER11> This is heavily dependent on hardware platform (namely, UEFI - and therefore SecureBoot, which is very foolishly being advocated given its limitations - are x86-only). While this might be acceptable for most users, this ignores that non-x86 workstations do still exist.

> Has a robust MAC/RBAC implementation (SELinux/AppArmor/Grsecurity) > (CRITICAL)

This is too specific; there are plenty of operating systems with a much better security track record than even GNU/Linux that don't implement MAC or RBAC (namely, OpenBSD), and it misses the point of MAC/RBAC: privilege separation. Really, the goal here is for any given program to only have the minimum necessary permissions required for it to do its job. You can do this quite effectively by keeping running services/daemons isolated to dedicated users with a minimum permission set (this is, in fact, the core of how Android apps are sandboxed), especially when paired with a proper sandboxing solution.

The nice thing about MAC and RBAC is that they have policy implications; when used properly, they can clearly define the level of access some running program should have to a given part of the system. They also tend to go hand- in-hand with fine-grained control over resource access, but it's not correct to conflate access control mechanisms with granularity (you _can_ have a fine- grained DAC-based system or a coarse-grained MAC-based system).

> Use full disk encryption (LUKS) with a robust passphrase (CRITICAL)

Or (inclusively) a key file (preferably one which is password protected).

> Make sure swap is also encrypted (CRITICAL)

Or just don't use swap. Even with encryption, if data can be ephemeral, it should be.

> Set up a robust root password (can be same as LUKS) (CRITICAL)

I very strongly disagree with this. As much as I dislike Ubuntu, it does one thing right: it defaults to disallowing any sort of direct root login (by setting root's password to some randomly-generated garbage during installation, IIRC), requiring all root access to be done with sudo unless the user explicitly sets a root password.

I _especially_ very strongly disagree with the suggestion that the disk encryption password should be the same as any other password, let alone the root password that shouldn't exist in the first place (well, more precisely, should exist but should be entirely unknown to anyone or anything, including yourself).

> Globally disable firewire and thunderbolt modules (CRITICAL)

This, along with the recommendations to not use hardware with such ports, should be marked as (PARANOID). While it's certainly a good idea if you know they won't be necessary, there are plenty of valid use cases for them (particularly on Apple hardware; while Thunderbolt display support is still sketchy on Linux, it's still a very common use case), and such actions meet (PARANOID)'s criteria much closer than they do (CRITICAL)'s.

And really, while FireWire and Thunderbolt do have specific security implications (due to them effectively being hotpluggable PCI and PCI-E, respectively), this should hold true for _any_ port on one's machine. Any connector can be a security liability when confronted with a sufficiently- motivated attacker.

> Configure the screensaver to auto-lock after a period of inactivity > (MODERATE)

This needs to be (HIGH), if not (CRITICAL). Why bother with some FireWire jig like what this guide is so afraid of when the machine's already unlocked?

> Installing rkhunter and an intrusion detection system (IDS) like aide or > tripwire will not be that useful unless you actually understand how they > work and take the necessary steps to set them up properly

 _None_ of the things in this guide will be that useful unless you actually understand how they work and take the necessary steps to set them up properly. _None of them_. Not MAC. Not RBAC. Not grsecurity and PaX. Not SELinux. Not LUKS. Not passwords. _Nothing_. This sentence is entirely meaningless.

Not to mention that rkhunter should probably be (MEDIUM)...

> SSH is configured to use PGP Auth key as ssh private key (MODERATE)

What? That's a terrible idea. It's as terrible an idea as using the same password for root and LUKS. If one key is compromised, now the other is, too, because they're the same key.

This is really just a waste of effort and time. The normal approach is to just generate two separate keys, and there's no reason to deviate from this; doing so will just make your life harder _and_ less secure.

</comment><comment><USER54> Install [http://wiki.debian.org/iptables](http://wiki.debian.org/iptables)</comment>


Is Coursera down? - <AUTHOR>

Not able to open since last 15 mins. <comment><USER2> Just as they announced new universities and courses!

<comment><AUTHOR> even i came to their website for that. :D</comment></comment>


Deep Learning and Climate Change - <AUTHOR> https://www.wandb.com/articles/deep-learning-and-climate-change <comment><USER2> A techno-centric world is an energy intensive world. AI, Humonoid-Robots, Automation and 3D printers need more energy. One of the biggest growth area of Energy consumption are Data centers.</comment>


Better to stay away from Bitcoin - <AUTHOR> https://www.dailysabah.com/feature/2017/12/21/better-to-stay-away-from-bitcoin <comment> onion-soup 2011: Better to stay away from Bitcoin

2012: Better to stay away from Bitcoin

2013: Better to stay away from Bitcoin

2014: Better to stay away from Bitcoin

2015: Better to stay away from Bitcoin

2016: Better to stay away from Bitcoin

2017: Better to stay away from Bitcoin

2018: Better to stay away from Bitcoin

2019: Uhh well..

</comment><comment><USER2> "I didn't invest in Bitcoin back in X, so it's shit for reason Y"

Yeah, we know it has its weaknesses but that doesn't mean Bitcoin is bad in its entirety and you should stay away.

</comment><comment><USER3> I wish -coin and crypto- articles/posts would stay away from HN.

<comment><USER4> Submit and upvote other, better articles and flag those you think are inappropriate. Help make HN the place you want it to be.

<comment><USER3> I am but one person and, despite me doing everything you suggest (well except submit, because others always beat me to the punch there), it's a massive uphill battle. This place is slowly turning into reddit, where folks upvote buzzwordy article titles and move on to upvote the next.

<comment><USER4> If you're not willing to help make it better, comments like the one you posted just make it worse by adding unhelpful noise, as is this one. The "place is slowly turning into reddit" trope is old and likewise does nothing to make things better. Yes, it does take effort: most good things do. It's much easier to vandalize than to construct. Please help, not hinder.

<comment><USER3> You clearly read (or retained) only the parts of my comment that you wanted to. Read it again.

<comment><USER4> You're right that I neglected to comment on the fact that you say you do everything but submit articles, and I should have pointed that out. Thank you for doing that! I instead focussed on additional ways to make HN better. It's both how one contributes and how one doesn't. I hope you take this in the spirit it's intended. Your initial comment indicates you want HN to be better. These are strategies to do so.

<comment><USER3> Totally appreciate the reminder that the "power is in my hands" to help make HN better. I flag so much crap, low-effort, buzzwordy articles I come across on HN that I'm surprised the mods haven't revoked my ability to flag. One day I hope to discover new content that someone else didn't already post, so I can submit it here!

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Too many inaccuracies in this article to be believable.

Yes, POW is a problem but reading this article I doubt the author ever designed mining hardware, description of sha256 is wrong for one, whole thing smells.

<comment><AUTHOR> I'm pretty sure the author understands sha256: [https://scholar.google.com/citations?user=pd- IjLcAAAAJ](https://scholar.google.com/citations?user=pd-IjLcAAAAJ)

<comment><USER6> Shh. airbreather has money in bitcoin. Don't confuse him/her with facts. :)

<comment><USER5> Actually I am betting against bitcoin as I only hold alts, and I only hold small amounts of POW coins because I believe the concept is not sustainable and the fixed block solve time brings certain kinds of scalability issues.

I like the look of Universa currently to try and address a lot of the POW issues and also the hard fork and Kitties type problems from full decentralisation.</comment></comment></comment></comment>


Ask HN: How Long To Stay in Boring Job? - <AUTHOR>

Hi, everyone -
About eight months ago, I started a job at a defense contractor that I was extremely excited about, at first. I foolishly thought that the defense world built a lot of cool stuff, which I've since found is only true if you're an aeronautical engineer. The software is bog-standard in my limited experience. I'm working on a system that displays data onto a Google Earth globe from many feeds. When I was interviewing I was told that there would be substantial amounts of work coming up in Flex to replace a Swing based UI that is getting clunky and difficult to maintain. This excited me because I haven't got any Flex experience, and since my Java is pretty solid, I figured this would be a great chance to build the resume and add something more modern.
I found out recently that, not only is the Swing UI staying, but Flex development is not going to happen and the program is going into what's called "operations and maintenance" mode. There will be bug fixes and minor enhancements but no new development. The project is deemed "finished", and most of the good engineers who built it are moving on. Since I already know Java, and none of the work has been terribly difficult, I feel like I'm wasting my time. Due to the nature of defense work, I'm not even allowed to clean up other code unless it is directly connected to a specific bug record.
Within the company, I'm not allowed to transfer until I've been in my current role for two years, so if I stay here it looks like I'm stuck for a while with the dregs of the team who chose to stay behind and make time on this project. This, frankly, pisses me off, because it's a waste of time and talent that I feel I could put to greater use elsewhere. I stayed at my previous job for 4 years, and was in school before then, so I don't think I'm a job-hopper.
What's my best course of action at this point? Should I tell my manager that this isn't what I signed up for and ask for the transfer restriction to be ignored? Should I go get another offer (I have friends at Mapquest and Amazon who have both asked me for a resume) and explain to them why I left this company so soon? Would this sort of thing be seen as legitimate grounds to leave a job so soon after starting?
Thanks. <comment><USER2> By the way you describe the industry, it looks like there aren't a ton of opportunities you find interesting even if you can ignore the transfer restriction.

My answer to your title question is "as long as it takes for you to get a better job". If the situation is as you describe it then no-one would blame you for leaving so soon after starting.

</comment><comment><USER3> Working somewhere less than a year is a yellow flag to future employers, but it is not a big problem if you have a reasonable story. If you switch jobs again, you might even consider omitting the defense contractor job from your resume. Not because a short job is bad necessarily, but it would give you more room on your resume to highlight your other work experience (and present a simpler, more linear "story" for busy recruiters reading through tons of resumes).

<comment><USER4> I wouldn't even call a single instance of a bad job a yellow flag. Lot's of people have accidentally taken a crap job at one point or other in their life. I'd say it's actually a credit to the poster that he realized so quickly that his prospects there are limited and doesn't want to waste his time there.</comment></comment>


The Horse Raised by Spheres - <AUTHOR> http://thehorseraisedbyspheres.com/

<comment><USER2> Most engaging web art I've seen in memory...

</comment><comment><USER3> derp</comment>


(Wel)come back! - <AUTHOR> http://taskforce.posterous.com/welcome-back

<comment><USER2> Looking forward to the new version.

<comment><AUTHOR> Thanks, we are excited to hear feedback of our coming new features as well!</comment></comment>


TransfeWise Borderless multi-currency account - <AUTHOR> https://transferwise.com/gb/borderless/ <comment><AUTHOR> This sounds almost to good to be true.. If so, major disruption imho!</comment>


Java Best Practices - <AUTHOR> http://jdevelopment.nl/java-best-practices/

<comment><USER2> _Not validating user input should have nothing to do with SQL or XSS or any other kind of security pratice. Validation of input has to do with business logic. Sanitizing input is another thing altogether. trying to do both at once is usually pessimal. For example, if you use input validation to prevent SQL injection, you might prohibit the ' character in input fields. This is guaranteed to annoy everyone named "O'Grady." Likewise, if you use input validation to prevent people from entering <script>, you will be shocked when you discover the entertaining ways people have of routing around your homebrewed "filters." Far better to make sure your display layer knows how to display any user input without inserting it as raw HTML._

 _And of course, if you're composing SQL queries by catenating string stogether, you do not need to validate input, you do not need "best" practices, you need basic training. There's a difference._</comment>


Show HN:  Peregrine - the REAL instant photo sharing app - <AUTHOR>

Peregrine! - designed as the real simple instant photo sharing app.  Simply snap and post to Twitter using the native iOS5 SDK.  Took about a day to make and has been open sourced.  Enjoy!<p>http://peregrine.cc/ <comment><AUTHOR> Did someone say promo codes?

JNLR9PKY6RMN N347LX3HHER7 YYJKHAMMYE6E RXEXNT7KMRT9 KL3R96RRWRXA

Try it out, review, enjoy :)

</comment><comment><AUTHOR> <http://peregrine.cc/>

</comment><comment><USER2> I'm not using iOS, so I can't try it out, but a couple of thoughts.

1) You're not winning any customers with that home page. It looks like spam, and isn't especially attractive.

2) If you built it with PhoneGap, why is there only an iOS client?

3) How is this any different than twitpic?

<comment><AUTHOR> I take the comments aboard about the homepage!

Phonegap makes it easy to develop platform specific functions, not just exploiting deploying on many platforms. This app makes sharing via Twitter easier, using the built in (iOS only) Twitter API to submit photos instantly after you snap them.</comment></comment>


IPhone 4S Camera Made by Sony « iFixit Blog - <AUTHOR> http://www.ifixit.com/blog/blog/2011/10/14/iphone-4s-camera-made-by-sony/ <comment><USER2> A surprise? A large chunk of the iPhone is made by Samsung, their most direct competitor: <http://www.economist.com/node/21525685>

What would be exciting is if the lens were made by Nikon, Canon, Leica, or another high end lens specialist, which would truly mark the beginning of the end for point and shoots.</comment>


Kubernetes Is in Hospice - <AUTHOR> https://www.linkedin.com/pulse/kubernetes-hospice-ian-eyberg <comment><USER2> This is not a very good article, there does not seem to be any actual facts in it. It seems to be a rant about something with no first hand experience or concrete exampls to back it up.

The article appears to be written by someone who is the CEO of a company that is directly competing with container industries.

Seems to be a lot of smoke generation.

<comment><USER3> More than a lack of facts, there's a lack of any real depth of opinion. E.g. "{containers, k8s} were an attempt to solve problems X, Y, and Z. Here's where we believe they fail, and where future directions lie." This could be an opinion-based approach, subject to debate, but have value as a point of conversation. And could we get any deeper into Appeal to Authority fallacies: cherry picking tweets, bashing k8s because _Google itself, with scale almost beyond reckoning_ is bound to another tool, etc.

</comment></comment><comment><USER4> This article lacked any useful insight into Kubernetes and the trade-offs involved in using it. My personal experience is this: Kubernetes itself is complex to operate. However, it's very easy to run applications on top of it. The question is whose life you want to make simpler: a small number of admins or a large number of developers?

Attentive readers will note that this is the same design trade-off that public clouds make. (There's also the cap-ex vs. op-ex thing but Kubernetes enables you to manage that as well.)</comment>


Show HN: CloudSkew – Draw AWS, Azure, GCP, K8s architecture diagrams - <AUTHOR> https://www.cloudskew.com/ <comment><AUTHOR> Hello everyone, I'm Mithun, creator of cloudskew.com: a free app for sketching cloud architecture diagrams.

Check out some diagram samples here - [https://www.cloudskew.com/docs/samples.html](https://www.cloudskew.com/docs/samples.html)

Icons for AWS, Azure, GCP, Kubernetes, CNCF, Alibaba Cloud, Oracle Cloud and more are already preloaded in the app.

Documentation for all AWS, Azure, GCP resources can be accessed from within the app itself.

Hope the community finds it useful.

PS: Follow me on twitter for regular updates on this app: [https://twitter.com/mithunshanbhag](https://twitter.com/mithunshanbhag)

<comment><USER2> Hihi, hope its okay to ask, but why is it free? It's a great tool, but you have an associated Professional Services and your privacy policy is currently empty [1]. Will we get contacted about contracting opportunities if we sign- up?

1\. [https://www.cloudskew.com/about/privacy- policy.html](https://www.cloudskew.com/about/privacy-policy.html))

<comment><AUTHOR> LOL. Good questions.

1\. Haven't found the time to fill in the privacy-policy, terms-of-usage pages. Been swamped with feature work.

2\. No, you'll never get ANY emails from us.

3\. Product is free for individual users. However, there are plans to release a paid enterprise version later in the year (with SSO, customer-managed- encryption-keys, customer-managed-storage, team collaboration features etc).

</comment></comment></comment><comment><USER3> No way to try it without signing in/signing up?

<comment><AUTHOR> At present, no. Details: [https://github.com/cloudskew/cloudskew/issues/38](https://github.com/cloudskew/cloudskew/issues/38)

</comment></comment><comment><USER4> The initial experience to get AWS icons loaded was a little strange. I saw all the Azure icons loaded by default, and when I searched for something like "S3" I got a message that said "No records found. Did you try adjusting your icon preferences from the 'user preferences and settings' menu?", but I couldn't find that menu.

I eventually saw the "Add/remove icons" option at the bottom of the screen, and figured out how to turn on the AWS icons, but then I got stuck in that menu. I had to refresh the page to get out of it.

<comment><AUTHOR> Thanks for reporting. Did you notice any browser console errors? If so, would you mind filing an issue here: [https://github.com/cloudskew/cloudskew/issues](https://github.com/cloudskew/cloudskew/issues)

</comment></comment><comment><USER5> This is super nice, congratulations on building and releasing it. It's great that you've got so many decent icons but I find having to go into my profile to choose icon sets a bit unintuitive, I only found that option by blind luck. Also please implement a collapse all for the icon groups.

<comment><AUTHOR> Feedback noted!

</comment></comment><comment><USER6> Looks pretty interesting!

I've been using Cloudcraft [0] for a while now for AWS diagrams, and I'm quite happy with it - it even can do some cost estimation stuff based on resources you have in your diagrams!

[0]: [https://cloudcraft.co/](https://cloudcraft.co/)

</comment><comment><USER7> Cool! Did you know about [https://arcentry.com/](https://arcentry.com/) when you started this? Sorry on mobile so I won't look at your commit history to see if you started before.

I know the guy behind arcentry so just curious.

<comment><AUTHOR> Unfortunately, from what I've heard, that product is being discontinued for business reasons: [https://arcentry.com/discontinuation- letter/](https://arcentry.com/discontinuation-letter/)

Which is a shame because the product screenshots look pretty impressive! I'm not too sure what the ultimate experience with 3D/isometric drawings is like, but the diagrams sure look cool!

</comment></comment><comment><USER8> Have you looked at Lucidchart - [https://www.lucidchart.com/](https://www.lucidchart.com/)? They also have cloud infra icons.

<comment><AUTHOR> Yes, true. However, here's a bit more context on the need for CloudSkew: [https://news.ycombinator.com/item?id=23613510](https://news.ycombinator.com/item?id=23613510)

</comment></comment><comment><USER9> Looks great! What libraries have you guys used in the frontend, if you don't mind sharing?

I worked on an internal tool at a company with a slightly similar UI so I'm curious about it

<comment><USER10> I wondered this too - it's Syncfusion Diagrams with Angular.

</comment></comment><comment><USER11> This looks pretty neat! A visio for the cloud.

I thought it might autogenerate visuals based on Terraform or Cloudformation specs. That would be neat!

Anyway, I'm keeping an eye on this. Thanks.

<comment><AUTHOR> Thanks. Good point.

Some time back, I've received a similar feature request for deployment scripts to diagram conversion (and vice versa).

However:

\- A very, very small fraction of CloudSkew users have actually requested this feature (i.e. not a whole lot of user demand).

\- This is a "high-effort-required" yet "hard-to-get-right" feature (extremely error prone).

So currently, there are no plans to work on this feature.

That said, if enough users demand it AND there is a compelling business case for this, I can definitely add this to the product roadmap.

</comment></comment><comment><USER12> Are there tools that can build a diagram automatically by looking at your AWS account (or some sort of export) for the truly lazy? Asking for a friend...

<comment><USER13> Lookup LucidCharts. I haven't tested it myself.

Edit: They have another service for this.

</comment></comment><comment><USER14> Export/import/sync PlantUML would be awesome.

Does anyone know a visual diagramming tool with diagrams as code support?

I've seen some with basic PlantUML importing.

<comment><AUTHOR> Try mingrammer (not entirely sure if that supports plantUML conversion though).

</comment></comment><comment><USER15> This is quite impressive and I like the transparency provided on the about page regarding your architecture, toolchain, and workflow.

<comment><AUTHOR> Thank you! I'll be writing more about the app as it evolves in the coming days.

Link for others: [https://www.cloudskew.com/about/cloudskew- architecture.html](https://www.cloudskew.com/about/cloudskew- architecture.html)

</comment></comment><comment><USER16> Looks really nice, similar to draw.io but a bit cleaner designs. I would recommend making the default sign up flow friendlier to AWS and GCP users. Right now figuring out how to add those libraries is hard.

Also I would highly recommend more top level groups (AWS, Azure etc...) instead of having each type of service for each cloud on a new side tab. Basically make it more hierarchical.

Finally, make everything collapsed by default. Having dozens of tabs expanded on start is annoying to say the least.

<comment><AUTHOR> Good points. Will add this to my backlog.

PS: The search box (on top of the icon palette) should make things a bit easier. For some icons, it can even search with synonyms (e.g. search for 'nosql' will show 'mongodb'). However this is not consistent across all cloud provider icons currently.

</comment></comment><comment><USER17> Looks nice, what does it do that something like draw.io doesn't?

<comment><AUTHOR> Good question.

While there are many tools for sketching flowcharts, mind-maps, UML diagrams etc, cloudskew has cloud architecture diagrams as its sole focus.

Also planning your cloud architecture requires several round-trips between your drawing tool, document editor (for architecture documentation), looking up reference architectures, googling for AWS documentation (for resource docs, pricing details etc).

CloudSkew can reduce some of these pains today:

1\. It already has a built-in document editor (so architecture documentation + diagrams can reside side-by-side).

2\. Links to official docs (including pricing details, SLA) for all AWS, Azure and GCP resources are available within the app itself.

3\. Bigger icon set (as far as cloud diagrams are concerned).

Later in the year, some cloudskew features will be coming to make cloud architecture planning easier.

<comment><USER18> These are all pretty killer. For non-generalist stuff this is great - I work for AWS myself and arch diagrams are generally draw.io for me, and considering this is a web service I'd be unlikely to use it but in another life, absolutely.

I feel like non-generalist tools like this are useful for exactly what they're good at, especially along with doc links etc.

Any plans to do this cool things like Cloudcraft with describes to pre- populate diagrams? I'd imagine this would be quite an undertaking for a cloud- agnostic service.

Kudos!

<comment><AUTHOR> Thanks.

1\. Does your team/org maintain a central diagram repository? Or do team members use their diagram tool of choice and then export diagram into a central doc library (e.g. github markdown)?

2\. The short-term plan is to add more diagram templates (e.g. VPCs, K8s clusters) to help folks author complex architectures quickly.

3\. There are plans to release a paid enterprise version later in the year with features like SSO, customer-managed-encryption-keys, customer-managed- storage, team collaboration etc.

Overall, CloudSkew will remain focused on cloud diagram only.

<comment><USER18> 1\. Yes/no - my own team is more the latter as I'm more customer-facing and lone-ranger-y, but other teams do a lot more collab and keep things central. As far as I'm aware though, it's a bit of a mixed bag, so getting to the point where we're all on the same page would be fantastic.

2\. This sounds great. I like the k8s angle particularly as well - I have yet to find much useful in that area, so having a service that's good at it would be wonderful.

3\. This I'd imagine would be end-game at AWS. Specifically ability to handle own storage and keys would be an immediate sell here. We've just taken on Slack Enterprise Grid for basically this (granted this was a 2-way deal: [https://www.theverge.com/2020/6/4/21280829/slack-amazon- aws-...](https://www.theverge.com/2020/6/4/21280829/slack-amazon-aws- partnership-amazon-chime-voice-video-calls)) so clearly we're up for it :D

I get the focus though. Seems like a good opportunity to set yourself up as best-in-class for this type of thing. I'll certainly be using CloudSkew for anything I need privately. :)

<comment><AUTHOR> Thank you for the pointers! This is great info.

Also, please feel free to file feature requests or bugs/issues over on github: [https://github.com/cloudskew/cloudskew/issues](https://github.com/cloudskew/cloudskew/issues)

</comment></comment></comment></comment></comment></comment><comment><USER19> Been using cloudskew for sometime. Happy with it. Great support.

<comment><AUTHOR> Thank you!

</comment></comment><comment><USER20> Export to ASCII would be awesome

<comment><AUTHOR> Cool, yes.

Adds business value, no :-)

<comment><USER20> The value is in the marketing, capturing the developer crowds attention

</comment></comment></comment><comment><USER21> What was wrong with draw.io?

<comment><AUTHOR> Nothing wrong with it. Answered here: [https://news.ycombinator.com/item?id=23613510](https://news.ycombinator.com/item?id=23613510)

</comment></comment><comment><USER22> Looks great.

Feature req: snapping to grid

<comment><AUTHOR> Aha, good observation. I actually disabled snap-to-grid a couple of weeks ago (was making the mouse drag sluggish for some reason). Probably a bug on my end, need to investigate further and fix.</comment></comment>


Show HN: CodingBrain – acquire skills faster - <AUTHOR> CodingBrain is a knowledge-management, research and productivity app aimed at developers, technical bloggers and anyone who uses the internet to learn something.
The purpose of CodingBrain is to make your learning, writing and remembering of technical facts more efficient. It serves as your central app that records what you do, helps you to generate new content, enables you to search or remember and tries to automate as much as possible to increase your productivity. This applies to grabbing content from websites, creating new files, moving content around, finding similar notes etc.
CodingBrain is not yet-another-note-taking-app. In fact, it doesn't even have an editor. You point CodingBrain to the location of your plain-text markdown files and then it indexes and analyses them. It integrates with your preferred tools, most of all your editor, but also your (though not fully yet) browser and search engine (Google only at this time, more coming).
* A markdown viewer of your notes (similar to Marked) * A markdown analyser that gives you info about: similar notes, files you linked to, websites you bookmarked or referenced, local & online searches you performed * It has a kind of automated tagging system, by using your search query as a tag * A searchable activity log of your file changes, browsing history and so on * A browser component that enables you to grab content from websites and optionally pasting it into your notes in markdown syntax * Every website you visit will be indexed and cached, and CodingBrain tries to generate a summary about the site that you can edit and annotate * A local search engine that allows you to search for notes, websites, bookmarks.
* A large set of index fields you can search for, for example, you can specifically search for content of markdown headers or code blocks
I have basically built CodingBrain for myself because I was unhappy with existing solutions and always longed for a tool like that. <comment><AUTHOR> Clickable: [http://www.codingbrain.com](http://www.codingbrain.com)

P.S: Mac only at this time. As it was developed in JavaFX porting to other OSes not that difficult so expect this to happen soon.

I'd very much appreciate any input or impression you have.

Thanks in advance :)

</comment><comment><USER2> Download link on the site does not work.

<comment><AUTHOR> Fixed, sorry for that

</comment></comment><comment><USER3> +

<comment><USER4> Pretty intuitive tool. I like it.</comment></comment>


The States That College Graduates Are Most Likely to Leave - <AUTHOR> http://www.nytimes.com/2016/11/22/upshot/the-states-that-college-graduates-are-most-likely-to-leave.html <comment><USER2> Not sure about the methodology here. Say you're born in KY, but move to MA for college. And from there you move back to KY after graduation. The first move doesn't count, since you're not college-educated yet. But the second move counts as moving from MA to KY? Is that why MA is losing college graduates, as per this study? Because MA is chock-full of colleges, thats for sure.

<comment><USER3> The methodology makes the whole study suspect. New York, Massachusetts, Michigan, and Pennsylvania have lots of universities that attract out of state students. They get dinged for out of state students who go to college there and leave the state for work, but get no credit for out of state students who come for college and stay.

It's possible that the overall effect of out of state students is small but we have no way of verifying that with the data presented.

<comment><USER4> I'm curious as to why you think it's such a major issue. The question asked is not "which states are the best at attracting people to their universities", the question asked is "which states are worst at keeping a student as a longer-term resident once the student has completed university in that state". And to answer that question you must report the results the way they have been reported here.

The issue really seems to be that you want a different question asked. In which case feel free to do the research to answer your question!

<comment><USER3> The content of the article makes it seem like the question being answered is "what states are the best at attracting college graduates?" The actual answered question, which you state above, is an artifact of the limitations of their data.

Say that NY and NJ are equally attractive destinations for college graduates. But say NJ has no colleges, and everyone goes to school in NY. Under the methodology of the article, NY will show a huge out-migration and NJ will show a huge in-migration, even though they are identical in terms of keeping long- time residents who graduate college.

I think that phenomenon explains exactly what you're seeing with pairs of neighboring states. Is anyone going to seriously argue that NJ or CT are more attractive destinations for college graduates than NY or MA?

</comment></comment></comment></comment><comment><USER5> "if states are losing more college graduates than they are holding or bringing in, they're effectively subsidizing other states' skilled labor forces."

Defining those subsidies could be helpful, if this refers to the in-state tuition rates, then it would be interesting to see what proportion of students are in-state. Out of all the in-state students, how many actually move out of the state afterwards? I'm pretty confident that in-state students are more likely to stay in the state than other students. On the other hand, it would be very unlikely for let's say a student who grew up in Georgia and studied at University of Michigan to stay in Michigan after graduation.

This is also unfair in the methodology: "Those who grew up in one state, went to college in another, and then moved again are counted as migrating from the state where they attended college." They were out-of-state students, so didn't get subsidized.

If there's other subsidies (than the in-state deductions) which apply to the entire student body, then the argument below is as valid:

"if the _US universities_ are losing more college graduates than they are holding or bringing in, they're effectively subsidizing other _countries_ ' skilled labor forces."

However, in that case there IS some "quick, easy solution."

<comment><USER6> I assume the quick easy solution to educating foreigners and then seeing them move home would be to award an unencumbered work visa on graduation?

<comment><USER7> Anecdata: That would have solved their problem entirely for some of my friends. I can easily think of a good handful of good engineers I know from college that were disappointed to have to return to their home country when they could not find work sponsors. That's not to say that there aren't also the ones who's plan from the beginning was to return home, but for others the US had become their home.

The common story that I heart was that employers were balking at the amount of risk and paperwork required to hire foreign employees.

<comment><USER8> The UK is going rather in the other direction with this: trying as hard as possible to ensure that foreign graduates leave the country when they graduate. :(

</comment></comment></comment></comment><comment><USER9> > A study comparing thousands of American and British census records between > 1850 and 1880 showed that nearly two-thirds of American men moved across > county lines, while only a quarter of British men did.

Doesn't really seem like a meaningful comparison. The US is comparatively massive, with individual geographic and economic regions easily being larger than the whole of Britain.

Not to mention parts of the US were literally still being settled during that time. The frontier didn't close until 1890.

<comment><USER10> In a sense US is still being settled. Populations are shifting and adjusting.

The United Kingdom has had two hundred years to adapt to the effects of industrialization. The United States got in on that much later, with the majority of it happening post-WWI, and at that point the modern layout of the country had only barely been realized. As you point out the frontier was still very much a thing in the years immediately prior to that.

There's still a lot of shifting within the US that you simply don't see in other countries. People are highly mobile, and cities like Austin and Atlanta have changed dramatically in character because of large-scale migration.

The only country actively changing more than the US is probably China.

<comment><USER8> The UK has had only about 30 years to adapt to _de_ -industrialisation, or at least the end of mass industrial employment. There are definitely places hollowed out by it.

<comment><USER11> The US has those same places that have been hollowed out by de- industrialization. Take Detroit, for example. But there are plenty of other examples.

</comment></comment></comment></comment><comment><USER12> Can anyone from New England comment on why Vermont and New Hampshire are so different? Demographics and weather are similar, so surprised to see that Vermont is highly negative and New Hampshire highly positive.

<comment><USER13> I assume it's related to the fact that New Hampshire has more industry than Vermont (concentrated near the Mass border).

But, honestly, as I said in another comment, I'm not sure how much these numbers mean. With respect to to the MA negative numbers, if you've been anywhere near the Boston/Cambridge area recently the idea that there's this mass net exodus of people is pretty silly. Certainly if you've looked at Boston Metro real estate prices or the construction going on in the Seaport or around Kendall Square.

EDIT: It may also be related to MA people living in NH for tax reasons.

<comment><USER14> > mass net exodus of people is pretty silly

Well not necessarily "mass" (pun intended?) but -2% from 2000 to 2015. Note that everyone who moved from other cities in Massachusetts to Boston (and Boston burbs) are considered neutral by this metric. And there's always bound to be graduates of those Boston universities headed for the other coast. Also note that things are very different in Boston and elsewhere in 2016 from how they were in 2000.

</comment></comment></comment><comment><USER15> Highly recommend Ed Glaeser's book if you'd like to further understand the socioeconomics and urbanisation aspects of this trend: [https://www.amazon.com/Triumph-City-Greatest-Invention- Healt...](https://www.amazon.com/Triumph-City-Greatest-Invention- Healthier/dp/0143120549)

</comment><comment><USER16> I'd love to see the statistics for the state of NY outside of NYC.

<comment><USER17> I wonder why NY in general has a negative trend.

<comment><USER18> One theory is that New York's schools are more attractive to people looking to start college than the state's job market, conditions and amenities, and cost- of-living to retain those people after they graduate.

<comment><USER19> You can also work in New York City and live in two neighboring states, which changes the stats somewhat.

</comment></comment></comment></comment><comment><USER20> In my anecdotal, non-scientific experience, a lot of students who go to a university out of state may indeed leave that state upon graduation, but not often to return to their home state, often other states instead. So I don't see a big disadvantage to the methodology.

</comment><comment><USER21> Does anybody have an idea why so many graduates are moving to Colorado?

<comment><USER22> Because it has been doing pretty well lately, economically speaking. People go where jobs are, and Denver is one of those places these days.

As to why that is... this is still a matter of debate, but here's one take. [http://washingtonmonthly.com/magazine/novdec-2015/why- denver...](http://washingtonmonthly.com/magazine/novdec-2015/why-denver- nashville-and-boston-are-booming/)

</comment></comment><comment><USER23> The States that college grads are most likely to leave?

Why, after recent political events, them United ones of A.</comment>


TypeWith.me: Live Text Document Collaboration - <AUTHOR> http://typewith.me/ <comment><USER2> I'm not sure what this offers over Google Docs...

<comment><USER3> This is just an install of the open-sourced Etherpad code. Etherpad, which was made by a YC company, was acquired by Google and discontinued their product, and then open sourced it.

<comment><USER2> Ahh, cool. Thanks for the info.</comment></comment></comment>


Ask HN: Should there be a shame list for bad YC companies? - <AUTHOR> I've been spammed by YC-invested companies in the past.  Usually I politely ask to be removed, or blacklist the appropriate domain.
For the past few months I've been receiving sporadic junk-mails, entirely unsolicated, from a YC company that even boasts about that affiliation in their signature:

    XXX (Y Combinator W16)
 The company has neither responded to my requests to stop, nor replied to the tweet I sent them.
Not all YC companies are spammers, but those that are should be held accountable.  Is there a shame list?  Or am I being petulant by wanting one? <comment><USER2> Just hit "report spam" in Gmail and before long their email domain gets burned. That hurts much more than some shaming list.

The crafty companies use dedicated and disposable domains (e.g. facebookmail.com) for their more "aggressive" forms of email marketing. Alas, most spammers are not crafty.

<comment><USER3> I find the "facebookmail.com" stuff to be super annoying — not just because it facilitates them sending more spam, but also because it becomes more difficult to know for sure if an email is legitimate.

Should I assume that [company] owns not just "company.com", but also "companyemail.com", "companyhelp.com", etc? Or are these domains registered (perhaps with the unicode trick) by savvy phishers?

</comment></comment><comment><USER4> You're probably being petulant.

Email spam is a problem, but "shame lists" are likely to be a bigger problem.

I would suggest solving your problem by creating an email filter for the company's domain name.

</comment><comment><USER5> There have been well over 1000 YC companies now. They aren't a unique enough demographic to get any special treatment, positive or negative. Just treat them like anyone else. Report them as spam and move along.

</comment><comment><USER6> Personally I'd just filter their emails and leave it at that (and report spam if using gmail). If that doesn't satisfy, leave a bad review somewhere?

I don't think a coordinated shame list, just for YC companies would do much.

</comment><comment><USER7> The more interesting question is how did they get your email address?

<comment><AUTHOR> Agreed.

They probably bought it on a list. It's certainly not something I've shared with them directly, or indirectly.

</comment></comment><comment><USER8> You could just filter the incoming emails to be deleted on arrival.

</comment><comment><USER9> It's sort of schizophrenic to want to make a shame list, and then redact out the company name. Unless it was edited by a moderator? (I sure hope not.)

<comment><AUTHOR> FWIW it was GitPrime, though I didn't think that was the sole point if this original post.</comment></comment>