79d697i6fdif

I wouldn't call the disclosure harmless. It's unknown if anyone made use of the leaked information before Cloudflare knew, so accounts should be treated as compromised unless it's shown otherwise.

Also, leaking user credentials to any system that handles payments and health info would also breach PCI/HIPAA . This broadens the scope of systems effectively breaking the law.

Another thing to keep in mind is that many(most?) token based authentication systems don't invalidate tokens. So any tokens captured will be valid until they expire, and they can't be "changed" without invalidating every outstanding token (changing the server key)

For all we know they cherry picked the responses they tested from a single site that doesn't handle anything sensitive.

Thankfully CloudFlare spent a week cleaning up the leak in search engines and caches before publicly announcing the issue, so a lot of the evidence is gone.

Accounts commenting that have made 10 comments in 5 years, people defending CF that, after going through their profiles, are clearly linked to CloudFlare or maybe even employees. Top relies suddenly being near the bottom and replaced by posts supporting CloudFlare with statements that don't match what was actually in the blog post.

Just seems really really fishy to me

This leak is being downplayed by webmasters because it's so incredibly bad that there's no way of handling it. The credentials of practically any internet user could have been leaked. The only "safe" way to handle this is to give everyone in the US new credit cards and SSN's and to reset accounts and security questions for every user on a site with cloudflare

IMO a leak this bad should be enough to sink cloudflare. A provider of SSL was randomly spitting out private data onto public websites. OVER A MILLION TIMES. Entire CA's have been shut down for leaking a couple hundred certificates. This has leaked private data over a million times, cloudflare is a joke

Wow, so just as bad as we thought.

We did not find any passwords, credit cards, health records, social security numbers, or customer encryption keys in the sample set.

BUT WAIT, THERE'S MORE

The sample included thousands of pages and was statistically significant to a confidence level of 99% with a margin of error of 2.5%.

Oh, so it could actually be as a high as 2.5% leaking encryption credentials. And if none of the data was found to leak anything sensitive where the fuck is the dataset? I've been around way too long to take a "study" like this at face value without third party verification.

I also enjoy the straight up lie at the end:

We are continuing to work with third party caches to expunge leaked data and will not let up until every bit has been removed.

That sounds great right? Well, its too bad that a lot of 'third parties' are a box sitting on the corporate network edge that hasn't been touched in 5 years. Deleting all of this data from third party caches is not physically possible. In fact it might actually make things worse because it's destroying evidence of which credentials were leaked.

He is also going to run into modulo bias since using the remainder to calculate a slot position is biased toward certain positions for every table size that isn't a power of two. (see https://ericlippert.com/2013/12/16/how-much-bias-is-introduc... for cool graphs) Prime number table sizes do nothing to fix these issue. The power-of-two size with a bitshift is not just faster, it gets rid of the modulo bias.

Fastrange is much faster than modulo but if his goal is to build the fastest hashtable it's stupid to use a table size of anything except a power of two.

Source: I also wrote a hashtable :)

I've known a few Iranian engineers and both of them were excellent. They didn't talk about politics either, the ones that come over here at least obviously don't have anything against the US.

#5 is a killer for so many places, maybe the most common big mistake. This is one place where "fake it till you make it" is absolutely mandatory for success. Selling yourself as a "freelancer" devalues everything you do. Selling yourself as a startup is similarly dangerous. Having the cutesy small business/startup vibe might sound appealing to customers and the valley but it makes you look disorganized and unstable to big successful businesses. These are the very customers willing and able to throw lots of money around.

I cringed at GitLab's unnecessary transparency recently because it makes their vulnerability and management missteps all more apparent. Their mistake is the kind of shit where the better choice from a business perspective is to be reasonably honest then give all your customers a free month or two so they stop talking about it. Their absolutely transparency exposes a lot of internal politics and missteps, especially mentioning people by name, A HUGE no-no in any kind of big business. If I was fortune 500, hell even INC 500, I would run away as fast as possible.

2) Started writing interesting content. Truly good content is a PITA and you need to be a decent writer to make something compelling, but our first good article got us more traffic than the entire site with over 100 content pages.

3) New tools. everything linked together to see where our sales were coming from. Phone system, website, live chat, in person. All of our leads funneled into one system. We could see what was getting people and what wasn't

4) Online advertising. Locally first, expand AD reach as campaign becomes more nationally competitive. Make sure all the tools you setup continue to track where all these leads are coming from

