Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment my plot (Score 2) 57

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/...

Comment NSA won't flinch (Score 1) 135

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

Comment Re: Cuz Minix Dude Was A Old Guy (Score 1) 469

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.

Comment Re:WebSockets (Score 1) 234

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

Comment Re: AOL exists and innovates (Score 1) 234

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

Comment still kicking! (Score 1) 234

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)

Comment secure platforms were attempted; market rejected (Score 1) 67

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

Comment they're behind (Score 1) 43

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.

Comment Re: the forces working against us (Score 1) 309

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.

Comment Re: the forces working against us (Score 1) 309

It's not a cop-out. How many people put off or refuse to do day-to-day responsibilities at home, preventative care for themself, maintenance on vehicle, checking on PC backups, and so on? Varies per person but happens a lot. People will also opt out of even an easy to use tool because of a single extra step. Web research shows a web site taking just a few seconds too long to load will cause a huge chunk of business. Such things show that people's very nature is to take on risk rather than put forth effort. This can't be ignored in a security, usability discussion or design attempt. People will only protect themself if it takes *almost zero effort* and will otherwise let themselves be devoured by digital wolves.

Note: Zynga doesn't count because it's just a game that they *want* to play as an *escape from work* and other things. Security in day-to-day apps is something they *have* to do they usually see as *an obstacle* to fun. Totally different. Although, Zynga's psychological tricks might be copied.

The bigger effects, though, are legacy and networking. The legacy effect says the new thing must build on or integrate well with what's already invested in. Lead to all the COBOL, SAP, and Windows out there. Builiding security on something inherently so insecure without vendor participation puts a limit on both security and usability. We see something similar with Facebook's hold on people after they've put so many photos, comments, shares, etc into it that they don't know how to move. Both companies and individuals simply will not let go of a broken-by-design product to get even the most usable, secure-by-design products. This issue is unresolved and it's why I think the better stuff can only take hold for *new* deployments + niche that will give up bad stuff.

The networking effect is illustrated best by Facebook. They start as just a social media site. All kinds of people start using it. Now, people start using it because others are using it. Their API let's all kinds of third parties and services develop that people start using. A whole network and platform of people, apps, and so on. Problem 1: how do you get them adopt something similar if nobody they know is using it? Problem 2: how do you get the 3rd parties to build similar effort into your platform if nobody is using it? Problem 3 (for non-snooping): How can you do anything like this without the billions in ads that paid for Facebook and esp while solving 1 & 2?

So, in summary, human nature has always worked against even the best efforts. There are very usable apps out there right now for private communication, storage, etc. Threema, Silent Circle, SpiderOak, ZixMail/Hushmail, and so on. Apps do almost all the hard things for you inexpensively. Threema is only $1 more than WhatsApp. Pop quiz: how many people buy these over the insecure alternatives? Now you know how much the users care. ;)

Nick P

Comment Re:git blame (Score 1) 309

"Then make it not necessary to type in a password. Even I don't understand why I should type a password for every mail I send."

They did: you type a password once to unlock the private key and then you just send emails from there on. The password method is used because (a) people rarely buy dedicated, secure hardware, (b) it's easy to implement, (c) people are used to it, (d) the method works on all platforms, and (e) protecting it is easier in a more secure architecture (eg trusted path to isolated component). Security engineers repeatedly come up with password replacements that get almost no adoption. Top labs are *still* researching how to replace passwords while maintaining security.

"No, it's not. It might be technically the best tool, but if it's unusable, then in sum total, it's not. There are many factors that go into these equations, and we techies are sometimes blind to some of them."

That's true except all kinds of people have learned to use GPG. I Google'd how to use GPG, got a nice page listing common actions + commands, and simply typed that into my terminal. The people with GUI's, Thunderbird, etc had it even easier: dialogs for configuration or keyrings + press-button sending of secure mail. That's pretty damned easy to learn and use. It could certainly get better. Yet, I've taught the basics to all kinds of people. The real reason people rarely use it is pure laziness and/or mainstream uses other, insecure things.

Comment Re:git blame (Score 1) 309

Although I largely stand by my post, I agree with your comments too. The users won't buy anything I build that's close to being truly secure. They won't make necessary sacrifices, even spending $1 more (eg Threema vs WhatApp). What you said is true, though: developers and security engineers often ignore the users' perspective when designing the product. The few that pay attention achieve a lot more success in terms of market adoption. The good news is there's more stories and advice on so-called UX (user experience) popping up in places like CodeProject news where developers might see it. I think we need to go further by designing and promoting best practices for usability for common types of apps. Then, people not wanting to think about users can just checklist and refactor their prototypes. What you think?

Comment Re:git blame (Score 1) 309

Oh no, he's smart: almost every high assurance security offering ever marketed has been ignored by consumers. They *don't give a fuck*. Being the demand side of the equation, they're the reason [1] the suppliers are producing insecure garbage all the time. It's what they buy. Steven Lipner, who managed VAX High Assurance VMM, wrote about the what it taught management here [2]. Summary: users wanted the features more than security and would decide against any product developing features too slow (read: all high security systems). Many users also wanted lower costs (security adds costs) and integration with whatever garbage went mainstream. Intel tried three times [3] to do their part with i432 being a marvel of engineering and Itanium being used in a highly secure, affordable OS [4]. Intel's security-oriented efforts tanked to the tune of billions lost as market favored backward compatibility and price/performance instead.

So, users and market don't give a fuck. Only a niche segment does. Unless subsidized by grants or government contracts, high assurance systems are typically not built at all. All the secure stuff being built is grant-funded academia, defense-funded commercial, and/or high priced, patented I.P. for niche use (eg smartcard, embedded). Those of us left doing custom solutions pre-Snowden had very little business with most doing it on the side of better paying work. Post-Snowden, there's more demand, the demand is once again making insecure tradeoffs, false security abounds, and talent to do high assurance is still mostly nonexistent after market killed it off post-OrangeBook. On top of the millions using ad-driven services and tech that sells them out. Truly don't give a fuck and it ain't changing.

[1] https://www.schneier.com/blog/...

[2] http://blogs.microsoft.com/cyb...

[3] https://www.schneier.com/blog/...

[4] http://www.secure64.com/secure...

Nick P, Security Engineer/Researcher (High assurance focus)

Slashdot Top Deals

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...