Becoming a Steelworker Liberated Her, Then Her Job Moved to Mexico - <AUTHOR> https://www.nytimes.com/2017/10/14/us/union-jobs-mexico-rexnord.html <comment><USER2> _At a factory where black and white workers bowled together on Tuesday nights, where at least two romances crossed racial lines, a subtle divide emerged: Many white men like John refused to train and shunned those who did; many black men like Mark openly volunteered.

The white workers who did agree to train tended to do so quietly, and kept it a secret as long as they could, said Jim Swain, Shannon's supervisor.

Some white men complained that they'd watched their economic prospects decline for decades. They had shared their jobs with black men, then with women. Now that blacks and women were welcomed in every facet of factory life, the jobs were moving to Mexico. It seemed like proof that their best days were behind them._

This has to be one of the most concise, insightful summaries of the roots of things like racism and sexism that I have ever seen. And it is surprisingly evenhanded and sympathetic to the white men that are so often maligned.

I don't know how we solve this. But, I think you have to start with having compassion for the fact that many "overprivileged assholes" are scared of losing the security they have worked so hard for, that they thought would be relatively permanent if they did the right things.

How do we create a society in which all people can expect some baseline security instead of squabbling over who to leave out? This is perhaps a strange question to ask in a discussion about a factory closing in the US and moving to Mexico. Or perhaps not.

I especially appreciated the part of the article that elucidated that the Mexicans had not realized they were taking the jobs of the Americans who were training them. The ending is perhaps supposed to be a downer. The headline certainly is. But the last paragraphs indicate her daughter got scholarship money and many of the workers went on to get other jobs.

That isn't to downplay what a big problem this is for Shannon, nor to dismiss the very real issue the plant closure represents across the US.

<comment><USER3> The problem is that even if you provide security, people are unhappy with living on the cost of others. People need to feel useful, having a job is about more then just getting a roof and food.

<comment><USER4> >People need to feel useful, having a job is about more then just getting a roof and food.

Unfortunately for people, having a job is not even about that.

Jobs are for you, an employee, to provide value to a company in exchange for whatever the market determines your labor is worth. Not to provide you with a sense of satisfaction, or dignity, or even enough money to afford a roof and food.

If your job can provide you with those things, then you're lucky. But as the global economy moves beyond the need to sustain itself on human labor, it makes less and less sense to expect employment to fulfill societal needs, or even basic human needs.

</comment></comment></comment><comment><USER5> The American Dream has been for many years to own a nice piece of property and work your way up the corporate chain at a single company until you die. Both of which have been radically shifting as technology improves productivity and global competition becomes more of a major factor. We see people stuck in this mindset that a job will last you forever (and in many cases there are still towns where there is only One Company and One Job) and as a result have been put in a lose-lose situation.

Meanwhile, other nations have a more flexible workforce that are cheaper to pay for roughly the same productivity in many cases.

Unfortunately there is no easy solution for this problem. For the people located in areas where jobs have entirely vanished you would have to relocate the population but that goes against the dream. You could cut regulations in order to entice companies to come back, but then you're selling the lives and well-being of the American people for jobs that Americans might not even do (see: labor shortages in the farm industries).

America will need to find a way to handle this and fast as automated cars enter the market and cut another huge swathe out of the market. The difference there though is that you can't blame other races or countries for taking your jobs.

<comment><USER6> > For the people located in areas where jobs have entirely vanished you would > have to relocate the population but that goes against the dream.

Relocate them where? American's are incredibly mobile in my experience, from going to college in another state, to having families sprawled across different states. If it were as simple as moving, people would be doing it.

> You could cut regulations in order to entice companies to come back...

Times have changed and we need to adjust to it. USA Inc makes a huge amount of money. In the past that required a lot of people in the workforce. Today it doesn't require nearly as many but we're making even more money! So the solution is not to remove regulation to have more people taken advantage of in dangerous factories and so we can pollute our environment. That does not benefit the Americans who live here who do not have jobs.

We need to come to an acceptance of the changing times and decide what it means to still have a society. Either we agree that we (USA Inc) make more than enough money for everyone in the country to have a good life (which we do), and work out the redistribution problem (which could take many forms), or we continue as we are with a whole lot of fellow citizens suffering needlessly.

<comment><USER7> "We need to come to an acceptance of the changing times and decide what it means to still have a society. Either we agree that we (USA Inc) make more than enough money for everyone in the country to have a good life (which we do), and work out the redistribution problem (which could take many forms), or we continue as we are with a whole lot of fellow citizens suffering needlessly."

As a foreigner living in the USA I'm sad to say that I both agree wholeheartedly with this comment and realise that it can never come to pass.

The entire political landscape of the US is built on ideological caricatures like the strong, independent, free American and the demon of socialism (or anything that even vaguely represents it).

The unfortunate consequence of this is a society sorely lacking in social concern with massive impediments to developing core infrastructure. Of course this benefits the ruling class who don't have to spend money on developing facilities that could benefit the lives of Americans.