5) Better "convincing" of clients that we're legit. Company T-Shirts and swag. Hotel-type exaggerated pictures of our team and office. Meet the team page. Professional website like I mentioned earlier. FB, google maps, yellowpages, wherever we could get a free listing. Automated scheduling systems for client meetings, phone tree for calls, tons of previous work repurposed as marketing material for clients to see. Listing our bigger clients on our website. 800 phone #. All the hallmarks of a big successful business even though we weren't exactly gave clients a much bigger confidence in our abilities and enabled us to charge more.

6) Marketing toward high value targets-- we needed to get the ear of C level and VP's. Concentrating on the fact that we were a US company without outsourcing. Marketing to wealthy areas "doctorville" we called it. Targeted marketing to business corridors. We went deep, going as far as checking the AS of your IP address and whether any services were running on it. A surprising amount of the time would could link an IP back to a company, so we could quietly market to your company just from you visiting our site.

7) competitive research. Found our biggest local competitors. Quietly outbid them on all their ad keywords. Even more quietly made sure we had all the backlinks they did on search. Got a list of their clients one way or another, marketed directly to their clients already knowing their weaknesses from our clients who previously worked with those competitors. One competitor hosted their own servers, so I figured out who owned the IP and tracked ownership of the company through their email server. Another put their email address at the bottom of all public sites they wrote, a simple targeted google search returned all/most of their clients' sites. Another had a "client login" page setup on all of their sites that had a redirect to their main page. Searching for backlinks using SEO tools revealed most of these client sites.

Lots more. It took a lot of creative thinking and some failures :)

If you want to make your chosen platform fast you can see what they're doing in the src to get those results. The ones not marked "stripped" and with "full" for ORM are very realistic examples. Not sure where you're going with this? Nobody's real workload looks exactly like benchmarks.

Encapsulation isn't the "classic version" of OO. It's literally the main reason OO was created. Javascript fails to encapsulate because it doesn't support true private data members. There's patterns to achieve some sort of data safety (see http://speakingjs.com/es5/ch17.html#private_data_for_objects) but they all have disadvantages because it isn't built into the language, it's another hack.

Composition can be easily achieved using interfaces in most languages, another thing javascript doesn't support.

Excusing these faults to being dynamic language is like saying the model T is a nice car because "it was good for its time". Many languages before JS (including perl even) supported a more sound and convenient type system.

JS was badly designed in many ways and we are still paying the price for it today. ES6 and transpiling have made it finally worthwhile to try to develop anything significant using it which has led to the recent explosion of javascript development. I pray that EMCA continue to remedy what can be fixed in future and that Typescript catches on since it mows over much of the insanity.

Much more thorough than this toy benchmark article, which reads like marketing release...

It also prevents sound encapsulation of class local variables and methods, the main point of object oriented programming in the first place.

>However, it can also be argued that the drop in rates catalysed an economic recovery, without which there would be fewer jobs for the younger generation.

trickledown houseinomics?

JS has been object oriented since the beginning it just has an insane prototype based inheritance hierarchy that they're increasingly trying to hide/pave over.

Lets take fizzbuzz for example. These types of problems almost always require manipulating strings and dumping them to the console in the simplest scenario possible. Usually the main method or equivalent in a console program.

It would be easy as hell except they don't let you use google or an IDE, so you need to memorize the syntax for the main method and string manipulation.

1) In real life you almost never write directly to the console. 2) In real life, you never manipulate strings using sub-string or regex really... In fact the only time I do this a lot is for terrible reasons in bad code. 2) Main method? If your real life app even has one it was written by the first guy 10 years ago and is 3 lines long, just some function that looks like this:

  var app= new BootStrapMainApp();
  app.run();
  logger.log("App crashed if we get here");

Good luck creating a maven project archetype and getting it to work during a whiteboard session. I would choke so hard on a basic "make a console app to display these numbers". I don't even remember the calls to string split and console display in some of my favorite languages. Why? You'd be an idiot to use those over Log4net or whatever you use in real life.

You're asking a guy that might know how to design rockets how to put together a bicycle. A does not imply B in this case.

I've always thought whiteboard interviews were biased towards those straight out of school, since that's the only place you would write toy apps that use basal language features.

On the other hand, I've got a ton of my own libraries on my Github and some of them are pretty popular. It's abundantly clear that I wrote all of these since they're all published in official package managers with my private keys.

I see things from the other direction. An employer too lazy to check my github and verify my credentials probably sucks.