david_shaw

It looks like this PDF has been posted to HN a few times before, too: https://news.ycombinator.com/from?site=beginners.re

I haven't read the book, but I did download the PDF and briefly check it out. I'm not a reverse engineer by any means, but this seems like a (very) comprehensive overview. It's over 1000 pages!

After reading the headline, I expected webcam footage showing the hackers' faces -- or something similar. I don't think m000 actually anticipated true pants-less video :)

That said, this is all really interesting; I'd love to see the data itself. Unfortunately, all this really shows is that Iran conducts state-sponsored cyber-attacks -- which, of course, we already know.

I don't see plain nuts as often as I'd like in stores, but they are super easy to find online: https://www.amazon.com/s?k=raw+almonds

Many, many respectable businesses use WordPress for their brochureware or corporate blogs. In my experience, it's not a security nightmare if it's well maintained.

I think you make a valid point, but there's a difference between their sales pipeline and their actual product. These VPN providers are businesses, and they're trying to optimize their sales. What demographics are most interested in their products? How did they get there? Does Google Analytics (or Facebook, or similar) have profiles on people shopping for VPNs? Are there advertising patterns that could have better ROI for attracting users?

I'm not defending the ethics of major VPN providers -- they certainly don't all have stellar records -- but I would be surprised if any major SaaS company didn't track user behavior on their brochureware/sales pages.

Cool product, by the way!

However, granting visibility to decisions (and the information that leads to them), when possible, is a great tool.

A generic example might be that a major client will sign onboard if a new API feature is implemented. Just asking a development team to build the feature will get it done, but in my experience, teams will feel significantly more included (and important) if they have the context of why it needs to be built.

The decision to pull resources off of already-planned tasks to build the new feature shouldn't be made by the developers, but understanding that they're helping the business in a major way can really help cohesion, inclusion, and perceived impact. Those are things that make people feel fulfilled and important at work.

I think this is an underrated (but very accurate) opinion.

While I'm not the founder of a company, I do have the tendency to shield my team from much of the insanity I deal with on a daily basis.

I've made active, conscious efforts to stop doing this.

When you shield your team from the harder, more hectic parts of the job, several things happen:

(1) You burn out. A burned out leader is not an effective one. You're not doing your team any favors by forcing yourself into an impossible position.

(2) Your team won't understand the pressures that are driving the business. Having a nice, relaxed work-week is great, but employees should at least be aware of high-pressure situations in the business.

(3) Your team will get bored. Great teams like to work on challenging issues, and high-impact engineers like to work on high-impact problems. They want to grow. Exposing people to issues outside of their direct control and comfort zones will actually help make them more satisfied at work, even if it does come with a little added stress.

These are issues that I've been working on, personally, for years. The gut reaction of "protecting" teams is often times not the best one for anyone involved.

How do you figure that it never pans out? Healthcare providers use a lot more technology today than they did in 1979.

From medical devices to billing software to electronic health records, I think this is an area that will continue to grow.

This is an interesting design choice.

I'm sure the idea here is to reduce the number of abuse complaints directed to Cloudflare, but it also seems to significantly reduce the value of the service.

I'm excited to try WARP, but without IP masking, I'll need to keep paying for a commercial VPN service. If I'm already paying for a commercial VPN, I don't see why I'd ever use WARP.

That said, I definitely trust Cloudflare more than PIA/NordVPN/etc. Some more "bulletproof" providers like Mullvad are probably even more trustworthy, but I don't think Cloudflare is going to mine (or sell) my data.

At this point, I'm just not sure what use-case WARP would really fill for me.

I've been happy with the switch. I was a long-time `screen` user, too, and something that helped me a lot with the switch to tmux was adding a few lines to my ~/.tmux.conf to change the command prefix from ^b to ^a, like screen. It made the muscle-memory shortcuts I'd used for so long still basically work.

  unbind C-b
  set -g prefix C-a
  bind-key a send-prefix

At the high-end, bulletproof suits and luxury vehicles certainly have a market that already exists today.

Other than specific edge cases (for example, competing with a colleague for a promotion), success is not mutually exclusive.

You can be happy for your peers when they do well -- their performance doesn't mean that you can't succeed, too.

Calibra, Facebook's wallet, is described here: https://newsroom.fb.com/news/2019/06/coming-in-2020-calibra/

Hope this helps :)

What games are you thinking about where this applies?

Many of the most popular games with which I'm familiar (Overwatch, PUBG, Starcraft II, DotA, League of Legends, Counter-Strike: Global Offensive, etc.) seem to have very high skill ceilings. That is, high-level competitive players in those games are way better than the average gamer.

I think a big way these games bring in players/stay current is by having a very active esports scene -- which only really works when you have "pro" quality players.

With the exception of time-gated achievement games (most MMOs, for example), the trend I see is a low barrier-to-entry but a very high skill ceiling.

One tactic that seems pretty common is to get people in-game quickly (f2p), teach them the core gameplay mechanics, then make it a very time-consuming grind to achieve the highest levels of play.

Attend community events and conferences. There are local "Bsides" conferences in most cities, and the big conferences (DEF CON, Black Hat, ShmooCon, etc.) are great too. I haven't been to Summercon or Hushcon East, but I've heard that they're both great NYC conferences. When you're at these things, don't just go to the talks (you can see them on YouTube later), but talk to people in the hallways/bars/parties and find out what kind of challenges they're facing.