</comment></comment></comment><comment><USER8> The job was important for this woman who needed to pay for her daughter's college and granddaughter's disease. Now the job goes to someone in Mexico who might also need it to pay for their daughter's college or granddaughter's rare disease. Is there a plan to help these Americans? People like Trump or Sanders seem to want some sort of forced reshoring, which is essentially taking the job away from the Mexican worker to give it back to the American one. But how is that fair?

<comment><USER9> Well I guess it will depend on where you draw the empathy line. Some people care only about themselves, they will look after themselves, if they have to choose they will always pick the option that benefits them.

Then you have the people who only care about themselves and their family, I guess a good percentage of the population will choose in favor of their family rather than someone's else.

Then people empathize with those who share things in common with them (culture, ideology, social status, race, nationality, religion) a kind of extended family.

Then you have people who think we should empathize with everyone around the world, but do they really?, if there was a chance where they have to decide between their children or some random dude in the other side of the world, who would they choose to help?

Is it fair? I don't think so. Would I rather help people who I empathize with? I would lie if I say no. I'm not a monster , I don't want a random guy to suffer, but there's something inside me that makes me look after my family first.

P.S. I'm from Mexico, and I live in a city whose economy depends on foreign manufacturing companies.

<comment><USER10> There's also this:

If every country has its own economy, there will be far more companies and jobs than if only a few multinational companies exist in the entire world.

<comment><USER11> Why country? Why not state, county, city, neighborhood, or block? If subdividing the economy creates good jobs, then we should do it as much as possible.

National protectionism has the same problems as state or city level import restrictions would, just at a different scale: you're throwing away comparative advantage, wasting time and capital duplicating others' work (so this time and capital is no longer available to unsolved problems), etc.

<comment><USER12> _National protectionism has the same problems as state or city level import restrictions would_

No, it usually doesn't. There are benefits of scale but there are also diminishing returns.

Having, say, a steel mill in every town would be a huge waste but centralizing all steel production in one place on the globe would provide only a very minor, if any, benefit over doing it in fifty countries at the massive hidden cost of now world-wide fragility of steel supply. (This almost happened with hard drives.)

<comment><USER11> The world's countries have drastically different scale. If we are concerned with the point of diminishing returns on industrial economies of scale, aren't those the same everywhere? Shouldn't large countries be partitioning into several economic zones, while small countries unify, into groups of about the same size?

</comment></comment></comment></comment></comment></comment><comment><USER13> One thing I picked up on was that the plan to move production to Mexico was to save 30 million dollars. The CEO's compensation was 40 million

<comment><USER14> It took him 6 years to make that $40 million. It's not clear the timeline on that $30 million. For all we know it could have saved the company $30 million a year.

<comment><USER15> The old CFO at my firm was awarded the first year of annual cost-cutting savings as his bonus. Executive comp can be weird, but at a public company it's probably not a loss-leader.

</comment></comment></comment><comment> a-dub 1) Bravo to the Times for dressing up rural realities in terms that urban elites can understand. It's cool to care about gender equality and all, but it don't make much difference if nobody has any work.

2) Computer people complaining about efforts to repatriate factory work is pretty hilarious. You do realize where this whole industry is headed don't you? I mean no other industry is better suited for it, as tooling gets better, and links around the world get faster, it will be _the_ fastest sector to fly to the cheapest place on earth to do it.

<comment><USER16> >it will be _the_ fastest sector to fly to the cheapest place on earth to do it.

Software outsourcing has been a thing for decades now and if anything seems past its peak as people find their programmers in Bangalore don't actually do as well as they hoped.

<comment><USER17> Companies have been burned by outsourcing production to India where they didn't get the quality they wanted and cultural differences are difficult. However, companies have gradually had more and more countries to outsource to, and Eastern Europe with its large young, "westernized" or "americanized", well-educated and English-speaking population is, if anything, more and more popular for companies looking to relocate production or acquire staff.

<comment><USER18> I think you're looking at the wrong factor — Eastern European outsourcing has plenty of the same failures, and for the same reasons. Most of the companies which jumped on outsourcing did so because their internal processes were failing and then spent the next few years learning that adding communications overhead and conflicting incentives doesn't improve that situation. That's a hard lesson for many companies since it means accepting that the root cause was management rather than the workers.

</comment></comment></comment></comment><comment><USER19> What is the endgame of all of this? If a nation is composed of rich people who live off wealth created in other countries, and a great many very poor people, for how long do those other countries continue to send the wealth they generate to foreign rich people? And advances in wealth creation; those will happen in foreign countries. The rich people in the country that no longer generates wealth will only survive by buying into those new wealth generators.

Eventually, will there be a leftover country composed of rich people who own some wealth generation in foreign countries and a great many poor people? I suppose eventually, Mexicans will be complaining that their jobs are going north to people who will work for much less money.

<comment><USER20> Wealth inequality is the end game. Even within the united states the divide only gets bigger. This state can be maintained indefinitely as long as the ones on the bottom aren't suffering enough to the point where they decide to just stop working or raise pitchforks.

<comment><USER21> It won't even matter in a generation or less, when robots do most of the labour and the rich have autonomous robotic armies to protect them from the revolutionary masses...

