beryllium

This is awesome! Thanks for posting!

I started one of my hobby projects (http://gibsonindex.org/) because media and government organizations were handling cyberattack reporting/prosecution so poorly, but it quickly grew tiresome. So many hacks in 2014, the mind boggles.

This post definitely offers some solid insight into the perils of reporting these types of incidents, and it's written a whole lot better than my stuff could hope to be.

I might just have to turn my site into a site that lists guitars. :-)

See if there's one feature that you can target and polish better than their version. That can be your spearhead selling point.

Edit: Just editing to comment on how full of "derp" this comment is. Reading comprehension fail on the original post - sorry! :/

There are other ways to be different. Be friendlier (or edgier). Be more mobile. Be faster (see: Pinboard versus other bookmarking services). Be exclusive. Be more expensive.

...

The last one is a hard sell, obviously, but said sale is much more valuable.

There's something else that can do that:

Revenue.

But perhaps this is the wrong forum in which to point that out ;-)

I've worked on something for four years, then went to market it and saw that it had already existed for a decade.

But, of course, I already knew that I was not unique.

The reason I spent so much time on it is because I have a small but active community of users who like it very much. I am not confident I can monetize it (it's a chatboard service), so I may ditch my "chatboard as a service" plans, but I will continue to work on it.

Maybe I should forge ahead with the CaaS plan anyway, just to see if I can get any takers? A handful of paying customers would be better than none, after all.

"monetizing the platform" is probably the main reason it's always on. Heheh.

I don't need marijuana for any of those things. Lucky me?

The next big field is going to be Potatoes, son.

(But in all seriousness, the reason you see low-hanging-fruit being picked is because everyone is still trying to figure out how best to employ the internet - you're seeing microeconomies rising and falling at a rapid pace, innovation both thriving and being stifled - there's a lot of flux at the moment. When everything clicks into place, it's possible that everyone will need to be an entrepreneur in their own way.)

Yay for Victoria/Vancouver Island shout-out - but I'm not sure that this is true in all corners of the world ... And definitely invest in better pockets, sheesh! :)

Well, think of the games - typically they need raw and low-level access to hardware in order to optimize the framerate and gameplay experience.

But there are several technologies on the market right now that can actually deliver such experiences with the rendering done off-device (albeit with some extra latency).

This is an example of new technologies mitigating the drawbacks to building non-native/remote-processing apps.

No. Native apps won't die.

There seems to be an ebb and flow between "thin client" and "thick client" computing. Right now we're leaning heavily toward the "thin client" realm, with the emphasis on "Cloud this" and "Web that"; however, it's entirely possible that something will happen to bring that remote compute capacity back to the local device for the sake of efficiency.

And even now, there are reasons to compute locally in a native language instead of remotely via an abstraction. Some of those reasons (speed, primarily) are beginning to be mitigated by new technologies, but the reasons will likely always exist for why a native app can be a better solution than a thin client style implementation.

Probably what we'll see is an emphasis on APIs and intercommunication - this gives companies the power to do a lot of logic server-side, and just roll native apps for things that are difficult to do on the server. Implementations like Dropbox, Evernote, Wunderlist, and Netflix are good examples of this bridge between philosophies.

"I am Dialysis Man!"

  Has he lost his mind? 
  Can he see or is he blind? 
  Can he walk at all 
  Or if he moves will he fall?

I posted a note above that might help:

apc.enable=1 turns on Opcode caching (when php-apc is installed), and apc.stat=0 turns off "stat" checks - this means that once a file is opcode cached, PHP won't even have to touch the file on disk to execute it. The I/O gains from this, as well as the execution gains from not having to parse the file, should help quite a bit.

Yep, this is exactly what I was wondering. Opcode caching is a key part of production PHP environments - in this case, since the code isn't changing, they should even disable the "change check" (apc.stat=0) as one would do in a production environment.

And if this is the case with their configuration of PHP, it makes me wonder what other platforms are not configured for production in this benchmark :)

ssh -D8080 -L3389:southkoreanupdatedistributionserver.kr:3389 -lfakeuser suspiciouschineseserver.cn

Hey, instant proxy and remote desktop tunnel. I wonder what movies they have on Netflix China? I wonder what the weather's like in south korea?

(ahem Obviously I'm simplifying and failing badly at being funny ... although if you don't recognize those SSH flags, you should look them up. VERY useful.)

Maybe I'm unclear on the specifics, but it doesn't say what filesystem is used for the mounted striped volume. Could the choice of FS affect I/O?

Two potential points you could address:

1) The Use command can also perform aliasing, e.g. "use ExampleNamespace\subnamespace\foo as TruckNuts" allows you to alias the class to something else. This can help improve code readability. And you can to $foo = new TruckNuts();. (I'd recommend not using that exact word as the example :)

2) Many people have complained about the "ugliness" of PHP's namespaces. Maybe you could adjust the post to have a section comparing PHP Namespaces to those of other languages, and explaining why such notations would not have worked with PHP?

It's a bit absurd. A chilling effect, even; now, instead of responsible disclosure (which weev seemed to think meant scraping 100K examples of the data and giving it to a Gawker reporter), we'll be left with irresponsible disclosure (anonymously reporting it or selling it on the black market).

That said, I don't think AT&T would necessarily have reacted well to an attempt at real responsible disclosure.

For an example of the ideal scenario for how this should be handled, there's the Steam data leak that Ars Technica found: http://www.gibsonindex.org/blog/2013/02/06/steam-leak/ - I rated it as a Level Zero event on my cyber attack ranking blog, because of the proper resolution.

I agree that the blame in this case lies mostly with AT&T. It's their responsibility to protect the data. They build the program so that if anyone asked it for anyone else's info, it went "OK, sounds good, here you go."

Weev was the one who asked. AT&T should be on the hook for answering.

The charges in the indictment seem ludicrously disproportionate to the observed impact. I mean, giving away your workplace credentials is beyond stupid (and highly unprofessional), but I think it doesn't quite rise to "30 years in jail" as a valid punishment.

I would say that this is untrue. How much (or how little) people care about what you say is simply tied to what they've heard from you or about you in the past.

A framework project helps with this, because it presents a history of your work - but it only helps if other people are actually using the framework. That same history and reputation could be established by authoring a widely-used library, or by voluminous contribution/collaboration with open-source projects.

In some cases, even just imparting your knowledge can establish the positive reputation. This is where blogging and speaking at conferences (and unconferences/lightning talks, to start out with) can help.

I use NetNewsWire (an iOS app) every day, and it interfaces with Google Reader very nicely. Very sad that Google has made this decision - I will have to look into the alternatives. Hopefully they are even better! :)

Edit/Update: I'm probably part of the problem. I never click ads - maybe they just had too many freeloaders like me? :) Weirdly, I also never block ads. I just don't click them.

Checking it out - looks like your PHP lib doesn't explicitly declare CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER, so that could be vulnerable to peerjacking. If I have some free time tonight I might be able to submit a PR for it.

That's pretty neat - it seems to only cover one aspect of what makes something a "cyber attack", though. Doesn't appear to cover things like XSS, SQLi, and other malware vectors - just network vulnerability probes and break-in attempts. Not that that's a bad thing, the information presented is still quite fascinating. :)