Maybe reduced odds of submissions but your comment seems false in general. I post as nickpsecurity on HN. I started by taking on their top commenter, tptacek, in INFOSEC discussions where fanboys maxed out at -4 downvoting. I called bullshit on claims of Rust team, esp pcwalton the compiler guy, plenty of times. We're still civil as it's a great project/community but they get overzealous with claims.
Being from high assurance, anti-fads, anti-cloud... I'd be long gone if your HN claims were true. Instead, I mostly get upvotes with posts that have sound analysis esp with references. Sometimes kind emails to grateful for a different perspective.
So, no, your problem was probably from how you said it or backed it up. HN has biases & moderation but no censorship. Even Paul Graham took tons of shit on the inequality thing with all messages plain to read on front page. Feel free to come back and try a different style of dissent.
The old VAXen that DEC sold came with a measure called VAX Units of Performance (VUP's). You bought stuff with a certain amount of VUP's rather than raw performance specs. Now Amazon is selling some Amazon-specific measure of performance that benefits them more than us. More signs the cloud is just re-inventing the mainframes and minicomputers of old. Cheaper, faster, more flexible, and so on for sure. Same concepts, though, plus what it seems is the same bullshit.:)
Yeah. It's why I wrote the second paragraph. Takeup was too minimal to stay in high assurance. I post solutions for free online to encourage takeup. But the methods are there and there's a niche market served by companies like Argus Systems and INTEGRITY Global Security.
That was a good start. Colin Robbins and some others had nice write-ups about why it wasn't enough. NSA, etc had nothing to do with it far as I can tell. Essentially, it was a combination of usability, compatibility with commercial clients, and the fact that you run into infrastructure issues the second you operate outside a small, closed group. Plus, you need protection against incoming emails and attachments. So, their solution which is worth FOSS knocking off was (a) a proxy on client that seemlessly does crypto, (b) plugin on email client that makes it easy to use, (c) input validation on risky data types with preferable conversion to safer ones, and (d) a guard to enforce strong controls/checking on all email traffic. For extra assurance, add strong endpoint security, mandatory access controls for app containment, and tools such as Softbound + CETS to make the app itself safer. And definitely don't use Windows.:)
This makes things difficult for attackers trying to read or forge communications. Among other things. PGP by itself was never sufficient, though, due to issues outside its control. The GPG code can support these efforts, though.
These attacks would be stopped by a combination of strong endpoint security, a guard protecting transfers, and mail guard + secure comms scheme so people know who's talking to who. These are all fielded as early as the 80's for military and some commercial use. Nexor is an example of a company selling the communications part. Argus, Tresys, Sirrix, LynxSecure, Dell Secure Consolidated Client, QubesOS... all examples of separating internal from risky stuff. Physical air gaps, KVM switches, separate networks, and guards (eg XTS-400, Genua's OpenBSD stuff) acting as gatekeepers are the strongest method. The important point is that anything mission critical happens in a way where external attackers can't see it or screw with it. Plus, validation of data flowing into network, diverse types of applications (eg non-standard PDF readers), secure messaging to spot forgery, and automated controls on transfers to detect unusual accounts or amounts.
Companies aren't going to do this, though. They'll keep using the other model: trying to do trusted computation on untrustworthy computers, using the networks the enemies can control, talking with untrustworthy protocols, secured by complex standards, and using centralized Internet ID systems possibly controlled by the enemy. Good luck. I'd do a consultation and help Ubiquiti deploy strong stuff but they'd never see people who can in Internet's noise. Too few left outside defense sector. Probably just got a traditional INFOSEC assessment, fixed a few things, made a checklist, and are hoping for the best. They'll get hit again if they don't fix the fundamental lack of trustworthiness in their infrastructure. True for 99% of companies.
I guess this means I'm sticking with Windows 7 on whatever good hardware supports it. The situation with Windows 8 and 10 is ridiculous. Microsoft knew what their *profitable* users wanted out of the platform. Windows 8 immediately resulted in a list of problems. They had old problems, as author noted, going way back. The best thing to do is keep what works, eliminate problems, add functions to make it easier to use, try some new things as OPTIONS, and continue to roll in profit from satisfied users. The Start Menu issue alone makes it look like Microsoft is intentionally trying to piss its users off. Meanwhile, Mac OS X and certain Linux distro's continue improving while remaining easy to use and (esp for Mac OS X) quite consistent.
Microsoft was known to copy anything better. They need to do that again for sane and consistent UI. Far as different devices, Apple's method worked so copy it: one product for desktops and one with touch-oriented UI for mobile/tablets. You can keep many of the dev tools, libraries, kernel functions, and so on the same to reduce duplication. They already do that for Xbox with even more coming now that it's x86. The problem is so friggin' simple to solve that it's amazing Microsoft hasn't figured it out, esp as it combines their two top qualities: leveraging what you already have to pinch pennies; copying successful stuff the competition does.
Very interesting that you do DO-254. My background was high assurance and I studied a lot of DO-178B stuff in the process. I didn't work in that market but it generated many high-quality components applicable to other areas. What they pulled off in terms of features amenable to assurance/certification also gave me a guess at what the next project with similar complexity would pull off. Also how I discovered SPARK and Astree.:)
My recent focus is on clean-slate, secure hardware with two aspects being ensuring hardware correctness and preventing subversion. I've come up with a lot of methods applicable to what HW people have taught me of their flows. Safety- and security-critical have considerable overlap in terms of verification from defect reduction to testing to traceability. I'd be very curious to hear of what flow you use for HW (esp ASIC) design in DO-254 space. I appreciate the memo as it's a good start on the subject and will help my own work. Still curious if there is a write-up by anyone on specific flow and what methods worked best on what problems past what's published on HW development in general.
Good work. Be sure to check out my comment below referencing a few things you might be interested in. You clearly know enough about this subject to assess their value. Any information is appreciated. Trying to get numerous opinions from HDL, synthesis, and bitstream mod crowds.
This is cool stuff. Here's some other stuff I found recently for anyone interested in messing with bitstreams, creating an open-source FPGA, or doing hardware more easily. Hardware designers feedback is appreciated.
Have fun people! Especially building on the first two. I'd appreciate experienced people telling me how good the Cx system is for (a) people doing FPGA with high-level synthesis tools and/or (b) beginners using behavioral verilog wanting something better.
I was a neutral party, too, who couldn't make sense of it. Most published evidence supported the claims of the feminists but strangely didn't mention much about the other side. Not objective at all. Least that was some kind of evidence. So, I challenged a bunch of pro-GamerGate people with that evidence and demanded they do more than troll or ask for us to take it on faith. One sent me this vid that shows feminist hypocrisy with evidence from her own game, points out these are entertainment products based on demand (which includes women!), and has other rational points supporting GamerGate's position:
https://www.youtube.com/watch?v=GXZY6D2hFdo&app=desktop
(Really makes the feminists opposing look like BS pushers esp as a commenter here pointed out Brianna also breaks their own rules in games.)
Another link I received was from the "Factual Feminist:"
https://www.youtube.com/watch?v=9MxqSwzFy5w
(She actually backed her claims with evidence that contradicts the claims of the feminists opposing gamergate. She also showed that their own studies cooked the books a bit.)
On top of it, out of millions of gamers, they've only got a relatively tiny number of people making threats. That means vast majority of gamers are *not* making threats. Yet, they talk like rape and death threats over right to abuse females is the only thing going on here. If anything, what I see here is a group of people (i.e. Brianna & co) calling out a whole segment of society (including women!) as evil, claiming to eliminate their market, making provably false statements, and being hated as a result. Who wouldn't have seen that response coming.... Ignoring the claims I see here like faking stuff, the basic analysis of anti-GamerGate's own claims and games *they* make show these women are deceitful, hypocritical pricks who deserve whatever *verbal* hate they get. It's called Internet Justice. Best to just not do the crime and especially against what's allegedly your own customers/demographic.
You have points on the 0-days being on the lower end compared to pervasive backdoors. Far as worst compromise, it's actually NSA compromising insane numbers of hosts using automated QUANTUM hits and drones via WiFi attacks. Much worse than manual stuff FBI does. That they continue to subvert things with little challenge is in their favor, as well. Far as crypto, NSA promoted strong algorithms while hiding all the ways their implementation could be busted (eg side channels). AES was actually more prone to these than some others. They also had the methods and tech to design nearly bulletproof stuff (eg Type 1, EAL6-7, TEMPEST). That they deliberately kept us in the dark and made those difficult to impossible to get weakened our security posture greatly across the board. They could've subsidized a few guards, VPN's, and endpoints to give us a chance but had other, devious ideas.
Anyway, your critique might be right on us *mostly* winning on the crypto side. Yet, they won in most other respects in being on top. I guess I need to change the claim to match that. Maybe the NSA's War on Security, starting when they killed the high assurance market (below). Crypto War would be battles within the greater framework. Main war still going on obviously. Recently being challenged by private parties and especially DARPA-funded research (eg crash-safe.org, CHERI). Gotta love DARPA: enemy's R&D organization will probably give us our best chances of defeating them.:)
"Bullshit. One of the most interesting things to come out of the Snowden revelations was the discovery that the NSA doesn't have any secret ways into properly done crypto -- Schneier even noted as much in his interview with Snowden."
I think you missed the whole point: NSA has been secretly beating many crypto you cite for years with a myriad of bypasses. They piled up attacks on applications, OS's, firmwares, and so on. They have it to the point that it's automated with QUANTUM. Linux's fragmentation gave non-mainstream distro's certain protection. I did that directly in previous work in what I called Security via Diversity. Academia has re-discovered that concept and regularly publishes it under banner "moving target." Yet, most people could've been smashed by NSA this entire time without realizing it.
So, after NSA *lost*, they waited for an opportunity. 9/11 provided it. Then, they started tapping the Tier 1 providers, intercepting whole datacenters worth of stuff, covert partnerships with U.S./foreign companies, coercive relationships with FBI support, infiltration of foreign companies/sites, weakening of crypto standards, insertion of 0-day's, deliberately leaving in 0-days, and buying up even more 0-days + attack kits for automated use. The combination of Snowden leaks and Equation Group report show they have utterly been dominating their opponents... without them even knowing... for over a decade.
In short, they went to war on everything (see BULLRUN) in secret, they won enough to create a "golden age of surveillance," and post-Snowden we're launching a new set of battle with new criteria to stop them. That's a... third... fight. Strange how security experts can say a quasi-military organization attacked, hacked, and subverted almost everything in wide use without saying they lost a war to them. They did loose. Many of us told them exactly what they were hitting pre-Snowden given it had to be anything in a system that ran code or could be reached by code (obvious eh?). We were told various things: too paranoid; that's impractical; nobody is reporting those hacks so they aren't happening; FBI & NSA are saying in public they can't do that. And on and on. They talked like they were safe on their FOSS & "secured" Windows boxes while they were getting stomped for years on end.
So, if anyone's calling bullshit, it's me on mainstream INFOSEC industry and security "experts" who didn't see this shit coming despite me outlining it nicely for years. My framework still exists (below) showing all the rigor it takes at every layer to stand a chance at beating them. Secure code or good crypto apps aren't enough. My framework is taken right out of the government's requirements for the ultra-secure systems (Type 1, EAL6/7) they use at most sensitive sites but won't let us have. Want to eliminate risk in your software and stick it to NSA? The opportunity is right there below waiting for your effort.
The sheer number of screwups and bad code in that library means the real advisory should be Avoid OpenSSL. Use LibreSSL instead. Its team knows how to write robust code and stripped out much of the worst stuff.
I keep saying we should call it the Third Crypto Wars because NSA + GHCQ already won the Second. They did that in a secret war on all systems and cryptography with aid from post-9/11 legislation. The Snowden leaks attest to what they accomplished. Most crypto out there doesn't deliver on its claims because they backdoored, weakened, or bypassed (endpoints) it. Now, from a position of dominance, NSA and FBI are launching a Third War on Crypto which is a mixture of public (see article) and secret (try to see TPP). This is an attempt to automatically achieve what they currently work hard for. We're not going to stand a chance of winning this third round if we don't acknowledge they already won the second. And did it without hardly anyone noticing pre-Snowden. That's how bad our current position is and why we need to fight that much harder for strong security across the whole stack.
Note: I've only seen a few strong constructions ever posted on Slashdot or most other IT news sites. *Those* kinds of things don't get popular. NSA etc love that. It's why the majority doesn't stand a chance whether using proprietary or FOSS. Rare exceptions to that.
So, how did you all like mine [1]? The goal was to show the danger of their double standard: they get ironclad security; we get backdoors. They argue that anonymity, encryption, and security can be the end of the country. I argue that, if true, then it's also a confession on their part.;)
Many countries are SIGINT partners with the NSA (see Fourteen Eye's etc). They share data. They almost all use vulnerable systems of the type the NSA can hit directly. Hence, data in Ireland isn't safe from the NSA by any means. It might also be used in mass collection that NSA gets to share. Der Spiegel has been reporting a lot of that sort of thing in Germany, for instance. The only well-connected, democracies listed in Snowden documents as resisting NSA cooperation were Iceland and Switzerland. Move your data there in partnership with citizens and in a way that benefits their cities. That should knock out the legal attacks. Then, you need EAL7+ security on all your systems with good supply chain and updates. Good luck with that part.;)
Nick P, High Assurance Security Engineer/Researcher
Nah, he was too busy working on hard problems (eg seemless distributed computing) so that others could implement them in production. Linus eventually followed his advice with a distributed VCS (git), although it's a nightmare to use compared to Andy's stuff. And Andy eventually applied his principles to build "a production kernel, maintained version compatibility, and evolved that kernel over time." I referenced Minix 3 in my original post you strawmanned. Despite only 2-3 people working for a year, it was already more reliable than Linux systems on the same hardware. Linus's approach produced systems so unreliable for so many years that I wouldn't even use them for production systems. When I did, I had to cluster them.
Gotta wonder what we'd be using if volunteers and corporations put a billion dollars worth of effort into microkernel, capability, or HLL (eg Oberon System) designs instead of Linux. The self-healing, process isolation by default, and easy extension properties alone would've been worth it. Linus and the mass market desired the opposite. So, we have unreliable, hard to maintain, insecure machines. NSA should thank them all.
He built a teaching OS, a cool ass distributed OS (Amoeba), a good WAN solution on top of it (Globe), and much later the self-healing UNIX-comcompatible Minix 3. That was all while he taught thousands of students how to build shit right. Andy is anything but lazy.
re Mac. Depended on the toolset. Certain 4GL's, GUI generators, and PGUI's targeted Windows + Mac (+ others). The portable scripting languages, like Tcl/Tk, had simpler interfaces but great portability. My route was first a custom generator that automatically generated the GUI side from a VB6 form's data and BASIC code I typed in. Later, with Flash taking off and my 3D interests, I redid my concept to target OpenGL: a standard graphic system that worked on both mainstream OS's and most high-end UNIX's too. If it had OpenGL, my tools could put a beautiful interface on it. Back when I had my tools... (sigh)
Note: programmers hated on me endlessly for using VB6 or a console BASIC at all. Yet, type safety, 1 s tool loading, 1 s compile-to-run, RAD GUI, and plugin for converting it to C++ GUI seemed like productivity heaven. Esp on a 200Mhz P2 w/ 64MB RAM. And my shit never crashed by the time I generated C++. Only imported, C++ libraries did lol.
re WebSockets. In theory, maybe. I'd have worried about the same legacy issue as you. It will certainly improve web app performance. Remember, too, that you have a whole browser to protect and manage. Single purpose applications using only specific files or API's can be protected with Mandatory Access Control, inline reference monitors, and whatever else you dream up. Browser is *never* that easy, as Chrome shows despite excellent architecture. Also, native apps let you use protocols such as UDT to eliminate overhead of HTTP and slowdowns/issues of TCP. Finally, if a browser was *absolutely* required, my compromise was putting a proxy in front of it that (a) spoke efficiently/securely to my server app and (b) trasnlated HTTP/HTML requests and responses to/from browser. I'll fake HTTP/TCP/IP rather than do real thing any chance I get.:)
AOL was once the largest site on the Internet. They were doing scalability before Microsoft invented the word. Under Michael Manos, they've been doing really innovative stuff like a lights-out, zero employee datacenter [1] and the recent micro-datacenter [2]. Their stuff is highly efficient, maintenance is scheduled in least costly way, and it mostly manages itself. Most of the "modern," "cutting-edge," "sophisticated" companies on Y Combinator's hiring page can't say the same about their infrastructure. Funniest part is that, despite all the case studies on highscalability.com etc, so many of them are still "trying to figure out" how they'll scale the exact same kind of apps. IT industry rarely learns from its successes or mistakes: keeps reinventing the wheel instead. AOL's old school approach just identifies the problem, applies a solution that works, invents one otherwise, and moves on to getting business done. The one thing to emulate, other than cool, datacenter design.:)
Funny thing is I did all my online gaming, hacking, file sharing, and so on with 28Kbps on 200Mhz P2 w/ 64MB RAM back in the day. Worked well for most things unless transferring "large" data. The "client-server" apps were better than Web 2.0 and used less bandwith. Most importantly, most people I knew always turned it off and disconnected it after use. Hackers had a narrow window to hit you, then only so much time to use your box. Plus, combined with good authentication, a point-to-point connection over dialup suffered *zero problems* that we see with businesses connecting over the Internet. That's true to this day: the very reason many use dial-up for remote access or leased lines for branch access.
This person probably just had "ain't broke, don't fix it" mentality with very limited use of the Internet. Lots of older people just do email, online news, and so on. Yet, as an alternative to leased lines, one of my modern schemes for robust remote access is a combination of broadband Internet and dial-up (or satellite). Most data is transmitted through the Internet via a VPN. Authentication, VPN configuration, highly sensitive data, and so on over dialup to highly secure system (all support serial ports). A link layer encryption suffices here. Plus, an efficient fall-back method for apps and comms to use dialup in case Internet is knocked out. Even with power out, dialup over POTS usually still keeps on working in this area. Dialup still kicks ass in 2015 for those wise enough to play to its strengths: low risk, high reliability, and *free long distance*. Elderly person forgot that last part.
- Nick P, Security Engineer/Researcher (high assurance)
Companies did that repeatedly. The Burroughs B5000 (1961) had bounds checks, pointer protection, and code/data separation. The System/38 and Intel 432 were capability secure from hardware up. There were type-safe platforms for high level languages such as LISP or Java. There were (are) highly secure systems designed under Orange Book B2/B3/A1 or Common Criteria EAL5-7. What do these have in common? People ignored them to buy PC's, DOS, Windows, UNIX, and so on. Intel and Siemens lost around a billion dollars building secure, maintainable stuff for the market. So, with the market trading away security for everything else, why should anyone spend several hundred million building a whole stack? That's why they peddle Win/UNIX/Lin-compatible bullshit instead of stuff that's secure, which has to be clean slate.
Nick P, High Assurance Security Engineer/Researcher
They're way behind other efforts. Anyone interested in this stuff look at crash-safe.org and Google Cambrige's CHERI processor project. CHERI already runs a port of FreeBSD. There's also numerous prototypes that put crypto in for confidentiality and integrity protection, some running Linux already. The recent Control Pointer Integrity work is pretty clever and was applied to FreeBSD userland.
Long story short, we already have a bunch of good solutions just waiting to be put into silicon and marketed. I'll be interested in seeing what MIT comes up with. Yet, BAE (with SAFE), Cambrige, and others have largely solved our main problems with usable prototypes. Gotta wonder why the best of INFOSEC research rarely makes press but organizations' promises do.
Time machine and backups are a good example of solving a usability problem. Thing is, much in INFOSEC or COMSEC needs a person in the loop to supply a secret or make a trust decision. GPG, for instance, forces you to think about keys because that's what you're trusting (not the person's name). Even if we simplify everything, the user still has to search for someone's name in a key database or click a link on their site. They might need to decrypt their private key. Then, they can see messages sent by that person automatically. Much simpler but still adds extra steps and time that people don't like.
Another example of the legacy problem is in more secure workstations. Every desktop OS is insecure. If you want security and desktop apps, the only known way to do it is a SKPP-style kernel separating them with a trusted piece of software for moving data between partitions. This is because security engineers can't control Windows or the apps. So, the user will have to tolerate loading up several VM's, switching between them for different types of work, and waiting for trusted apps to move (and check) data flowing through partitions. I can make the VM's start quick, have VM's pre-built, have drag n drop on domain transfers, and so on. Yet, simply hitting a key to change VM's or manually sharing a file between them is intolerable for most people.
So, you keep saying the INFOSEC people just need to build something that's secure and as easy to use as existing stuff. INFOSEC *has been doing that*. Especially in appliance market. Sidewinder firewall internally had SELinux-style protection while being easy to use. IBM's System/38 was easier to use, integrated core functions, and had security. Secure64 DNS is easier to use than many while defeating top red teams. There are many encryption products that are very simple and cheap. DefenseWall and Sandboxie both made HIPS *super* easy. In every case, the product is a tiny, minority player in the market where insecure options flourish. Lazy or lack of due diligence is my theory given the products are usable and affordable for their target markets. What's your theory?
"Messaging apps are driven purely by networks. If all your friends switched to Threema, you'd do it too."
"AND THE TRUTH... WILL SET YOU FREE" (Jim Carey, Liar Liar)
With that, you just totally contradicted your own position, supported mine implicitly on GPG, and supported mine for messaging apps in general. I argued GPG could improve to perfect usability and still would have no takeup. I said it's because users (1) use what other people use and (2) don't care about security. You agree on the network effect. For the other, what's one thing every famous messaging app or service had in common? No attempts at security for maximal convenience and cost-efficiency. People didn't care. Marketing departments aren't going to put massive work into security enhancements they see no demand for. Many companies tanked trying exactly that, with Intel losing over a billion on theirs.
It's the user's and market's fault: they always kill off secure systems regardless of usability.
Slashdot Mirror
Maybe reduced odds of submissions but your comment seems false in general. I post as nickpsecurity on HN. I started by taking on their top commenter, tptacek, in INFOSEC discussions where fanboys maxed out at -4 downvoting. I called bullshit on claims of Rust team, esp pcwalton the compiler guy, plenty of times. We're still civil as it's a great project/community but they get overzealous with claims. Being from high assurance, anti-fads, anti-cloud... I'd be long gone if your HN claims were true. Instead, I mostly get upvotes with posts that have sound analysis esp with references. Sometimes kind emails to grateful for a different perspective. So, no, your problem was probably from how you said it or backed it up. HN has biases & moderation but no censorship. Even Paul Graham took tons of shit on the inequality thing with all messages plain to read on front page. Feel free to come back and try a different style of dissent.
The old VAXen that DEC sold came with a measure called VAX Units of Performance (VUP's). You bought stuff with a certain amount of VUP's rather than raw performance specs. Now Amazon is selling some Amazon-specific measure of performance that benefits them more than us. More signs the cloud is just re-inventing the mainframes and minicomputers of old. Cheaper, faster, more flexible, and so on for sure. Same concepts, though, plus what it seems is the same bullshit. :)
Yeah. It's why I wrote the second paragraph. Takeup was too minimal to stay in high assurance. I post solutions for free online to encourage takeup. But the methods are there and there's a niche market served by companies like Argus Systems and INTEGRITY Global Security.
That was a good start. Colin Robbins and some others had nice write-ups about why it wasn't enough. NSA, etc had nothing to do with it far as I can tell. Essentially, it was a combination of usability, compatibility with commercial clients, and the fact that you run into infrastructure issues the second you operate outside a small, closed group. Plus, you need protection against incoming emails and attachments. So, their solution which is worth FOSS knocking off was (a) a proxy on client that seemlessly does crypto, (b) plugin on email client that makes it easy to use, (c) input validation on risky data types with preferable conversion to safer ones, and (d) a guard to enforce strong controls/checking on all email traffic. For extra assurance, add strong endpoint security, mandatory access controls for app containment, and tools such as Softbound + CETS to make the app itself safer. And definitely don't use Windows. :)
This makes things difficult for attackers trying to read or forge communications. Among other things. PGP by itself was never sufficient, though, due to issues outside its control. The GPG code can support these efforts, though.
These attacks would be stopped by a combination of strong endpoint security, a guard protecting transfers, and mail guard + secure comms scheme so people know who's talking to who. These are all fielded as early as the 80's for military and some commercial use. Nexor is an example of a company selling the communications part. Argus, Tresys, Sirrix, LynxSecure, Dell Secure Consolidated Client, QubesOS... all examples of separating internal from risky stuff. Physical air gaps, KVM switches, separate networks, and guards (eg XTS-400, Genua's OpenBSD stuff) acting as gatekeepers are the strongest method. The important point is that anything mission critical happens in a way where external attackers can't see it or screw with it. Plus, validation of data flowing into network, diverse types of applications (eg non-standard PDF readers), secure messaging to spot forgery, and automated controls on transfers to detect unusual accounts or amounts.
Companies aren't going to do this, though. They'll keep using the other model: trying to do trusted computation on untrustworthy computers, using the networks the enemies can control, talking with untrustworthy protocols, secured by complex standards, and using centralized Internet ID systems possibly controlled by the enemy. Good luck. I'd do a consultation and help Ubiquiti deploy strong stuff but they'd never see people who can in Internet's noise. Too few left outside defense sector. Probably just got a traditional INFOSEC assessment, fixed a few things, made a checklist, and are hoping for the best. They'll get hit again if they don't fix the fundamental lack of trustworthiness in their infrastructure. True for 99% of companies.
I guess this means I'm sticking with Windows 7 on whatever good hardware supports it. The situation with Windows 8 and 10 is ridiculous. Microsoft knew what their *profitable* users wanted out of the platform. Windows 8 immediately resulted in a list of problems. They had old problems, as author noted, going way back. The best thing to do is keep what works, eliminate problems, add functions to make it easier to use, try some new things as OPTIONS, and continue to roll in profit from satisfied users. The Start Menu issue alone makes it look like Microsoft is intentionally trying to piss its users off. Meanwhile, Mac OS X and certain Linux distro's continue improving while remaining easy to use and (esp for Mac OS X) quite consistent.
Microsoft was known to copy anything better. They need to do that again for sane and consistent UI. Far as different devices, Apple's method worked so copy it: one product for desktops and one with touch-oriented UI for mobile/tablets. You can keep many of the dev tools, libraries, kernel functions, and so on the same to reduce duplication. They already do that for Xbox with even more coming now that it's x86. The problem is so friggin' simple to solve that it's amazing Microsoft hasn't figured it out, esp as it combines their two top qualities: leveraging what you already have to pinch pennies; copying successful stuff the competition does.
Very interesting that you do DO-254. My background was high assurance and I studied a lot of DO-178B stuff in the process. I didn't work in that market but it generated many high-quality components applicable to other areas. What they pulled off in terms of features amenable to assurance/certification also gave me a guess at what the next project with similar complexity would pull off. Also how I discovered SPARK and Astree. :)
My recent focus is on clean-slate, secure hardware with two aspects being ensuring hardware correctness and preventing subversion. I've come up with a lot of methods applicable to what HW people have taught me of their flows. Safety- and security-critical have considerable overlap in terms of verification from defect reduction to testing to traceability. I'd be very curious to hear of what flow you use for HW (esp ASIC) design in DO-254 space. I appreciate the memo as it's a good start on the subject and will help my own work. Still curious if there is a write-up by anyone on specific flow and what methods worked best on what problems past what's published on HW development in general.
Good work. Be sure to check out my comment below referencing a few things you might be interested in. You clearly know enough about this subject to assess their value. Any information is appreciated. Trying to get numerous opinions from HDL, synthesis, and bitstream mod crowds.
This is cool stuff. Here's some other stuff I found recently for anyone interested in messing with bitstreams, creating an open-source FPGA, or doing hardware more easily. Hardware designers feedback is appreciated.
Open Source Bitstream Generation without R.E. or license violations: http://www.isi.edu/~nsteiner/p...
Archipelago - an open-source FPGA with toolflow support: http://www.eecs.berkeley.edu/P...
Cx, open-source, hardware & synthesis language: http://cx-lang.org/
QFlow Open-source Flow from behavioral synthesis to detail routing: http://opencircuitdesign.com/q...
Have fun people! Especially building on the first two. I'd appreciate experienced people telling me how good the Cx system is for (a) people doing FPGA with high-level synthesis tools and/or (b) beginners using behavioral verilog wanting something better.
I was a neutral party, too, who couldn't make sense of it. Most published evidence supported the claims of the feminists but strangely didn't mention much about the other side. Not objective at all. Least that was some kind of evidence. So, I challenged a bunch of pro-GamerGate people with that evidence and demanded they do more than troll or ask for us to take it on faith. One sent me this vid that shows feminist hypocrisy with evidence from her own game, points out these are entertainment products based on demand (which includes women!), and has other rational points supporting GamerGate's position:
https://www.youtube.com/watch?v=GXZY6D2hFdo&app=desktop
(Really makes the feminists opposing look like BS pushers esp as a commenter here pointed out Brianna also breaks their own rules in games.)
Another link I received was from the "Factual Feminist:"
https://www.youtube.com/watch?v=9MxqSwzFy5w
(She actually backed her claims with evidence that contradicts the claims of the feminists opposing gamergate. She also showed that their own studies cooked the books a bit.)
On top of it, out of millions of gamers, they've only got a relatively tiny number of people making threats. That means vast majority of gamers are *not* making threats. Yet, they talk like rape and death threats over right to abuse females is the only thing going on here. If anything, what I see here is a group of people (i.e. Brianna & co) calling out a whole segment of society (including women!) as evil, claiming to eliminate their market, making provably false statements, and being hated as a result. Who wouldn't have seen that response coming.... Ignoring the claims I see here like faking stuff, the basic analysis of anti-GamerGate's own claims and games *they* make show these women are deceitful, hypocritical pricks who deserve whatever *verbal* hate they get. It's called Internet Justice. Best to just not do the crime and especially against what's allegedly your own customers/demographic.
You have points on the 0-days being on the lower end compared to pervasive backdoors. Far as worst compromise, it's actually NSA compromising insane numbers of hosts using automated QUANTUM hits and drones via WiFi attacks. Much worse than manual stuff FBI does. That they continue to subvert things with little challenge is in their favor, as well. Far as crypto, NSA promoted strong algorithms while hiding all the ways their implementation could be busted (eg side channels). AES was actually more prone to these than some others. They also had the methods and tech to design nearly bulletproof stuff (eg Type 1, EAL6-7, TEMPEST). That they deliberately kept us in the dark and made those difficult to impossible to get weakened our security posture greatly across the board. They could've subsidized a few guards, VPN's, and endpoints to give us a chance but had other, devious ideas.
Anyway, your critique might be right on us *mostly* winning on the crypto side. Yet, they won in most other respects in being on top. I guess I need to change the claim to match that. Maybe the NSA's War on Security, starting when they killed the high assurance market (below). Crypto War would be battles within the greater framework. Main war still going on obviously. Recently being challenged by private parties and especially DARPA-funded research (eg crash-safe.org, CHERI). Gotta love DARPA: enemy's R&D organization will probably give us our best chances of defeating them. :)
http://lukemuehlhauser.com/wp-content/uploads/Bell-Looking-Back-Addendum.pdf
"Bullshit. One of the most interesting things to come out of the Snowden revelations was the discovery that the NSA doesn't have any secret ways into properly done crypto -- Schneier even noted as much in his interview with Snowden."
I think you missed the whole point: NSA has been secretly beating many crypto you cite for years with a myriad of bypasses. They piled up attacks on applications, OS's, firmwares, and so on. They have it to the point that it's automated with QUANTUM. Linux's fragmentation gave non-mainstream distro's certain protection. I did that directly in previous work in what I called Security via Diversity. Academia has re-discovered that concept and regularly publishes it under banner "moving target." Yet, most people could've been smashed by NSA this entire time without realizing it.
So, after NSA *lost*, they waited for an opportunity. 9/11 provided it. Then, they started tapping the Tier 1 providers, intercepting whole datacenters worth of stuff, covert partnerships with U.S./foreign companies, coercive relationships with FBI support, infiltration of foreign companies/sites, weakening of crypto standards, insertion of 0-day's, deliberately leaving in 0-days, and buying up even more 0-days + attack kits for automated use. The combination of Snowden leaks and Equation Group report show they have utterly been dominating their opponents... without them even knowing... for over a decade.
In short, they went to war on everything (see BULLRUN) in secret, they won enough to create a "golden age of surveillance," and post-Snowden we're launching a new set of battle with new criteria to stop them. That's a... third... fight. Strange how security experts can say a quasi-military organization attacked, hacked, and subverted almost everything in wide use without saying they lost a war to them. They did loose. Many of us told them exactly what they were hitting pre-Snowden given it had to be anything in a system that ran code or could be reached by code (obvious eh?). We were told various things: too paranoid; that's impractical; nobody is reporting those hacks so they aren't happening; FBI & NSA are saying in public they can't do that. And on and on. They talked like they were safe on their FOSS & "secured" Windows boxes while they were getting stomped for years on end.
So, if anyone's calling bullshit, it's me on mainstream INFOSEC industry and security "experts" who didn't see this shit coming despite me outlining it nicely for years. My framework still exists (below) showing all the rigor it takes at every layer to stand a chance at beating them. Secure code or good crypto apps aren't enough. My framework is taken right out of the government's requirements for the ultra-secure systems (Type 1, EAL6/7) they use at most sensitive sites but won't let us have. Want to eliminate risk in your software and stick it to NSA? The opportunity is right there below waiting for your effort.
http://pastebin.com/y3PufJ0V
The sheer number of screwups and bad code in that library means the real advisory should be Avoid OpenSSL. Use LibreSSL instead. Its team knows how to write robust code and stripped out much of the worst stuff.
I keep saying we should call it the Third Crypto Wars because NSA + GHCQ already won the Second. They did that in a secret war on all systems and cryptography with aid from post-9/11 legislation. The Snowden leaks attest to what they accomplished. Most crypto out there doesn't deliver on its claims because they backdoored, weakened, or bypassed (endpoints) it. Now, from a position of dominance, NSA and FBI are launching a Third War on Crypto which is a mixture of public (see article) and secret (try to see TPP). This is an attempt to automatically achieve what they currently work hard for. We're not going to stand a chance of winning this third round if we don't acknowledge they already won the second. And did it without hardly anyone noticing pre-Snowden. That's how bad our current position is and why we need to fight that much harder for strong security across the whole stack.
Note: I've only seen a few strong constructions ever posted on Slashdot or most other IT news sites. *Those* kinds of things don't get popular. NSA etc love that. It's why the majority doesn't stand a chance whether using proprietary or FOSS. Rare exceptions to that.
Nick P
Lol. It seems we entertained each other.
So, how did you all like mine [1]? The goal was to show the danger of their double standard: they get ironclad security; we get backdoors. They argue that anonymity, encryption, and security can be the end of the country. I argue that, if true, then it's also a confession on their part. ;)
[1] https://www.schneier.com/blog/...
Many countries are SIGINT partners with the NSA (see Fourteen Eye's etc). They share data. They almost all use vulnerable systems of the type the NSA can hit directly. Hence, data in Ireland isn't safe from the NSA by any means. It might also be used in mass collection that NSA gets to share. Der Spiegel has been reporting a lot of that sort of thing in Germany, for instance. The only well-connected, democracies listed in Snowden documents as resisting NSA cooperation were Iceland and Switzerland. Move your data there in partnership with citizens and in a way that benefits their cities. That should knock out the legal attacks. Then, you need EAL7+ security on all your systems with good supply chain and updates. Good luck with that part. ;)
Nick P, High Assurance Security Engineer/Researcher
Nah, he was too busy working on hard problems (eg seemless distributed computing) so that others could implement them in production. Linus eventually followed his advice with a distributed VCS (git), although it's a nightmare to use compared to Andy's stuff. And Andy eventually applied his principles to build "a production kernel, maintained version compatibility, and evolved that kernel over time." I referenced Minix 3 in my original post you strawmanned. Despite only 2-3 people working for a year, it was already more reliable than Linux systems on the same hardware. Linus's approach produced systems so unreliable for so many years that I wouldn't even use them for production systems. When I did, I had to cluster them.
Gotta wonder what we'd be using if volunteers and corporations put a billion dollars worth of effort into microkernel, capability, or HLL (eg Oberon System) designs instead of Linux. The self-healing, process isolation by default, and easy extension properties alone would've been worth it. Linus and the mass market desired the opposite. So, we have unreliable, hard to maintain, insecure machines. NSA should thank them all.
He built a teaching OS, a cool ass distributed OS (Amoeba), a good WAN solution on top of it (Globe), and much later the self-healing UNIX-comcompatible Minix 3. That was all while he taught thousands of students how to build shit right. Andy is anything but lazy.
re Mac. Depended on the toolset. Certain 4GL's, GUI generators, and PGUI's targeted Windows + Mac (+ others). The portable scripting languages, like Tcl/Tk, had simpler interfaces but great portability. My route was first a custom generator that automatically generated the GUI side from a VB6 form's data and BASIC code I typed in. Later, with Flash taking off and my 3D interests, I redid my concept to target OpenGL: a standard graphic system that worked on both mainstream OS's and most high-end UNIX's too. If it had OpenGL, my tools could put a beautiful interface on it. Back when I had my tools... (sigh)
Note: programmers hated on me endlessly for using VB6 or a console BASIC at all. Yet, type safety, 1 s tool loading, 1 s compile-to-run, RAD GUI, and plugin for converting it to C++ GUI seemed like productivity heaven. Esp on a 200Mhz P2 w/ 64MB RAM. And my shit never crashed by the time I generated C++. Only imported, C++ libraries did lol.
re WebSockets. In theory, maybe. I'd have worried about the same legacy issue as you. It will certainly improve web app performance. Remember, too, that you have a whole browser to protect and manage. Single purpose applications using only specific files or API's can be protected with Mandatory Access Control, inline reference monitors, and whatever else you dream up. Browser is *never* that easy, as Chrome shows despite excellent architecture. Also, native apps let you use protocols such as UDT to eliminate overhead of HTTP and slowdowns/issues of TCP. Finally, if a browser was *absolutely* required, my compromise was putting a proxy in front of it that (a) spoke efficiently/securely to my server app and (b) trasnlated HTTP/HTML requests and responses to/from browser. I'll fake HTTP/TCP/IP rather than do real thing any chance I get. :)
Nick P
AOL was once the largest site on the Internet. They were doing scalability before Microsoft invented the word. Under Michael Manos, they've been doing really innovative stuff like a lights-out, zero employee datacenter [1] and the recent micro-datacenter [2]. Their stuff is highly efficient, maintenance is scheduled in least costly way, and it mostly manages itself. Most of the "modern," "cutting-edge," "sophisticated" companies on Y Combinator's hiring page can't say the same about their infrastructure. Funniest part is that, despite all the case studies on highscalability.com etc, so many of them are still "trying to figure out" how they'll scale the exact same kind of apps. IT industry rarely learns from its successes or mistakes: keeps reinventing the wheel instead. AOL's old school approach just identifies the problem, applies a solution that works, invents one otherwise, and moves on to getting business done. The one thing to emulate, other than cool, datacenter design. :)
[1] https://loosebolts.wordpress.c...
[2] http://www.zdnet.com/article/a...!
Nick P, Security Engineer/Researcher
Funny thing is I did all my online gaming, hacking, file sharing, and so on with 28Kbps on 200Mhz P2 w/ 64MB RAM back in the day. Worked well for most things unless transferring "large" data. The "client-server" apps were better than Web 2.0 and used less bandwith. Most importantly, most people I knew always turned it off and disconnected it after use. Hackers had a narrow window to hit you, then only so much time to use your box. Plus, combined with good authentication, a point-to-point connection over dialup suffered *zero problems* that we see with businesses connecting over the Internet. That's true to this day: the very reason many use dial-up for remote access or leased lines for branch access.
This person probably just had "ain't broke, don't fix it" mentality with very limited use of the Internet. Lots of older people just do email, online news, and so on. Yet, as an alternative to leased lines, one of my modern schemes for robust remote access is a combination of broadband Internet and dial-up (or satellite). Most data is transmitted through the Internet via a VPN. Authentication, VPN configuration, highly sensitive data, and so on over dialup to highly secure system (all support serial ports). A link layer encryption suffices here. Plus, an efficient fall-back method for apps and comms to use dialup in case Internet is knocked out. Even with power out, dialup over POTS usually still keeps on working in this area. Dialup still kicks ass in 2015 for those wise enough to play to its strengths: low risk, high reliability, and *free long distance*. Elderly person forgot that last part.
- Nick P, Security Engineer/Researcher (high assurance)
Companies did that repeatedly. The Burroughs B5000 (1961) had bounds checks, pointer protection, and code/data separation. The System/38 and Intel 432 were capability secure from hardware up. There were type-safe platforms for high level languages such as LISP or Java. There were (are) highly secure systems designed under Orange Book B2/B3/A1 or Common Criteria EAL5-7. What do these have in common? People ignored them to buy PC's, DOS, Windows, UNIX, and so on. Intel and Siemens lost around a billion dollars building secure, maintainable stuff for the market. So, with the market trading away security for everything else, why should anyone spend several hundred million building a whole stack? That's why they peddle Win/UNIX/Lin-compatible bullshit instead of stuff that's secure, which has to be clean slate.
Nick P, High Assurance Security Engineer/Researcher
They're way behind other efforts. Anyone interested in this stuff look at crash-safe.org and Google Cambrige's CHERI processor project. CHERI already runs a port of FreeBSD. There's also numerous prototypes that put crypto in for confidentiality and integrity protection, some running Linux already. The recent Control Pointer Integrity work is pretty clever and was applied to FreeBSD userland.
Long story short, we already have a bunch of good solutions just waiting to be put into silicon and marketed. I'll be interested in seeing what MIT comes up with. Yet, BAE (with SAFE), Cambrige, and others have largely solved our main problems with usable prototypes. Gotta wonder why the best of INFOSEC research rarely makes press but organizations' promises do.
Nick P.
Time machine and backups are a good example of solving a usability problem. Thing is, much in INFOSEC or COMSEC needs a person in the loop to supply a secret or make a trust decision. GPG, for instance, forces you to think about keys because that's what you're trusting (not the person's name). Even if we simplify everything, the user still has to search for someone's name in a key database or click a link on their site. They might need to decrypt their private key. Then, they can see messages sent by that person automatically. Much simpler but still adds extra steps and time that people don't like.
Another example of the legacy problem is in more secure workstations. Every desktop OS is insecure. If you want security and desktop apps, the only known way to do it is a SKPP-style kernel separating them with a trusted piece of software for moving data between partitions. This is because security engineers can't control Windows or the apps. So, the user will have to tolerate loading up several VM's, switching between them for different types of work, and waiting for trusted apps to move (and check) data flowing through partitions. I can make the VM's start quick, have VM's pre-built, have drag n drop on domain transfers, and so on. Yet, simply hitting a key to change VM's or manually sharing a file between them is intolerable for most people.
So, you keep saying the INFOSEC people just need to build something that's secure and as easy to use as existing stuff. INFOSEC *has been doing that*. Especially in appliance market. Sidewinder firewall internally had SELinux-style protection while being easy to use. IBM's System/38 was easier to use, integrated core functions, and had security. Secure64 DNS is easier to use than many while defeating top red teams. There are many encryption products that are very simple and cheap. DefenseWall and Sandboxie both made HIPS *super* easy. In every case, the product is a tiny, minority player in the market where insecure options flourish. Lazy or lack of due diligence is my theory given the products are usable and affordable for their target markets. What's your theory?
"Messaging apps are driven purely by networks. If all your friends switched to Threema, you'd do it too."
"AND THE TRUTH... WILL SET YOU FREE" (Jim Carey, Liar Liar)
With that, you just totally contradicted your own position, supported mine implicitly on GPG, and supported mine for messaging apps in general. I argued GPG could improve to perfect usability and still would have no takeup. I said it's because users (1) use what other people use and (2) don't care about security. You agree on the network effect. For the other, what's one thing every famous messaging app or service had in common? No attempts at security for maximal convenience and cost-efficiency. People didn't care. Marketing departments aren't going to put massive work into security enhancements they see no demand for. Many companies tanked trying exactly that, with Intel losing over a billion on theirs. It's the user's and market's fault: they always kill off secure systems regardless of usability.