<comment><USER22> _...the crusade against computers, thinking machines, and conscious robots begun in 201 B.G. and concluded in 108 B.G. Its chief commandment remains in the O.C. Bible as "Thou shalt not make a machine in the likeness of a human mind."_

</comment></comment></comment></comment><comment><USER23> This is a heart breaking read. And it is about the sort of people who hoped that Trump was going to make things better. In my opinion, Trump spoke to their pain, Hillary did not. So they voted him in and he's doing nothing to help them.

The only positive, if you will, is her daughter got into Purdue and will maybe have a better chance in life.

The american dream, for working class people, seems pretty darn dead. It's super depressing.

</comment><comment><USER24> the article is worth reading. it really makes you feel for the workers at these plants. they're on the front lines of globalization, unlike workers in certain other sectors, whose jobs are protected _by law._

a good deal of US politics is about classes of workers (and entire corporations) trying to either maintain their current barriers against globalization, or trying to build new barriers against globalization.

</comment><comment><USER25> I read a comment elsewhere that the strife is between the people on the left side of the iq bell curve, and those on the right.

Steelworkers and blue collar jobs, left side, mostly, while those in upper management that ship the jobs elsewhere in search of arbitrage are on the right side. Lobbyists and pols, right side, that rejiggered the export and import laws to benefit the right side.

Wondering what others think of this explanation...

<comment><USER7> Appallingly simplistic (if not entirely wrong).

And I've never met someone in management that belonged on the right side of an IQ bell curve.

<comment><USER26> You accuse the other person of being "entirely wrong" and then you go and claim that all management you've ever worked with is effectively on the left- side of the IQ bell curve? I.e. Saying they are all unintelligent.

<comment><USER7> Good, you understood me. Well done.

</comment></comment></comment></comment><comment><USER27> Maybe they should just learn to code. That's the magic job these days right?</comment>


There's a Hole in the Bottom of the C: Effectiveness of Allocation Protection [pdf] - <AUTHOR> http://web.mit.edu/ha22286/www/papers/SecDev18.pdf <comment><USER2> Short version: yet another hokey scheme for fixing buffer overruns in C fails for

       typedef struct {
            char buf[124];
            void* fptr;
        } mystruct;

because if you overrun "buf", you can overstore "fptr" without going outside the bounds of "struct". Exploit for Ngnix found.

We've got to get more code out of C and into something with subscript checking. None of the kludges for fixing C work.

<comment><USER3> or you could move all pointers to the beginning of the struct, and could even make the pointer a const (read only).

typedef struct {

            const void* fptr;

            char buf[124];

        } mystruct;

<comment><USER4> The const keyword really doesn't mean anything. It is not checked at runtime, so a buffer-overrun could change the const member regardless

<comment><USER5> and even if it were, it is in the wrong position (as defined, fptr is a mutable pointer to const data).

</comment></comment></comment></comment><comment><USER6> Here's my proposal for fixing buffer overflows in C:

