adricnet

Bokken is great but I only really use it on REMnux because it's difficult to install due to dependencies and relation to other products there.

This brief writeup from Puppet Labs seems to answer most of the questions I had about the nature and usefulness of the technology released.

https://puppetlabs.com/blog/nsa-release-system-integrity-man...

Ah, the document at that link is

a) labelled confidential and

b) scanned and OCR'd with some problems visible on the first page.

If this is officially public I would like to read it, please provide a legible copy. If this a leaked document than I can't use it and don't particularly want to read it.

Motive: I write this sort of thing from time to time and I would not enjoy seeing it leaked and discussed.

Thousands of mobile app developers feel this pain now, from that particular library.

Not updating these applications is not acceptable to most organizations / device operators.

Just in case anyone thought the parent was sarcasm or theory, some refs:

http://www.digitaltrends.com/mobile/heartbleed-bug-apps-affe...

http://blog.trendmicro.com/trendlabs-security-intelligence/b...

This is actually sometimes the case, though please double-check your analyses before committing to outliers or "betting the farm". Since it does happen and can work for some people / some places it certainly complicates the simplified dichotomy presented in the OP and this topic.

Chromebooks are not fragile by laptop standards, but are nothing like XO.

You could try out one of these with a Bluetooth keyboard? They are somewhat sturdier than other tablets and have some OLPC-inspired software, plus whatever else for Android you can find. There are other Android kid-targeted tablets around, but they are all more expensive, afaik.

http://xotablet.com/

Wow. I did volunteer some with OLPC early on, but no to all of that.

I'm talking about the water proof, sandproof, nearly indestructible laptop with the always viewable screen over there on my shelf with awesome user serviceability that "retailed" to me for less than $200 USD. By comparison my modern Chromebook (via CodeStarter), similar street price today as XO-1 then, has a much nicer processor, raw specs but can be easily killed by cat, coffee, or child and is useless outside (screen vs sun) or more than 1 day from a power tap (batteries) and is almost unrepairable by users. I like it but it's not the same kind of thing at all, and it's out-of-the box Linux is much less hackable and educational ... hence CodeStarter.

There's plenty of discussion around about the software stack (Sugar), the newer hardware (XO > 1), and no end of people discussing the organizations in Boston, Florida and elsewhere all over the Internet if that's what you were looking for ... but that really has nothing to do with what I said.

I agree that was worth reading, but it seemed a touch harsh. There seems to be some disconnect between review objectives of 'is this a great product with growth potential' versus 'is this perfect for everyone' ... but maybe I just did not like the author's comparisons to toys as negative descriptors.

Fairness: I backed Pebble twice on KS, am wearing one, waiting for my new Time to arrive, and still marvel at the OLPC XO-1, also derided as a toy but one of the most amazing computers ever built. I like viewable screens :)

I backed the Kickstarter. Looks like a really neat device with interesting capabilities and Debian :)

https://www.kickstarter.com/projects/1598272670/chip-the-wor...

This is a really interesting argument you've advanced. The chart you describe is illustrative and the changes wrought on it certainly disturbing.

Unfortunately, I think you have over-simplified a complex issue to a dichotomy (encrypt everything or nothing) that is perhaps more confusing than helpful.

Encryption is a broad and diverse subject, as well as a field of expertise (not mine). I doubt parties in the debate have axioms that align here as there are so many interpretations and levels of detail to disagree about. Put more clearly I don't think any three people reading this would agree on what you mean by encryption in your post.

If you instead said "protect" "everything" / all traffic / all data/ all browsing /... , and gave some details as to the threats you are concerned about, it might strengthen the argument you are making.

EG : "protect" the "names of sites I visit" from sousveillance ... "protect" the "integrity of software packages I download" from "evilgrade" attacks ... protect "the pseudo-anonymity" of "journalists posting to social networks" from "state sponsored malware injection" ... and so on. Encryption techniques could be (are) used against all of these problems, but in different ways.

There is a lot to discuss and try to understand in these issues. Thank you for contributing positively to the discussion ( and I hope I am as well).

Thank you for posting and discussing on HN. More discussion and more viewpoints can only help as we all struggle with these political and technical issues.

You trust wires?

To me this sounds like the debate over WEP. I think it is still not commonly understood how secure wires are. I think that the WEP protocol and successors do a good job of fulfilling the desire for "wired equivalent privacy", but many people expect something very different from encrypting wireless networks ... and I find the arguments for HTTPS everywhere to have similar gaps.

And who said anything about perfect? :D I'm just trying to do what I can to cut away at the Fog of War, plus maybe save IT and NetEng a great deal of work.

Side stepping your first point, apologies. The requirements of an individual organization are not something we can always change.

There are other technologies to detect and resist injection in communications beside encrypting the whole network, aren't there? Maybe you just need nice HMACs and good crypto of that for that feature. Would that make more sense in your applications? would you trust that more than relying on the OS, or the routers to protect your application / verify the communication source?

Thanks for responding and fiercely debating, cheers!