Attend local meetups. See what people are talking about. Be involved with the community.

If you do these things, I can guarantee you'll stay current -- and hopefully, it will keep your interest in security going strong :)

As someone working in security, I'm fairly distraught that I still don't know exactly what happened last week. The Docker post-mortem[1] states:

> On Thursday, April 25th, 2019, we discovered unauthorized access to a single Docker Hub database storing a subset of non-financial user data. Upon discovery, we acted quickly to intervene and secure the site.

> During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as GitHub and Bitbucket tokens for Docker autobuilds.

> There was a brief period of unauthorized access to a Docker Hub database. During this time some sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of users as well as GitHub and Bitbucket tokens for Docker autobuilds. All these tokens have been revoked.

To the best of my knowledge, the above excerpts are the entirety of information about the incident that Docker has officially released. This is not nearly the level of detail that any security-conscious customer cares about, and in my opinion, it's an egregious violation of trust to not give more information.

For those that may not be working in security day-in, day-out, here's what I mean:

If this incident was, at its core, a DockerHub error that exposed a database to the Internet without proper authentication in place -- and then someone stumbled upon it -- that's an embarrassing mistake, but these things happen. I'd feel comfortable that Docker understands the extent of the breach, and that we can continue to use these products with some degree of confidence.

If, however, the breach was -- and we're going to the other end of the spectrum here -- a state-backed APT that blew 0days to breach the DockerHub network, then the threat model is significantly different. Did Docker bring in incident response professionals? What were the attackers targeting? How confident can we be that they didn't pivot to somewhere else on the Docker infrastructure undetected?

I know that Docker is likely trying to save face, and that the former scenario is significantly more likely than the later -- but guessing about whether or not the breach was severe is a ridiculous situation to be in for major organizations that use the DockerHub service.

In case anyone was wondering, I wasn't personally or professionally impacted by the breach, but we performed full credential rotation anyway. If the breach was more severe than described (e.g., persistent access was established), then that probably wouldn't do much good... but it's better than just assuming that "only 5% of users could have been impacted," and doing nothing.

I'm very unhappy with Docker's communication of this breach/misconfiguration/incident/whatever it may have actually been. I really hope they release more information (perhaps in the form of a real post-mortem) so that DockerHub users can better understand the risks of using Docker products. In my opinion, it's incredibly irresponsible of Docker to keep this information to themselves.

1: https://success.docker.com/article/docker-hub-user-notificat...

It's absolutely ridiculous that any kind of a security team -- not to mention one that's supposedly safeguarding such an immense amount of data -- could let monitoring certificates expire at all. It's almost inconceivable that they could let seventy nine certificates that are required for security monitoring expire for months on-end.

I've worked in security for my whole career, and I'm firmly of the optimistic belief that someday, far fewer security-minded people will be needed to keep organizations secure. This is an excellent counterpoint to my argument, though: even the people who supposedly specialize in keeping things secure can apparently be absolutely clueless.

Really? The author learned Chinese, studied kung fu for years, then traveled to China to train -- only to decide that getting up early was simply too much effort?

I found this article informative (if someone erratic), but this part truly baffled me. Still, it's very interesting that a fifth century temple is still operating -- and making money! -- today.

I totally agree with your points, but only when talking about the traditional/entrepreneurial sense of "business owner." The article is talking more about owning equity in a business, whether that's real estate (which is his example), or just investing in businesses. He even explicitly states that:

> Owners do not have to be entrepreneurs. They don’t even have to be competent. They can hire competent people to manage their money for them. The amount of 'entrepreneurship' in my story was miniscule.

In other words, if you're very wealthy, you can invest in diversified REITs and have exposure to the real estate market. You do not (and cannot, really) work on these projects, and your investments -- ownership of real estate through REITs -- will keep making money. That's not to say it's without risk, of course: the market could crash, the funds could fail to return on investment, the business could collapse.

Again, I think that for the HN crowd, your critiques are totally valid and I agree 100%. I just think this article is more about "hey, if you're really wealthy, your money can work for you!"

Not that that's particularly groundbreaking.

From there, growth was organic/"viral," in that people shared it amongst themselves. I've also had some traditional media (NYTimes, Toronto Star, etc.) cover the site, but that was after traffic was already pretty high.

Not an insane amount of money, of course, but enough that you can consider the project successful if you're getting a solid amount of views.

My largest project, http://sleepyti.me, gets about 1.5 million unique views per month. The revenue Google Adsense brings in is not nearly enough support myself, but it's enough to make the effort feel solidly "worth it" in terms of development time and hosting costs (which are very low at this point).

How (or if) you should be monetizing depends on the nature of your side project. If your "side project" is a business -- say, designing WordPress themes -- then you should sell your product! If it's something that gets 50 views per month, maybe it's not the best candidate for monetization (and is instead a portfolio/resume builder). Either way, gaining experience building things is almost always a good thing.

In my experience, people submitting vulnerabilities to bug bounties tend to incorrectly estimate in the other direction, since they have financial incentive to do so.

You replied to a comment indicating that even minor bugs can be serious -- which they can -- but many researchers will find actually minor bugs (nginx version disclosure, existing account enumeration on signup page, etc) and claim they're critical.

There's a balance there, and it can be tough to find. In any event, my stance is that if there's a security bug, you should damn well fix it :)

I think soon it will seem weird for a TLS-enabled site to not use HSTS.