Why you should let Google host jQuery for you - <AUTHOR> http://encosia.com/2008/12/10/3-reasons-why-you-should-let-google-host-jquery-for-you/

<comment><USER2> For folks interested in his #2 benefit (using multiple domains causes static assets to be loaded in parallel, speeding up observed speeding page load times) -- you can capture it without involving Google in the slightest. It requires a perhaps two-line tweak to your web server configuration files to make it answer requests on domains other than www.example.com

For example, my main domain is www.bingocardcreator.com . There are some honking images which load on the front page that used to block the (more valuable to my conversion pathway) images on the sidebar from popping up. I reconfigured my webserver to accept images1 through images4 as acceptable host names, and (lazily) manually split the static assets over the 5 hosts.

This actually resulted in improving the loading of my sidebar by upwards of a second. That is worth, oh, probably $100 a month or so. (If you do not know how I can possibly say this, you owe it to yourself to try CrazyEgg right now.)

Not bad for an hour's work that never has to get repeated.

Credit given where credit is due: I found this tip out through using Yahoo's YSlow plugin for Firefox, and following their "Best Practices for Speeding Up Your Website". This document is one of the best practical "Here, do this, it will make you money" sources I have ever found on the Internet.

<http://developer.yahoo.com/performance/rules.html>

<comment><USER3> This is a tip that I've also used to great effect, but I thought that I should point out (if it isn't obvious) that you must make sure the same image always points to the same subdomain (image 1 is always linked to images1.mysite.com) otherwise you'll shoot yourself in the foot by eliminating browser caching.

I usually write a quick function in $language to turn the first few letters of the filename into ASCII then modulus by the number of fake subdomains that I've set up to decide which server to link to. The overall distribution may be imperfect but file x will always be linked to server x across pages, so it's a nice quick solution, especially if you have multiple maintainers.

</comment></comment><comment><USER4> I've thought about this, but I decided against it for one simple reason: if google is down my site is in trouble. By serving it locally it's all or nothing, either your site works (because it's up), or it doesn't.

But if the site is up, but google is down it's will do really bad stuff.

Plus I don't really understand the multiple connections issue - what about HTTP/1.1 and keep alive? Doesn't it download everything all in one go, but only if it's all one server?

And finally about the caching issue - sure the first time might not be cached, but most sites rely on people visiting more than once, or at least clicking on more than one page, so it'll be cached the rest of the time after that.

So none of the arguments are really holding with me.

<comment><USER5> How often is Google down? Is it worth worrying about?

(questions are 80% rhetorical, 20% genuine curiosity)

<comment><USER4> Google doesn't usually go down, but routing issues or DNS problems mean that it does happen that they are unreachable.

<comment> tsetse-fly How often are there routing issues to Google, but none to your site? It's much more likely that your site will be unreachable. The probability that Google will be down is probably insignificant for most cases.

<comment><USER6> Last week I found an issue with routing internal to Yahoo's core network that was causing an esoteric DNS failure for our customers.

Routers are configured by people, and people make mistakes.

<comment><USER7> Yes, but what does that have to do with Google's reliability? What does it have to do with routing issues between one particular site and Google?

He's not claiming that Google is infallible. I'm more confident in their ability to maintain availability than yours. All of this paranoia about Google going down is mostly FUD.

<comment><USER4> You missed the point, which was that your site could be up, and google would be down, which would cause big problems with javascript errors.

OTOH if your site is down, it's fully down - no partial content, and javascript errors.

<comment><USER7> I understand your point and I'm dismissing it as FUD because you're playing the "what if" game. Comeback with some uptime graphs. I don't believe it's worthwhile to worry about Google's uptime and it's perfectly legitimate to let them host jQuery for you until proven otherwise.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I don't want to provide user stats for my site to Google for free.

Granted, if the user has the library already cached, I suppose Google sees nothing, but still.

Maybe HTML should be extended so that together with <link> tags you can state a hash of the content, so that the browser could recognize identical files. (Would be a bit dangerous, though).

<comment><USER9> It's not like you don't already use Google Analytics, right?

<comment><USER8> I don't use Analytics, for the same reason. It is also protecting the privacy of my users.

</comment></comment></comment><comment><USER10> This isn't a good idea.

I use noscript and I rarely will let it load 3rd-party Javascript. The more times I have to click "temporarily allow ..." the more i hate your site. As a user, I don't like every site telling Google what I'm doing. Google is becoming the panopticon of the internet. Forcing users to load content third- party content is a sign that you don't respect their privacy.

IE8 in private browsing mode will block 3rd-party scripts that are referenced from more than 10 (by default) sites. This includes all this Google stuff and Google Analytics.

<comment><USER11> How many users have even heard of NoScript or know what "3rd-party Javascript" is?

They just care that your page works and loads fast.

You are a vanishingly small minority.

</comment></comment><comment><USER12> The cool idea in this is that universal libraries like jquery basically become locally cached...no download needed even if it is the first time they hit your site.

<comment><USER13> It would be even cooler if this were done by comparing a hash of the library's remote and local copy, so it could be on any server and not bound to the same domain.

<comment><USER2> I hope it is a cryptographically secure hash that STAYS cryptographically secure. Otherwise ten years down the road someone will figure out a way to force collisions and then, bam, you'll be running l33tcrew.ru's copy of Prototype with the access privileges of bankofamerica.com .

No problem fixing that one, all you have to do is roll out a patch to every standards-compliant browser in the world, oh, yesterday would have been good.

<comment><USER6> Or specify the hash type you'd like to see at the point you invoke the script. It can't retroactively protect pages that were published with the insecure hash, but it certainly would allow the author to update their site upon awareness of a hash vulnerability.

</comment></comment></comment></comment><comment><USER14> Sure, if JQuery's the only JavaScript file on the page. But if you use multiple plugins that depend upon JQuery, you're usually better off concatenating them all into one file, minifying that, and GZipping the content. You'll get slightly better compression than if you serve them separately, and don't need to worry about multiple HTTP requests.

<comment><USER15> Yes but you lose the benefit of the cache of jquery.min.js some people may already have when loading the first page of your site (the most important time for performance)

<comment><USER14> True, but they're not going to hit the cache anyway for the plugins, so download time will still be slow.

</comment></comment></comment><comment><USER16> If you're already serving your other assets from a separate domain (which is a very good idea - and if you use a separate domain rather than a subdomain you can be sure you won't have any cookies included in incoming HTTP requests, speeding things up even further) then it might be better to serve jQuery from your own asset server, to save the additional DNS lookup. Worth benchmarking, anyway.

</comment><comment><USER17> And extension of this theory is hosting your static content on Google App Engine. (aka cheap CDN for initial stage of a startup!)

<comment><USER18> I have been using Google App Engine as a CDN to serve up images and some core js, as well as using Google Ajax Library to serve up MooTools for about 5 or 6 months now. It has worked out really really well. In our case, we needed to serve our clients with our in house servers running ESRI's ArcGIS server. Splitting the load between Google and our Arc servers cut the load time in half for some cases.

</comment></comment><comment><USER19> YUI has been doing the same thing (hosting their JS professionally), and it does really make sense.

We've been doing this for years at fluther.com and it's worked out great. We have a switch for using a local copy when we're offline (on an airplane), but in general it adds speed and saves bandwidth.

This was always a nice benefit of YUI, and I'm glad to see there's an option with JQuery, too. (I'm planning to switch at some point--we went with YUI in the first place because it had the only stable autocomplete plugin but that's long since changed.)

</comment><comment><USER20> 1 reason why not to: loss of control.

Perhaps I'm being paranoid, but I do not want to rely on ANY external providers - not even when it's Google.

<comment><USER21> Do you provide your own internet bandwidth? You have to rely on external providers at some point and in all likelihood Google is better at keeping the lights on than you are.

<comment><USER22> I've never really understood that argument. Assuming that your site is totally down when your server goes down and that you rely on jquery so heavily that loosing it essentially renders your site unusable it doesn't seem to matter how much better google is at delivering content than you are. If you can manage an uptime greater than 50% the likelihood is that your server and google will be down at different times so the downtime is additive.

<comment><USER23> I think the argument is that google is an order of magnitude or so better at downtime than you are, so any google-created downtime is lost in the noise.

</comment></comment></comment></comment><comment><USER24> This is a terrible idea if the security of your site matters, because you're loading Javascript off an untrusted, unsecure source.

<comment><USER25> Dude... it's Google

