Updated Firefox Security Indicators - <AUTHOR> https://blog.mozilla.org/tanvi/2016/01/26/updated-firefox-security-indicators/ <comment><USER2> Even more interesting: In the current Firefox nightly inputs with `type="password"` on insecure origins are being marked explicitly as insecure. This also includes common anti patterns such as loading an iframe from a secure origin on an insecure page.

There's a screenshot of this on my latest blog post[1] and another article[2] on this topic.

I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices.

1: [https://hugotunius.se/2016/01/24/how-browser-vendors-are- pus...](https://hugotunius.se/2016/01/24/how-browser-vendors-are-pushing-for- https-adoption.html)

2: [https://www.fxsitecompat.com/en-CA/docs/2015/non-https- sites...](https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites- containing-login-form-will-be-marked-insecure/)

<comment><USER3> This is a good, important feature.

Do you know what the plans are for enabling this in all editions of Firefox?

<comment><USER4> The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it.

[0]: [https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10](https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10)

<comment><USER2> Fx 46 is scheduled to be released on the 19th of April FYI [https://wiki.mozilla.org/RapidRelease/Calendar](https://wiki.mozilla.org/RapidRelease/Calendar)

</comment></comment></comment></comment><comment><USER5> Somewhat off-topic: I feel that Firefox has improved significantly lately, even though it ceased to be the "star" browser a while ago. Its usability is much better than other browsers. On Linux for example, it integrates with GTK and the rest of the OS seamlessly. Also websites tend to display and function more accurately than in Chrome. This is subjective, it might be just me who experienced more broken websites lately.

<comment><USER6> I have noticed that Firefox on Android seems to keep up much better on bigger pages. I regularly browse SBNation sites and Chrome locks up to the point that I have to kill the entire browser. Firefox handles it much better, also in my anecdotal experience. That it allows you to install plug-ins like uBlock is simply a bonus.

That being said, the performance on OSX at my last check seemed to be inferior to Chrome unfortunately. The development tools are still inferior, too. I want to move away from Chrome on OSX but still can't justify it.

</comment></comment><comment><USER7> I disagree with their rationale in changing the padlock used to indicate a DV certificate from grey to green (and thus mirroring EV certs) to a point: Yes, the _connection_ is secure, but given the numerous free and automated options to obtain DV certificates, phishing sites are going to increasingly use TLS, and mostly do so using DV certificates.

I guess this boils down to me actually favouring a clear divide between EV and DV. My EV connection to bankofamerica.com should be as visually different from the DV connection to the phishing site bank0famer1ca.com as possible. As it is, the Firefox UI improves visibility of encryption while I think it might be more appropriate to improve the differentiation between encryption and authentication.

As for all the other states: good work. The new iconography seems more streamlined and clear to me.

<comment><USER8> For me the presence of the organisations name in green letters emphasizes the difference. (Besides the green/grey lock difference alone is small enough to miss)

The UI choice i don't like is having a hazard sign for secure websites with mixed active content blocked . Hazard sign implies some hazard exists - but in this case the hazard has been averted, so why show a hazard sign still?

<comment><USER7> > Hazard sign implies some hazard exists - but in this case the hazard has > been averted, so why show a hazard sign still?

The way I see it, the browser actively blocked a hazardous action. The site continues to be hazardous, and another browser might not properly block the action in question. As long as the site is trying to do hazardous things, it should be considered as such (and warned against).

</comment></comment></comment><comment><USER9> what i really want is an indicator of how many 3rd party https domains have dumped active content onto the page. better yet, disallow this behavior entirely.

the fact that banks and other critical portals can dump third party scripts like optimizely and stuff from https cdns is truly disturbing.

it's such an obvious oversight to me that i dont understand how a green anything can be shown on mixed https domain sites. am i not understanding something?

<comment><USER10> Mixed content means HTTP+HTTPS resources, not HTTPS-only resources from multiple domains.

And it's not always clear what's "third-party", as a common optimization technique is to serve static assets form a second domain, to increase the number of parallel connections.

<comment><USER11> > what's "third-party"

That's already defined by the same-origin policy.

> a common optimization technique

Optimization should never happen at the expense of security. (and yes, 3rd party scripts are a security risk)

> increase the number of parallel connections.

I believe that trick is to save bandwidth by not sending the (large) cookies that would normally be sent to the normal domain.

<comment><USER12> Working around browsers' maximum concurrent connections settings is a major reason to use multiple hosts. This table of browser [0] is somewhat dated but these limitations have been have always been present since the first browsers, I doubt they've radically changed in the last few years.

[0] [http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent- co...](http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection- to-same.html)

<comment><USER11> I could have outdated information; in either case speed isn't as important as security.

Why haven't servers started advertising how many connections they are willing to accept? The need for other domains could be easily removed with something like an HTTP response header:

        200 Ok
        ...
        X-Max-Parallel-Connection: 10
        ...

This type of header could even be used to give per-page values:

        X-Max-Parallel-Connection: 20, scope=local-page-only

(there's probably a better way to phrase these, but that works as an example)

Yes, I know these are not supported by browsers _yet_ , but sensibility is one of the best features of HTTP.

<comment><USER10> That's been kinda pre-empted by HTTP2, with its TCP multiplexing and server pushing.

</comment></comment></comment></comment></comment></comment><comment> angry-hacker I think it's safe to assume HTTPS when it comes to browser indications is broken. In a sense that majority of user don't care or understand.

I once had a client who wanted an EV cert, so the company name gets "shown nicely in the address bar". After explaining about encryption for half an hour, the only question was why should I care. It was a simple website for a company. Contacts and about us mainly.

I often ask regular users, and they don't know what difference does it make, the click everything and as far as they care, the lock can even be purple. Which doesn't mean we shouldn't keep pushing https mainstream of course.

Correct me if I'm wrong.

<comment><USER13> > I think it's safe to assume HTTPS when it comes to browser indications is > broken. In a sense that majority of user don't care or understand.

I'd agree with this as well. I find summarising it as "if you enter secret details when the green lock isn't there, a hacker could steal them" isn't concrete enough to sink in for most non-technical users. To really understand what the HTTPS lock icon means let alone what mixed content warnings means requires a lot of background knowledge most of us take for granted (web servers, networking, hacking, how a web page loads scripts/images/css).

Given many people still use simple passwords and the same passwords everywhere because of lack of understanding of what hackers can do, I think it's a lost cause.

People do pay attention to e.g. Chrome's big red "this site is not secure" screen that you have to bypass when there's something wrong with the SSL certificate though. Showing something like this as standard would help.

<comment><USER6> I managed to get my mother to use a password manager. I did my due diligence in explaining the security aspects, as far as "well if someone gets your Facebook password, how likely is that to be your Gmail password" , but mostly had to frame it as a convenience feature of being able to use all these complicated passwords without having to remember any of them.

<comment><USER13> I've lost count of how often I've heard friends and family say things like "well there's nothing important in my computer/email/Facebook anyway". I try to explain about how hackers can use credentials to eventually get into their bank accounts, steal their identity, use their computer in botnet and spam schemes etc. but it usually comes across as farfetched for some reason. I'm sure it sinks in when they or someone they know is directly impacted by a hacker but I think the problem is this doesn't happen often enough.

<comment><USER14> I think the part that is hard to grasp for people without a technical background is the danger of automated attacks. It's hard to explain that even if nobody is interested specifically in their computer/email/Facebook, they can still be a victim of a dragnet kind of an effort.

<comment><USER13> Yeah, I struggle to think of any good analogy that would help explain the problem. You could explain HTTP as like sending a postal letter where an attacker can intercept and read the letter undetected, reply back as if they were the receiver etc . but that's already pretty abstract. Drawing a real- world analogy with automated password attacks seems even harder.

<comment><USER15> "There's a gang around here that like to walk up to every car in the parking lot and try every door. They aren't targeting you specifically, they just try every door knowing that some doors will be unlocked. So always lock your doors"

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> November 2015 these rolled out, not sure why they're republishing them now

<comment><USER17> The post is from November 3, 2015. I'm not sure why this was resubmitted now.

</comment></comment><comment><USER18> Has Mozilla studied how end users acutally understand and respond to those icons?

I have no idea what they mean, other than the plain grey lock and plain green EV lock and name.

</comment><comment><USER19> The real truble with Firefox UX regarding security is that a HTTPS connection with an untrusted certificate is more hassle than an unencrypted connection. But from a security concern, HTTPS with an untrusted certificate is better, it prevents passive eavesdropping at least. It's certainly not _worse_ than unencrypted traffic.

And yet firefox continues to make it hard to accept untrusted certificates.

<comment><USER20> Everyone always defends this, and I can't understand why. Here's the way I see it:

unsecure-cert= me + some unknown entity can read it.

no-cert = me + anyone can read it.

I'd rather have some shady unknown entity read it, than _everyone_ read it. Of course, a warning for both should exist, but IMO, the 2nd is much worse. Am I mis-understanding how this works?

<comment><USER21> An encrypted-but-unauthenticated connection is not readable just by some unknown entity, but by an arbitrary, unbounded number of unknown entit _ies_ , which is practically the same as "anyone."

Anyone who's in a position to passively eavesdrop an unencrypted connection is usually able to actively eavesdrop an encrypted-but-unauthenticated connection with just a bit more work.

<comment><USER20> OK, so then lets change my equation:

unsecure-cert= me + some unknown entity + possibly others

no-cert = me + some unknown entity + absolutely others

So, and insecure-cert still seems like the lesser evil?

<comment><USER21> An unencrypted connection isn't "absolutely" seen by others. If no one eavesdrops on it, it's private, just as an encrypted-but-unauthenticated connection is private if no one actively attacks it.

Theoretically, an untrusted cert is the lesser evil since active attacks should be harder/more expensive than passive attacks, but no one knows exactly how much harder/more expensive they are in practice. This makes me very hesitant to declare one better than the other.

Ultimately, browsers are going to start warning about unencrypted connections, and hopefully one day browsers will treat them just as severely as connections with untrusted certs. Unfortunately, we have to undo decades of bad practices first, which is a slow process.

</comment></comment></comment></comment></comment><comment><USER22> Why not a red "open lock" icon?

<comment><USER23> People look for a lock - that's the only thing everybody knows about web encryption. An open lock is still a lock, thus plenty of people will understand it as secure.

On what case do you want the open lock? If this is about the active mixed content warning, I do think it's worse than the previous version. But well, it can only happen by manual intervention, so nobody will ever see it.

</comment></comment><comment><USER24> Ok, so how do i explain in two sentences to my mom if she is actually on her bank or not?

Can the company name text inside the green bar for EV certificates be spoofed and used for phising?

</comment><comment><USER23> Still no warning on HTTP sites.

</comment><comment><USER25> Too complicated...</comment>


"Curl Bash piping" wall of shame - <AUTHOR> https://gnu.moe/wallofshame.md <comment><USER4> I had this conversation with a person on reddit just the other day. After I pointed that there is no difference between piping a script directly into bash and downloading a package and installing it, they told me that they can audit a script/package they download and that they have personally audited every bit of code on their linux box. The kernel, gnome and metasploit.

I got to thinking what it would take to do such a task, and mainly what I came up with was a whole damned lot of time. Assuming a person can read, understand and remember 5000 lines of code per day (which honestly I think is way more than is realistic), it'd only take 8.5 years to audit the linux kernel. Add in all the other stuff and I figure something on the order of two decades. And in the end you'd be running two decade old software or you'd have to start over.

At the end of the day, security comes from the personal and corporate economics of reputation, profit, and prison avoidance. Do your best to get your stuff from people who you judge to be trustworthy and rely on their own self interest to not be malicious and to do their best to protect their repositories. And rely on others to be good citizens and report the bad shit that happens to them so that things can be cleaned up.

Now I'm not saying to throw out security best practices, but people should be aware that the quality of their systems are built on trust in human nature and self interest.

<comment><USER5> What if the download gets interrupted due to network error and bash runs something else than what was intended. E.g. the script has:

      rm -rf /tmp/something

But when the pipe gets interrupted it executes:

      rm -rf /

<comment><USER6> The body of the shell script should be wrapped in a function which is invoked at the end. If you do not trust them to get this incredibly basic thing right, how can you possibly trust any of the other code they have written?

<comment><USER7> Soo, maybe a silly question... but are downloads from the internet always "linear"? Meaning they go uninterrupted from start to end and if it drops it will stop in the middle of the downloaded file? Doesn't it get "pieces" and then place them together?

<comment><USER8> It depends on your download program, but that's irrelevant because of the pipe. It has to be linearized before going through the pipe.

</comment></comment></comment></comment></comment><comment><USER9> I'm really not a fan of this author's style. The content seems angry just for the sake of it. I'm no expert on it, but it's pretty unclear whether the complaint is even valid, as there are talented, non-"retarded" developers that disagree:

[https://sandstorm.io/news/2015-09-24-is-curl-bash- insecure-p...](https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp- verified-install)

And for an egregious example of the author's approach of being angry without validating anything:

[https://gnu.moe/petpeeves.html](https://gnu.moe/petpeeves.html) <\- an angry post complaining about English mistakes that is itself splattered with basic grammar errors

<comment><USER10> > an angry post complaining about English mistakes that is itself splattered > with basic grammar errors

The following on the home page [0] is hilarious:

      I also maked a sitemap for those who want to dounloud
      errything.

[0] [https://gnu.moe/](https://gnu.moe/)

<comment><USER11> OMG, that looks like a parody of a 1990's web site, except that it's not a parody.

<comment><USER12> How's it not a parody? Seems like it's parodying of a pseudo-Japanese Free Software enthusiast, likely by a 4channer, that just happens to have some real content.

Also: <!DOCTYPE QTML>

</comment></comment></comment></comment><comment><USER13> This page is completely wrong.

`curl | sh` is insecure if you're using an http url, although as has already been said here, it's not really any more insecure than "download this script and run it", unless you're expecting all of your users to actually read through the whole script first. But if you're using an https url then you should be ok since the page cannot be hijacked or modified en route (unless the attacker actually has a trusted certificate for the domain, which is an attack that's way out of scope of this discussion).

The biggest risk with this approach, which the page doesn't even mention, is the danger of the connection being terminated before the whole script is downloaded, as the shell will still evaluate what was sent. But this can be handled in the script by making sure that an early EOF means nothing is actually run (e.g. you can wrap the whole script in a bash function, and then the last line executes the function).

So if you're using an https url, and the script is written to be resilient against early termination, then this is a perfectly reasonable way to install things.

<comment><USER14> There's a few subtle differences you haven't mentioned:

1) If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent.

2) You'd have a hard time proving the first point, or reviewing to see if a script acted poorly, if you didn't have a local copy, which piping to a shell like this normally prevents you from doing.

<comment><USER15> > If you attempt to read the script in your browser first, and everything's > great, then go pipe to bash, the server can send alternate content based on > your user agent.

If you can't trust the site to give you a safe installer then you can't trust the rest of the sources it gives you either--you would need to audit the entire package. Virtually nobody is going to do that. Singling out the installer as uniquely dangerous is security theater.

<comment><USER16> Windows and OSX also do this and present pointless non-defeatable "omg but this is from the scary internet, are you SURE you want to run it????"

<comment><USER17> To be fair, those have been very effective in keeping my non-techie family members from accidentally installing malware because they'll at least check with me when presented with a scary system dialog. And it hasn't impacted my own use other than the occasional extra clicks. In a locked-down corporate setting, I can see how that could be maddening, though.

</comment></comment></comment></comment></comment><comment><USER18> "curl | bash" isn't actually very different security wise from "download this piece of software from our webpage and install it". Every time you install software these days you put a certain amount of trust on the vendor. (This may change in a theoretical future of reproducible builds and binary transparency logs.)

I'd argue that "curl [http://.*](http://.*) | sh" is always bad, but so is every webpage offering software downloads that isn't https by default (and there are plenty of them).

</comment><comment><USER19> How is this more of a security risk than having the user do wget [https://example.com/whatever.deb](https://example.com/whatever.deb) and then dpkg -i whatever.deb? Or adding their apt repo & public keys? Sure, the project maintainer could include malicious code with a curl bash, but they could do in either of the ways I mentioned as well.

And maybe it's not relevant, but I find it really off-putting how the author calls these developers idiots and retards constantly.

<comment><USER20> It's definitely off-putting. And I'm totally fine with curl | bash. Composer (PHP package manager) does that and I've used it hundreds of times (production is containerized, but I do this on my personal machines too).

BUT. There is a difference -- code signing. HTTPS ensures that the data isn't compromised en route, trust in the vendor is what makes you OK with letting them run code on your computer, but neither of those things protect against a compromised payload. ie, if the vendor's server gets hacked and the script replaced, HTTPS doesn't help, and you get code that the vendor never intended for you to run. Code signing is what protects against this, cryptographically ensuring that the code you got is exactly the code the vendor wanted you to have, and is the last link in the chain that connects your machine to a trusted vendor.

<comment><USER13> But it also requires you to have some way to actually validate that the signature is valid. Apple provides this service to registered Apple developers, so you can code-sign your independently-distributed app or installer and the certificate you sign with is generated and signed by Apple. But in nearly all cases of code signing I've seen outside the Apple developer ecosystem, it's GPG signatures, which relies on you being able to independently verify that the signing key is valid and belongs to the vendor and was not compromised. Which is to say, not very many people who download stuff outside of a package system are actually going to validate that sort of thing.

</comment></comment></comment><comment><USER21> I often see the claim that curl|bash is no worse than what a package manager does. That is simply untrue, for the following reasons.

(1) HTTP (no S) MITM. At least the lazy devs admit this one.

(2) No key/signature checking _at all_. Sure, some semi-lazy devs will tell you to add their own repo, and maybe you don't check the key for that repo yourself, but there are others who do and they'll raise an alarm you might hear. With curl|bash you don't even get this kind of herd immunity.

(3) No dependency checking.

(4) No adherence to standards. If you've ever tried to get a package included in e.g. Fedora or Debian, you know that there are people who will go over them with a fine-tooth comb and will reject them if they do bad things (or do them in a bad way).

(5) Most install scripts don't handle interrupted downloads well unless the author has taken special care (thank you for this one eridius). If you're piping directly into the shell you have no idea whether that's the case, and if the dev's lazy enough to be doing things this way in the first place the odds are poor.

Packages and package repos can be deployed and used in many ways. Some ways provide pretty strong safeguards and guarantees; other ways are weaker. Curl|bash is weaker than _any_ of them. There's just no excuse.

<comment><USER16> (1) you can easily see and just not use it (2) is incorrect, see [https://rvm.io](https://rvm.io) \-- it verifies the script (3) you can do within the script, though you'd have to handle different package managers (4) is true for packages as well. You can put whatever you'd like in an RPM or deb including e.g. A post-install hook to sudo rm -rf --no-preserve-root /

Making packages is hard if you want to support many distros. Maybe we should adopt the Go model and just ship binaries.

<comment><USER22> Underneath the curl|bash method, which is what is being discussed I believe, there is a link to a "more secure installation.": [https://rvm.io/rvm/security](https://rvm.io/rvm/security) . These instructions have you download and verify a signed installer.

</comment></comment></comment><comment><USER23> This is a perfect example of dogma over logic. I'm not sure if the author just prefers we all use the Mac app store. Three rules for any installation process:

1\. Make sure you trust the vendor

2\. Make sure you trust the delivery (TLS)

3\. Think twice before you sudo

<comment><USER22> In the world of signed payloads the delivery, (2), includes all the distribution infrastructure. And trusting the vendor, 1, means verifying signature of the payload with their public keys. The assumption here being the building and signing infrastructure is more secure than the distribution infrastructure.

This level of security isn't desirable for everyone in all situations, but it's not just dogma and it's not "the same thing".

</comment></comment><comment><USER24> I don't disagree with the author that it is a huge security risk. But this is yet another example of a software enthusiast who doesn't get the value of convenience. In fact, "convenience" is probably the first attribute of great software.

So again, while I agree with their general sentiment, being "baffled by how [oh my zsh] became so popular" just because it instructs users to curl pipe shows that they don't get the core issue at play here.

<comment><USER25> If I had to provide some sage piece of wisdom that summarized the learnings of my life, it would be this:

"Never, ever underestimate the power of convenience."

</comment></comment><comment><USER26> Piping curl into a scripting environment is problematic for a lot of reasons. For starters, it has a worse user experience than "Download and run this program". I know we love inventing worse user experiences than what's been done for decades, but it's a trend that needs to reverse.

It's easier to mess up security (the early reset thing). This type of install script can't be run offline, because it needs to fetch dependencies (so you can't download it once and run it on multiple systems, and you can never run it on an airgapped system). It accustoms users to pasting commands into shells without knowing what they do, which is irresponsible even without JS clipboard shenanigans.

The author of this page went a lot overboard with the rhetoric, but the simple truth is that there's no good reason to suggest an install method like this. Even taking the exact same script, and asking the user to download and run it is a better plan, because it gives an improved user experience (though still nowhere near ideal).

And yes, I've seen Sandstorm's defense of this practice. I use and very much respect that project, but I couldn't disagree more with the choice of installation method.

<comment><USER15> > there's no good reason to suggest an install method like this

It is useful for bootstrapping a package manager. Haskell's Stack uses this, Rust uses this, Nix uses this, etc

<comment><USER26> Why, though? Why is it better than asking users to download and run the exact same script?

<comment><USER15> Because it's easier for their use case to copy and paste (1 step) than do however many steps you want them to do. If you want to run something offline or run it on multiple machines there is generally a different method available for you to do so. That's not the use case curl | sh is trying to solve in this instance.

<comment><USER26> Copy and paste is 3 steps:

      - Select text
      - Start up a shell
      - Paste the text into the shell

Download and run is 3 steps for a shell script:

      - Click download link
      - Start up a shell so you can access stdin/stdout/stderr
      - Run the script in the shell

For a GUI program, it's 2 steps:

      - Click download link
      - Run the file from your download manager once it's downloaded

Why is piping the file directly into my shell easier than any of these? It's considerably worse than the GUI option, and slightly worse than the shell option because running programs is something I do from shell all the time.

<comment><USER15> > Download and run

I generally have a shell open, so it is easier for me to copy/paste into that session than open a file dialog, save a temporary file, (potentially) switch to a different directory, run the script, and delete it.

> GUI program

Creates a temporary file on my disk, needs a correct file association for .sh since the download manager won't save it with +x (for my machine it automatically opens in Emacs, which isn't what I want), I don't even know how to make Linux open a terminal automatically for .sh. I know on Windows cmd.exe would close the window immediately after running the script so you can't see the output. All in all more complicated than just copy and pasting into an active shell session.

<comment><USER26> The shell is an invariant for script-based installers (i.e. required no matter what). My workflow is also apparently somewhat different from yours, because I tend to open a new shell for each distinct task.

Still, if you're the type of person who generally has a shell open, you can probably figure out how to pipe something from a URL into an interpreter on your own. Which is the better thing to teach to users that can't figure that out?

I haven't manually deleted a temporary file in years, I just have a cron job that clears out my downloads directory. Though this may be a case where my weird workflow changes things from typical, from what I've seen most people just ignore the temporary files.

Most of your objections to the GUI program workflow don't actually apply to GUI programs. I admit that I forgot about the executable bit. I use a mix of Linux and Windows, and basically zero Linux packages have GUI installers -- most prefer .deb/.rpm files, which would be ideal. So I haven't actually run into that before.

It seems like it's only a couple of clicks to fix the permissions in the Nautilus GUI through Firefox, though. Really I would just run the installer from a shell anyway, but that's part of the better user experience: I get to choose that, it's not forced on me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> "And most of all, the people that are part of the project are also likely to be malicious because trying to infect someone is the only valid reason to recommend this method of installation."

I've seen a lot of random accusations about us in the Rust project, but this is the first time I've seen anyone accuse us of deliberately trying to spread malware. I guess I'm learning how it feels to be a politician :)

</comment><comment><USER28> Amusing list. I would like to share it but the unnecessary use of "retard" is a bit upsetting when there are many other appropriate terms (fools, dangerous idiots, whatever)

</comment><comment><USER29> Railing against `curl [https://foo/](https://foo/) | sh`? I guess security theater's not just for the TSA.

(Do be aware of pastejacking though, but this is not nearly an important enough issue for a wall of shame)

EDIT: We can all learn something from the readability of that page though. One zoom and it's better than 90% of the websites I've seen. Text -- it works.

<comment><USER30> Monospaced typefaces have never been good for readability.

<comment><USER11> I beg to differ. There is so much botched typography on the internet and widespread use of Arial-like fonts that monospaced, while not ideal, is far from the worst of choices.

</comment></comment></comment><comment><USER31> It boils down to "Is there any type of attack that can compromise `curl | sh` without compromising a download from the site? I can only think if one - <USER2> download allows for md5 check.

Also the language is too condescending to be taken seriously. Not to say that the tone has anything to do with the argument. And this probably matters less in the software world. But if you want yourself to be taken seriously, you either need to be Linus Torvalds or learn to disagree respectfully.

</comment><comment><USER32> Security is not pass/fail. What threats are enabled by this method? Are there mitigations? Are there alternatives?

It would be a mistake to group all curl pipes. Does it require elevated privileges? Is it served over TLS? Does it do any signature verification? What the heck does the script actually do?

Different levels of security are required depending on trust. I trust Debian's repository, so I feel less need to audit packages. But a random startup promising ponies? I'd like to at least skim what I can, then throw it in a jail/vm/container to test.

How is curl piping beneficial compared to grabbing the script, giving it a quick read, then executing it? Convenience is all I can come up with, and convenience often seems to be at odds with security.

</comment><comment><USER33> Even though I know it's fine, it still feels weird to me when a site asks me to pipe their script directly into a shell. Since I always have the option of breaking it into two steps, though, it doesn't bother me, and I don't think a "wall of shame" is called for.

I do usually glance over a a script/makefile/whatever before I run it--not so much to find security issues but to see if there's anything I'd like to tweak about it. For example, I always install homebrew in a nonstandard location, and that means changing a couple things about the installer script first.

</comment><comment><USER34> At least you have an option to download the script and glance at it before running it if you're worried. Compare that to "Save and Run" an MSI in Windows, which is putting the same level of trust in the product you are downloading except its much more opaque to what is actually happening.

RVM and Homebrew are two big projects that also do this method of installing. They are a breeze to setup. There's something to be said about just getting a job done and going home for the day.

</comment><comment><USER35> This might be attacking the wrong issue. How about making it easier to create packages for major distributions? (this includes Windows and macOS)

<comment><USER36> You mean like `brew` for macOS, or the many other options like it?

It's not the wrong issue, because I believe the main goal here is to raise general awareness that piping to bash with untrusted data is a bad idea and we as developers should frown on it not promote it.

<comment><USER35> Yes, but what alternative are you suggesting for developers who want to distribute software to multiple platforms?

IT security can't just be the ones that come in and say "you've got issues here, here and here" without also providing solutions.

<comment><USER21> Bash scripts aren't magically multi-platform either. If you want something to work right on multiple platforms, you have to understand those platforms' proper distribution and packaging methods. Sure it's a pain, but so is writing the mother of all bash scripts to handle every condition on every platform. You won't get it right, just like all the people who tried to do the exact same thing back in the 80s didn't get it right. That approach failed so consistently and so badly that people created package managers to bring some sanity to the situation. They're still the best solution available, even if they're not perfect.

BTW, it's not _just_ about security. It's also about correctness, consistency, repeatability, reversibility, auditability, etc. As a developer, I still build and install actual packages on my test systems not because there's a security issue but so I can be sure that an uninstall/reinstall will work exactly as they should and not pollute my system with untracked changes. I don't know what kind of developer wants to risk checking in changes that don't match what they tested, but not the kind I want to work with.

</comment></comment></comment></comment><comment><USER37> Aside from the fact that this is a plaintext markdown file, the tone of this page is an immediate turn off.

</comment><comment><USER38>
      And most of all, the people that are part of the project
      are also likely to be malicious because trying to infect
      someone is the only valid reason to recommend this method of
      installation.

This lacks any empathy.

One valid reason: large projects (e.g. rvm) have proven over time to not be malicious. It is far easier for a user to copy and paste one line than any other install method. This lowers the barrier to entry and reduces support requests for the maintainer.

Having an opinion is fine. Disagreeing is fine. Pretending like your answer is the only reasonable one: not likely to win over many people.

</comment><comment><USER39> This is among the many use cases we're hoping to solve with our secure shell scripting language Shill ([http://shill.seas.harvard.edu/](http://shill.seas.harvard.edu/)).

We're currently working on a commercial version of Shill targeting Linux. If Shill sounds like a product your company wishes it could find, we'd love to hear from you. Shoot me an email at firstname.lastname@example.com.

</comment><comment><USER40> Unless you're installing from a package manager with signed packages everything is going to suck by comparison.

What exactly is the alternative the author would suggest? Git checkout? Couldn't you paste-jack that too? If the instructions come from a webpage, aren't they all basically paste-jackable? What is the specific issue with using this method?

</comment><comment><USER41> I've seen so many arguments over this, I wrote a short article on it.

In short, I'd prefer apt-get over curl-bash any day of the week, but most Windows users install loads of software (sometimes signed, never checked) since their OS offers nothing better, and also on Linux you never hear this debate when someone offers a package for download. People worry about what you might be piping to bash because they can see it and notice it could have easily been anything; a deb package (or equivalent) is much more opaque.

More details: [http://lucb1e.com/!126](http://lucb1e.com/!126)

</comment><comment><USER42> How is this different than say, brew install <whatever>?

I'm trusting someone to serve me a piece of code to run either way. Brew, or the people that provide the https cert for the given endpoint, right?

<comment><USER43> When a third party is involved there is a degree of accountability. A proper package repository would require everything to be logged and signed.

<comment><USER42> Well, there's also accountability if I'm installing, say, docker.

Surely they want to make it easy to install their thing without a hitch, and that's why they provide [https://get.docker.com](https://get.docker.com) for me to pipe into bash.

My point is it all boils down in who you trust. If you are downloading something unknown, sure, it's harder to go wrong with a package manager (if the package is available), but you're still trusting someone not to attack you or to leak the private keys.

Crucifying curling into bash has nothing to do with how safe you are. It's almost like saying "Never run anything you download from the internet, it's dangerous!"

</comment></comment></comment><comment><USER44> Many of the comments here are utterly missing the point. Likely, you've been spoiled by the cancerous javascript ecosystem and so don't realize what exactly you're giving up.

1\. An https URL is _not_ secure unless your trust model involves trusting the server completely. Unless you're running this script in an isolated throwaway sandbox, this is a terrible idea.

2\. Obviously auditing can't rule out well-hidden maliciousness or clever bugs, as we're up against the halting problem. But it is quite easy to do a quick sanity check on a downloaded script to see if it is going to do anything wacky or boneheaded.

3\. Explicit packages are expected to have identities like versions and hashes. This allows us to talk about how something has been modified, whether a specific download instance has been tampered with, etc. A rando script has these things from the developer's perspective, but not from the users'.

4\. These "easy install" scripts usually want to puke files into random places on your system. /usr/local, /opt, /home/crap, /who/knows, etc. This is a great way to create an unmanageable system. Standard practice for software outside the package manager is to let the user choose where things should be installed, eg ./configure --prefix=xxx. Lazy people choose /usr/local and can always blow that part of their system away, the more astute use /usr/local/pkg-1.0.0 (for stow), and some even have completely arbitrary paths (I personally use something like /x/local-x64/pkg-1.0.0 which gets synced across machines with unison).

5\. Such scripts usually continue their reign of brokenness by instituting some sort of auto-updating. Now the user has little idea what version they were running (say they want to upgrade to a source install to investigate some bug), is less able to not change versions at an inconvenient time, and is further discouraged from bringing the package under their management.

The sheer majority of these installers provide files that would be fine as plain archives, but the distributors think they're being clever while forgetting about users' general requirements. I do understand that in this age of concentrated Melcalfe's law, it helps to appeal to the lazy people who don't really care if their system becomes an insecure unmaintainable mess. But really, you owe it to your users to provide a proper downloadable package that is installed in a manageable way. (And the same goes for proper versioned source releases, as opposed to telling users to grab a random git checkout).

<comment><USER45> You seem to be arguing install scripts vs package managers, and we are all discussing something else.

<comment><USER44> Sure, but the two generally go together.

The last time I saw a downloadable shar-esque installer was quite some time ago, and I've never seen software which installs a proper distribution's package using curl | sh.

Plain install scripts are still around, but are generally fixed when a package grows up. A large problem with curl | sh (especially which runs further curls) is that it makes a crappy approach masquerade as a polished solution.

</comment></comment></comment><comment><USER46> I do not even dislike curl|sh for security reasons. Package managers go to great lengths to provide a reproducible runtime within them. When was the last time you saw 'curl | env -i sh -C' as instruction?

If the script fails halfway? Good look trying to undo whatever it did if you do not have access to `zfs rollback` or similar.

It is also less-than-fun to go through `zfs diff` and the downloaded script to make a package out of it that can be distributed and automated.

<comment><USER47> Agreed, I think this is the biggest issue. Also you have to trust some random installer to put the binary...somewhere? Is it going to overwrite junk in /usr/local? Does it assume ~/.something is available? Does it require root and then try to stuff code into /etc? Does it work if the install directory has a space in it? What if there's a symlink somewhere in the path?

There's a million things that the script can do stupidly, and practically every single one has at least one assumption that is bad.

One trick I've learned is to edit the script before running it and prefix anything that looks dangerous with "echo" (because of course none of them ever support --dry-run). Then I can at least see what they are doing, what they are downloading, etc.

curl|sh is the bane of my existence. Shame on you if that's your _only_ means of installing.

<comment><USER45> None of this is an inherent problem with curl and piping however; any installer you could download and run has the same list of issues, and many of those aren't even auditable.

You should redirect your anger away from curl and pipe and toward using install scripts vs package managers in general, because that's where your beef really is.

<comment><USER47> I don't know about you but I don't end up running binary installers too much. Certainly not on linux.

Even so, windows style binary installers are at least frameworks designed for installing stuff (many with years of bug fixes under their belt), while the curl|sh style installers are just ad-hoc one-offs written in a language that's known for being pretty hostile to defensive programming.

So yes, any installer _could_ make those errors, but in my experience only random shell installers seem to do that. Saying they are the same is a false equivalency in my eyes.

<comment><USER45> Who said anything about only binary installers? I specifically mentioned install scripts as being different from the subject of the discussion, and you seem to be conflating the two.

<comment><USER47> You said, "many of those aren't even auditable."

The only installers I can think of that aren't auditable are binary installers. If you meant something else, I'm not understanding.

</comment></comment></comment></comment></comment></comment><comment><USER48> I try to read scripts before I download and execute. The only time I thought WTF was this:

[https://bootstrap.pypa.io/get-pip.py](https://bootstrap.pypa.io/get-pip.py)

Even though the author made it clear something funny was about to happen - <USER3> just could not execute.

When I showed it to the guy next to me (at work) - he said he already installed it on another box and didn't even look.

<comment><USER49> Where is the WTF in that script? Just because the author chose a base-85 encoding over base64? (That's a little weird, as I suspect the savings are so minor as to not be worth it …)

<comment><USER48> it could be base3, base64, base84.. that does not matter.

The part that I find interesting is how many people who read the script are going to decode the blob and verify that the blob is non-malicious.

</comment></comment></comment><comment><USER50> I like this approach:

[https://github.com/ellotheth/pipethis](https://github.com/ellotheth/pipethis)

Either check a pgp signature if there is one, or skim the script before executing. Also covers off that pesky dropped connection problem.

curl ¦ sh is too handy to ever die, but it's possible to be smart about it!

Edit: typos

</comment><comment><USER51> > because they are either run by retards or intelligence agencies.

Now would be a good time for the author to expand their vocabulary.

</comment><comment><USER52> curl|sh isn't the least bit less secure than downloading a software distribution and just running it.

</comment><comment><USER10> I'd be tempted to say that `curl | bash` is as insecure as

      ./configure && make && sudo make install

The logic in the article effectively implies that one shouldn't be installing an software without auditing every single line of code.

</comment><comment><USER53> AppFS ( [http://appfs.rkeene.org/](http://appfs.rkeene.org/) ) solves almost all of the problems with "curl | bash" and indeed package managers in general. I'm the author. Feedback desired.

</comment><comment><USER54> (Archived version if it's down: [http://archive.is/Y9z0w](http://archive.is/Y9z0w))

</comment><comment><USER55> Doesn't that popular software that tracks you tell you to install by piping the output of curl. I think it's call Brew Ware.

</comment><comment><USER56> "Download this executable"

"Add this repo and key"

...so on.

</comment><comment><USER57> This stupid hack exists because Linux is so fragmented it's impossible to distribute software easily in any other way.

That and most Linux distributions are significantly harder to deal with both technically and administratively than Apple or Google app stores.

Fix these problems and curl pipe bash will die.

But here we have the usual sort of nonproductive advice you get from security people: shaming with no thought to underlying causes and God forbid we try to improve anything.

</comment><comment><USER58> Also see [https://curlpipesh.tumblr.com/](https://curlpipesh.tumblr.com/)

</comment><comment><USER59> [https://weakdh.org/logjam.html](https://weakdh.org/logjam.html) even uses it as one of the examples. (the site has since been fixed)</comment>


Last Words From Death Row (2015) - <AUTHOR> http://babble.nfshost.com/babblenumber1/ <comment><USER2> Nice to analysis but one should be hesitant to draw conclusions. Word frequency analysis lacks context. Same problem for approaches that separate words into positive and negative categories.

Example:

       I love to kill your family and the people that support my death.
       God is going to come for you and all your friends and I know that even your lord Jesus will not forgive what you have done.
       You will be sorry, you will see.

</comment><comment><USER3> /r/dataisbeautiful has had a lot of fun with this particular dataset: [https://www.reddit.com/r/dataisbeautiful/search?q=last+words...](https://www.reddit.com/r/dataisbeautiful/search?q=last+words&restrict_sr=on&sort=relevance&t=all)

</comment><comment><USER4> The death penalty is barbaric. The only time when a criminal should die is when they immediately threaten another person's life and there is no other safe way to stop them.

That's why I'm so impressed with how Norway handled Breivik after he was arrested.

<comment><USER5> It's interesting that an opinion that is supported by the Universal Declaration of Human Rights, by the EU (which ended up banning companies from exporting supplies for death penalty to the US due to that), and by the International Court of Human Rights, is downvoted on HN.

It goes so far that countries in the ECHR can not extradite citizen to the US if they might face the death penalty, because the death penalty is something that, according to the European Council of Human Rights, no one, not even a criminal, deserves.

<comment><USER6> I didn't downvote, will probably be downvoted, but as someone who is atheist/nihilist/suicidal, I don't understand the great value placed on human life. We slaughter animals, we put down dogs which bite, I see no reason not to put down humans who have malfunctioned. All while being generally left wing. I think suffering should be an active goal, but I don't believe execution is suffering. There's enough effort to focus on progressing those who do buy into constructivism; those who don't wish to participate should exile themselves from society rather than lash out in deconstructivism

This logic likely exists in a watered down form amongst the HN crowd more than Human Rights groups

<comment> aaron-lebo It's weird because life is both overvalued and undervalued.

The same people who believe that the death penalty is barbaric (hey, we all die, that's the hard truth) get fixated more on the tragedy of the criminal on death row than the dozens of people they killed.

I do mean that literally. Monsters like John Wayne Gacy don't need to live any more. They have nothing to offer society but a sneering "kiss my ass" as they are put to death.

<comment><USER7> I think your position is perfectly coherent, but I don't think the opposing view is necessarily _that_ weird, for two reasons.

The first is that this isn't zero-sum; there's no evidence I'm aware of that the death penalty reduces homicide. Killing a murderer isn't going to bring the victims back, anyone even mildly sceptical about the criminal justice system should be against irreversible punishments, and (speaking personally and emotionally for a moment) I think it does something bad to a society when "giving up on one of your citizens completely" becomes an option.

The second is the idea that a lot of the passion surrounding the death penalty is about signalling membership of a political tribe rather than about any of the individuals involved. This is the "I can tolerate anything except the outgroup" theory [1]: tribe A attacks/defends murderer M not because they hate/like M but to emphasis their difference from tribe B.

[1] [http://slatestarcodex.com/2014/09/30/i-can-tolerate- anything...](http://slatestarcodex.com/2014/09/30/i-can-tolerate-anything- except-the-outgroup/)

<comment> aaron-lebo You're right. Didn't mean that suggest that the other side is weird, just that society's back and forth is weird, your second point gets to that. Yet another controversial topic that gets at that friction is people's view on abortion and war. Some people will fervently protect an unborn child but see nothing wrong with carpet bombing fifty others. On the other hand some people are fervently anti-war but see nothing odd about someone having six abortions (slow down maybe?). So much of it does seem like political signaling.

You are right the deterrent argument is dumb and unsupported.

> it does something bad to a society when "giving up on one of your citizens > completely" becomes an option

Human societies have been like this forever, though. Sometimes the protection of the society is more valuable than an individual's life. That stance can be taken too far, but I struggle to see what the point of keeping individuals like Dahmer, Gacy, Bundy around. We can give up on them. We give up quicker on lots of people in society, why not someone who is a mass murderer? They've got nothing to offer and they've given up their rights in taking the rights of and normalcy of hundreds of others.

<comment><USER7> Abortion is actually a different case, I think; that comes down to incompatible axioms. Two people can both believe 100% sincerely that killing people is wrong, but if one of them considers a foetus to be a person and the other doesn't, they aren't going to agree on abortion.

> We can give up on them. We give up quicker on lots of people in society, why > not someone who is a mass murderer?

Yeah, I know. Ultimately I think my unease here is a kind of slippery-slope argument, and deserves to be taken with the same generous pinch of salt as any other slippery-slope argument.

I suspect that much of the opposition to capital (and corporal) punishment has to do with how strong and visceral a mental impression it makes on those witnessing or even thinking about it. Conversely, I'm sure we underestimate the soul-destroying misery of long-term incarceration, because it doesn't offend our sensibilities as much. Same goes for many of the other people we give up on, which goes back to your point.

In any case, thanks for the thoughtful replies. Being able to have a reasonable discussion on an emotive topic with someone holding different views is always a breath of fresh air.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> [2015]

</comment><comment><USER9> > As a society, while our ethical ideal is justice, a more practically > compelling priority is safety. This word, "wouldn't," is not compatible with > our sense of safety

Safety is the ethical ideal, not "justice". We don't punish people because it makes us feel good or for some sense of fairness, we remove people for the good of society.

Edit: I'm Canadian. I know this isn't true today, but I'm glad I said it and am grateful for the replies below. I hope this statement becomes true in America one day.

<comment><USER10> The United States justice system, as well as that of most common wealth countries, is based not on safety or rehabilitation but on vengeance and systemic racism. To claim otherwise, when the United States has institutionalized slavery ("Neither slavery nor involuntary servitude, _except as a punishment for crime whereof the party shall have been duly convicted_ , shall exist within the United States, or any place subject to their jurisdiction.") and more prisoners per capita or by absolute number than any other country on this planet is naive at best. The overcrowding at every prison, chronic corruption and mismanagement, privatization of the system and unionization of its beneficiaries, and lack of all but the cheapest rehabilitation programs makes it nearly impossible for convicts to reenter society and become productive members. Texas is one of the most egregious examples - especially given that they speed up the appeals process on purpose and have shit for oversight on forensic science in criminal cases. Texas alone has executed over 500 people since 1980, many of them borderline too mentally incompetent to stand trial, let alone face death row. Combine that with a culturally accepted racism among law enforcement, itchy trigger fingers, zero training for how to actually deal with people, and a cultural obsession with violence and you get the United States: a place where entire communities of Latinos and African Americans are decimated because a significant fraction of their working age males are stuck in a tiny cell with nothing to learn except more crime and nothing to do when they get out except more crime.

Countries with prison systems that try to rehabilitate, like Norway, Sweden, Denmark, etc., regularly close prisons and they have an amazing track record with recidivism. People like to claim "blah blah homogeneous society blah blah" but the fact is that common wealth countries like to kill and enslave people to punish them - often because they view it as doing "God's work."

We do not have justice systems, we have vengeance factories.

<comment><USER11> I'm very unimpressed with the US justice system and agree with a lot of what you say.

But does this really explain a massively disproportionate homicide rate among certain groups in the US? Sure for lesser or non-crimes like drugs there can be massively unfair, racist enforcement and penalties. For rape, sure, certain groups will get away with it. But for homicide? Are murders being selectively investigated?

As far as Norway and "blah blah homogenous society" do they not also show a heavy bias in crimes committed by the "non homogenous" population there?

<comment><USER12> _" But for homicide? Are murders being selectively investigated?"_

There's a scale from accident, via involuntary manslaugher to murder. There may well be bias in judging what to prosecute.

Also, laws such "three strikes you are out" may lead to more murders. If, say, you're a burglar with two strikes, and a house owner wakes up and recognizes you, hitting him hard out of fear for that third strike becomes more likely. Similarly, racial bias by the police may make people so wary of "he said, she said" situations that they will 'snap' and kill someone instead (IMO, many people convicted for murder aren't cold-blooded killers, but mentally not the most stable persons who have been dealt a socially unfavorable card in life)

<comment><USER11> Very good points, thank you. I wonder if there studies that show what kind of impact this has, overall? Probably hard to measure without finding an area that had a rapid racial change in government.

I guess I was just objecting to the idea that "racism" is the cause for these statistical imbalances, especially since you see the same kind of thing happening in Europe which would seem, at least on the surface, to have less racism issues, no? But perhaps I'm wrong since a lot of good people think the opposite, but it's hard to tell since it's so politicized and sensitive, just like anything about race.

<comment><USER13> It is absolutely _not_ the case that Europe has less problems with racism than the United States. Racism is a very real problem throughout pretty much all of Europe.

<comment><USER11> Interesting. So e.g. Norway has a similar level of racism towards blacks as the US does? Why?

<comment><USER13> Non sequitur. Your analyses across this thread are all very weak, based on weirdly fallacious premises; here, that "racism" means "racism against black people".

A reasonable reader might suspect that you reached, for whatever reason, the conclusion that capital punishment couldn't be racist (perhaps because, as you've stated in other comments on HN, you feel the term "racism" is used too often), and are now intent on working your way backwards from that conclusion.

I think you should take a beat and reconsider how you're approaching the topic. It's an odd experience discussing this with you and watching you do little dances after each response to reorient yourself towards your preferred conclusion.

 _Edited extensively from the one-liner I originally wrote, sorry._

<comment><USER11> Fair enough, though I'm not talking about capital punishment or lack of racism in the US justice system. It's terribly unfair, especially to blacks in the US - zero argument there.

Do you have any suggestions on straight, fact-based reading on the subject, sources that aren't trying to appear sensitive? It's hard - even admitting races and may have differences upsets people.

On Norway, I'm just saying they don't have the same levels of racism baggage as the US regarding "Africans" (quotes cause it seems weird that many of them have families in the US longer than mine, but I would get no qualifiers as an American) yet still Norway sees overrepresentation.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


TSMC Boosts CapEx by $1B, Expects N5 Node to Be Major Success - <AUTHOR> https://www.anandtech.com/show/15420/tsmc-boosts-capex-by-1-billion-expects-5n-node-to-be-major-success <comment><USER2> This is even more good news for AMD as well since it points to a clear path to 5nm in its chips well ahead of anything Intel has demonstrated.

<comment><USER3> This really good for AMD because they are soaking up a bunch of Apple's old 7nm capacity for a bunch of upcoming products (Xbox, PS5 being the major ones). Apple seems to be going all in on 5nm. Plus, I bet the next Epyc will be on 5nm too.

[https://www.macrumors.com/2020/01/02/tsmc-a14-iphone-chip- pr...](https://www.macrumors.com/2020/01/02/tsmc-a14-iphone-chip-production- second-quarter/)

<comment><USER4> 1\. Qualcomm, Broadcom, Nvidia, and nearly 70 others have 7nm designs waiting in queue. It is not like all the 7nm Capacity immediately goes to AMD.

2\. Next Epyc ( Zen 3 ) is 7nm+, not 5nm Yet. That would be Zen 4.

3\. From the latest AMD quarterly results it was clear it wasn't capacity that were holding them back. They have just been far too conservative with their forecasting.

</comment></comment></comment><comment><USER5> I find it strange, that in this strictly B2B market, where target audience is just dozen hundreds/thousands chip design engineers, they still use BS marketing. There is no physical dimension of 5nm anywhere, neither there were for "7nm" or "10nm" processes.

<comment><USER4> >I find it strange, that in this strictly B2B market...

Except it is not, It is very much consumer marketing. Look at how _all_ their Chip Vendors proudly market themselves as 7nm, or first to EUV.

Samsung Foundry started this whole thing, and TSMC CEO said during an investor conference their customers were asking for smaller nm because "another" foundry were using those numbers.

At the end of the day, all we have to know is that each full node has roughly 2x density improvement over previous node. And we still have 5nm, 3nm, 2nm, 1.4nm and 1nm coming up. Someday Moore's Law will indeed be dead, but for now at least we have another 5 - 6 years to go. I am happy I will get even more powerful GPU down the line.

<comment><USER6> _Samsung Foundry started this whole thing, and TSMC CEO said during an investor conference their customers were asking for smaller nm because "another" foundry were using those numbers._

That's not consumer marketing. That's still B2B, except the audience is management instead of engineering as assumed in the GP. TSMC's customers are not consumers. Set up costs run into the millions of dollars.

After the whole gigahertz wars, there aren't many consumers that are savvy enough to know that you want _fewer_ nanometers.

edit: quote for clarity

<comment><USER4> >That's not consumer marketing. That's still B2B........

Apple announced they were first to ship 7nm Chip in iPhone during an Apple event watched live by more than 50 millions people.

Huawei Announced their Soc being the first shipping EUV chip, most advanced SoC ....

Qualcomm announced their 5G Modem on latest 7nm to give industry leading performance......

None of these are B2B, they are directed to consumer, and these Vendors pushed TSMC for those numbers. TSMC delivered.

<comment><USER7> Nvidia and AMD are also hyping 7nm process to the enthusiast market where it'll propagate onwards.

</comment></comment></comment></comment></comment><comment><USER8> The cut-over into sub-micron process was a real trip, but sub-nanometer is going to be wild.</comment>


Ask HN: What's the best Master's degree in  security and cryptography? - <AUTHOR> My background is computer engineering. Anything with the word 'IT' is out. I want to learn about low-level OS internals/kernel hacking, embedded security, and cryptographic protocols/algorithms, their hardware implementations, etc.. <comment><USER2> There's a course offered by CMU in Computer Security. You might wanna check that.</comment>


Define rich: you are rich when ... - <AUTHOR>

I'm often confused about the meaning of the word rich. What does it mean to be rich? Does it depend on other values than money? When are you officially rich? Can you be rich but not wealthy, or can you be wealthy but not rich? Are they the same? <comment><USER2> Richness is relative. If you make $25k a year in NYC, you are not rich. If you make $25k a year in Zimbabwe, you are quite rich.

Richness is sustainable. If you make $10k a day, you are rich regardless where you live. If you make $10k in one day and nothing the rest of the year, you aren't rich, even on that one day.

Richness is based on what you can afford, not what you choose to have. If you have $500 million of assets and you drive a Ford and do all your shopping at Walmart, you're still rich.

In summary, you are rich when you can sustain a lifestyle requiring significantly more money than an average resident of your area.

"Significantly" and "area" are flexible and somewhat subjective.

</comment><comment><USER3> Well, to take one question, someone who has a trust fund which will steadily pay out enough money for middle class class lifestyle for the rest of their life is probably "wealthy" but not rich (unless of course they set aside enough and wisely invest from that regular payout, or otherwise go beyond the obvious scenario).

</comment><comment><USER4> The definitions used by wealth advisors:

<http://en.wikipedia.org/wiki/High_net_worth_individual></comment>


Why monads have not taken the Common Lisp world by storm - <AUTHOR> http://marijn.haverbeke.nl/monad.html <comment><USER2> Another reason monads are cumbersome in other languages is that other languages use lazy evaluation. If you consider the naively implemented function

        skipMany :: Parser a -> Parser ()
        skipMany p = (p >> skipMany p) <|> return ()

and then consider how you might write it in some other language, you'll note that the translation, strictly evaluated, gives infinite recursion. To practically work with monadic computation requires some form of non-strict evaluation. Another, less catastrophic example would be the following.

        printNTimes :: Int -> String -> IO ()
        printNTimes 0 s = return ()
        printNTimes n s = putStrLn s >> printNTimes (n - 1) s

Strictly evaluated, that would build up Theta(n) memory usage.

For this reason, the more computation-oriented monads cannot be used practically in other languages without added weight to avoid strict evaluation.

Ironically, it's the non-monadic uses that cause the problems -- those that don't need the full power of 'bind', i.e. uses where the monad's user doesn't pass return values from previous actions to future actions. When you pass a return value, you end up needing a lambda expression, which cuts off strict evaluation. When you only use them in ways that applicative functors can be used (which often applies for parsers), that's when you suffer. It's not the end of the world; there certainly are workarounds, but that requires adding explicit promises everywhere, which is just a pain.

<comment><USER3> The first example, naively translated to scheme, results in:

        (define (skip-many a)
          (or (and (a) (skip-many a))
              (void)))

This is not infinite recursion. The Parser monad used in the Haskell version is simply a stream dressed in monadic clothes (and even C has streams a-la FILE*).

As for the second example, the naive translation to scheme is:

        (define (print-n-times n s)
          (cond
            ((zero? n) (void))
            (else (put-str-ln s)
                  (print-n-times (sub1 n) s))))

Here, both Haskell & scheme demonstrate constant memory usage; not because of Monads, or strict/lazy evaluation, but because of tail recursion.

Also, in your first sentence, I think you meant "strict".

<comment><USER2> Neither of your translations convert your code to anything that has to do with _monads_ , and your first translation is just plain broken.

Your print-n-times doesn't return an action---it's an imperative function that performs an action.

The naive translations to Scheme would be as follows:

        (define (skip-many p)
          (<|> (>> p (skip-many p))
               (return 'nothing)))

        (define (print-n-times n s)
          (if (= 0 n)
              (return 'nothing)
              (>> (put-str-ln s)
                  (print-n-times (- n 1) s))))

In order to fix the infinite recursion in my first example, the parsing framework I made in Scheme had a macro `thunk-parser` (actually, it had a shorter, stupid-sounding name) which for all intents and purposes just wraps the expression in a (lambda ()).

        (define (skip-many p)
          (<|> (>> p (thunk-parser (skip-many p)))
               (return 'nothing)))

Also, both your examples rely heavily on non-strict evaluation. 'and' and 'or' are both macros that non-strictly evaluate expressions.

<comment><USER3> Agreed; neither of the translations use monads, because monads are a semantic hand-job proscribing order within a declarative language. However, Scheme is not a declarative language, therefore order is implied in the structure, therefore monads aren't necessary.

>> Your print-n-times doesn't return an action...

Nope, look again. It returns the results of applying `void'. Who knows what (void) may return in a loosely-typed language?

>> ...it's an imperative function that performs an action.

Well, considering Scheme is an imperative language with side-effects, it's hard to dodge such criticism.

>> The naive translations to Scheme would be as follows...

That's not a translation from Haskell to Scheme, that's writing Haskell using a prefix syntax.

>> Also, both your examples rely heavily on non-strict evaluation. 'and' and 'or' are both macros that non-strictly evaluate expressions.

I went back and re-read your original post:

>> ...you'll note that the translation, strictly evaluated, gives infinite recursion.

Mea culpa--I completely missed your point that translating from a turing complete language to a non-turing complete language might have some pitfalls.

<comment><USER2> Then maybe I'm misunderstanding the point of your reply. I was pointing out how monads are inconvenient to use in strictly evaluated languages. Why did you follow up with an example about how not using monads is convenient?

<comment><USER3> >> Then maybe I'm misunderstanding the point of your reply.

I was pointing out that your examples don't make sense, as it's trivial to translate the Haskell code into another general purpose language (such as Scheme, C, Perl, Fortran, etc), while impossible to translate into an eager (strictly evaluated) language (such as...?).

Additionally, the reason monads are cumbersome in other languages has nothing to do with eager/lazy evaluation, or conditional computation, and everything to do with the fact that monads exist in Haskell to solve it's sequencing problem (arising from the fact that it's a declarative language). Imperative languages have no problem with sequencing, and therefore have no need for monads.

</comment></comment></comment></comment></comment></comment><comment><USER4> I liked the article, but it was very much "in the weeds".

I hack Scheme, and have never written any Haskell, though you have to know some to read the papers. But when programming in Scheme I find myself wanting monadic operations, like the seed in Oleg's SSAX parsers. But my code that rhymes with monads _requires_ tail recursion, and the author didn't mention tail recursion at all.

I prefer to see monads as fold + tail recursion -- and without the latter, it seems you need the mutation that Common Lisp encourages.

<comment><USER5> "I prefer to see monads as fold + tail recursion"

I don't think this is accurate, monads are orthogonal to both folding and tail recursion. Monads are types representing computation, and providing the operations `bind' and `return'. They're much simpler than many imagine at first.

"... and without the latter, it seems you need the mutation that Common Lisp encourages."

I agree that when using looping constructs other than recursion, it is often required that a counter or accumulator be mutated. Common Lisp does not encourage _general_ mutation, however, and the standard functions and macros illustrate that.

<comment><USER6> > the standard functions and macros illustrate that

You do know that nearly all of the standard list functions destroy at least one of their arguments, right?

People like to call Lisp a functional language, and you can use it that way, but it is really just a very nice imperative language.

Statements like:

       (loop for x in some-list sum (* 2 x))

are just more efficient in CL than the "functional" approach:

       (reduce #'+ (mapcar (lambda (x) (* 2 x)) some-list)

In this case, the LOOP is about 10x faster than the reduce, probably because it conses about 5000 times less memory. CL is not set up the same way Haskell is, and hence you want to reuse data structures (or never create them) where possible. This is very imperative and very non-functional. (But I am not saying it's bad, LOOP (or ITERATE, which is what I use "in real life") is very easy to read and write.)

<comment><USER7> I have a feeling you don't have much CL experience...

There really aren't very many CL destructive (mutating) list functions, and I personally almost never use them except on fresh lists (like for example when I nreverse a list I just created with successive pushes) and I'm pretty sure it's standard practice.

Let's see what destructive list functions I can find in CL (ref: [http://www.lispworks.com/documentation/HyperSpec/Body/c_cons...](http://www.lispworks.com/documentation/HyperSpec/Body/c_conses.htm))

      rplaca, rplacd, nsublis, nsubst*, nconc, nreconc, nbutlast, mapcan, mapcon, nintersection, nset-difference, nset-exclusive-or

I took some liberties but that's about 12/58 = 20% destructive functions (push, pop, pushnew are usually used on variables, not list structure). And good style dictates to use them very sparsely... Also, (loop for x in some- list sum (* 2 x)) is pretty functional, you're just mutating x locally but who cares, this is exactly like saying (apply #'+ (mapcar (lambda (x) (* 2 x)))) which is obviously functional.

<comment><USER6> Point conceded. The post I replied to says "CL discourages mutation" which is not true. I said "nearly all sequence functions are destructive", which is also not true.

Upon further reflection, I think we can say CL doesn't really care if you mutate or not. There's more than one way to do it :)

<comment><USER7> CL _does_ discourage mutation... With all the structure sharing going on in CL programs you can't afford mutating things thoughtlessly.

<comment><USER6> But OTOH, if you are careful about mutating when possible, your program will run faster. Not the most important thing in the world, I agree, but it is a "reward" for mutating things.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Not knowing a lick of Haskell, these sorts of articles always make me wonder whether it makes Lisp look like Blub.

<comment><USER6> It depends on how important you find purity and strict typing. They are both useful, but the mistakes that experienced programmers make are not usually related to types. Having recently started writing "real" software with Haskell, I've noticed that the type system doesn't save me a lot of time. I still have to debug stupid errors, like calling a function with the right type signature but with the wrong effect. By the time I've debugged and written tests, I haven't gained a _whole lot_ over Lisp or Perl. The advantage of Haskell is that it's as expressive as either of those, but executes _a lot_ faster. (One concurrent app we ported was very quick to use 100% CPU on Perl with just a few outstanding operations. In Haskell, it gets to 10% CPU and runs out of file descriptors. Wow!)

As for monadic computation in Haskell, it is very comfortable. You can create an environment where you only have exactly what you need, which makes your program easier to read and reason about. (No "IO a" signature? This function doesn't do IO.) It is not something I can't live without in other languages, but it does solve the intended problem very cleanly. (Similar abstractions like monoids and functors are also nice ways of looking at their respective problems.)

The author of this article is right, though -- in a language with mutable state and without type inference (for return), monads are just not worth the bother. They won't give you anything you don't already have.

<comment><AUTHOR> _I still have to debug stupid errors, like calling a function with the right type signature but with the wrong effect_

I wonder if a way of writing tests which is significantly easier (taking one or two magnitudes less time) would help here?

Say for example, something like Python's doctests which run inside your IDE... it seems my standard way of development anyway - to write a piece of code, test it in the REPL, repeat.

<comment><USER6> Haskell's quickcheck is really nice for this case.

</comment></comment></comment></comment><comment><USER9> Has _anything_ taken the Common Lisp world by storm in the past decade?

<comment><USER10> SLIME, perhaps.

</comment></comment><comment><USER11> One of the problem using monads in dynamically typed languages is, as this article suggests, the need to overload 'return' operation by the type of results, not by the type of arguments. I once tried to address this issue.

[http://practical- scheme.net/wiliki/wiliki.cgi?Scheme%3aExpli...](http://practical- scheme.net/wiliki/wiliki.cgi?Scheme%3aExplicitMonad%3aEnglish)</comment>


Where do interrupts happen? - <AUTHOR> https://travisdowns.github.io/blog/2019/08/20/interrupts.html <comment><USER2> This is fantastic for reminding us of how the "programmer's model" of a CPU differs from what's actually happening, which can be considerably more complicated. We humans basically cannot handle anything other than an in-order model where the processor fixes everything up to maintain that appearance.

It seems like you could also model this mentally (although I'm not sure you could instrument it) as: "On receiving an interrupt, do not give any more instructions to the execution units; wait for execution to drain, then transfer control flow to the interrupt handler, and mark the instruction after the last drained instruction as the interrupt return point."

<comment><USER3> Well one of the key points is that interrupts (apparently) do not drain currently executing instructions: almost all outstanding isntructions are thrown away, including already executed but unretired instructions. Only the next to retire instruction is apparently allowed to complete (possibly because interrupts are only checked every time an instruction retires).

</comment></comment><comment><USER4> Thanks for writing this, BeeOnRope!

I'm not all the way though it yet, but I'm having trouble understanding the "eligible" column. There are a few nops with a nonzero entries, and I haven't been able to figure out the pattern yet. I'd appreciate a clarification if you have a moment to spare.

<comment><USER3> Sure. Here's the section from the post for context:

<quote>

Here, the eligible column indicates when the instruction is eligible for retirement in the sense that it has finished executing. nop instructions have no dependencies hence basically execute instantly (in fact, no not execute at all) and hence are eligible on cycle 0. The other instructions come eligible as defined by their position in the mov -> add -> ... dependency chain. The actual column shows when the instruction actually retires. You can build it by basically scanning down the eligible column and retiring up to 4 uops if their eligible cycle is less than or equal to the current cycle.

</quote>

Basically instructions [1] need to execute before they can retire. Instructions execute out-of-order when their inputs become ready and when some other constraints are met (e.g., their execution port is available). This post [2] is a good introduction.

So here "eligible" is the cycle at which an instruction would be expected to complete execution (starting arbitrarily at cycle 0), if you have a chain of mov instructions they will be eligible at 0, 4, 8, 12, ... since this chain has latency 4. If you have a bunch of independent instructions with throughput 4/cycle, they would be become eligible at 0,0,0,0,1,1,1,1,2,2,2,2 since 4 can start every cycle and they take 1 cycle each.

"Eligible" is relevant here because it defines when the instruction can retire. Unlike execution, retirement happens in order, so you can imagine the retirement unit maintaining a pointer to the oldest (i.e., "higher up" in source order) instruction, and asking "is it eligible yet?" every cycle. If yes, that instruction will be retired _in addition to up to the 3 subsequent in-order instructions if they were also eligible_.

So from eligible cycle analysis we can reconstruct the retirement pattern (sometimes more than one pattern is possible, I didn't touch on this yet in this post).

Let me know if it makes some sense?

\---

[1] Actually uops are what execute, but they are equivalent for this example.

[2] [https://fgiesen.wordpress.com/2018/03/05/a-whirlwind- introdu...](https://fgiesen.wordpress.com/2018/03/05/a-whirlwind-introduction- to-dataflow-graphs/)

<comment><USER4> Thanks.

Sorry if I'm being thick, but I'm still having trouble seeing where the pattern for nops is coming from, in this example from the post:

                           /- eligible
                           |  /- actual
        mov  rax, [rax]  ; 0  0
        nop              ; 0  0
        nop              ; 0  0
        add  rax, 0      ; 1  1
        nop              ; 0  1
        nop              ; 1  1  <</comment></comment></comment><comment> ?
        nop              ; 0  1
        mov  rax, [rax]  ; 6  6

I would think that the fourth nop is eligible only at cycle 1 because only four uops can start each cycle, but then the fifth nop is also eligible at cycle 4. What's different about the fourth nop from the third and fifth?

<comment><USER3> You are not being thick. It was a typo on my part, I intended for all the nops to have 0 for their eligible column.

As you point out, putting them all at 0 isn't even really accurate because only 4 can allocate (rename) a cycle, so the true eligible pattern should be 0-0-0-0-1-1-1-1-2-2-2-2 or something like that (it's more complicated than than because the mov/add also needs to allocate, so it's rp). I'm basically ignoring that assuming the front-end (including allocation) can keep up, or basically that the scheduler is infinitely large and always totally full.

I am going to fix this to be more accurate but I'll have to unroll the loop a bit more for the difference between retire and eligible to make sense.

BTW, this is just a few simple version of what llvm-mca -timeline view does:

[https://godbolt.org/z/ZrGXrH](https://godbolt.org/z/ZrGXrH)

Timeline view simulates a simple CPU pipeline, and with -dispatch=4 -mcpu=Skylake it's pretty close to Skylake. Unfortunately, llcm-mca models "unlimited retire bandwidth" so if 100 instructions all become eligible in the same cycle, it will retire all 100. So it's not too helpful here in any cases where it would retire more than 4 per cycle (but it works for this example because that doesn't happen due to the dep chains).

I didn't find any argument you can pass to limit retire bandwidth. In practice this is not a problem for most performance-oriented investigation because the retire limit isn't really a bottleneck, so reported performance from the tool is likely to be the same even though it simulates unlimited bandwidth.

<comment><USER3> I fixed the typo, but also tried to improve the way cycles are accounted, adding two columns in support of that. If you have a moment can you check out:

[https://travisdowns.github.io/blog/2019/08/20/interrupts.htm...](https://travisdowns.github.io/blog/2019/08/20/interrupts.html#lookhere)

and see if makes sense to you? I'll upgrade the other examples to that format if it does.

I've added you to the Thanks section at the bottom.

<comment><USER4> Yeah, that makes a lot of sense, thanks.

Thanks again for writing these articles, I very much appreciate them.

</comment></comment></comment></comment><comment><USER5> As a degenerate case, can anyone design a simple 'meta machine' or constraint- set in the instructions which imposes specific costs on the interrupt decision logic? Can one code to this? Is this useful or just entertaining?

It might (for instance) be analogous to designing solutions which fit in L1 cache, for the outcome in time to execute.

Or it might affect the side channel consequences of some forms of crypto.

(or am I missing the obvious "this is in fact, how it works" answer. I am sure I recall in simpler times reading that writing interrupt _handlers_ demanded some consideration of what was fixed or mutable in the throw)

<comment><USER6> I'm not sure that this addresses your question directly, but the x86 MMU is turing complete.

[http://beza1e1.tuxen.de/articles/accidentally_turing_complet...](http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html)

<comment><USER5> its turtles all the way down.

</comment></comment></comment><comment><USER7> One thing I have noticed with statistical profilers is that conditional jumps tend to be highlighted a lot.

On the other hand, if I can massage the compiler into using CMOV instead of e.g. JNE, I often end up with much faster code, so the clustering around that instruction ends up being useful sometimes anyways.

<comment><USER8> Out of curiosity, how have you managed to do that? I've noticed even with GCC or Clang's -O3 option I'm still getting jumps rather than conditional moves.

<comment><USER9> Clang\LLVM has some heuristics where it will convert cmovs generated by earlier passes back in to jumps [https://reviews.llvm.org/D34769](https://reviews.llvm.org/D34769). Also the compilers can't always prove its safe to evaluate both sides of a ternary operator which would be needed to use a cmov. Here's a compiler explorer sample for clang and GCC that shows all these problems [https://godbolt.org/z/IpZfZv](https://godbolt.org/z/IpZfZv), you change the -x86-cmov-converter option to true re-enable clangs cmov converter which will disable cmov in the last function.

<comment><USER3> Yeah I have spent a long time fighting to get cmov into code that wants it.

The cmov1 case in your example ends up getting a cmov1 because the compiler was able to apply the cmov to the pointer rather than to the read value (essentially transforming it to `return (cond ? v1 : v2)->i`).

It's fragile though, if you change it a bit it stops working:

[https://godbolt.org/z/hs71Jb](https://godbolt.org/z/hs71Jb)

It isn't clear if it stops because the heuristics aren't in favor any more (you'd need 2 cmov-y things to handle the +1), or because the compiler no longer sees the transformation is possible at all.

gcc even fails if you add +1 to _both_ sides which should be almost as simple as the original:

[https://godbolt.org/z/y7PIcU](https://godbolt.org/z/y7PIcU)

I have tried to use the "unconditionally deference" trick many times to convince a cmov, but it seems it doesn't always work because the compiler might re-optimize it back to only doing the read inside the branch/conditional, so later phases don't see the read as safe.</comment></comment></comment></comment>


Math Inspector: Alpha Test Registration Is Open - <AUTHOR> https://mathinspector.com/ <comment><AUTHOR> Project author here! I have been working on Math Inspector for the past year and recently got featured on Mathologer for one of my youtube comments so I decided to launch the math education channel I have been dreaming about and start the process of releasing the tool I got carried away making when I decided to roll my own software for creating animations for math eduction videos</comment>


Grieving Orca Carries Dead Calf for More Than 3 Days: 'She's Just Not Letting Go - <AUTHOR> https://www.nytimes.com/2018/07/27/science/grieving-orca-dead-calf.html <comment><USER2> this is terrrible. no births in this population, and i think they have had at least two deaths in the existing population this past year. in may of this year, the southern residents were not seen by researchers, at all, which is unheard of. they are really spread out trying to find salmon. that specific population has been heading towards exinction for some time now. :(

this is all due to the horrific captures that happened in the late mid-century for captivity, the ecosystem damage, dammed rivers blocking salmon from reproducing, salmon farms, toxicity levels in the prey ladder, and more, all due to selfish human behavior. we are more concerned with bleeding as much money from "ai" and going to visit a dead rock than we are with protecting the most vital source of life on our planet (the ocean), the likely origin of life, and one of the shining examples of intelligence in the animal kingdom.

orcas are truly an amazing species. they are far more intelligent than generally recognized, even surpassing primates (including us) in certain areas. and they are damn emotional. it is really a travesty how humans interact with other intelligence on the planet.

[https://msu.edu/~marablek/whal- int.htm#sect7-1](https://msu.edu/~marablek/whal-int.htm#sect7-1)

[https://pugetsoundblogs.com/waterways/2018/06/29/two- deaths-...](https://pugetsoundblogs.com/waterways/2018/06/29/two-deaths-no- births-for-southern-resident-orcas-over-the-past-year/)

[https://www.seattletimes.com/seattle-news/southern- resident-...](https://www.seattletimes.com/seattle-news/southern-resident- killer-whales-inbreeding-may-devastate-the-population/)

</comment><comment><USER3> This is heartbreaking, there's not much more to say about that situation. Poor Orca.

On a sidenote, for those who got paywalled like me: [https://outline.com/7fPjUN](https://outline.com/7fPjUN)</comment>


Ask HN: What's a fair policy for employee-generated IP? - <AUTHOR> My cofounder and I have long agreed that most big company IP agreements suck (we've written about it at http://devver.net/blog/2008/08/looking-for-your-first-cs-job-be-sure-to-own-your-ideas/). Many of them state that employee IP, no matter when it's created, is owned by the company (whether or not that's enforceable is another state-specific question).
Now we're hiring (http://devver.net/jobs) and are trying to figure out a reasonable agreement for the IP employees generate in their free time.
On the one hand, we want to encourage our employees to work on what they want outside of work. They'll be happier, they'll increase their breadth of knowledge, and we want to support open source.
On the other hand, we do want to make sure we own the IP that directly relates our business (no matter when it's created). And since we want to hire full-time employees who are free to work from home, there won't always be a clear distinction between "company time" and "personal time."
Have any of you founders come up with an agreement that both encourages outside work yet protects your company adequately (and doesn't completely freak out investors)? I'd love to what different companies are doing in this regard. <comment><USER2> In the past I've requested explicit opt-in and out.

Usually there is a blanket IP clause, but if I say "I'm going to work on ABC in my spare time" - and we all agree this isn't core the business - then it's added as a schedule exclusion.

You need to be specific, but it works just fine if all the parties are operating in good faith (which you'd hope with a good employee relationship).

</comment><comment><USER3> My current agreement requires that I explicitly seek company exclusion for any ip I work on at home. The key to this sort of implementation is that it is ridiculously simple. I write up a sentence or a paragraph or so, I bring it to the CTO (it is a small company so he is a desk away) and he signs it.

The easy way to think of it is sort of a right of first refusal, with the company being extremely likely to refuse anything. Basically I am going to him and saying "hey can I spend my work time on this?" and he says "no we don't want any part of that" and then it's all official and documented with signatures and good stuff like that.

I bristle at IP contracts, but the simple fact of the matter is that as an employee (especially of a somewhat mature funded company, bootstrappers may have a little bit more flexibility) I know that I'm going to be subject to them. Being up front about it and making it possible and simple to exclude my IP from the company's means that every few months I bring a list of fairly early-stage ideas to get signed off.

The other option is just to start with a "Hey, your IP is your IP and our IP is our IP." policy and wait until you're actually screwed over to change. There's value in protecting yourself, but building a giant wall around you for a problem that may never occur can also be extremely restrictive.

</comment><comment><USER4> "(and doesn't complete freak out investors [and their lawyers doing due diligence])" is the key here.

I totally get where you're coming from in trying to be reasonable with your new hires. Unfortunately, everything-you-do-belongs-to-us is pretty much the standard for IP ownership in employment contracts. Whether you enforce it is a different matter, and this is where your "goodwill" towards your employees will come into play.

jwilliams is correct though, if a guy comes to you with a specific project that he's working on, perhaps you can have a specific carveout -- but even that's a little awkward (may be hard to define the scope of that side project).

At the end of the day, as a company you'll want to be making the call of whether IP created by an employee should be considered company property, and not the other way around. So it might be wise to be a little selfish up front and have a blanket clause.

Just my two cents.

</comment><comment><USER5> What is a fair price for permanently giving up a piece of the only brain you're ever going to have in your career in exchange for a job from which you can be laid off at a moment's notice without, it must be noted, getting back that piece of your brain you had to sign away?

If I were (which I am not) gullible enough to buy into the kind of rules that applies the same logic to ideas as fixed property [1] I would certainly start the conversation by asking what kind of rental you think you can afford!

[1] ...and then everyone acts surprised when both the market for ideas and fixed property suffers!

</comment><comment><USER6> California law has a pretty good balance. If it's related to the job, it's the company's. If you use the company's resources (hardware, software, customer list, employees, ideas) it's the company's. Otherwise, if it is on your own time, with your own resources, and unrelated to your job, then it's yours.</comment>


Microsoft Introducing the UWP Community Toolkit - <AUTHOR> https://blogs.windows.com/buildingapps/2016/08/17/introducing-the-uwp-community-toolkit/ <comment><AUTHOR> its amazing how much Microsoft is trying to push UWP development and yet no one seems to want to make any apps for it. I'd love it if there was a similar toolkit for Android.

<comment><USER2> My guess is it will be a long hard road until they realize that UWP apps will be behind until it is easy to port them to other platforms.

Right now all you get with UWP is support for a popular but declining desktop platform, a limited living room gaming platform and a practically dead mobile platform.</comment></comment>


Snowden's Chinese Fans - <AUTHOR> http://www.newyorker.com/online/blogs/evanosnos/2013/06/snowdens-chinese-fans.html

<comment><USER2> "We hack network backbones—like huge Internet routers, basically—that give us access to the communications of hundreds of thousands of computers without having to hack every single one"

</comment><comment><USER3> And there it is:

"...and nominated him for the next Nobel Peace Prize."</comment>


The Next Tesla Roadster Can Fly – Elon Musk - <AUTHOR> https://twitter.com/elonmusk/status/1083095876392964096 <comment><USER2> I think it's safe to say Elon has officially lost his mind. It's sad, but it happens frequently to people with too much money.

No one person can fix electric cars, solar power, underground urban transportation, and sending people into space. No one. The flying Tesla is only slightly more kooky than the one-at-a-time Tesla going through his tunnels. Britain had electric underground railways in the 1800's. I fail to see how Elon's tunnel invention is improving on that.

People can't go to Mars because of the Van Allen belts. But Elon wants us to get excited about 50's-style stainless steel rockets. Come on.

</comment><comment><USER3> He replied that it's just some high pressure air cylinders and thrusters. Same composite overwrap tank technology that are in a Falcon 9 helium tanks.

You could probably add water to make the thrust higher, to make a bottle rocket...</comment>