shortstuffsushi

For some reason, when I try to load the page, all the slides flash past, and I'm left with just the image of the author at the end.

Edit: On Mac Chrome 37.0.2062.124, for what that's worth.

You both raise fair points. I do think the community is typically construed that way, and it's probably accurate to say that a lot of the older Waterfall devs would be a part of that community (or C/C++).

Could you or the parent express what you dislike about backends written in Java? I think there tends to be a pretty negative stigma associated with it, but I haven't really seen why. Personally, I've worked with both C# .Net and Java backends, and it's really a horse a piece. Is performance the issue? Security? What is the general dislike of Java about?

I do use an Ad Blocker as well, I just installed Ghostery to better understand what it did (had heard the name, wasn't familiar with the product).

As a coder, I was actually shocked to realize just how bad it was when I tried Ghostery. Some pages load more than 10 scripts that are just trackers and analytics. Aside from the performance implications, the amount of data collected on your behalf, on each page, without any mention (implied consent, I spose), is pretty crazy.

Is this truly random? The first ten or so that I clicked through seemed to be HUGE open source projects like modernizer, cocoapods, less, etc. Not just random projects by random people. Did you hand select the list it chooses from? Not a bad thing if you did, I'm just curious.

Just out of curiosity, why did you fork it immediately? Did you find issues you wanted to fix, code you wanted to change, something else?

If you pick just those words, then yes, I'm only considering Coursera. If you take the comma into consideration, sure, you could even claim that I'm taking their best interest before their customers. It's a stretch, but if we want to pick apart words, sure.

Why would you never ask if it benefits Coursera? There are people who have an interest in them not failing, whether it be people making money, or people using the service. It seems you're only considering the people with money at stake. What about the people who rely on Coursera for the educational content?

I don't understand how Coursera being the one to come forward in any way deflects attention from their failings. It would literally be them bringing attention to the issue. Maybe I'm misunderstanding you here, but to me it seems that the company coming forward show not only responsibility, but maybe even some humility -- acknowledging their failure rather than trying to cover it up. And maybe you'll find that a bit of a stretch, but I'll try to give some credit for attempting at least.

That said, the message they did publish (see the current top comment on the post) doesn't really seem to do a great job of stating what actually happened, or what they're doing now, so it's not the best I've ever seen. It's also going to be 'too little, too late' in many people's eyes, as they now look like they're trying to backtrack to cover themselves after being exposed by the author of the article.

The "precluding others from acting" thing is what I've been trying to say this whole time. No, his findings, and being told that they are in the process of fixing it does NOT prevent him from publishing his findings (clearly, as he did). However, they made clear they were working on it (or at least enough so that he acknowledged they were), and it seems to me that he has now kind of cut their legs out from under them, exposing their failings while they were working on them and before they made the announcement themselves. It just seems tactless to me, regardless of who it benefits. I don't mean this as "oh, poor Coursera, they've been made fool of on the internet" or anything like that, it just kind of rubs me the wrong way. Take that for what you will, clearly you don't feel the same way.

Regarding the less tech savvy, you've got it backwards. I in no way mean that we should be less concerned for less savvy users -- just the opposite. If we're going to expose a vulnerability that affects them, we should go out of our way to defend them (or, the responsible party should). The author of this article does not do this, and consequently leaves them exposed without any opportunity for remediation.

I really think you're misunderstanding me. I think Coursera should have all the blame, and I think they should be the ones responsible for coming forward with their problems, what they're doing about it, and what their users can do about it. If they had failed to do so, then yes, absolutely someone should come forward and warn the public. That wasn't the situation here -- when contacted, they immediately began working to fix the problems.

The only thing they didn't do was immediately announce to everyone that there may be security flaws. Should they have? Perhaps, but then at that point, they're making themselves a target until they complete their fixes. Announcing the problem after the fix seems a pretty standard procedure to me. So again, to make clear and alleviate any remaining doubts you have, yes, Coursera screwed up. I think everyone knows this by now. They've also gone through the steps they needed to take to fix the problems now (as far as we know). I still don't think it was responsible for the author of the article to release this before they had completed those fixes, though.

Hey, you've got other interests aside from coding, don't you? Some people like to bike, some like to play games, some like to study law. Some like to do all three ;)

I'm not really sure how you infer the first line there. I'm in no way defending Coursera -- clearly they need to run their services through some better security checks.

I still generally disagree with your second point -- informing users of a security breach/flaw could (and should, even now after this article was published) be done by Coursera. In this situation, they should be the ones who come forward to their users and A. describe what the issues at hand are and B. describe how to avoid falling victim to them. The author of this article doesn't provide any suggestions for the non-tech-savvy.

Regarding users not signing up, perhaps you're right. It does prevent them from potentially losing their private information. In all likelihood, though, users who don't sign up after reading this article will never sign up. Yes, I realize this primarily hurts Coursera, so in this case, my concern is for them. It also means that potential users miss out on whatever they might gain from the site. A better option that Coursera itself might offer is a temporary "hey, we aren't accepting new users right now -- check back in a week" or something.

And again, I do not believe Coursera should just forgiven for something like this. As I mentioned, I've never been on the site, probably never would, and now am even less likely to do so, as I have no faith in them. I still don't believe that publishing open security holes is the right solution, unless they specifically said something along the lines of "yeah, we're not gonna fix that."