I'm not making a broad recommendation, expect maybe to slow down a bit :)

It sounds like you have lots of usecases for applications that need protection against injection , MITM, or eavesdropping. It's great that you understand that. Those sites and apps need that protection, and the network protocols are one place to look for it.

Also, there is a huge difference between "all web software should support encryption" and "turn all of that on by default". I just want a broader discussion of the costs and more discussion about the problems people are trying to solve.

Thanks!

Not saying anything really about EFF's efforts or publication, however the topic is common now ... Please don't senselessly "encrypt all the things".

May I encourage some requirements gathering and threat modelling? Who are you trying to keep out (in?) of your application communications? Why?

The unfortunate requirement of common business systems is that we need visibility into what these systems are doing for troubleshooting, audit, and incident detection. Logs are good, but packets and flows are better. Trust, but verify.

Driving to encrypt all traffic, all the time may be a noble goal^1, but please understand that there are good people who need to adapt requirements to their organizations and projects. This is one of the points, along with firewall policies, user privileges, useful remote logging, and ... well, have a look at the CC20[1] for more.

http://www.sans.org/critical-security-controls

^1 though doing it effectively may be much more difficult and expensive than you imagine.

HackerOne manages bug bounty campaigns / community vulnerability research for orgs and companies. This campaign is sponsored by FaceBook and Microsoft, according to this page: https://hackerone.com/internet-bug-bounty .

Well, I put in for two and I imagine some others did as well.

hth, adric

Objection: argumentative.

And yes, if the claim didn't match with my observations I would expect that they have or be prepared to provide proof in some reaonable form. "Extraordinary claims .." and all that.

That's certainly an interesting read... and one I can't really argue with the anecdata of from my own experiences. So I'll add one:

After it was too late by that author's reckoning, the parent of Radio Shack tried another venture, a "big box" store called The Incredible Universe. When that failed and they wrote it off, it wiped out the entire profit of Radio Shack thousands of stores for that financial year.

I still think of it when I'm trying to understand the machinations of large companies.

And I, too hope that the folks I worked with at RS in the 20C found better jobs, especially the poor store managers.

Well, as big a fan of the BLO[1] as I am, I think your energy might be better spent elsewhere.

Lamilly[2] was successfully crowdfunded, manufactured, and is shipping soon. She's already a world traveler and will surely have more career options than Barbara soon.

http://www.rtmark.com/blo.html

https://lammily.com/

Random's tutorials are very good, though at the moment I'm making more headway with Lena's (linked above on tuts4you). This is probably because I'm still new to assembly language and Olly/idb.

The canonical intro book I recommend is Practical Malware Analysis (No Starch), with their debugging and IDA books as supplements :) http://www.nostarch.com/malware

I don't understand the niche for this product, especially against their own Fire TV (which FD I have and like a fair bit).

From the catalog page details, besides the portability of the stick model (use USB with some TVs so no need for AC power) it seems there are some games that will not play on the stick. That seems a bit crunchy and weird for customers and developers.

Any one see or know any other differentiators that make this worth an additional SKU, support costs?

Thanks for sharing. This echoes some of my thoughts before some recent changes I made and is a good read for everyone to provoke some thinking about goals, work/life balance, and of course, money.

Well, I understand your reaction, but it may help to point our that there are three different algorithms involved here and that to ensure content completeness and ensure security concerns (CIA, NR, etc) you want them all, and all done correctly:

  *  Checksums, like in Xmodem or CRC
  *  Cryptographic hashes (including MACs)
  *  Cryptographic signatures (ie OpenPGP key or cert)

As noted in the other comments these protect against different kinds of problems in transmission, but in used correctly in combination can protect from both glitches and active attacks.

To say that it is difficult to implement all of these correctly and in concert is a grave understatement, but this is what modern crypto software and network protocols that use it, have to do.

Now back to the thread on HTTP header checksums :)

The are actively responding to a possible intrusion and are therefore not motivated to give away specific details of the attacker's techniques to either the attacker or other hostile parties.

The MD5's you want are specific to the kit used to attack their client and would disclose the effectiveness of their response and investigation to an attacker,and are also not much good to anyone else. In the Disqus comments the author offers to provide them on request from legitimate researchers.

This is a standard precaution, not at all bogus, and it is great that they were able to share as much as they did for general use.

Errors and Omissions insurance might help with this.

Surely everyone on HN already has an informed opinion on that topic but perhaps Wired's readers provoke further thinking and understanding in a larger group?

Perhaps someone could run a directory of these sites there is no point in using? Then we can all be happier.

Could we get a more accurate headline please? At least s/attack/dump/ ? There was no attack reported.

The Google blog post noted in a comment has much better information, it seems: http://googleonlinesecurity.blogspot.com/2014/09/cleaning-up...

I don't see an article or site title at the URL so hopefully suggestions are useful here.

Gizmodo's live blog here has been working well for me: http://live.gizmodo.com/our-new-iphone-liveblog-starts-right...