[https://www.digitalmars.com/articles/b44.html](https://www.digitalmars.com/articles/b44.html)

It's simple and it works, we've got 15 years experience with this in D.

<comment><USER7> I mean, sure, fat pointers are the "right" solution, but the point of "low- fat" pointers in the original paper [1] is for greater compatibility with existing C code, including at the ABI level. Adding fat pointers to C (which is what your proposal is) is incompatible with those goals. Page 2 of the paper discusses this.

[1]: [https://www.comp.nus.edu.sg/~gregory/papers/ndss17stack.pdf](https://www.comp.nus.edu.sg/~gregory/papers/ndss17stack.pdf)

<comment><USER6> My proposal does not impact existing C code, and does not make existing C pointers into phat pointers.

It's purely additive, which means you can incrementally adopt it in places where it matters.

<comment><USER7> It makes a subset of what are currently C pointers—arrays in argument position—into fat pointers.

<comment><USER6> The phat pointers only appear when they are specifically declared as phat pointers. Existing syntax does not change behavior.

<comment><USER7> Yes, and that's a laudable goal, but it's not the same problem as the one the "low-fat" pointers proposal is trying to solve. The "low-fat" pointers proposal attempts to improve the safety of _existing_ code.

<comment><USER8> Is your complaint that because we don't have a perfect automatic solution we shouldn't bother offering _any_ solutions, not even incremental opt-in ones?

<comment><USER7> I never said fat pointers shouldn't be added to C. The point is that they're irrelevant to _this_ paper, which demonstrates a weakness in a mitigation designed to improve safety of _existing_ code.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Just simply slowly substitute C code, piece by piece into Rust. Building userspace less depending from C ecosystem.

<comment><USER10> Yes, at least as long as you're working on a target supported by the Rust compiler.

</comment></comment><comment><USER11> > In this paper, we have illustrated a new type of attack that can bypass > bounds checking spatial memory safety techniques that protect allocations.

No they have not. Bounds checking only outer structs doesnt do bounds checks on inner buffers. They haven't analyzed traditional bounds checks in C: asan, fortify, c11 Annex K, Intel MPX, only a broken application, which does none of these, and uses a wrong bounds check.

</comment><comment><USER12> Without protection function pointers themselves, this only covers a small part of the issue.

I'm more interested in seeing how CPI and CPS pans out in the end:

[https://dslab.epfl.ch/pubs/cpi.pdf](https://dslab.epfl.ch/pubs/cpi.pdf)

</comment><comment><USER13> tl;dr: the authors overflow from one struct field into another struct field, thus avoiding any allocation protection scheme that protects individual heap allocations from each other. Most of the paper is just spent implementing basic ROP-style gadget hopping.

I'm not actually clear on what's new or novel here. Allocation protection mechanisms exist to prevent one allocated block from overflowing into another allocated block. They usually don't protect allocated blocks from themselves.

</comment><comment><USER14> Hard to read a paper that repeats "legacy languages" many times just on the first page.

</comment><comment><USER15> There's a hole in the bucket... dear liza dear liza.

I suspect the circular never ending problem song might not have been what they were going for (or maybe it was).

[https://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket](https://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket)</comment>


Ask HN: Which $1B startups will fail if the bubble bursts? - <AUTHOR> Tech stocks are crashing. Bill Gurley says we're at an inflection point, and investors are going to start looking at profitability instead of growth. Most of the unicorns in the $1B+ club have gotten their valuations by rapid growth, though not necessarily the profitable kind.<p>If things take a turn for the worse, and funding becomes hard to come by, which unicorns will have the hardest time getting to profitability? <comment><USER2> Square. It's a bloated mess of a company still trying to "pivot" after its idea of being the credit card middle man never really took off (or took too long and allowed others to catch up, depending on how you see it). They're doing a bunch of different things but nothing that really seems to stand out. Have you seen anyone use Square Cash? Squareup? Didn't think so.

Quora. I'm surprised YC even took them in. It has an overwhelmingly unmonetizeable userbase (primarily in India). It's growing and growing but there's nothing really that can justify the $900mm+ valuation if there's nothing to monetize. I also personally hate their pesky model that_forces_ you to sign in to view more than a single answer. Maybe Yahoo will buy them and quietly kill them at a lower valuation in a few years.

<comment><USER3> Loved Quora about 2/3 years ago and could spend hours reading it but the questions and answers have become incredibly low quality to the point where I barely check it anymore.

<comment><USER3> They really need to sort out their notification system - I logged in and had ~200 notifications, it just instantly caused me stress and I closed the tab.

</comment></comment></comment><comment><USER4> Take your pick at one of the dozen on-demand food delivery startups: [ Postmates, SpoonRocket, Eat24, GrubHub, Caviar, Munchery, ZeroCater, Eat Club ]

I've used Eat Club and actually think they are the best of the group. The startups that are focused on business/corporate catering will most likely fare better than individual focused startups.

<comment><USER5> Strange, I actually disliked Eat Club when my former employer used them. Also, Caviar has a huge business catering component and has Square money, they're not going anywhere for a long, long time and are actually my favorite in your list (as an individual and as a gluttonous tech worker)

</comment></comment><comment><USER6> Handy.com is a likely candidate, a flawed business model, one only needs to look at Homejoy's failure at the best of times.

<comment><USER7> I'm on their email list and 2 hour cleaning offers at $29 can't be sustainable for long.

</comment></comment><comment><USER8> Seems to me that the bubble bursting has nothing to do with it. No matter what your valuation, sooner or later you have to show profitability. Those that aren't going to make it if the bubble bursts probably aren't going to make it anyway. The bubble bursting may make it faster, but it won't change the final outcome.

</comment><comment><USER9> I believe that over-invested categories like food delivery, Uber for X and social media will face challenges. These businesses also require significant upfront capital to build out their infrastructure.

That said, I don't believe we are necessarily in a bubble. Investment decisions made today are much much more fundamentally sound than they were perhaps in 2000. In my experience, markets work up and down in cycles. If you are a good company, you will survive any market condition. This does not necessarily mean you need to be profitable during that period. Investors are just more cautious in these periods and want to know that you have a PATH to profitability; you don't need to have it today. Note that while valuations are dependent in a way to how public comparable companies are trading, that specific point is only one of many inputs in thinking about how to make an investment. Investors look at many more things than just that.

With the exception of extremely few unicorns, most of the valuation practice undertaken today by VCs and angels reflects three good things:

1\. Investing in a great team and product vision: Most of the unicorns didn't become an overnight success. It took time, years. The investors did not reward them with their unicorn valuation in their first year as a company. However, the team and the product proved they can get traction, they can get customers, they address a need in the market. This is what attracted investors, and the startup's ability to beat its competition / creation of a new market is why they are being granted this unicorn valuation.

2\. Market Opportunity: A common theme with the unicorns is that they are genuinely targeting very large markets. In some cases, they are even expanding the addressable market. Most of these companies are first of their kind in either establishing a unique product experience/service or business model or both. Valuations of these companies reflects not only their current growth but the potential they can achieve if they can get to be pseudo-monopoly in the future.

3\. Supply and demand: While not every investment VCs make is a home run, the approach they have to investments is something akin to a baseball player's batting average. This means that when a hot startup or category comes along, VCs tend to double down. This creates competition amongst them and can lead to higher valuations for the startup. Even so, the valuations usually have root in either the startup's product, team, market opportunity and/or business model. Not everything is evident to us from the outside until later (case in point being Snapchat).

At the end of the day, the investors are not gunning to give the unicorn valuations. A wise founder also does not want a run-up valuation; it increases their risk of having a down round if they don't deliver on oversized expectations.</comment>


When I'm Mistakenly on an Email Chain, Should I Reply All Asking to Be Removed? - <AUTHOR> http://www.nytimes.com/2016/09/02/technology/when-im-mistakenly-put-on-an-email-chain-should-i-hit-reply-all-asking-to-be-removed.html <comment><USER2> Relevant Wikipedia page, since the article is completely lacking in historical context: [https://en.wikipedia.org/wiki/Email_storm](https://en.wikipedia.org/wiki/Email_storm)

"On 14 October 1997, a Microsoft employee noticed that they were on an as-yet unknown email distribution list 'Bedlam DL3', and emailed the list asking to be removed. This list contained approximately a quarter of the company's employees, 13,000 email addresses. Other users replied to the list with similar requests and still others responded with pleas to stop replying to the list. A Microsoft employee estimates that 15 million emails were sent, using 195 GB of traffic."

<comment><USER3> This happened a few times at the bank I worked at for almost a decade.

You could count on the technologists to not throw gas on the fire by replying (everyone'd heard of Bedlam DL3), but once non-technical sales, trading and ops were on the list, all bets were off.

<comment><USER4> Well, aside from the trolling devs. At my company there've been a couple incidents of this where someone jumps on the thread with advice like "Unsubscribe has to be in the _title_ " or "You have to BCC the list!". When that happens... oh dear god.

</comment></comment></comment><comment><USER5> Crusty though the software is, this is why list-hosts matter. Reply all is a terrible way to manage group communication by email. list- email@example.com is a pretty decent way to go about it. Emails that get distributed have a [list-name] tag prepended to the subject line for trivial filtering on the client side. You can set a large list to require moderation before distributing messages (except from a list of blessed senders). You can tell the software to set the Reply-To header to the sender's email, rather than the list's address, so that the "Reply" and "Reply all" buttons have the expected behavior. And there is self-service subscribe/unsubscribe via a web interface (with permissions, of course).

My university operates such a server and it's heavily used by everyone from department announcements to student organization coordination/discussion.

[https://www.gnu.org/software/mailman/](https://www.gnu.org/software/mailman/)

</comment><comment><USER6> This is purely anecdotal, but I am seeing far fewer replyallpocalypses than I did 10-15 years ago.

Has something changed, like better server or client email software? Or perhaps admins and users are more savvy about avoiding this kind of behavior?

(Maybe I've just been lucky to not have to deal with one of these for several years.)

<comment><USER7> I've seen maybe 1 a year over the past 5 years. The best ones are the ones that are sent out by accident, like, cc'ing in the distribution list to EVERY employee by mistake.

I love it and hate it, I find it laughable that it just keeps on going, but it makes me sad that some humans cannot grasp what they are doing, nor learn from the example, and this is in huge global organisations too, full of supposedly professional, educated people!

My favourite one of all time though is when a reply-all chain (office wide, think 1000+ recipients....) was fully in its stride and someone attached a 10mb animated GIF.

Needless to say, I don't think the people managing the Outlook Exchange servers had a good day that day trying to cope with that one...

<comment><USER8> I've seen flamewars where someone would copy the entire text of Beowulf into the reply just so that everyone would have dozens of copies of it that would be dragged around every time someone added something to the chain.

</comment></comment></comment><comment><USER9> Why was the answer in a PDF? I don't understand. The increased casualness of the NYT lately has been bothering me.

<comment><USER10> My best guess: The article is about an online faux pas, and hyperlinking to a PDF when an HTML page would be perfectly sufficient is a self-aware nod to another online faux pas. (Fellow HN user oneeyedpigeon points out this faux pas in their comment.)

My seventh-best guess: The NYTimes' CMS lacks support for actual footnotes, so linking to another page is the next best thing. But since the footnote doesn't make complete sense unless you've come from the main article, the web editors didn't want the other page to be easily discoverable. Problem is, the CMS automatically makes any article styled as a regular article SEO-friendly, so they decided to work around that by putting the text into a less-SEO-friendly PDF.

</comment></comment><comment><USER11> When I want to publish some text on the open internet, should I put it all in a print-focussed file format instead of the HTML standard?

No.

</comment><comment><USER12> Content of the ridiculous article in PDF

By Daniel Victor

O.K., here's a little more context, for those of you who need it.

It begins when an innocuous email that you probably don't need lands in your inbox (as it did mine on Thursday).

Soon someone inevitably replies (all): "Please remove me from this email chain."

Then another: "Unsubscribe."

Soon, dozens of people are replyingall, sending their fruitless requests to people who are equally annoyed. Notifications on your phone won't stop buzzing.

This is known as the dreaded replyallpocalypse.

When you are in this situation, the logical, expert opinion is: Do not hit "reply all."

You will only make things worse.

Another option: If you're using Gmail, you could mute the conversation and go on with your day.

Otherwise, hunker down. We're all in this together, and it'll all be over soon.

</comment><comment><USER13> I mostly don't experience this, with one notable exception. My uni's computer science department administrator has a mailing list for my entire class (~80 students). Whenever she sent out an email blast, it would appear to come from her email address, but for god knows what reason, the Reply-To address was set to the mailing list's address.

So basically every time someone had something they needed to discuss with the dept admin after an email blast went out, they would end up sending their response to the entire CS class. No matter how many times it happened, there would always be that one person who hadn't yet learned not to reply to the email blasts.

</comment><comment><USER14> "The New York Times's internal email system contributed to this report."

</comment><comment><USER15> For those who wonder (also mentioned in the article) in gmail there is a feature called "mute" exactly for this.

</comment><comment><USER16> Couldn't an "unsubscribe" functionality be written into an email server? You'd have to change the way mailboxes are stored. In particular, email threads and recipients lists would have to become explicit objects in a distributed database. Perhaps threads could be identified by a canonicalized version of the original recipients list, plus some other information?

<comment><USER17> Or you could just reply to the list itself with the word 'remove' in the subject (doesn't work for all list servers). That's how most servers handled subscriptions back in the days and probably still is now.

<comment><USER16> That would work for a LISTSERV -- but this is a special kind of server that does keep the list as an explicit object. If it's a recipients list in a regular email, that would be different.

</comment></comment></comment><comment><USER18> At a former job someone sent a completely inane email asking about something personal to an HR email list or all people in the company, about 21,000 people.

Why does such an email list even exist? For some kind of HR emergency? Aren't there other emergency messaging systems that could be more effective?

<comment><USER19> At my company, certain lists can only be used by certain people to prevent exactly this sort of thing.

<comment><USER18> Perhaps they implemented such a restriction afterwards. Fortunately I never found out; perhaps they did.

</comment></comment></comment><comment><USER20> As mentioned by the pdf, "Muting or ignoring conversations" in Gmail: [https://support.google.com/mail/answer/47787?hl=en](https://support.google.com/mail/answer/47787?hl=en)

</comment><comment><USER21> My employer just issued written notices to people sending mails to "Territory All" type addresses without good reason. I mean it asks you 3 fk'in times "Are you sure???"...

</comment><comment><USER22> Like most article titles that end in a question mark, the answer is no.

</comment><comment><USER23> Should I reply all and tell them not-to reply all?

Still NO.

</comment><comment><USER24> they say brevity is wit, and the NYT does not disappoint</comment>


Introducing rkt's ability to detect privilege escalation attacks on containers - <AUTHOR> https://coreos.com/blog/rkt-detect-privilege-escalation.html <comment><USER2> I don't have the inclination to write a long comment about this. But reading sections like this:

>This state can then be verified whenever a process performs an action requiring a permissions check. For example, when a process requests that a file be opened, the kernel now calls out to the hypervisor. The hypervisor is then able to examine the process state and ensure that it remains consistent with its internal representation of process state.

Makes me very uneasy. You're making the hypervisor more complicated, duplicating the logic in the kernel, because you feel the kernel is insecure. The only argument for doing this, AFAIK, is that the hypervisor is still simpler overall, and therefore more secure. But when you start introducing these kind of complications, that argument becomes kind of farcical... Adding another layer on top of the kernel and duplicating your permissions checks in there, I do not think that will end well.

<comment><USER3> You can take a look at the patch - there's very little additional complexity in either the kernel or the hypervisor. The kernel permission checks remain unmodified, with the hypervisor checks as a backup.

The argument for this isn't that the hypervisor is simpler, it's that the hypervisor is running at a separate privilege level to the rest of the stack. The hardware enforces an additional level of separation. This just adds validation on the other side of that boundary.

(Disclaimer: author of the code)

<comment><USER4> Hey, author, thanks for commenting. AFAIR, you also are the guy who criticizes Ubuntu's policy regarding derivative works. Anyway, I have a question for you.

If I understand rkt's architecture correctly, the hypervisor runs multiple Linux kernel instances, every kernel runs several processes. If somebody exploits one of those processes and creates a root-owned process, then rkt detects such an attempt and restarts the kernel. But what if the exploit doesn't create any root-owned processes? You can get rights equal to those of the superuser without getting uid=0.

<comment><USER3> It also detects any bump in capabilities. Getting superuser level abilities without modifying either your uid or your capabilities would require modification of kernel code.

<comment><USER4> > would require modification of kernel code

And it's impossible for an exploit to do because?..

EDIT: "?.." in this case means "please continue my sentence".

<comment><USER3> Kernel code is mapped read only

<comment><USER4> Thanks for taking time to answer my questions.

> Kernel code is mapped read only

What part of the system makes sure that read-only kernel code stays read-only? Is it hardware or the hypervisor?

Another question. Is there any chance that you missed something and there's a way to get privilleged access without actually modifying your uid, bumping your capabilities or modifying kernel code?

<comment><USER3> The hardware - it's an attribute on the page table. You could certainly monitor that from the hypervisor as well, although there'd be some performance overhead. You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. The blog points out that this class of vulnerability isn't covered.

<comment><USER4> > The hardware - it's an attribute on the page table.

And the only way to make the page writable again is to clear the page first. Am I correct?

> You can avoid all of these protections if you can inject new code into an > existing privileged process or SUID executable, which is how DirtyCOW > worked.

It can happen if either one of these is true: 1) the existing privileged process or SUID executable is vulnerable; 2) the kernel is vulnerable. DirtyCOW is interesting because it's the case #2. The case #1 is not that interesting, because targeting vulnerable privileged executables is a known attack vector.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Sounds very familiar to VMware's VMsafe [1], which apparently they EOL'd [2].

[1] [http://www.gabesvirtualworld.com/vmsafe-what-is-it- exactly/](http://www.gabesvirtualworld.com/vmsafe-what-is-it-exactly/)

[2] [https://kb.vmware.com/kb/2058911](https://kb.vmware.com/kb/2058911)

</comment><comment><USER6> Who is using rkt in production? I'm working on a system from scratch and planning on using k8s and just assumed docker would be the container engine of choice, but the more I hear/ read about rkt the more it seems like the better choice.

<comment><USER7> BlaBlaCar have been using rkt since some really early version. Simon Lallemand gave a talk in Berlin at the CoreOS meetup about it. I don't recall it being recorded, though there is a blog entry covering some of the details[1]. Interesting how they built a lot of tooling for the container building and management before other ways appeared, and the approach they took to it.

[1] [http://blablatech.com/blog/why-and-how-blablacar-went- full-c...](http://blablatech.com/blog/why-and-how-blablacar-went-full- containers)

<comment><USER8> Video of a talk from BlaBlaCar in Paris on rkt: [https://www.youtube.com/watch?v=dW7U2PZ16ek](https://www.youtube.com/watch?v=dW7U2PZ16ek)

And a blog post on their site: [http://blablatech.com/blog/why-and-how- blablacar-went-full-c...](http://blablatech.com/blog/why-and-how-blablacar- went-full-containers)

</comment></comment></comment><comment><USER9> How close are we to a world without SUID binaries? It seems like you could just replace sudo with RPC to some privileged daemon (which could be as simple as the existing sshd and "ssh root@localhost", but another daemon would be fine), and most of the other use cases (mount, pt-chown, dbus-daemon-launch- helper, etc.) have been slowly disappearing.

That would avoid the weird special case for SUID binaries, which looks like the sort of thing that someone is going to discover an attack on in a year or two. (And it's a special case in lots of systems, not just this one.)

<comment><USER2> >most of the other use cases (mount, pt-chown, dbus-daemon-launch-helper, etc.)

Those listed examples could also be could be achieved with IPC to a privileged daemon. But unfortunately not all setuid executables can be replaced that way.

The major design flaw with setuid executables is that they run in an execution environment (view of the root filesystem, Linux namespace, etc.) provided by the caller. A good explanation of this is [http://maxsi.org/blog/setuid-bit- considered-harmful/](http://maxsi.org/blog/setuid-bit-considered-harmful/)

Unfortunately this is why not all setuid executables can be replaced with IPC. setuid binaries like "nsenter" allow you to run processes with a selective modification to one part of your execution environment, while still inheriting everything else unmodified. You can't achieve this with IPC to a privileged daemon because that daemon cannot inherit your current execution environment when starting new processes.

Nevertheless, getting rid of setuid is very important. Kind of baffling to me that it hasn't been done yet. The closest we've come is replacing setuid with filesystem capabilities, but those have the same fundamental design problem. I've been working on genuinely getting rid of setuid some myself. Happy to collaborate with anyone else who wants to work on this.

<comment><USER10> > You can't achieve this with IPC to a privileged daemon because that daemon > cannot inherit your current execution environment when starting new > processes.

What if it could? An "execution environment" could be turned into some sort of kernel token object that could be passed to another process over IPC. A privileged daemon could receive one, fork(2) once, drop some privileges, and then fork(2) again, this time with the execution-environment parameter—and end up with a copy of itself running _under_ the IPC-sender, with environment inherited from the sender but privileges inherited from the receiver (and, presumably, an address space that contains all the mappings of both parents, with the IP pointing into the receiver's code section, like a normal fork(2) would.)

<comment><USER2> Definitely, that is one possible design. Although that would be fairly tricky to implement in the kernel.

One way you could do this is to heavily abuse the CRIU project. [https://criu.org/Main_Page](https://criu.org/Main_Page) Just do the following:

1\. fork

2\. send a request to a privileged daemon

3\. privileged daemon checkpoints your child

4\. privileged daemon modifies the saved state of your child in whatever way you requested

5\. privileged daemon resurrects your child (which is possible because it is privileged)

I am not really serious about this method but it is certainly a thing you could do. :)

</comment></comment></comment></comment><comment><USER11> i think this is useful in that against unsophisticated attackers and people who don't know it is there the protection will trigger. however, it sounds like it only is going to be triggering when a process forks. so if you have some exploit that raises your creds then just don't fork and you don't trigger the detection. you can do everything evil in the system you want to do without forking. and if you want the convenience of a shell you can just chmod suid a binary and exec that. anyway, i think this generally idea is interesting because you can do a lot with it and if you keep what you are doing a secret (because you are running a public cloud platform for example) then you can have quite effective protection against attackers that don't have insider information. but if you are running a public cloud probably one of your biggest threats are insiders. so meh.

<comment><USER3> It validates on every syscall that has a permission check. If you modify your process status without forking and then make a syscall, it'll still trigger.

(disclaimer: author of this feature)

<comment><USER11> Sorry. I completely misread the original post. That seems a lot more sound :)

</comment></comment></comment><comment><USER12> Glad to see that they acknowledge GRSecurity.

<comment><USER13> GRSecurity has some interesting ideas and if systemd is any indication some Linux vendors will happily work with iconoclasts. However it seems like much Theo De Raadt can rub people the wrong way resulting in OpenBSD, GR Security's alleged refusal to submit patches in a manner Linus will accept has resulted in their rejection from the kernel mainline. Considering for some applications Linux needs all the hardening it can get, this is truly unfortunate.

<comment><USER14> You've got it a bit wrong. Brad Spengler (aka spender) and much of the grsecurity team's goal is making Linux more secure by working on grsecurity. They're not interested in totally rewriting large portions of Linux technical debt to make Linux more secure, but upstream demands they do it. Is spender often a bit of a prick, yes, but is he virtually 100% right on security things, also yes. It wasn't really a rejection from kernel mainline so much as they don't have any interest in submitting it. You can't have rejected what you never submitted in the first place.

Fast forward to now and you have kernel heavyweights like Kees Cook (former Canonical kernel/security lead now chromeos security badass extraordinaire) working on bringing these features into mainline via the aforementioned KSP projects. In the end, Linux is getting more secure, and it is largely in part to the hard work of the entire GRSec team, even if they're a bit abrasive to work with.

<comment><USER13> I was specifically referring to this post by Linus himself [http://article.gmane.org/gmane.linux.kernel/774824](http://article.gmane.org/gmane.linux.kernel/774824) in which he states

>The apparent inability (and perhaps more importantly - total unwillingless) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be merged.

Although there are other posts since debating the same point such as this one [https://lkml.org/lkml/2005/1/25/141](https://lkml.org/lkml/2005/1/25/141)</comment></comment></comment></comment>


Ask HN: Why are clickbait titles bad? - <AUTHOR> A lot of times when I'm reading HN I notice there are a lot of people complaining about articles having clickbait titles.  I have always been under the assumption that that was the entire purpose of a title which is to grab the readers attention and get them to read the article or in other words, in the context of the internet, be a bait for clicks.  While it's not an excuse to have a misleading title, some articles are less technical and meant for a more general consumption so are they expected to have a title similar to that of one more serious and technical?  Even if the article is crap and the title is misleading it will either be filtered out of the front page or could even possibly insight a really good discussion. So instead of complaining about weather a title is clickbait, maybe it would be better to just explain what is wrong about the article instead to help prevent any misinformation or just ignore it and let it sink? <comment><USER2> The usual clickbait title will get you to a page by asking a question or leaving something out. "Do butterflies have the dna from two different creatures?!?" (btw The answer to those is always "No") Once you're there, you find its a waste of time. Just to get some impressions or whatever.

I've stopped clicking anything that doesn't answer the question in the title. But that means I can hardly click on anything, especially facebook posts. Because even my friends don't bother to label them! Its so easy to say "This article explains X" but they just leave the clickbait title. So I guess I'll become a hermit.

"This man became a hermit for the Weirdest reason!"

<comment><AUTHOR> And that's the type of reaction I would encourage. Yes you stop clicking on a lot of articles, but you're less likely to waste your time. I find that instead of going to around yelling clickbait, just ignore it, or at least make your time useful and either build something from the article or explain why it's bad so others could learn to ignore more stuff that source

</comment></comment><comment><USER3> I usually call "clickbait titles" titles that, after reading the article, end up being misleading. Either because they end up having very little to do with the article, or sometimes even telling the opposite story the article is telling.

Understood that headlines are supposed to make you want to read the article, with clickbait titles there is this feeling that you've been tricked. Tricked in spending a chunk of your time to read a story that ended up having very little to do with the title that was use to "sell" it to you.

<comment><AUTHOR> I understand your point of view, I guess I'm more bothered by how it seems to me that people are quickly to yell clickbait and just that which if anything could bring more attention to the article. I almost feel likes it's yelling "Don't look!", which is going to make me look.

</comment></comment><comment><USER4> Clickbaits are good for the journalist/newspaper (if they don't value their reputation) but are bad for us, the readers. So it's better (for us) to change the title to a good title before submitting it to HN.</comment>