Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:WebSockets (Score 1) 233

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) 233

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) 233

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

by Kishin (#49570099) Attached to: How Security Companies Peddle Snake Oil

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

by Kishin (#49261719) Attached to: MIT Launches Three-pronged Effort To Thwart Cyber Attacks

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

by Kishin (#49197711) Attached to: Moxie Marlinspike: GPG Has Run Its Course

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

by Kishin (#49159075) Attached to: Moxie Marlinspike: GPG Has Run Its Course

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

by Kishin (#49148255) Attached to: Moxie Marlinspike: GPG Has Run Its Course

"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

by Kishin (#49148161) Attached to: Moxie Marlinspike: GPG Has Run Its Course
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

by Kishin (#49142259) Attached to: Moxie Marlinspike: GPG Has Run Its Course

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)

Comment: gpg is best option anti-NSA (Score 1) 309

by Kishin (#49142069) Attached to: Moxie Marlinspike: GPG Has Run Its Course

All good points if you're stopping run of the mill hackers or snoops. Some people are worried about Five Eyes, China, Russia, and other High Strength Attackers. Author misses that the only proven approach to surviving them are high assurance security engineering and/or obfuscation + diversity + battle-hardened software. There's no H.A. FOSS for this so gotta do the latter. GPG is specifically mentioned in leaked slides as a pain in the ass for NSA: true going back to Zimmerman's PGP. GPG also runs on many hardware architectures and buying old hardware (esp RISC) is a good way to dodge any subversion programs that are going on. So, the best route to high security email is GPG + FOSS OS + diverse, old hardware behind a guard for interface level protection and preventing them hitting the lowest (weak) layers of the old system. Easy to use, cheap, and pretty? No, but high security setups rarely* were.

This, with contractor developed implementations, is one of the ways the NSA's own black programs protect their information from their opponents. Same is true for Five Eye's. So, it has both stopped them and they rely on similar approaches. That's best endorsement an encryption product can get. That so few people use it has more correlations to NSA SIGINT effectiveness than GPG's. ;) So, per INFOSEC history's lessons, we let people develop (and PROVE!) better solutions that don't have GPG's problems. Meanwhile, we use GPG, improve its interface, and make solid workarounds to any issues with it that don't violate security arguments. Only new scheme I've seen with strong security properties is Tinfoil Chat. Everything else usually has a weak TCB allowing bypass or an unproven design/implementation they might covertly beat. I'll stick with what works until situation changes.

*Note: Capability, tagged, and language-based methods can be nearly identical to insecure product in functionality with better, easily-done security. They're the exception, though.

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

Comment: Re:PL/I on TIOBE (Score 1) 386

by Kishin (#48860513) Attached to: Is D an Underrated Programming Language?
PL/I is what many mainframe applications were written in. MULTIC's was written in a similar language because it prevented errors you see in others. IBM's mainframe OS IIRC was written in a runtime-less version called PL/S. They considered it a secret weapon for a combination of productivity, performance, safety, and safety/speed tradeoffs. There are two papers you can find with Google on it. Interesting part is how you can put identifiers in each function to control how compiler will transform it to machine code. That both allows and documents tradeoffs you make on a per module/function basis. Mainframes set the gold standard in reliability with often 30+ year uptimes so I think it's unwise to laugh at their design and implementation choices. Unlike my UNIX/Windows boxes, those PL/S and PL/I apps virtually never fail. Language design probably contributes a little bit. -Nick P

Comment: Re: Hmmm ... (Score 1) 234

by Kishin (#48709869) Attached to: NSA Says They Have VPNs In a 'Vulcan Death Grip'
Certain industry members are already doing it so you're wrong in the micro sense. In the macro sense, I totally agree and I've stayed out of the market specifically because of their power over U.S. citizens. I already know the parallel construction strategy they'd use against me. Good news is some people overseas have a chance of building something and I can at least teach people how to do it right in my various essays. More people learn from it every year although single digits lol.

Entropy requires no maintenance. -- Markoff Chaney

Working...