It may or may not have. These holes have been present presumably since the launch of these APIs. However, the author has now made public specific vectors of attack. You may be right that hackers have already been aware of them. In either case, does making these publicly known benefit Coursera, or its users in any way? I can't think of how it could possibly help, but I can certainly see how it might hurt -- anyone who comes across that page now might feel the urge to further 'explore' these findings.

That would presumably solve this issue. Perhaps that is what they will end up doing -- hard to say since they haven't addressed this issue yet. The author was guessing at solutions that might help (though, as you've noted, he was mostly off base).

Well, yes and no. Ultimately yes -- Coursera should have been more diligent about considering the implications of their API endpoints.

On the other hand, telling the whole internet before they've addressed the items he told them about, and potentially opening them up to more scrutiny (likely less white-hat like) is not an especially helpful thing to do.

That seems like a pretty extreme response. I know most apps only get one chance to fail before people uninstall them, but giving up on the whole app seems a bit much. It's new technology, and not trivial either. Why not give them a little more chance to improve before entirely shooting it down?

Yeah, it would be cool to see. As I mentioned in the readme, it's not necessarily indicative of anything -- if someone started a new iOS project, 95% of their code ownership would be of template/project setup code, so it'd be hard for anyone else to see how much they've actually contributed. That's why I added filters, though.

While this is something that may be possible for you, I think what the parent is saying is that most people lack not only the desire and willingness to do their own research, but also the general knowledge of the topics to fully comprehend what it is they're reading.

While doctors do typically go to school for a more 'general' understanding of any given disease, they still have a great more background on the subject than the average person, which probably helps them differentiate (to an extent) between the signal and noise of any given research paper that someone researching may come across.

The same could very much be said about software. To a non-technical person, searching about 'why you should use Windows vs Mac' could be pretty fruitless. Sure, there's plenty of information available, and numbers can easily support one or the other, but do you actually know what those numbers represent?

Now, I'm not saying that patients shouldn't be able to see their records, nor that they shouldn't spend the time learning about any conditions they may have (though I won't claim that I have), but I don't think we should discredit the knowledge that your average doctor has about your health.

Distrust of your healthcare provider isn't exactly healthy either. And again, as to your last point, can you elaborate? I'm assuming your referencing something to do with depression and obesity, as you mentioned in your original comment, but you haven't really mentioned what it is they're failing at.

Neat. Looks like it outputs something similar to what I had started with this[0] project. I had the idea while sitting in a meeting one day, and played with it for an evening, and the morning after... Never really followed up and finished it yet, though.

[0] https://github.com/shortstuffsushi/WhatDidIDo

An interesting idea, but in what use case would you actually want this?

> The medical community currently has an abysmal record with treating chronic health problems.

Could you elaborate on this a bit more? What sort of 'chronic health problems' are you referring to, and what is it that the medical community is failing to provide (short of cures, presumably)?

Really? For me they are all aligned, with the exception of the REST row which isn't present in the basic level.

I agree that they aren't checked by default, you'd need to implement it (as the parent commenter seemed to be doing with their gradle plugin). Regarding the sums being sent over HTTP as well, seems that you'll need a checksum for your checksum. Ultimately, though, it just seems that it'd be best to avoid this while it's over HTTP.

That's interesting, doesn't Maven offer a checksum option to begin with? I feel like just the other day, someone was saying "who ever uses checksums anyway," but a package manager run over insecure methods seems like the perfect time to do so.

The Vatican in no way represents the average. They're about as far an outlier as you're gonna find. The parent comment mentioned specifically small churches with low budget/tech-phobia as well.

I don't think that the period panty product is actually what they're sending to Africa. They mentioned that "the purchase of a pair of THINX also buys seven washable pads for girls in Uganda."

I don't think the majority of startups are out to 'help the world,' though many are out to change/'disrupt' (even this one claims to be disrupting). I don't know that I find that such a bad thing, though. Many products try and fail to change what they see as a problem, but there's really no harm in that. They're just trying to help.

Wasn't there a post on here a couple months back indicating the EOL for Python 2.7? Maybe it was "we'll release through 2.7.10, and that's it."

Edit: Found it here - https://news.ycombinator.com/item?id=7581434. Release will continue at least through 2015, support through 2020.

Really? I think a lot of people find the opposite to be true about Javascript, in terms of source. Javascript allows for some fun magic, but that pretty quickly cuts into readability/debugability. Look at Bluebird -- works great, but not just a "I'll jump right in here and understand it" sort of module.

You're definitely right about the C# docs, though. I always feel totally lost looking through those, especially since I'm not much of a C# dev to begin with.

My comment implied that I was. I said it's not exclusively their fault, implying that it is partially their fault. In the case of reusing the same password between sites, the blame for reusing that password does lay with the victim. That's not to say that sites should be sending the password to them -- that's still a horrible idea. A site cannot prevent a user from reusing the same password, though.

I guess what I mean to say is that you need to play both sides of it. As a developer, you should be doing all you can to prevent anything from leaking user info. As a user, you should do anything you can to prevent leaks from one site affecting other parts of your internet identity. Isn't that the entire goal of the FAQ this guy is putting together?

I don't mean to exclusively blame the victim, but you can only go so far to protect a user if they won't protect themselves. I haven't read through the suggestions on the site, but it seems like this should be the primary -- as a user, you need to take care of your own safety and not rely on good development practices to protect you.

Does none of that responsibility lay with you for using the same password across all sites? What if, on the other side of the spectrum, their site was compromised, and your password was retrieved that way? You'd be vulnerable in the same way.

Do you know what Sass means? http://sass-lang.com/