<comment><USER24> NO IT ISN'T. It's any of the computers between you and Google that influence where your unencrypted HTTP connection is going to land.

<comment><USER25> Ah I see what you're saying. Good point sir.

</comment></comment></comment></comment><comment><USER26> I think it's unlikely you'll see increased parallelism usually. All but the newest browsers (IE8, Safari 4, FF 3.1) wait until they encounter script tags before they download them, rather than looking ahead to download multiple scripts in parallel.

<http://stevesouders.com/ua/>

</comment><comment><USER27> and CloudFront the other JS libraries your site must use.. [http://paulstamatiou.com/2008/12/08/how-to-getting- started-w...](http://paulstamatiou.com/2008/12/08/how-to-getting-started-with- amazon-cloudfront)

</comment><comment><USER25> Answer: it's faster</comment>


Zero-days in Cisco Discovery Protocol - <AUTHOR> https://www.armis.com/cdpwn/ <comment><USER2> Does anyone actually have faith in their hw+sw security these days? The speculative execution stuff on CPUs, system code full of buffer overflow / privilege escalation bugs, attacks that can work across airgaps using high frequency sounds, all the attacks on various hash functions, fake digital signatures, sandbox escapes, ... it goes on and on and each time you realise that it's been wide open for ages, and whichever security researcher found it could just as well have sold the exploit for lots of money instead.

Even as a fairly tech savvy guy I wouldn't actually know how to make a truly secure computing environment short of putting the whole thing in a silent Faraday cage and having metal detecting scans going in and out.

<comment><USER3> The speculative execution stuff is fascinating and a little terrifying but, _for the most part_ , has been of little practical impact so far, at least after the first round of Meltdown/Spectre fixes.

Attacks on various hash functions are not really a thing. We've known not to use SHA-1 for over a decade, and cryptographers working in the space have started saying we may never find a viable preimage attack on MD5, let alone SHA-1. We are on pretty sound footing with hash functions; what you were doing in a competent system 10 years ago (using SHA-2) is still the right thing today.

I've been a vulnerability researcher since around 1995. I feel significantly better about security today than I have at any point in the past. We've been doing an imperfect but steady job of shutting down bug classes for decades, with the obvious and most important factor being the deprecation of insecure systems languages.

<comment><USER4> I don't see C anywhere near being "deprecated" in general. Usage of Rust/Zig/ATS/whatever is a rounding error by comparison to C/C++, even for new projects. Anecdotally, I've been interviewing with a few startups building ambitious infrastructure-level projects, and none of them are using Rust. C/C++ is still the only game in town outside the HN bubble.

<comment><USER3> If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises aren't compatible, because I am talking about things like Java and Python. In the 1990s and early 2000s, we were still building application code in C/C++.

<comment><USER4> Hmm, I had in mind the phrase "insecure systems languages", but I don't want to get into a boring debate about what "systems languages" or "systems programming" mean...

<comment><USER3> It's at least as much my fault as yours, since I said "systems language" as a shorthand for C/C++, not to describe the problem domain, and it's true that the modern zero-cost-abstraction memory-safe languages that can displace the last of the C/C++ code are very new. We'll be out of the era of C/C++ when a mainstream browser is written in one of them.

<comment><USER2> As I understand it, Firefox now has substantial parts written in Rust, Mozilla's own language. Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.

<comment><USER5> > Also, unless the OS and drivers are written in a memory-safe language as > well, that castle is to a degree built on sand.

You have to start from somewhere. There's Rust. I'd like to see some more language (and tooling) competition with systems that can prove functionality at compile time in practical situations.

Not impressed with current C/C++ static analysis landscape. I've used a ton of static analysis for writing Windows kernel drivers for instance — from known tools like Microsoft's Prefast (requires a ton of annotation, sigh!) to clang. And others. And fuzzing on top.

But it still doesn't come anywhere near replacing a good pair of eyes and some hard thinking. And I'm not talking about logic bugs here, but for example concurrency and memory safety related issues. I've had plenty of "quality time" (not!) with the kernel debugger...

I'm _very_ seriously considering to use Rust instead of C/C++ whenever I have my next Windows (or other OS) kernel mode project. Even though some consider it a bit unproven in this space. At this point, I don't feel like C/C++ is proven either...

To a bit lesser degree, same for anything that touches untrusted inputs, directly or indirectly. Even if you can sandbox it.

I do need to work around some issues with Rust. Like to learn how to minimize code size for those situations where it is a constraint. Like device firmware. However I feel that's easier than writing bulletproof C/C++ code.

<comment><USER6> Part of me would like to see .NET Native available on all levels of the stack, but with WinDev vs DevTools politics, that is unfortunately just wishful thinking.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> If this bug was discovered in a Huawei device we'd immediately call it a backdoor and plea to ban all these devices from our critical infrastructures.

And yet, when Cisco has a security bug we patiently wait for the patch and move on with our business.

<comment><USER8> I think Cisco's [existing] reputation goes a long way

<comment><USER9> Their reputation for security flaws like this and helping suppress human rights by selling hardware to the Chinese government?

<comment><USER10> Perhaps. But also their reputation for actually originating ideas and technology (or legally acquiring them) instead of stealing swaths of intellectual property like Huawei has and does.

</comment></comment></comment></comment><comment><USER11> I've read through the description and now the whitepaper and I've got a few takeaways.

1\. These attacks can't be carried out over the internet, you need local access. Thats easier than you'd think with employees with unsecured laptops/vms/etc.

2\. The exploit(s) appears to be RCE in the OS that runs on the device, but not neccesarily translating into executing configuration commands on the control plane. But its not a big leap to make configuration changes...

3\. The DoS case doesn't seem great either but also requires local access.

4\. The string format bug has the most entertainment value for me -> You can spew CDP packets into a switch/device which potentially overwrite other devices CDP data, which means you could potentially issue a poweroff or change the name of said device.

5\. The phone vulnerability is good too -> If you can broadcast/spew CDP from your host, you can be annoying to phones.

6\. The cameras can only be harassed by plugging directly into it, rendering the vuln somewhat useless.

My takeaway is that you can't easily escalate vlan privileges via CDP which is good, but you can def monkey with the controlplane and maybe someone will come up with a way to change the IOS configuration.

<comment><USER12> They can be carried over the internet: VPN vulnerabilities are pretty common, eg [https://www.us-cert.gov/ncas/current- activity/2019/07/26/vul...](https://www.us-cert.gov/ncas/current- activity/2019/07/26/vulnerabilities-multiple-vpn-applications)

VPNs commonly bridge at layer 2, that's a direct path to pwnage in this case.

<comment><USER11> You'd have to -

A: own the VPN endpoint (unlikely)

B: own a local laptop and bridge the network together (more likely), but owning a local laptop is better than using a VPN.

<comment><USER12> C: own the vpn gateway

I think A and C are somewhat "likely" threats roo.

</comment></comment></comment></comment><comment> ga-vu They're not zero-days if they've been privately disclosed and patches are available.

<comment><USER13> I'd argue with most enterprise's upgrade cycle for this gear it is better than a 0 day, it is a -5 to -3 year exploit.

</comment></comment><comment><USER14> Security best practices have always recommended disabling CDP in an untrusted environment (that applies to things like LLDP, too). It is comical to see how many people leave both of those running on internet exchange points or sometimes worse things (like ospf or isis). The general default on nature of products to enable this is unfortunate.

<comment><USER12> Security best practices have always recommended treating all networks as untrusted and having non-internet-hardened stuff turned off by default in network facing products. You're right of course too, but Cisco is the real bad guy here.

<comment><USER14> Eh, I know a lot of folks who do enable CDP/LLDP for internal device to internal device links for discovery and troubleshooting. But they don't turn it on any customer/external facing interfaces (this enforcement thru offline config generation). So there can be a time and a place for it under the right conditions provided you understand the security risks (possibility of someone plugging something on an internal link, changing the router config incorrectly).

</comment></comment></comment><comment><USER15> Nice reminder that fuzzing protocol decoders is a good plan. Also a nice time to ask yourself if your last protocol decoding code should have been a structured parser instead of a handmade hack. [https://objectcomputing.com/resources/publications/sett/marc...](https://objectcomputing.com/resources/publications/sett/march-2016-protocol- parsing-in-scala-part-i)

</comment><comment><USER16> The NSA used to intercept Cisco routers in-transit to swap them out for back- doored ones.

I'm sure they knew about these, that's the problem, the NSA "hoards" zero-days instead of alerting the manufacturers.

And then we end up with nonsense like this, and you know half of these won't be patched for years, if ever.

Tens of millions of Cisco devices.

<comment> yjftsjthsd-h If they have a known exploit in the normal firmware, why bother MITMing hardware in order to backdoor it?

<comment><USER16> They may not have known about these protocol flaws at the time they were intercepting the physical devices.

Either that, or they were not vulnerable to these exploits at the time.

</comment></comment></comment><comment><USER17> This doesn't surprise me. I've avoided Cisco equipment since I wrote cdp-tools over a decade ago. During development (reverse engineering) lots of things I tried crashed switches and routers. No faith in anything Cisco makes after that.

But lots of networks I was connected to learned my topology from CDP so I needed to speak CDP...

</comment><comment><USER18> Do we really need half of the features pre-installed on our cisco devices. Like honestly- I really wish I could "tune" my ios firmware and remove things I dont need so I could reduce my attack surface.

Since its not called out clearly in the title this affects cicso's LLDP implementation as well [https://go.armis.com/hubfs/White-papers/Armis-CDPwn- WP.pdf](https://go.armis.com/hubfs/White-papers/Armis-CDPwn-WP.pdf)

<comment><USER19> That's what I was taught to do by my dad. Take the uncompiled kernel, remove _every_ driver and feature from it that you don't use for your use-case and then compile. Then go through hardening steps at each layer, chroot all the things, tripwire, etc. Compile all applications configuring for only the features you're going to use. Get a report on all versions and subscribe to vulnerability mailing lists.

And then at the end, understand that you have a system that is still vulnerable so set up a regular cadence of maintenance.

It's a bit harder to do these days for various reasons.

</comment></comment><comment><USER20> Anything about all the other millions of devices(different brands) that implement CDP?

</comment><comment><USER21> From my CCNA days I seem to recall that this protocol is a local one and would require a break into another host on the network.

Though the diagram shows the core switch directly connected to the internet instead of having an external router connect to the internet - which was the design CISCO suggested back when in did my CCNMA evening class

<comment><USER22> The article does not suggest that devices can be attacked from the internet. The threat is VLAN hopping or lateral movement. That illustration is oversimplified.

<comment><USER11> I read through it - it doesn't seem like VLAN hopping would really be possible unless you can straight up get into the control plane and change the port configuration. Thats at least 2-3 more steps from "RCE" basically.

</comment></comment></comment><comment><USER23> Damn, that's a wide array of devices...

</comment><comment><USER24> not a backdoor?

<comment><USER25> "Backdoor" usually implies the vulnerability was put in there intentionally.

<comment><USER26> They might be alluding to the fact that depending on who manufactures the device, security vulnerabilities will be reported as a backdoor.

<comment><USER25> Admittedly I didn't read the whitepaper, but the CVEs that were mentioned on the page summary sounded like your run-of-the-mill stack overflow or string vulnerabilities. So yes, the end result might be the same (i.e. remote takeover), but I would hesitate to call them backdoors unless it was demonstrated that this vulnerability was intentionally known or left unfixed for the purposes of being abused by parties in the know.

<comment><USER27> The idea if the same bug was in a Chinese product the title would have been "backdoor injected" ... see yesterday and recent articles on HN.

<comment><USER28> I searched and only found something about a vulnerability in "HiSilicone" hardware mentioned yesterday.

That article mentions a pre-installed telnet server including accounts that can be started with the right command send over TCP. Whereas here, it's apparently a typical buffer overflow resulting in arbitrary (but BYOT (bring your own Telnet)) code execution.

Sure, maybe Cisco is just better at disguising their backdoors for plausible deniability. But with what's known, intent seems far more likely in yesterday's case than this.

<comment><USER27> The article title was different initially and was something that included backdoor,injected,Huawei(was no direct relation with Huawei). There were also many similar reports about US routes and IOT having default passwords or easy to guess passwords but each time the stupidity is assumed. Also the Windows "NSA key" article and comments were very convincing that for sure it was nothing evil and was never used anyway.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> Represents most of what I hate about the 'security industrial complex'. Self serving and to that point at the bottom of the page is a link saying:

'With the discovery of the CDPwn vulnerabilities, organizations from every industry as well as governments are looking for a way to identify which of their devices are impacted by these vulnerabilities. Armis offers a CDPwn Risk Assessment to help organizations looking to understand their exposure.'

Then - 'Request a CDPWN threat assessment'.

<comment><USER30> My thoughts as well. I'm interested in hearing about new novel security issues; I'm not interested in reading a advertisement. With widespread deployment of IP Phones and the like, I think this is a interesting find. But at the same time I wish I read about this on bugtraq.

<comment><USER31> Same. I'm a CCIE and after a five minute skim I can't tell if this is grandstanding or an actual threat. Best practice is to disable CDP on all eternal interfaces. This is a given.

<comment><USER32> There's a funny name and a logo, so grandstanding.</comment></comment></comment></comment>


Shoring up Tor - <AUTHOR> https://newsoffice.mit.edu/2015/tor-vulnerability-0729

<comment><USER2> Previous discussion here: [https://news.ycombinator.com/item?id=9967984](https://news.ycombinator.com/item?id=9967984)

</comment><comment><USER3> I find it a bit telling that neither the paper, the arstechnica nor this article mentions the most common argument against fingerprint attacks are describe in the base rate fallacy.

With 12% false positive rate that the paper mention, you still only need to visit a small number of websites to generate a false positive. I also doubt that the 12% is actually correct in real life circumstances, since the research only tested single traffic flows from clients and many website has JS that trigger simultaneous traffic flows while users browse the web in other tabs.

<comment><USER4> Yeah. Browse the web with multiple tabs and every current fingerprinting attack is useless.

</comment></comment><comment><USER5> The the discussion of the paper at the tor project or ars technica is much more informative for the HN crowd; if for no other reason than the simple fact that they include a link to the paper:

Paper: [http://people.csail.mit.edu/devadas/pubs/circuit_finger.pdf](http://people.csail.mit.edu/devadas/pubs/circuit_finger.pdf)

TorProject: [https://blog.torproject.org/blog/technical-summary-usenix- fi...](https://blog.torproject.org/blog/technical-summary-usenix- fingerprinting-paper)

Ars Technica: [http://arstechnica.com/security/2015/07/new-attack-on-tor- ca...](http://arstechnica.com/security/2015/07/new-attack-on-tor-can- deanonymize-hidden-services-with-surprising-accuracy/)</comment>


Magic Leap – another unicorn startup joins the line of Enrons of Internet era - <AUTHOR> https://tech.slashdot.org/story/16/12/09/1535221/magic-leap-used-fake-tech-demos-and-is-years-behind-schedule <comment><USER2> This is poor quality. Magic Leap is still unique to Hololens and they have always had a very "long game" in mind. I feel this may be a little on the FUD side of things.

Also, the source of this is Slashdot > IBTimes > The Verge > The Information (which is behind a paywall). So none of us can actually read the source.

[https://tech.slashdot.org/story/16/12/09/1535221/magic- leap-...](https://tech.slashdot.org/story/16/12/09/1535221/magic-leap-used- fake-tech-demos-and-is-years-behind-schedule) > [http://www.ibtimes.co.uk/magic-leap-dead-report-claims- compa...](http://www.ibtimes.co.uk/magic-leap-dead-report-claims-company-used- fake-tech-demos-years-behind-schedule-1595726) > [http://www.theverge.com/2016/12/8/13894000/magic-leap-ar- mic...](http://www.theverge.com/2016/12/8/13894000/magic-leap-ar-microsoft- hololens-way-behind) > [https://www.theinformation.com/the-reality-behind- magic-leap](https://www.theinformation.com/the-reality-behind-magic-leap)

<comment><USER3> Abovitz publicly said _just a few months ago_ that the production line was ramping up and they were getting ready to start.

[http://www.businessinsider.com/magic-leap-production- begins-...](http://www.businessinsider.com/magic-leap-production-begins- summer-2016-2016-6)

IMO that's not a "long game" announcement by any means.

</comment></comment><comment><USER4> Please don't editorialize in the headlines.

And no, there's nothing even close to an Enron situation with Magic Leap. Misleading investors is no where near the same as repeatedly pushing and encouraging your employees to reinvest retirement funds into the company at the same time that you're instigating wide-spread fraud with that same money.

</comment><comment><USER5> Previous discussion including some about proven bogosity in claims they have made: [https://news.ycombinator.com/item?id=13135735](https://news.ycombinator.com/item?id=13135735)</comment>


Project Thumper Walkthrough (The Geek Group) - <AUTHOR> http://hackaday.com/2013/09/29/project-thumper-walkthrough/

<comment><AUTHOR> Come hang out or ask questions via irc.thegeekgroup.org 6667, many cool projects and people. Web based live stream and IRC client [http://thegeekgroup.org/live/](http://thegeekgroup.org/live/).</comment>


Very Short But Amazing Speech by Coca Cola CEO Bryan Dyson - <AUTHOR> http://www.startupceo.co.za/2010/03/01/amazing-speech-bryan-dyson/ <comment><USER2> Anyone have a verifiable citation on this credit to Dyson? Initially my spider sense tingled when something so perfunctory was attributed to a CEO of Coca Cola (a common theme to chain emails).

Some quick Googling credits a 1996 Commencement Address at Georgia Tech. However, another source says it's from the book, Suzanne's Diary for Nicholas.

Does anyone have a source at Georgia Tech that can confirm/deny 1996's commencement address?

<comment><USER3> The oldest use of the quote that I can find is from a 1998 WHO document: [http://www.searo.who.int/en/Section1257/Section2181/Section2...](http://www.searo.who.int/en/Section1257/Section2181/Section2211/Section2219_11481.htm)

"Suzanne's Diary for Nicholas" is a 2001 novel by James Patterson, so I don't think that can be the origin of the story.

Also, note that Brian Dyson was CEO of Coca Cola Enterprises (NYSE: CCE) not CEO of The Coca Cola Company (NYSE: KO). (When people say "Coke" or "Coca Cola" they almost always mean the latter, not the former.) [http://www.wilsoncenter.org/index.cfm?topic_id=5949&fuse...](http://www.wilsoncenter.org/index.cfm?topic_id=5949&fuseaction=topics.item&news_id=477942)

</comment></comment><comment><USER4> I doubt that this is true. Realistically, your loved ones will be more loyal to you than your boss. Which is more common: lying, embezzling employee keeps getting rehired by the same boss, or lying, cheating husband keeps being forgiven by his wife?

You'd have to be a pretty shitty human being to exploit this, but it is true. The transactional nature of business means it's the least amenable to long- term relationships, and requires the most aggressive maintenance if you want to optimize it. Most people naturally behave in a way that counteracts this: they _could_ abuse the trust of their loved ones, but they don't.

So perhaps he should have said something like "business is a glass ball. The others are all hamster-balls, with little hamsters in them. If you drop the hamster-ball, it's not going to kill the hamster; it might not even seriously hurt it. But don't be an asshole; if you're going to drop something, drop something that won't be hurt."

<comment><USER5> I didn't read it in the same light. I don't think it's about being an ass to anybody, or abusing the trust of others (your boss, or your family).

I would sum it up as in "your job is not the most important thing in your life". When you're juggling with your 5 balls and you reach a point where you can't handle it anymore and need to drop a ball, dropping the work part is not as big of a deal as the rest. E.g. if you do something just to keep your job but that hurts other people or your health, don't do it, it's not worth it: don't stay late every night, when it's forbidding you to kiss your kids to bed; don't accept to be dropped off in a war zone just to keep your job, etc.

<comment><USER4> I chose extreme examples to illustrate it. But look at it this way: your boss is the least likely person to forgive you for a given offense, because the relationship is more transactional.

The opposite hypothesis seems pretty absurd. You wouldn't argue that, e.g., if you have to disappoint your boss or your spouse, your boss is more likely to remain unconditionally faithful to you.

People don't exploit this, and that's a good thing. But if I were trying to avoid harm in both my professional and personal life, I'd know that personal connections are more loyal, and thus I can more afford to let them suffer in the short term.

I guess health is an exception there. I'm not sure what "spirit" means, but it seems hard to change.

</comment></comment></comment><comment><USER6> Bryan Dyson is not Coke's current CEO. Muhtar Kent holds that position now (since 2008). IIRC, Dyson was CEO in the mid 80s. Title should read ex-CEO to not confuse users.

Edit: after some Googling, Dyson was President & CEO of Coca-Cola North America in 1983. Then became CEO of Coca-Cola Enterprises in 1986. BTW, there is a HUGE difference between The Coca-Cola Company and Coca-Cola Enterprises, and they are often confused with each other. They are two separate, publicly traded companies. CCC produces the Coke syrup. CCE actually takes the syrup, mixes it with water and CO2, bottles it, then distributes it to stores.

</comment><comment><USER7> Uh,

Odd person to imagine as an advocate of health.

The circumstantial evidence for the health-damaging effects of high-fructose corn syrup in particular are still fuzzy but the correlation of sodas and obesity is pretty established. Where is Coke on that question?

\-- I wouldn't advocate imagining your health as a glass ball. There's something to the point that your body responds to the imagines of yourself that you give it. I'm a rubber ball but not one whose going to put Coke into my system.

<comment><USER8> First off, only some parts of the world use high-fructose corn syrup in their coke. If you get a coke from mexico (and I imagine much of south america) it uses cane sugar.

More importantly though, I am currently drinking an amazing Odwalla juice which is a distributed by minute maid which is owned by coke. Though they have a highly successful, and not so healthy product, they also have a diverse number of companies which focus on health.

<comment><USER9> Sugar is just as bad as HFCS, according to this video lecture that came across HN:

<http://www.youtube.com/watch?v=dBnniua6-oM>

It also asserts that pretty much any juice is not a good idea because you're losing the fiber that helps your body deal with the fructose. I need to learn more about it though.

<comment><USER8> Well, lots of things are bad for you, but taken in moderation. I don't have 1.5 hours to sit through the video.

I just checked out the juice/smoothies I have, and was VERY surprised to see that you are correct, they have 0 fiber. Just goes to show that their really is no substitute for the real thing.

</comment></comment></comment></comment><comment><USER10> I don't know about amazing; this just seems depressing.

</comment><comment><USER11> What's `spirit'?

<comment><USER12> Morale?

Spunk?

Whatever you call the thing that fights back psychological depression?

I highly doubt he's talking about spirit(uality).</comment></comment>


Chuck Norris Exception - <AUTHOR> http://criso.github.com/ChuckNorrisException/

<comment><USER2> Here in India, we have a very popular actor, RajniKanth, whose awesomeness occasionally goes down the line drawn by Chuck. Here are some cool RajniKanth quotes:

Once Death had 'near Rajnikant experience'

Rajanikanth can do a wheelie on a unicycle.

<comment><AUTHOR> Yeah , he's pretty epic <http://www.youtube.com/watch?v=HyuzNP_UP4w></comment></comment>


Masheeh Entrepreneurship Prize Competition  - <AUTHOR> http://maseeh.usc.edu/

<comment><AUTHOR> One of the founders must be a student at the Viterbi School of Engineering at USC. Deadline is November 15th. Winner gets $50K.</comment>


Show HN: Photosaic – Build mosaic images with a small library and a few photos - <AUTHOR> https://github.com/whatl3y/photosaic <comment><USER2> Nice work I love these types of projects. About 10 years I coded up an infinitely zooming mosaic for a big museum in New Zealand.

Just found someone's video of it on YouTube - [https://youtu.be/06GTEfSD2PM](https://youtu.be/06GTEfSD2PM)

I used an app called AndreaMosaic to generate the big mosaics and Silverlight + Deepzoom for the app, what a dreamy platform after developing for Flash :)

</comment><comment><USER3> Looks really cool! I've been looking for something like this for a while. Ideally I'd like to make a large image to then print, I'll give this a try!

<comment><USER4> Same here. Looking forward to trying this out!

</comment></comment><comment><USER5> would be nice if it also gave the coordinates for showing the expanded picture on hover!</comment>


Palm Pre Hatchet Job - <AUTHOR> http://blogs.barrons.com/techtraderdaily/2009/06/03/palm-shrs-slide-on-business-weeks-hatchet-job/

<comment><USER2> I think that there are some fair things that one can argue against the Pre:

* It doesn't have applications like the iPhone.

* It has a smaller screen while being a larger device.

* The screen is plastic rather than glass.

* It's carrier is Sprint which is deemed unpopular by consumers (personally, I use Sprint and am happy, but my experience doesn't change public opinion).

* It's closed source (against an open-source Android).

* It (currently) only has HTML/JS as a development environment.

I'm going to be getting a Pre when it comes out since it's the best I can get on Sprint, but it faces a tough battle. If they don't sell well, I know I won't be getting an application ecosystem like the iPhone has. Android might become the iPhone opposition rather than webOS given it's open-source status and availability from several manufacturers.

And Palm is having their grand opening so to speak 2 days before Apple's WWDC. For all we know, Apple could decide that the $200 iPhone will be 16GB with a 32GB model selling for $300. That would be devastating for Palm. They could lower the Pre's price to compete, but Apple could easily upstage Palm with such a simple announcement.

To be honest, I'm a little sad since this is going to be my device and it practically looks like an also-ran before it's even released. Then again, Apple might have nothing new at WWDC (other than the 3.0 OS) and Google might be exaggerating the interest in their Android OS (which they've claimed will be on around 2 dozen devices by year end).

If Apple doesn't change storage capacities or improve hardware dramatically and Android doesn't become the "second platform" after the iPhone and Palm gets the Pre (or other webOS device) on other carriers in 3-6 months, Palm has a good chance to be a big hit.

<comment><USER3> I think the Pre is more a BB competitor. And in that space I think there's plenty of opportunity for Palm to find success.

But it has an unmistakable 'corporate' angle that makes it unlikely to attract the crowd that the iPhone's been selling to.

<comment><USER2> It's funny because Palm has actually been saying that corporate customers shouldn't be buying the Pre - that they should be getting one of the Treo models instead.

I don't think the Pre is really an enterprise device. It just isn't boring enough ;-). Really, it's that it has untested support for things like Exchange (other than Palm's internal testing). I'm sure businesses will support it just as they've started to support the iPhone, but even Palm is saying that enterprise customers should go with a different device (at least for now).

What makes you think it has a corporate angle? Specific features? The way it's being marketed? The real keyboard? I'm curious since it's not how I see the device, but when I see the device I think about what I'd do with it as a consumer. It would be really cool if Palm carved out a chunk of that market.

</comment></comment></comment><comment><USER4> Palm too easy to develop for is a minus? Could this mean we will see even more fart applications for the palm than the ones currently on the iPhone?

</comment><comment><USER5> Why does Palm not want to sell this to "IT Centric" customers? Isn't the point of the Pre to connect people to multiple data sources including exchange?

Seems like a good IT device if you ask me...</comment>


10 Billion Dollar Ideas For You To Steal - <AUTHOR> https://medium.com/p/d86e55a40418

<comment><USER2> ...or a billion $1 ideas? Its not the idea that counts; its having some insight into the market and an execution plan that counts.

</comment><comment><USER3> It is not enough to steal an idea - you need to "steal" the execution also. But that is hard work I guess ...</comment>


Web App Integration In Ubuntu - <AUTHOR> http://www.jonobacon.org/2012/07/19/web-app-integration-in-ubuntu/

<comment><AUTHOR> Android was leading the way in this (best sharing between online services etc). This looks like the first other OS to "get it" and push hard to integrate with the cloud. I think in some ways this surpasses Android.

Mean while we have iOS that's just congratulating itself for allowing photo uploads to twitter, meanwhile my Android phone has integration with services I've never even heard of.

And MacOS and Windows... nothing. Stupid autistic children sitting on the internet.

It's nice to see some real innovation in the Linux camp on the user end front.</comment>


Why was Mini USB deprecated in favor of Micro USB? - <AUTHOR> http://electronics.stackexchange.com/questions/18552/why-was-mini-usb-deprecated-in-favor-of-micro-usb <comment><USER2> This is a great answer, but IIRC there's an other reason to prefer micro over mini: the moving parts in the micro-USB connection are in the male plug, not the female one like the mini.

Since those parts tend to break easily, it's cheaper to replace the cable rather than the smartphone/device having the female port.

That being said I'm still a bit mad at Apple for ditching their old large port, only to replace it with an other proprietary standard.

<comment><USER3> Apple's port, which doesn't have an up/down direction, is much easier to plug in than the micro USB port, which does. It is an innovation, like it or not, that USB doesn't have.

<comment><USER4> Although Lightning Cable is not the first to be bidirectional I am mad at Apple for not making Lightning an open standard.

<comment><USER5> > I am mad at Apple for not making Lightning an open standard.

Lightning is just Apple's marketing term for Intel's Thunderbolt interface. The standard is available from Intel, and if it were not it would be more appropriate to direct your anger at Intel.

<comment><USER6> Thunderbolt is Intel's external, hotswappable PCI-e interface found on many Apple laptops. Lightning is Apple's proprietary interface found on iOS devices. Aside from being named after different aspects of the same natural phenomenon, they have _nothing_ in common.

<comment><USER5> Not sure how I got those so thoroughly mixed up, thanks for the clarification.

<comment><USER6> Well, being named after the same natural phenomenon is confusing enough. I often have to stop and think which is which. It's an understandable mistake.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I only ever had one mini USB cord go bad, and that was a minor pain. But I have had the micro USB _port_ on a cell phone become unreliable, which is insanely frustrating. The post holding the contacts no longer wants to push them against the cord, so it frequently loses the connection.

I can solve the problem temporarily by pushing the post back with a small screw driver, but "temporarily" here is measured in minutes or hours.

<comment><USER8> Exactly the same experience here, except that I never had a mini-USB failure. After roughly 6 months of use, the USB receptacle of my LG smartphone was just not holding on to any cable anymore. I sent it back to LG, and they replaced the part containing the mirco-USB port.

On an unrelated note: LG noticed that I was running a custom ROM but didn't make any problem of it, while technically they can claim that such an action voids my warranty.

<comment><USER9> Actually, if you're in the US the Magnuson-Moss Warranty Act covers you in the case of customizations [1]. Under this law, manufacturers are only able to claim your warranty as void if the modifications are what caused your warranty claim. I doubt they would be able to claim that your custom ROM caused your hardware failure on the USB port, so legally they had to fix it. More info on this FTC law [2].

[1] [http://www.examiner.com/article/what-modifications-will- void...](http://www.examiner.com/article/what-modifications-will-void-my- warranty-on-my-new-car-purchase)

[2] [http://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty_...](http://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty_Act)

<comment><USER8> I'm in Europe, but it may well be that a similar law is in effect here. However, a lot of consumers (me included) wouldn't know about that, and companies try to get out of repairs that they are legally required to perform.

Take a look at Apple's warranty: they claim to provide only 1 year of warranty, while European law requires them to provide two years. They will repair your device in the second year (it's the law!). However, I bet their confusing labeling etc. will cause a lot of people to believe their warranty has expired. Those people will either not ask for a free repair or pay their shop to repair the device.

<comment><USER9> In the US, Magnuson-Moss is often referred to as "the lemon law" (a defective product that can't be repaired is colloquially called a "lemon"). Specifically, "the lemon law" refers commonly to cars that have issues the dealer didn't specify before the sale and will not/can not fix.

Problem is, the FTC requires you to have a lawyer file a lawsuit and coordinate your legal costs and representation with the FTC, generally requiring a lawyer specifically dealing in lemon law cases. I've been down this path with a defective cell phone (HTC Touch Pro) and trying to get my carrier to replace it, and it's impossible to find a lemon law lawyer that deals in anything besides used car sales.

As always, the law is well intentioned but enforcement is next to impossible, just like you said.

</comment></comment></comment></comment></comment><comment><USER10> Important point - back in 2007, China _mandated_ that all cell phones be able to charge from a standardized connector [1]. The connector they chose was Micro USB. Thus regulatory concerns played no small part in the mini vs micro wars.

[1] [http://www.techrepublic.com/blog/tech-news/micro-usb-to- be-a...](http://www.techrepublic.com/blog/tech-news/micro-usb-to-be-a-new- phone-charger-standard/)

</comment><comment><USER11> Another point: AFAIK the Mico USB connector is designed so that if you apply force from the side to a plugged in connector, the plug will deliberately break and the socket/pcb will stay functional.

Edit: I can't relate to those who say Mini USB is more reliable than Micro USB. I've had a lot of trouble with Mini USB connectors and especially cables, especially if I move a connected device i've had lots of short disconnects. This never happened with Micro USB. So.. go Mico USB!!1!

<comment><USER12> Yep, I have had several mini USB ports quickly destroy themselves, to the point that it affected my buying decisions. The accepted answer in the link perfectly explains why.

</comment></comment><comment><USER13> I thought that another big advantage of micro USB over mini USB was that it's a lot easier to combine type A & B. The difference between A & B is most obvious in a full size USB cable. The "A" plug is the flat side that goes into your computer, and the "B" plug is the square one that goes into your device.

The differentiation made a lot of sense when USB was exclusively master-slave. However, the addition of the on-the-go standard (OTG) means that things like a cell phone can function as either a master or a slave. Thus the connector on your cell phone is likely a micro-AB connector that can accept either a type-A or type-B plug so you can connect your cell phone to both computers & storage devices without requiring two different ports.

However, a double check before posting indicates that a mini-AB standard does exist. So that's not the reason. I'll post anyways because I think it's useful information on its own...

</comment><comment><USER14> So I am not nuts!

I always wondered if something was wrong with my charging cables and USB phone cables always failing to work after only some months...

So indeed, the mini and micro both have issues (thankfully the micro is "less worse" or I would be buying cables like there is no tomorrow)

<comment><USER15> Still, that doesn't prove you're not nuts.

</comment></comment><comment><USER16> I still wish they would have standardized on 2.5mm jacks for usb. You can plug it in any direction, and you can pull a cable out of a tangle of wires without snagging due to the round shape. It is a superior connector.

<comment><USER17> that would be far too easy to short out/catch fire/damage circuitry/blow a fuse.

<comment><USER18> This x100.

Never use this style of connector/jack for supplying power. The cable tip will make contact with both the jack ring and sleeve in most jacks, and the cable ring will make contact with the jack sleeve. No matter how you wire the cable/jack, you always have the high probably of short on insertion/removal.

<comment><USER15> With electronics on both ends, the devices could easily negotiate in which direction power should flow, how much, and detect open and short conditions.

<comment><USER18> So, tell us how you expect this task would be achieved. (I know some possible ways, but I could just as easily say "but none are as effective as using the right cable for the task!")

</comment></comment></comment></comment></comment><comment><USER19> I've had more micro-USB failures than mini but good connectors are expensive to make so part of the problem may be that micro is better in theory but harder to manufacture in practice.

</comment><comment><USER20> I hope this doesn't start a sad trend of 'Nano USB' and 'Pico USB'.

</comment><comment><USER21> [http://en.wikipedia.org/wiki/Lightning_(connector)#Reception](http://en.wikipedia.org/wiki/Lightning_\(connector\)#Reception)

Please note under "Reception" about Micro USB and it being "standard". WHO'S LAUGHING NOW?!

</comment><comment><USER22> Can Micro-USB support USB 3.0 speeds?

<comment><USER23> USB 3.0's highest speed (termed "SuperSpeed" to easily separate it from the previous, equally clearly labelled, speed grades "LowSpeed", "FullSpeed" and "HighSpeed") requires more pins than USB 2.0 speeds, so the connectors are different.

Here's a link, picture of USB 3.0 micro plug on the right: [http://en.wikipedia.org/wiki/USB#Cable_plugs_.28USB_3.0.29](http://en.wikipedia.org/wiki/USB#Cable_plugs_.28USB_3.0.29).

<comment><USER24> If USB 4.0 doesn't come labeled as "LudicrousSpeed" I will be severely disappointed.

EDIT: For those who don't get the reference: [http://www.youtube.com/watch?v=ygE01sOhzz0](http://www.youtube.com/watch?v=ygE01sOhzz0)

<comment><USER25> Why not go straight to plaid? :)</comment></comment></comment></comment>


Hustle rallies $30M for grassroots texting tool Republicans can't use - <AUTHOR> https://techcrunch.com/2018/05/01/hustle-sms/ <comment><USER2> This is terrible. The country is already polarized enough as it is, we don't need businesses that cater to one tribe and exclude the other.

Also, I think it's creepy and a turn-off to get any kind of faux-informal mass-message "customized" with my name, mad-libs style. It's a particular uncanny-valley kind of impersonal.

<comment><USER3> I don't see this as polarizing. The focus of the campaign is not something negative about the opposition. This seems about reaching people who share a common interest and motivate cooperative action; however it could easily be used as outreach to those with opposing views seeking to inform and persuade.

As far as "impersonal" is concerned. It's goal is just the opposite: to _initiate_ personal contact and interaction, interaction which occurs after the initial contact. It could be used in an impersonal way, but as you indicate that would be offensive and produce the wrong result.</comment></comment>


Cycript – Objective-C++/JavaScript hybrid debug REPL for OSX/iOS - <AUTHOR> http://www.cycript.org/ <comment><USER2> Thank you so much for sharing this, for making it open source, and even more so for documenting it so well!

I've used F-Script (on the Mac) whenever I needed something like this. However, the Smalltalk syntax seems to limit its appeal, and I've wondered whether a similar tool leveraging JavaScript could really take off. What you have created is far more sophisticated than I ever imagined. Looking forward to digging into it more.

<comment><USER3> For those like me who find the Smalltalk syntax appealing, there's hope to make more of it (given Objective-C's roots, this makes every sense): [http://objective.st/](http://objective.st/)

<comment><USER4> That looks really cool, but maybe a little ambitious? I don't know what Apple's restrictions are for iOS apps these days, but last time I was in the iOS game, they didn't allow anything that wasn't written directly in ObjC or C.

<comment><USER5> That's not the case anymore (ever?). There are iOS apps written in C#, Ruby, C++, and of course JS/HTML care of Phonegap.

I think the only real opposition to alternative stacks Apple publicly displayed was to Flash.

Edit: Actually it looks like Adobe Air also works: [http://www.adobe.com/devnet/air/articles/air-on-ios- faq.html...](http://www.adobe.com/devnet/air/articles/air-on-ios-faq.html#b)

</comment></comment></comment></comment><comment><USER6> I've been using cycript for a while now for reverse engineering iOS applications, and it's absolute witchcraft! You can tab-complete your way through objects, call arbitrary functions, -- it's a fantastic tool for any pen-testers doing work in the mobile space.

It's nice to see this project get some much needed love, I tried to compile it from source a while back and it was a nightmare.

<comment><AUTHOR> I _highly_ recommend reading the new manual: I have added tons of new features in the last few weeks. Example: you can now query live objects given a Class (I scavenge the heap looking for live memory ranges that are the right size and shape for that Class, or any subclass).

</comment></comment><comment><USER4> > I pronounce "cycript" using a "geminate S" or "long S". The result sounds a > little like a stereotypical serpent from a cartoon: "sssscript". I doubt > anyone else will pronounce it like this, but I have my hopes.

I can relate. Okay, I'll pronounce it that way! :)

</comment><comment><USER7> Wow, this looks awesome.

> [x+1 for (x of @[1,2,3])]

I wasn't aware Objective-C++ or JavaScript supported list comprehensions like that.

<comment><AUTHOR> This is a feature from "JavaScript 1.7" (the versions after 1.5 are Firefox- only). There is a similar feature in ECMAScript 6, but the syntax is slightly different. I support both the Firefox-specific syntax and the current ECMAScript draft. (But yeah, if you try that expression without the Objective-C @ symbol in Firefox, it will actually work.)

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guid...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Guide/Predefined_Core_Objects#Array_comprehensions)

</comment></comment><comment><USER8> Great job! thank you saurik for all the effort and help. I'm having a small problem when attaching with the new version when on iPhone5 iOS7

(gdb) r Starting program: /usr/bin/cycript Reading symbols for shared libraries + done Reading symbols for shared libraries ++++................................................. done cy# Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000010 0x000127bc in CYDisplayMove () (gdb) where #0 0x000127bc in CYDisplayMove () #1 0x00012b50 in CYDisplayUpdate () #2 0x0015c9ae in readline_internal_setup () #3 0x0015d16e in readline () #4 0x0000b2fc in Main () #5 0x0000e668 in main ()

</comment><comment><USER9> Can anyone share similar things for other environments/languages/OSes? Would love to play with something similar but I'm not on OSX/iOS.</comment>


Binary Authorization for Borg - <AUTHOR> https://cloud.google.com/security/binary-authorization-for-borg/ <comment><USER3> In case anyone else wonders what 'borg' is:

"Our infrastructure is containerized, using a cluster management system called Borg."

I was hoping they had some predictable, indexed build for borg backup[1].

[1] [https://www.stavros.io/posts/holy-grail- backups/](https://www.stavros.io/posts/holy-grail-backups/)

<comment><USER4> Borg is basically the internal predecessor to Kubernetes.

<comment><USER5> Predecessor may imply "worse" or "outdated" (although may not be the intent of the OP). I want to clarify that is definitely not the case: Kubernetes is a joke compared to Borg when it comes to running Google workloads (on many dimensions, most importantly scale).

<comment><USER6> This post highlights why many start disliking Google - its that vibe of superiority that comes across often. These days Google workload (e.g. qps) isn't that unique anymore...

Moving Borg to Kunernetes will eventually happen because it doesnt make sense to help maintain two systems that solve the same problem. And because Kubernetes is open source it will eventually be superior, because of diverse group of contributions.

<comment><USER7> Huh? How is superiority relevant here? I don't work at Google (I have in the past) and both systems come out of that company with some of the same people have worked on both. If anything, Google marketing department would probably prefer for people to believe that Kubernetes ~= Borg to help sell GKE, not the other way around. Kubernetes is basically limited to several thousand hosts. That doesn't even register at Google scale. Other folks do have high QPS systems but none really use Kubernetes to manage the entire cluster; Facebook comes to mind, for example, with an in house system. I would bet against that prediction; I don't believe such a thing is even on the roadmap internally.

</comment></comment></comment></comment></comment><comment><USER8> On a related note, we have built an E2E-verified, tamper-evident CI/CD pipeline for the Datadog Agent integrations [1]: the Agent will trust and install only integrations that correspond to source code that have signed by our developers. If there is an attack anywhere between our developers and end- users, it will be caught.

Unlike Binary Authorization for Borg, our security guarantees are publicly verifiable.

[1] [https://www.datadoghq.com/blog/engineering/secure- publicatio...](https://www.datadoghq.com/blog/engineering/secure-publication- of-datadog-agent-integrations-with-tuf-and-in-toto/)

<comment><USER9> That's a bit of disingenuous reply...

Binary Authorization for Borg is for verifying binaries running inside Google, not code installed on end-user machines. Having the authorization be "publicly verifiable" makes no sense.

<comment><AUTHOR> Agreed with this statement. It's a best practice generally to verify all software updates originate from a particular source before applying them in your environment. Most over the wire updates do this. What's different with Binary Authorization for Borg is that within Google, that last verification step means more than just "came from Google", but "came from Google and went through all previous necessary checks", because of the way the CI/CD system works together.

Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.

<comment><USER10> in-toto.io also addresses the "proof it went through some steps". How would you compare the two systems?

<comment><AUTHOR> The biggest difference for me is that in-toto allows you to define any set of upstream metadata requirements, in a very open format, and Binary Authorization has a set of centrally defined requirements, that teams tend to implement in tranches, to meet minimum requirements. It may sound better to have a freeform format, but in practice, I've found that it makes it harder for people to know what they should _actually_ do. In Binary Authorization for Borg, services still define service-specific policies, but pick from a previously defined set of potential requirements. See the section on service- specific policies: [https://cloud.google.com/security/binary-authorization- for-b...](https://cloud.google.com/security/binary-authorization-for- borg/#service-specific-policy)

You can more easily compare Grafeas and Kritis (OSS projects Google developed, which are similar to GCR Vulnerability Scanning and Binary Authorization for GKE), to in-toto. In fact, I gave a talk covering some of the options for this here: [https://youtu.be/uDWXKKEO8NU?t=1314](https://youtu.be/uDWXKKEO8NU?t=1314)

Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.

</comment></comment></comment></comment></comment><comment><USER11> I led the portion of this project on Borg itself.

Security team did most of the security infrastructure, and coordination among almost every large infrastructure system team inside TI.

I'll be waiting for them to answer any questions. :)

<comment><USER12> I've seen references to gVisor being used 'in production' for google app engine && cloud run and so forth.

Scanning through recent commits && the github repo this is clearly not the case - there are way too many outstanding issues and outright missing support for various things. Is this another project where it was written in a different language or something and then ported out?

Can you clarify?

<comment><USER13> I work on gVisor, I can answer this!

gVisor is not a rewritten version of an internal tool. The code you see really does run in production for App Engine and Cloud Run. While there are some internal modifications to better integrate with internal infrastructure, the vast majority of the code is identical to open source, critically including all of the system call handling, filesystem, and memory management code.

While browsing through our issues will show that we still have plenty to work on, the vast majority of applications work well inside gVisor.

</comment></comment></comment><comment><USER14> One thing that really squicked me out when I left Google is how other companies, even large and sophisticated ones, are using all kinds of garbage that comes from canonical or red hat or percona, and they have NO IDEA what's in there. Say what you want about google's NIH culture, but in regards to code provenance and verifiable builds they are doing the right thing and many others are not.

<comment><USER15> Can you give an example of this garbage?

<comment><USER14> Literally anything that comes from a vendor in a package? Percona server/toolkit? Every binary package in Ubuntu? The Linux kernel as built and distributed by Red Hat?

<comment><USER16> Yeah, that's not a definition of garbage that's going to be taken seriously.

<comment><USER14> You're right; Google is the only big tech that takes insider risk seriously.

</comment></comment></comment></comment></comment><comment><USER17> > Adopting similar controls in your organization

> Figure out how to manage third party code.

> Many of the CI/CD controls we describe in this paper are placed where your > code is developed, reviewed, and maintained by one organization. If you are > in this situation, consider how you will include third party code as part of > your policy requirements. For example, you could initially exempt the code, > while you move towards an ideal state of keeping a repository of all third > party code used, and regularly vet that code against your security > requirements.

I don't know how much third party code is in use at Google these days, but I'd be curious to know if there is a formal effort at cataloging most-often used / most-sensitive third party code and prioritizing reviews of it.

I've thought about the problem of vetting programming language packages (pypi, npm, rubygems, whatever) off and on. It seems like the only two tenable strategies are "don't pin anything / always use tip of master" and "freeze deps, vet transitive deps at that frozen point, vendor the corresponding deps, and if you ever need to update a requirement for a feature or bugfix, go through the process again".

The latter seems like it could be out-sourced to a certain degree, if you trusted other organizations to "vet transitive deps".

<comment><USER18> For one thing, all third-party code is checked into one top-level folder in the monorepo.

This is publicly documented here:

[https://opensource.google/docs/thirdparty/](https://opensource.google/docs/thirdparty/)

This means that dependencies on a third-party library can be found simply by looking at deps lines in BUILD rules. That can then inform which projects you want to run (for example) fuzzers on:

[https://opensource.googleblog.com/2016/12/announcing-oss- fuz...](https://opensource.googleblog.com/2016/12/announcing-oss-fuzz- continuous-fuzzing.html) [https://google.github.io/oss- fuzz/](https://google.github.io/oss-fuzz/)

</comment></comment><comment><USER19> At Microsoft, we just require all binaries to be signed on production systems. Some systems are configured to block execution 9f unsigned code. Where we can't do that, monitoring cuts an immediate sev-2 and wakes us up if any unsigned code is executed.

Does Linux not have a way to run only signed ELFs?

<comment><USER18> If a single person can generate a signed binary by themselves, then restricting execution to signed binaries does not address the threat model in the article.

<comment><USER19> You can't. Only official builds are signed, and two different people have to submit and approve PRs.

<comment><USER18> That's a big difference from the starting state that Google had, which was that a single person could create a signed production binary from _unsubmitted_ code all by themselves.

(It was very convenient for iterating on one-off fixes in production in an emergency, but you would rightly question how someone gets into that position in the first place. Plus there was no guarantee that the code would ever get submitted, and post-fix code review might cause the code to be subtly broken prior to being committed to the monorepo.)

</comment></comment></comment></comment><comment><USER20> Has anyone outside of Google implemented something similar in spirit to this for K8s or ECS? What was the threat model you were considering when you built it? Was it worth it?

<comment><AUTHOR> Yes, there's a few listed in this blog post: [https://cloud.google.com/blog/products/identity- security/bey...](https://cloud.google.com/blog/products/identity- security/beyondprod-whitepaper-discusses-cloud-native-security-at-google) \- Kubernetes admission controllers, OSS part of Kubernetes: [https://kubernetes.io/docs/reference/access-authn- authz/admi...](https://kubernetes.io/docs/reference/access-authn- authz/admission-controllers/) \- Kritis, OSS: [https://opensource.google/projects/kritis](https://opensource.google/projects/kritis) \- OPA Gatekeeper, OSS: [https://github.com/open-policy- agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper) \- Binary Authorization on GKE/Anthos: [https://cloud.google.com/binary- authorization/](https://cloud.google.com/binary-authorization/) They don't all do all the pieces. The hardest part is going to be integrating whatever enforcement solution you choose with your upstream CI/CD pipeline.

Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.

</comment></comment><comment><USER21> Fascinating, the part we may get the most out of is "Adopting similar controls in your organization" \- not just Google For Everyone Else.

</comment><comment><USER22> I read the CIO-level summary!

Woo hoo hoo! Im portant.

</comment><comment><USER23> _> We want to have confidence that the administrators who run the systems that access user data cannot abuse their powers._

So "Binary Authorization for Borg" is a defense against getting Snowdened.

<comment><USER24> It's more a defense against getting NSA'd (via the specific threat model of an attacker secretly replacing a security service with an implementation that looks very similar but is much easier to crack).

<comment><USER25> More generally you might say it supports rule of law. If something happens according to procedure then it's ok.

You might not think that's much of a guarantee, but it beats the alternative where things happen due to shadow processes.

<comment><AUTHOR> I think that's right. I would strengthen that statement slightly - it's about ensuring that no actor - whether an insider, or someone who has stolen their credentials, or otherwise compromised them - can perform an action that single handedly accesses user data, without it being known to another actor - <USER2> access logs, via approvals, etc.

In terms of the upstream introduction of a new vulnerability, Binary Authorization for Borg can only verify that the code was in fact merged. See the section on third party code, "When importing changes from third party or open source code, we verify that the change is appropriate (for example, the latest version)."

Disclosure: I work at Google and helped write this whitepaper on Binary Authorization for Borg.</comment></comment></comment></comment>


Deep Learning Business Models - <AUTHOR> http://npbay.es/deep-learning-business-models.html <comment><USER2> I didn't know there was a deep learning gold rush. Maybe this explains the crazy number of stars on my libdeep library on Github, while there being no comments or issues raised.

Deep learning is not any sort of magic bullet. It may be marginally better than other machine learning methods in specific contexts, but I'm not convinced that there are going to be any deep learning tycoons or deep learning entrepreneurs (were there any SVM tycoons?). But I suppose as a buzz term "deep learning" is better than the meaningless "big data". Just replace the latter with the former in the marketing literature.

<comment><USER3> I've been noticing a slight trend among the same group of people that are likely to use the big data buzzword without really understanding it, to also use deep learning in the same way, to simply mean "gain business insights from [obviously big] data".

As far as I know the only gold rush is around marketing surrounding this and related buzzwords, i.e., it's the latest thing that your business absolutely _must_ be doing to keep up with your competitors. That particular usage of course has as little to do with actual deep learning as the misappropriation of big data has to do with anything.

Fortunately this trend has been a bit slower to take off, presumably because whereas big data is a fairly nebulous concept, it's much easier to correct someone when they talk about deep learning quite wrongly.

<comment><USER4> That's the exact market I'm cashing in on. But rather than just be someone in the space who talks about it, I made it[1].

I think at the end of the day, the stuff talked about in the media may or may not have some merit (otherwise why would google or these other companies put resources in to it?)

Rather than read the blogspam, read the papers instead though. Try to understand the merits of what's going on and apply it to your use case.

[1]: [http://deeplearning4j.org/](http://deeplearning4j.org/)

<comment><AUTHOR> Blogspam? I demand satisfaction!

<comment><USER4> Let me clarify: Techcrunch articles talking about papers being published.

Blogspam to me is just something that talks about the stuff at such a high level, there's no meat in it. Within that subset I'm talking about academic concepts where you can learn a lot more if you just read the papers.

<comment><USER4> Before I get bombarded here, I think it's best to clarify that the word blogspam is a term thrown around a lot around here.

When the press talks about an academic paper, they tend not to add much value in terms of actually explaining what's going on. I think people drawing their own conclusions from the original works is the better way to go. Obviously not everyone will agree with me here, but so be it.

</comment></comment></comment></comment></comment></comment><comment><USER5> If you believe a few assumptions:

1\. Machine learning will come to play a more important role in the future (not less)

2\. Machine learning is a wide field with many areas of complexity and a wide variety of applications, many not yet discovered

3\. Deep learning is an exciting area in machine learning research showing promising (state of the art?) results in several domains

Then I think a few conclusions follow:

1\. New tools will address this market, both free and commercial.

2\. Services will be a major part of this ecosystem (see history of databases, ERP, CRM) and those consultants both use and sell tools (applications)

3\. Deep learning is interesting, quite possibly worth using, and changing rapidly. But it doesn't negate what came before it (or after).

So the answer here is all of the above models will be important, with the application of machine learning to everything really being the larger umbrella opportunity, and deep learning currently being an interesting avenue of research?

<comment><USER6> Does your company have customers?

<comment><USER5> Yes

</comment></comment></comment><comment><USER7> "Deep learning requires a ton of tuning and tweaking, and getting good results is as much art as science."

Funny when you think about it : Deep learning is supposed to avoid that ^^'

<comment><USER8> I think you're confusing deep learning with strong AI.

<comment><USER9> No, deep learning really does automatically (read - without much art) learn good features, that's its main purpose. Problem is that deep learning itself is not trivial to use.

</comment></comment></comment><comment><USER10> WTF is 'the deep learning gold rush'? (Also, the HN title does not match the article title, which is: "Deep Learning Business Models".)

Would love a better explanation from someone than this article gives to support the notion of some kind of massive 'Deep Learning' market that is yet untapped.

<comment><USER11> > the HN title does not match the article title

Right. We changed it. The submitted title was "Business models in the deep learning gold rush".

</comment></comment><comment> dj-wonk > Deep learning requires very large training sets, and these shouldn't be > shipped around a lot.

To the extent that this is true, companies that offer these services may be driven to integrate more closely with customer data. This may involve custom in-house deployments or ways of getting the data in a cost-effective way from, say, Amazon S3, or wherever the data lives (HDFS, etc).

This leads me to speculate on an additional business model, "Behind The Firewall" Software Deployment. This could be somewhat different from the others suggested in the article: 1. Sell hardware; 2. Open source plus services; 3. Hosted API, "Deep Learning as a Service"; 4. Individual deep learning services.

<comment><USER4> I think there is something to be said for the "deep learning gold rush" I'm one of the ones trying to cash in myself by being an independent player in the space with my own distributed deep learning framework[1].

The goal of data accessibility can be solved by an abstraction layer that auto vectorizes (transforms in to matrices) the needed data at runtime, trains the nets on that particular mini batch of data, and continues on.

That's what I'm trying to do with a concept of a DataSetIterator[2]. This understands how to pull in the data, and handles all the logistics while the runtime only knows about DataSetIterators.

I'm also partnering with a former cloudera engineer in the hadoop space to take on in process YARN deep learning[3]. Data should not be moved. It should be processed and left where it is. I'll be interested to see the innovations in this space in the coming years.

I don't believe deep learning as a service is the way to go, I think behind the firewall deep learning apps will be the way to go here.

[1]: [http://deeplearning4j.org/](http://deeplearning4j.org/)

[2]: [http://deeplearning4j.org/customdatasets.html](http://deeplearning4j.org/customdatasets.html)

[3]: [https://github.com/jpatanooga/Metronome](https://github.com/jpatanooga/Metronome)

</comment></comment><comment> dj-wonk For many (most?) analytics tools, the application developer has to specify what gets recorded and what gets fed as an input to predictive analytics. I expect to see more tools that assume _any_ data is fair game; e.g. all data is worth at least a quick look. These tools will probably figure out how to select what is interesting enough to examine more deeply.

</comment><comment><USER6> The only gold I see in that gold rush is from acqui-hire.

</comment><comment><USER12> Agreed, was unaware that there was a gold rush, anyone know about specific companies in this space that are still active?

<comment><USER4> Ersatz Labs is in the space, and we're in the process of launching as well [wait till tomorrow ;) ] At the end of the day, companies that focus on apps will be the ones that get bought or cash in. I don't think "machine learning" appeals to businesses. 30% more revenue because of a more accurate model sounds pretty good to me though.

[1]: [http://www.ersatzlabs.com/](http://www.ersatzlabs.com/)

</comment></comment><comment><USER13> kaggle++

</comment><comment><USER14> ARGHHHHHHH</comment>