Making Web Components Work - <AUTHOR> https://engineering.mixpanel.com/2018/06/12/making-web-components-work/ <comment><USER2> I've been using web components in production for a while now and it's great. Our front end "stack" consists of a single polyfill and Webpack. Use template literals for templating, so you don't even need handlebars/mustache anymore. Webpack lets you write SASS that is compiled directly to CSS and inserted in your shadow DOM with an ES6 import, so no more style sheets for anything but high level page layout. Everything is standards based web components written in vanilla ES6, transpiled for browser compatibility down to IE10.

One major issue we've had though, which wasn't touched in this article, is inter-component communication among siblings. Sure you can just do a global event bus, and that works, but I've yet to see an elegant solution for this yet.

<comment><USER3> _> > Use template literals for templating, so you don't even need handlebars/mustache anymore._

You can do better than template literals. You can use TSX, which gives you compile-time verification for tags and attributes, in addition to JavaScript expressions.

See: [https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

With TSX (which is JSX written using TypeScript, you get things like syntax coloring and indentation for tags, because HTML and JavaScript are both first- class citizens in TSX.

<comment><USER4> I've only been using React for a few weeks but the comparisons on that page to React are FUD and the incompatibility with web components is just plain wrong and mixing them is covered here [https://reactjs.org/docs/web- components.html](https://reactjs.org/docs/web-components.html)

<comment><USER5> From the page you linked: "Events emitted by a Web Component may not properly propagate through a React render tree."

React components are brittle, that's not FUD. For example, CSS classes used by React components can clash with other React components, or with the page that includes them. What's FUD about that?

<comment><USER6> That's misunderstandong of the technology. React has nothing to do with styles, it manipulates DOM. Handling styles is up to you, and it's extremely easy to use CSS modules.

<comment><USER7> _> > React has nothing to do with styles_

That's one of its limitations.

React is a component technology and doesn't solve the problem of clashing styles, element ids and so on. Web components is a component technology that does.

<comment><USER6> No, it's not a limitation, it's called separation of concerns, I don't want my component framework interfering with the job of Webpack or application runtime. I want to use my preferred (also easy, standard, ...) solution.

> clashing IDs

React solves that one, not through namespacing though. You never need to use IDs with React.

> clashing styles

React gives you power to solve this one by your preferred solution. You can use expressions in your JSX, and thus it's very easy to do one of the following:

\- Generate optimal global CSS stylesheet with no code repetition, generate classnames on the fly ([https://github.com/typestyle/typestyle](https://github.com/typestyle/typestyle))

\- Import your CSS file as a module using Webpack - classnames are guaranteed to be unique; additionally, similar approach as TypeStyle (global optimal stylesheet) can be set up

\- Use just "inline" styles (preferably not really inlined in your JSX) since React will keep it updated for you as well

<comment><USER8> >You never need to use IDs with React.

If you don't care about accessibility then yes.l, but try using properly annotated aria attributes without appropriately scoped ids(which you can do in react, but it's not free).

<comment><USER6> Hmm, right now I truly don't (that's the business requirement :-/). I'll investigate, thank you.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I still find it bizarre that no one has stated the obvious yet:

Having a component tree (because the rendering model of a browser requires it) does not mean state management needs to be cramped into the same tree or use a tree in the first place!

A DOM tree itself doesn't do any kind of binding and it doesn't do inter- component communication. (it merely offers events) Why should web components? Keep them as dumb as DOM nodes please.

A lone H1 element doesn't register itself on some event bus, doesn't observe attribute changes and doesn't create odd 'actions' tied to some obscure state management system. And it shouldn't.

<comment><USER10> I only recently started looking at upgrading from angularjs to angular and web components were one of the things that made me question the emporer's clothes..

Zone js implements zones and by that they apparently mean exactly 1 zone.. making a supposed abstraction where you can't safely add 2 implementations of web components (or apps?) to 1 page without planning for that with 1 global setup for them..

My initial impression of shadow DOM is that I would get the same scope separation as iframes with a nicer method of passing data and describing the layout.. Then I assumed web components were this missing piece finally implemented.. now I'm wondering if I completely misjudged and everyone else really wanted a complicated footgun where seeming builtins are colliding with your namespace?

</comment></comment><comment><USER11> For me, the biggest plus of web components is the potential simplicity of unifying the document's object model with that of your application. Every JS framework, like React, Angular, Vue, etc. seems to have a parallel OM that either wraps or renders into the DOM (Angular seems to have about 5 of them).

The result is your can never just use the basic DOM APIs and devtools to inspect and interact with your application's components. Instead, you always have to get at them through some other API, and understand how the UI and state you see in the DOM is produced and updated by some mediating layer (virtual DOM, view hierarchy, etc.). It feels like trying to get at the truth by talking with two different people, who each only possess a subset of the facts.

<comment><USER12> These layers were created for efficiency, not for their own sake; there's no "DOM transaction API", so every DOM mutation causes a reflow. Thus, you mutate a virtual DOM, render the resulting changes to a new subdocument, and then replace an existing DOM node with that new subdocument.

<comment><USER11> Incorrect. This idea was a result of some early React users misunderstanding the purpose of the virtual DOM, and has unfortunately been thoughtlessly repeated ever since.

In reality, browser engineers are not that stupid. Mutating the DOM will queue a layout operation, but it will not actually occur until the current JS task has finished executing. Within a JS task, such as an event handler, an XHR completion, or a setTimeout, you can mutate the DOM as many times as you like, and it will only result in a single layout pass.

(The exception is if you try to read back some measurement from the DOM, such as an element's bounding box, after mutating it. In this case, the browser does have to block while it performs layout, but that is not something can be solved with virtual DOM).

So, what is the purpose of the virtual DOM? It was invented to allow React to provide the illusion of full re-rendering. React's authors wanted to a provide an experience similar to that found on the server, where an entire HTML page is re-rendered from scratch for every load. In that way, there is never any possibility of part of the HTML becoming stale, as it all gets recreated from scratch each time.

However, the browser DOM is not designed to be blown away and recreated from scratch all the time. Nodes are expensive objects, spanning the JS and C++ worlds. Recreating the whole DOM tree each time any part of it needed updating would be too slow. So, instead, they created the virtual DOM as an intermediate data structure. React renders the virtual DOM. The virtual DOM is diffed against its previous state, and then the changes are applied to the actual DOM tree. In that way, every component's render() method can be executed, but only those parts of the DOM that have actually changed will be updated.

It's a nifty optimisation, but it's not about avoiding reflow, it's just another method of dirty checking, similar to that done in other frameworks like Angular or Ember. It's just that React chooses to diff the data structure produced by render(), rather than diffing the model data that is later used for rendering.

<comment><USER13> Please read this blog post titled "How to win in Web Framework Benchmarks" [https://medium.com/@localvoid/how-to-win-in-web-framework- be...](https://medium.com/@localvoid/how-to-win-in-web-framework- benchmarks-8bc31af76ce7)

It goes into some details how different approaches in different frameworks work, and why. Moreover, it shows how you basically need to re-implement Virtual DOM and other tricks in vanilla JS code to approach the same speed.

Yes, browser engineers are not that stupid. But they don't batch operations as efficiently as a proper Virtual DOM implementation would (including efficiently handling event listeners, looking for clues like `keys` on repeating DOM elements etc. etc.).

<comment><USER11> That article doesn't quite support what you're claiming. The Vanilla JS implementation uses optimised DOM mutation techniques that are inspired by how the Virtual DOM libraries do things, but it doesn't re-implement a Virtual DOM. Yet it's faster than any of the Virtual DOM implementations its benchmarked against.

So the takeaway is that DOM mutation can be slower or faster depending on the techniques you use. Using a Virtual DOM library can help you improve performance, because these techniques are often baked in, but they don't intrinsically result from using a Virtual DOM: You could write a V-DOM library that didn't use them, and was slow, and you could write, for example, a static template library that did, and was fast.

In theory, a compiled, static template approach should be faster than V-DOM (or anything other than a set of totally bespoke and optimised vanilla JS functions for each app operation). Because while a compiled template does not have the turing-complete flexibility of something like JSX, it has the advantage of knowing in advance exactly which parts of the DOM can change and how, which eliminates the need to build and diff the Virtual DOM tree.

<comment><USER14> > In theory, a compiled, static template approach should be faster than V-DOM

Maybe faster in basic microbenchmarks. As soon as you start optimizing UI library for complex applications, there are many other optimization goals you should focus on, like the size of the generated code per component type, the amount of different code paths(increase probability that executed code is JITed), etc.

Virtual DOM solves many issues, it is not just diffing, it is also a lightweight component model, possibility to add lightweight synthetic events, single code path for creating/updating/destroying DOM nodes, the simplest algo that handles complex tree transformations, etc.

</comment></comment></comment></comment></comment></comment><comment><USER15> I just started using Web Components, and in my opinion, their future is definitely very bright. Now that HTML imports have been squashed, they're basically just standard JavaScript objects imported as modules, as they should be. Before, you created a class/object that had a property like foo.el which was the element it was associated with, but the link was tenuous, and required a bunch of code to keep things in sync, and various component styles could easily clash. Extending native elements and the Shadow DOM is a great way to contain everything. Wiring them up to something like Redux or MobX is trivial.

The only real missing piece is the concept of props over attributes. If I want to pass an array of ids to a sub-component declaratively, there's not really an easy way to do it. Hopefully there will be some consensus about this soon. The best thing is that this is all part of modern browsers without libraries, or even precompilation. Not every web app needs massive libraries, so having web components as a built-in, light-weight component system is fantastic.

<comment><USER3> _> > If I want to pass an array of ids to a sub-component declaratively, there's not really an easy way to do it._

Yes, there is. See [https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

<comment><USER15> Err, no. What part of that mass of crazy non-JavaScript did you think was "easy"? Wow. I didn't even know TSX was a thing. To each his own, but yet another dependency written in indecipherable pseudo-script (regardless of its popularity) is not my idea of easy.

</comment></comment></comment><comment><USER16> Web Components were interesting but too complicated and never gained traction at Autodesk (my former employer) where we just ended up going with React, which is actually a pretty good solution to the crappy ecosystem that browser based programming has become.

</comment><comment><USER17> I read Polymer is switching to JS modules with 3.0, sounds like a right step for Web Components :)

<comment><USER18> We already did :)

</comment></comment><comment><USER19> Just started using Vue.js and the components approach makes a lot of sense. Web Components is a not-quite-ready pure JS approach? Vue, polymer, react native... I feel confused every time I read "Web Components" because it means something different depending on context.

<comment><USER18> Web Components means the standards of <template>, Custom Elements, and Shadow DOM. There's an overview here: [https://developer.mozilla.org/en- US/docs/Web/Web_Components](https://developer.mozilla.org/en- US/docs/Web/Web_Components)

Polymer has always been a set of helpers for making Web Components. There are others like SkateJS and Stencil.

Vue is not normally Web Components, but they have an option in CLI 3 to compile to Web Components.

React and React native have basically nothing to do with Web Components, though React can use Web Components because Web Components are just HTML elements.

<comment><USER13> > Web Components are just HTML elements.

Yup. And you can't use Polymer elements in React because React passes data as attributes whereas Polymer expects properties.

And then there's the issue of event handlers etc. etc. etc.

"Web Components" are now a largely non-intersecting collection of mutually incompatible frameworks and libs: [https://custom-elements- everywhere.com](https://custom-elements-everywhere.com)

Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere

<comment><USER18> > And you can't use Polymer elements in React because React passes data as > attributes whereas Polymer expects properties

This is mostly React's existing opinion that elements don't even need properties set, and is not the fault of Polymer or Web Components. Most Polymer elements are fine with simple types like strings or numbers being set as properties or attributes.

> "Web Components" are now a largely non-intersecting collection of mutually > incompatible frameworks and libs: [https://custom-elements- > everywhere.com](https://custom-elements-everywhere.com)

That is a site that says how well _frameworks_ work with Custom Elements, ie do they make closed-world assumptions about HTML that interfere with using Custom Elements. It says nothing much about what a Web Component is, so I'm not sure how Web Components could be "non-intersecting".

> Good luck using Polymer's <custom-element binding="{{a.b}}"> anywhere

I know you troll every Web Components and Polymer discussion you can now, but this is just a non-sequitur. Polymer's template syntax is only used to implement elements with Polymer. `<custom-element binding="{{a.b}}">` would only ever occur in a Polymer template and is not intended to be used "everywhere", so no luck is needed, thank you.

<comment><USER13> > I know you troll every Web Components and Polymer discussion you can now

This is not trolling. This is called hard truths that Web Component proponents are completely blind to.

Riddle me this: why is it that there are almost no resources, blog posts, projects, or comments that talk about and use vanilla Web Components? 99.9% of posts and videos about WebComponents always immediately use Polymer, or Stencil, or... or... or...

The answer is easy: Web Components are crap, pure and simple. They are unusable in their present form. You need to throw in a data binding library, a templating library, a virtual DOM, a callback handling library, a..., a... etc. Better still, throw in a full framework like Polymer or Angular.

Even the project we're commenting on, titled "Making Web Components Work" needs the following to make them work: "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats".

How the hell is that "Web Components", "standards" and "work"?

When you call out all these inconsistencies, half-truths and outright lies about Web Components, you're called a troll, go figure.

\---

As an aside. I remember saying that templating in Web Components is also crap because you have to use horrible DOM APIs or `innerHTML` to do anything useful. Obviously I was called a troll etc. However, when Apple proposed Mustache-like template instantiation [1] the same very people who called me a troll pissed themselves with joy and wonder. You _know_ Web Components APIs and specs are crap. You chose to bury your head in the sand, turn a blind eye and preach how "WebComponents are the future". Well, it took browsers 11 years to get to two-thirds of jQuery's capabilities. It will take another 50 to maybe get one-third of capabilities of Web Component frameworks or React, or Angular, or Vue (hell, of even Snabbdom).

[1] [https://github.com/w3c/webcomponents/blob/gh- pages/proposals...](https://github.com/w3c/webcomponents/blob/gh- pages/proposals/Template-Instantiation.md)

</comment></comment></comment></comment></comment><comment><USER20> I think the next major leap forward in HTML app development will happen when Web Components are portable across client framework types so it's not necessary to rewrite every visual element when switching from Angular6 to Vue or even something compiled to WASM in a few years.

<comment><USER18> This is exactly what Web Components already do. Web Components are just HTML elements, and generally usable in any framework or with no framework.

<comment><USER20> Oh -- awesome! I've been focused on back-end and mobile the past few years. I guess it's time to dive into Web Components!

<comment><USER21> Check out [https://www.webcomponents.org/](https://www.webcomponents.org/)

</comment></comment></comment></comment><comment><USER22> Off topic.

Not to be harse. But for a company as big as Mixpanel, the blog UI is terrible. No branding at all and seems unprofessional.

Even more ironic is they say this as the first line in the post: "Clean, attractive user interfaces and effective user experience have always been pillars of Mixpanel's products."

They should look at companies like GitHub, Facebook, Twitter, and the likes for an example.

<comment><USER23> You _are_ looking at the engineering blog, which--judging by the rest of the mixpanel.com site, probably isn't borrowing much from the marketing/ux side of the company.

Check the Mixpanel blog ([https://mixpanel.com/blog/](https://mixpanel.com/blog/)) and you'll find it the brand consistency more similar to the other tech companies you mentioned.

I'm actually okay with engineers spending less time on shiny css and more time on the content of their posts.

</comment></comment><comment><USER24> One thing their example doesn't handle is browser location history on clicking elements in their UI.

Maybe it was due to how simple the example was, but having to click back many times based on how many times a user used the interface is just bad design.

<comment><AUTHOR> Sorry about that, the example was developed as a standalone SPA with history for the routing. But since we decided to embed it into the blog post itself, the pushState routing doesn't make a lot of sense in that context.

<comment><USER24> Ah I figured it'd be something like that.

I'm looking forward to a future where we use web components.

</comment></comment></comment><comment><USER25> They remind me too much of WPF (.net ux tech) which I never cared for. Once I moved to web dev with React I found that much simpler. Web Components seems like a step backwards to me.

</comment><comment><USER13> The lib "does so by providing an easy-to-use state management and rendering layer built on Virtual DOM (the basis of the core rendering technology of React). Through use of the Snabbdom Virtual DOM library and first-class support for multiple templating formats".

How is this "making web components work" any different from making DOM work via snabbdom or React?

</comment><comment><USER26> A few months ago Mixpanel notified me that they had been accidentally transmitting and storing passwords for some customers due to a UI issue. I wonder if the re-architecting had something to do with that or if it was the resolution.

</comment><comment><USER27> Web Components are awesome. They will be the future. That said, I feel React has good future just because of React Native. It's amazing that you can develop highly performant applications and target multiple platforms

<comment><USER28> Didn't Facebook stop using React Native in their own app (or part of it) because it's performance was poor? Or the file size was gigantic, there was something wrong...

</comment></comment><comment><USER29> I'm surprised that the Mixpanel engineering blog is hosted on Wordpress with the default theme. The default theme doesn't align with their designed brand, and it makes me suspicious of whether they have taken steps to secure the installation. For this low-effort of a blog, I would have expected them to use Medium.

</comment><comment><USER30> while web components are interesting, how can you do native apps on top of it when needed? e.g. vue-native, react-native etc, or at least support by something like Electron etc.

or is it strictly a web-browser-only thing?

<comment><USER31> It's a browser spec, so yeah browser-only. Electron is browser-based (Chrome), so web-components can be used there.

Check out [https://github.com/Polymer/pwa-starter- kit/wiki](https://github.com/Polymer/pwa-starter-kit/wiki) for concrete examples using LitElement ([https://github.com/Polymer/lit- element](https://github.com/Polymer/lit-element))

</comment></comment><comment><USER32> i use stenciljs web component compiler. it is not a framework... it is great as it lets you do things without having to worry about browser support.

</comment><comment><USER33> web components are never happening

<comment><USER34> That seems like a rather bold statement without much reasoning behind it. What in particular makes you think that web components are "never happening"?

<comment><USER35> This looks less than promising: [https://caniuse.com/#feat=custom- elements](https://caniuse.com/#feat=custom-elements)

<comment><AUTHOR> That's the deprecated v0 spec, fyi.

<comment><USER35> [https://caniuse.com/#feat=custom- elementsv1](https://caniuse.com/#feat=custom-elementsv1) doesn't look much better.

<comment><USER36> Out of the 4 major browsers, 2 major browser vendors have support for the base stuff, 1 has it behind a flag being tested ready to be turned on, and 1 doesn't have any support yet...

That's pretty far from "not happening"</comment></comment></comment></comment></comment></comment>


Singularity University: Cyber Crime and Terrorism - <AUTHOR> http://mccannatron.com/2011/12/08/singularity-university-cyber-crime-terrorism/

<comment><AUTHOR> I went to one of the classes taught by Singularity University today and my mind was completely blown about whats going on in the world of cybercrime. Happy to answer any questions or relay them to Marc Goodman who gave the talk.</comment>


More than digital quilting: the maker movement may be new industrial revolution - <AUTHOR> http://www.economist.com/node/21540392?repost=1

<comment><USER2> The Maker Movement is going to destroy manufacturing as we know it, and that is going to hurt emerging economies more than anyone wants to say.</comment>


Ask HN: What APIs do you wish existed? - <AUTHOR> Are there APIs that you wish existed to help make your work easier? Help your startup? Or just allow you to build cool products? <comment><USER2> \- US & State Government tax information. The tax code is amazingly complex. It would be good if you could figure out the tax implications of various events. Better if they simplified the tax code to where this was possible. Moreover, data.gov so far is a disappointment. Maybe they'll improve it. But I'd love to dig in to purchasing and personnel costs for every branch of government.

\- Good stock market historical tick data (and streaming data). Opentick tried for a time, but mostly you need to contact expensive services. This makes it hard to mess around.

\- A good local event API. Lots of companies have tried, few have good results.

\- LinkedIn: They've been promising an open contact book API since 2007, but have kept it closed. If they had an open API (that lets you actually store data/invite), it would mean a lot of sites would be building on them.

\- My dream: The big scientific journals would require everyone publishing a paper to upload all relevant datasets to a central repository which could be queried.

\- Anyone you have an account with (Financial firms, banks, vendors) would have a standard commerce API. Sure, today you can export stuff in Quicken, etc formats, but Mint had to do a big deal with Yodlee to get the data in a uniform, queryable way.

And, mad props to Microsoft for opening the Bing API with pretty good terms. Google used to have a search API and it had horrible terms. Then they decommissioned it. Who would have guessed that MS would be more developer- friendly than G?

<comment><USER3> _Who would have guessed that MS would be more developer-friendly than G?_

Anyone who's done Microsoft-based development? MS is incredibly developer- friendly compared to many platform vendors. It's a point of business strategy for them (if memory serves me, that's what Ballmer's infamous "developers, developers, developers, developers" thing was about in context).

Just don't try and mix in any technology from one of MS's competitors and you'll be fine.

<comment><USER4> True, they are developer friendly. .NET is a good platform. It's extensive and well documented. There is innovation in C# as well. But the purpose of all that goodness is to make you sell their licenses. Where Oracle has their salesforce, Microsoft has their developers to do the selling for them.

Unfortunately their licensing is from an era that has come and gone. Building software that uses things like Windows Server, SQL Server, SharePoint or Office means to limit your scale to what they call "Micro ISV". You provide that package to your client and 95% of your revenues go straight to Microsoft.

You can build on their stuff but you won't scale and you won't grow, not because their technology doesn't scale, but because their licensing doesn't scale.

<comment><USER5> _You can build on their stuff but you won't scale and you won't grow, not because their technology doesn't scale, but because their licensing doesn't scale._

What about their licensing for Azure? Does that scale or is it more of the same?

<comment><USER4> I don't think it's entirely clear yet what direction Azure will take. The base offering using only .NET and Windows with simple storage is priced almost exactly the same as google app engine. It's difficult to compare to Amazon because the architecture is so different. Google and Azure (I believe) won't let you do any serious computation in memory whereas Amazon does support that very well.

However, look at SQL Azure. Microsoft thinks that their SQL offering is worth paying 66 times what you pay for google's database (or Azure BLOBs&Tables) and that's just for storage alone ($1 per GB, maxing out at 10GB right now). Add data transfer and you may get to 100 times.

Yes SQL Server has vastly more features than google's db, but does it make me 100 times more productive or profitable? I don't think so. If I need more SQL features I could run Postgres on Amazon or use Amazon's MySQL service for roughly 10% of what SQL Azure costs.

So if SQL Azure is the model of what's to come then I think it's indeed more of the same.

</comment></comment></comment></comment></comment><comment><USER6> My body, starting with my brain. Please provide clear documentation.

<comment><USER7> I would like:

      storeNewBrainMemory();

and

      saveBrainToDisk();

<comment><USER8> I think brain.serialize()

would be pretty cool...

<comment><USER9> thoughts are to writing as data structures are to serialization stream

<comment><USER10> I'm thinking that an electronic interface could greatly increase transfer speeds though.

</comment></comment></comment></comment></comment><comment><USER11> Banks. Online payment processing is a mess.

<comment><USER12> Interestingly, since the failure of OFX, many many banks in North America prefer screen scraping because they can guarantee the web interface has accurate data since their actual customers use it. Conversely, these banks find supporting APIs to be highly fragile since no one is watching them.

I find that logic amazing, but considering how old the online banking software is and the high risk of changing it wholesale, I don't think they are in a position to fix it in the short term.

</comment></comment><comment><USER13> Free or low-cost tv schedule api. Currently one has to pay about $500 per market/region per month.

<comment><USER14> Not exactly an API (just data), but it's cheap (USD20/year):

<http://www.schedulesdirect.org/>

<comment><USER13> Too many restrictions on the use of the data:

<http://www.schedulesdirect.org/sagreement>

</comment></comment></comment><comment><USER15> Generally: I wish practically everything had an open API. It's incredible what people can build when they have decent access to an API.

Specifically:

TuneCore, as it would make my startup idea a whole lot easier.

School registrations. I really wish there was some standardized API for universities. That'd make it possible to plug in the classes you want to take along with when you want to take them and get back a personalized schedule. As it is now (at least for my school), you pretty much have to write down on paper the classes you want to take along with when they're available and do it all yourself. I'd prefer something like this be standardized so one could make one website that would serve all universities and their students.

<comment><USER16> +1 for school registrations. My school only provides READ access to the courses catalog but not WRITE access to actually register courses.

[http://courses.illinois.edu/cis/2010/spring/schedule/index.h...](http://courses.illinois.edu/cis/2010/spring/schedule/index.html) [http://courses.illinois.edu/cis/2010/spring/schedule/index.x...](http://courses.illinois.edu/cis/2010/spring/schedule/index.xml)

I really wish that they will provide one in future.

</comment></comment><comment><USER17> Appliances: stove, oven, coffee maker, refrigerator. Various other household items: garage doors, locks, etc. This overly expensive, yet dumb, flat panel TV we just bought. Extending out to the driveway...my car. The energy meter on the side of the house (read-only access, obviously, just to keep the power co. happy). The most mundane stuff could use an API, if you ask me!

<comment><USER18> have you heard of <http://www.pachube.com>?

</comment></comment><comment><USER19> Gmail.

But more than a specific API, it would be cool if websites simply provided an XML(/JSON/etc) version for every urls. Eg, <http://news.ycombinator.com/item.xml?id=955077> would return the data in this page in XML format. This would be pretty simply to create (at least as read- only API), handle the situations where people resort to HTML scraping and effectively remove the need for API docs.

<comment><USER20> GMail has APIs - POP3 and IMAP.

<comment><USER19> There's also RSS, but all of these provide access to mail functionality, while Gmail is a lot more than that. The uses I have in mind are closer to Google Labs' "Unsend", or having web service-like access to moving stuff around in gmail, creating alternate UI etc.

</comment></comment></comment><comment><USER21> Real-estate API (open homes, home sales by zip etc)

<comment><USER22> zillow has a pretty decent api

<comment><USER21> Zillow is a start but there is a ton of data that is tied behind MLS licensing and Realtor associations. That data should be free and public.

<comment><USER23> Yes. I got hired to integrate MLS data and man was that a nightmare. Many are surprisingly low-tech and almost all use different formats. There is a half- assed attempt at standards (RETS), but that's for accessing the data not the data itself. Not to mention getting and presenting the data legally--each MLS group has different rules about what you're allowed to display (and it can be incredibly restricting). tl;dr the project went down in flames.

I'd love to see Google get ahold of the data and make it available through Base.

<comment><USER24> I'm sure Google will get there eventually, as they're doing with all industries that traditionally make information inaccessible. Google just enhanced Google Scholar to be a major competitor to Westlaw, which should make a lot of frugal lawyers happy.

</comment></comment></comment></comment></comment><comment><USER25> Sports statistics. NFL, MLB, NBA, etc.

<comment><USER26> I work for a sports data integration company, so you can get this data easily. Oh, you mean for free? Yeah, that's not gonna happen any time soon. _Someone_ has to pay people to collect those statistics and then make them available.

<comment><USER27> A lot of people really enjoy keeping track of sports stats. Maybe some sort of a wiki would work well for this purpose?

</comment></comment></comment><comment><USER28> An API into the postal system of every country.

<comment><USER29> How about one of these:

<http://l-mail.com> <http://postful.com> <http://earthclassmail.com> <http://postalmethods.com>

</comment></comment><comment><USER30> APIs into hospitals medical data.

<comment><USER31> And schools: class registration

</comment></comment><comment><AUTHOR> I'll start. Wish there was an API that:

1) Allowed me to find high quality, license free images easily.

2) Let me access LinkedIn data. I know LinkedIn has an API, but its not open.

<comment><USER32> On flickr there is an option to search for commercially usable images. To do it from the API you need "prior arrangement" though.

</comment></comment><comment><USER33> Disclaimer: I'm an amateur in every sense of the word but eager to learn. A Craigslist API could make for some really cool mashups but many of those could probably also be created using the RSS feeds they provide. Do you see any substantial advantage to a distinct Craigslist API?

<comment><USER10> There was a mashup that did something with Craigslist and photos, but Craigslist shut them down. I think it allowed you to view the listing with the photos in it (rather than needing to click on each listing to see the photos).

</comment></comment><comment><USER34> Hacker News API?

<comment><USER24> I can't imagine what you would need other than HN's RSS feed. What did you have in mind that could extend Hacker News?

<comment><USER35> comments for a given thread, score of posts and comments, and user information.

<comment><USER24> Can't you do that already with a simple scrape?

<comment><USER24> "scrape != API"

No kidding. He's looking to get "comments for a given thread, score of posts and comments, and user information", which you can use an HTML parser (like Hpricot if you're using Rails) to retrieve any info you need.

<comment><USER24> Care to explain why I'm being downvoted?

EDIT: If you're going to downvote, please leave an explanation to teach me what I'm missing. I'd sincerely appreciate that. Thank you.

<comment><USER20> _to teach me what I'm missing_

You're being annoying. Nobody wants to screenscrape, it's awkward and fiddly and fragile and verbose and requires reverse engineering and is wasteful of bandwidth.

It really doesn't matter if you _can_ get the information by screenscraping. The thread topic is "what would you like an API for?", not "scorn people about what they want an API for."

 _Care to explain why I'm being downvoted?_

Because I want less of this sort of thing on HN. I want it to fall to the bottom of the page, and to discourage it in future. I cannot articulate precisely what it is that I want less of, it's a big vague fuzzy blob of things, some of which I even agree with, and your few posts here and above here are within it, so down they go.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Subway. On the stations here they have displays, that show in how many minutes the next train will arrive (which is real-time data). Would be cool if they broadcast this information on the net, you could see if you need to hurry to the station or not.

<comment><USER23> Petition your local system to get on it. BART makes the data available which is pretty slick:

<http://www.bart.gov/schedules/developers/index.aspx>

</comment></comment><comment><USER37> a real-world grep. this might be solved in my lifetime, since books, notes, etc are all moving to digital. sometimes i just wish i could grep for x and it would find x in all my books, notebooks, etc.

<comment><USER38> I'm actually working on this problem. It's remarkable the amount of content we actually generate and the number of services/mediums we generate them on. Simply fetching all the data and hosting it centrally is a large enough problem, let alone indexing all of it.

</comment></comment><comment><USER39> IMDB's API

<comment><USER40> Have you tried TMDb? <http://api.themoviedb.org/2.1/>

I've played with it and seems good enough.

<comment><USER41> TMDb is pretty decent (I use it to keep track of my personal movie collection [1]), but a lot of the data is missing/incomplete.

It's a whole lot better than nothing, but it's far from perfect.

[1] <http://moviedb.samwarmuth.com>

</comment></comment></comment><comment><USER42> A solid global small business geo data API.

Fortunately there are a few different startups working on this, and a rudimentary way to hack it with Google AJAX API but there's still nobody who can allow me to simply punch in name+city search and give me the address, geocode meta reliably for any city in the world and without cache restrictions.

Google has it all but needs to open this data up better.

</comment><comment><USER43> Centralized Spam filter API with an access to Gmail spam filter, Yahoo Mail spam filter, etc. to report spam and check emails for spam.

<comment><USER10> Why centralized? Why not just make it decentralized with peering?

</comment></comment><comment><USER44> A OCR API. The Google Docs OCR API is a good start, but it's tied pretty closely to GDocs. I'd like to post an image and get back text.

<comment><USER45> Is that even possible at the moment? Most software I've tried just isn't ready for something like that (granted, I haven't tried any of the commercial products). Tesseract is pretty good, but definitely not perfect.

<comment><USER44> "Not perfect" is good enough for me. There's a whole class of applications where being able to take a photo of some words and have at least a few of them understood would be useful. I'd like to be able to index against the words that can be understood, and present the original image as the search result.

<comment><USER46> You can do this with the Evernote API. It was designed for search, and does a good job with both print and handwriting.

[http://www.evernote.com/about/developer/api/evernote- api.htm...](http://www.evernote.com/about/developer/api/evernote- api.htm#_Toc200272594)

</comment></comment></comment></comment><comment><USER47> College class schedules (as well as registration schedules). Currently, even the best are buggy, slow and cumbersome. I have to take certain classes at different schools in order to fulfill my degree requirements and keep working full time. So, I often need to search for a single class across multiple institutions for the time that fits.

<comment><USER48> I had the same problem, worked over-time (startup life), and took classes at two institutions as a way around the bureaucracy for pre-reqs. I ended up automating the class look up process using selenium on Firefox. But then they called me in because my account was making requests every second, and were worried more students would try what I was doing and crash the system. (The DID tell me to keep checking for open spots, they never said to not use scripts)

This was the only way I could get the classes I needed to graduate on time

<comment><USER47> Ouch, polling every second? How often did the data actually change?

</comment></comment></comment><comment><USER49> Hulu, Clicker, Mixcloud, Comcast's "TV Everywhere", Spotify, Mog, iTunes store, Amazon VOD & mp3, etc.

</comment><comment><USER50> A reverse lookup for finding all the shortened URLs associated with a given canonical URL.

<comment><AUTHOR> Interesting... what would be the application of this? Any ideas you can share?

<comment><USER50> Lots of possibilities, but think backtweets.com as an example of something which would be much easier to accomplish if such an API existed.

<comment><USER51> We opened up an API for backtweets a while ago: <http://backtweets.com/api>

What would you build with it? Some people are using it in cool ways right now, e.g. hype machine uses it to power a twitter music chart.

</comment></comment></comment></comment><comment><USER52> <http://en.wikipedia.org/wiki/Direct_Market_Access> _to_ <http://en.wikipedia.org/wiki/BRIC>

</comment><comment><USER53> Suggest/autocomplete. Well, it's not really enough to call it an API, since it's already just AJAX requests for JSON, but it'd be nice if the format was standardized and they all supported JSONP so that it can be cross-domain.

</comment><comment><USER54> Craigslist

<comment><USER55> I've always wanted to break into CL's space due to their utter disregard for the garden of web APIs growing up around them. They could be doing so much more with their service for the community, and I don't mean going the big time corporate route obsessed with short-term revenue.

There have been many CL clones(kijiji), but none gained enough eyeballs to make an interoperating API work. I suspect these attempts failed because they didn't pay attention to the community and instead acted liked closed corporations right out the starting gate. I thought the CL killer would appear on Facebook, but that hasn't happened because of totally different dynamics in Facebook's ecosystem.

Actually, I'm surprised that I haven't seen someone one here posting a hacked up API wrapper around Craigslist as a mini-startup.

</comment></comment><comment><USER56> An API that implements multiple tableview row editing in the iPhone SDK.

</comment><comment><USER57> An semantic equivalent to an "#include" or "using" statement that looked for the library on a central repository instead the local disk, automatically managing caching and versioning.

<comment><USER58> maven?

</comment></comment><comment><USER59> Pandora - Music Genome Project. I've been working on a media player, AuraMP, for a number of years and I've really wanted to plug into sites like Pandora.

<comment><USER32> what about <http://www.last.fm/api>?

<comment><USER59> Correct, they do have an open api but it just doesn't always seem to have the ability or content that Pandora has. I would like best to use as many of the major providers as possible.

</comment></comment></comment><comment><USER60> Music. I'mm yet to find a good api which let's me query information about artists / songs etc.

And the good local events api someone mentioned would also be great.

<comment><USER61> check out <http://developer.echonest.com/>

</comment></comment><comment><USER62> A concurrent REST api, written in scheme. That support a parallel/multicore environment. Which in turn compiles to C.

</comment><comment><USER63> Fantasy Football APIs, partuclarly Yahoo's.

<comment><AUTHOR> Wow, I forgot about this - couldn't agree more. Have been waiting for this for a long time.

</comment></comment><comment><USER64> Any and all data from the Federal Government. There cannot possibly be enough structured data coming from there.

</comment><comment><USER65> Image processing API? <http://urlimg.com>

</comment><comment><USER66> I would love to have a food nutrition info global read write api

</comment><comment><USER67> An open Linkedin API.

<comment><USER68> Wish granted. I think LinkedIn released their API to the public this week.

<comment><USER67> They did. Rock on!

</comment></comment></comment><comment><USER69> mlb game data, within 24 hours of each game

<comment><USER70> i wrote a parser for NBA games, get the data straight from yahoo. Using Python and BeautifulSoup, piece of cake. I would think MLB could work the same.

<comment><USER57> Yeah, HTML scraping ESPN.com is not very hard. I did it for college basketball once in a strange sort of database that attempted to predict March Madness brackets. It worked really well for teams that had encountered each other during the season... except only 2 or 3 pairs of teams had ever played each other during the regular season. Works much better on NBA and NFL games, where there are far fewer teams, they see each other more often, and the rosters are a little more static.

<comment><USER10> > _Yeah, HTML scraping ESPN.com is not very hard._

I've seen a few people respond with this "you can just html scrape that." Sure you _can_ HTML-scrape for the information, but the topic of this "Ask HN" is about what APIs you would like to see. Maybe he already HTML-scrapes ESPN.com, but would prefer that there was an official API for it, no?

<comment><USER57> Yeah, but I prefer real solutions, regardless of how ugly they are, rather than wishful thinking for so-called "elegant" solutions.

<comment><USER10> No offense, but isn't this wrong discussion for you then?

</comment></comment></comment></comment></comment></comment><comment><USER71> iTunes Connect (Contains sales, payments, reviews, ratings for publishers with products in iTunes)

</comment><comment><USER72> Google Tasks

<comment><USER73> This guy reverse engineered the google tasks ajax calls and created a perl module interface for it:

<http://github.com/nickspacek/Net-Google-Tasks/>

Works decently. Could easily be replicated in any language.

</comment></comment><comment><USER74> Stubhub & movie tickets

</comment><comment><USER75> Health insurance

</comment><comment><USER76> Traktor Pro

</comment><comment><USER77> doWhatIMean("parse a bunch of names and sort")

This is from the same framework that has winTheGame() and doMyHomework()

<comment><USER20> and justMagicallyWork(), the call that papers over leaky abstractions, off-by- one errors, misunderstandings, logical errors in your thinking and just does whatever it is you were trying to do.

>>> data = urlopen('example.org/lovelydata/2009/') YetAnotherException: [...]

It needs some kind of web form cookie login non-standard authentication. Aaargh I can't spend any more time on this sub-project it was only supposed to take two minutes!

>>> import bigGuns _Warning, Universe enters a fragile state. Tread carefully._ >>> data = justMagicallyWork(urlopen('example.org/lovelydata/2009/')) Success. Cost: 12 Karma. >>> del bigGuns _normality restored_

Phew!

</comment></comment><comment><USER78> Local movie times. It's stupid this isn't available from someone. The only thing it's going to do is increase the number of people going to see a movie.

Maybe there's one now but 3 years ago there wasn't one and I had to build a scraper for Yahoo movies to build the product I wanted.

<comment><USER20> There's one for the iPhone <http://code.google.com/p/metasyntactic/wiki/NowPlaying>

(From a Microsoft C# compiler/parser guy, no less).

<comment><USER79> Meta's an ex-Microsoftie -- he's currently at Google.

</comment></comment></comment><comment><USER80> An API for a service that prints and snail mails documents cheaply and professionally in the Netherlands. That would let me build a cool online billing app.

</comment><comment><USER81> I'd like an API that had a function similar to this:

         make_this_many_dollars_magically_appear_in_my_bank_account(1000000000);</comment>


On the Trail of Nazi Counterfeiters - <AUTHOR> http://www.thedailybeast.com/articles/2014/09/20/on-the-trail-of-nazi-counterfeiters.html

<comment><USER2> Robert Harris's 1986 book Selling Hitler: The Story of the Hitler Diaries covers some of the same ground and was an excellent read (and introduced me to his later books which are at least as good).</comment>


Ask HN: Another twist on dating web sites? - <AUTHOR>

Most of dating web sites I've seen are more like online catalogues (with some relatively minor exceptions). You browse for girls/guys, pick those who look better and sound more appealing to you. It feels somewhat disgusting — like you're shopping for a soulmate.
What if one used another approach to help people with dating, such as urban quests of some sort that might lead to a dating with person without prior exposure to any this person profile? Would it be viable?
I am pretty much aware of some security concerns it might raise, but nevertheless :]
P.S. And yeah, if this idea sounds interesting to you, feel free to implement it (if it is worth it, I have no idea yet). I had some ideas on how to implement it (business-wise, security-wise, etc.), and would be happy to share them as I don't have much time for this project at this time. <comment><USER2> I had an idea at one point that the current sites go about it the wrong way. They charge money to talk to the people, encouraging the catalog effect. My idea was that you charge a reasonable fee to join, and then the system makes some guesses (not any of the "compatibility stuff", but provide a list of reasonably close matches so you'll have at least one thing in common) and provides you the list. You can't see anything except their username and initials at first. You then have "correspondence levels," basically, after x exchanges it reveals a little more about the profile (say, list of hobbies), and so on. So you don't really know much about them at first, and it's after having to communicate that you can see what their profile.

As for the group outings one, I just had an idea about that, too. Most people have difficulties finding people they click with, and getting that initial conversation going. I think a 6 person semi-speed date would be a way to alleviate that. Essentially, 3 guys, 3 girls (or however their preferences lean, match it so there's 3 and 3) and they rotate through. Each guy would get 15-20 minutes with each girl. And during the "date", they have two coaches, one being a guy, and the other a girl. It's encouraged for the coaches to interrupt and pull someone aside to give them a brief bit of advice, etc.

<comment><AUTHOR> this coaching stuff sounds a little bit awkward for me :) isn't dating a little bit more an intimate kind of activity?

</comment></comment><comment><USER3> I've had lots of ideas for dating sites: setting up group outings like ad hoc speed dating, a rating mechanism for actual dates, a virtual currency system where you could "buy" access to deeper levels of people's profiles, and many more.

The problem is always the chicken/egg question. How do I get a sizable membership to the site. The only answer I see is piggybacking onto a social network like Facebook.

<comment><AUTHOR> I had this piggybacking idea too, it is pretty obvious</comment></comment>


How to Enjoy the Often Exhausting, Depressing Role of Parenthood - <AUTHOR> http://www.theatlantic.com/health/archive/2012/01/how-to-enjoy-the-often-exhausting-depressing-role-of-parenthood/250901/

<comment><USER2> "Spending time with your spouse is also an important tool for getting through parenthood"

Goes right along with the best advice I got early in my marriage: "A babysitter is cheaper than a divorce."

</comment><comment><USER3> "Remember the cost, idealize the benefit"

In other words, it's magical. As in, magical thinking.

</comment><comment><USER4> how about some love for the people who want to be parents but can't?

<comment><USER5> We don't have a shortage of kids, we have a shortage of good parents. Adopt!

The problem--at least here in the US--is that we create too much friction in adoption, both legally and socially, resulting in people going to insane lengths to conceive children in risky situations, rather than taking in children who desperately need loving homes.</comment></comment>


Space Invaders - <AUTHOR> http://www.computerarcheology.com/Arcade/SpaceInvaders/ <comment><USER2> > Interestingly, vector graphics like in Atari Asteroids did not hit the > market until 1979.

Not true. The vector graphics game Space Wars was released by Cinematronics in 1977.

[https://www.arcade- museum.com/game_detail.php?game_id=9691](https://www.arcade- museum.com/game_detail.php?game_id=9691)</comment>


Seven Strings Over Iowa - <AUTHOR> https://www.tabletmag.com/jewish-arts-and-culture/271918/seven-strings-over-iowa <comment><USER2> Would have been fascinating to hear a little about how the current crop of seven and even eight string guitars that have been popularised by metal musicians grew (or didn't) from this. I know they're different beasts used for different purposes, but that's where my thoughts immediately went.

</comment><comment><USER3> There's a pile of lovely Brazilian music using seven-string guitars. It's often used as a counterpoint to samba melodies and in the style known as 'choro'.

Yamandu Costa is worth a listen to hear how far a technically brilliant soloist can take the instrument.

<comment><USER4> You're going to love these guys:

[https://youtu.be/H5ii0wnMEBs?t=41](https://youtu.be/H5ii0wnMEBs?t=41)

[https://youtu.be/3j0Jx9IThII](https://youtu.be/3j0Jx9IThII)

</comment></comment><comment><USER5> Seven string guitars are used extensively in metal (I have two downstairs!), but I don't see a reference to them here; bit disappointed to see such a prominent use ignored.

<comment><USER6> Yeah it threw me off with the hero image being of a common electric 7-string type, but the article focusing strictly on an early-music relic.

</comment></comment><comment><USER7> I can't believe I've been living in the "seven-string capital of the world" for 10 years and didn't even know it.

<comment><USER8> Ha, me too!

</comment></comment><comment><USER9> Missed opportunity: the cult film "Six-String Samurai" set in post-apocalyptic Las Vegas and featuring the Russian-American music of the Red Elvises could have instead been entitled "Seven-String Samurai."

But I don't know whether the Red Elvises ever played a seven-string guitar. And their style wasn't exactly up the lines of old, traditional Russian music.

[https://en.wikipedia.org/wiki/Six- String_Samurai](https://en.wikipedia.org/wiki/Six-String_Samurai)

</comment><comment><USER6> What I found really interesting is the tuning of this referenced Russian 7 String guitar. By today's standards, that's nothing out the range of a regular 6-string in the common Drop-D tuning (only a whole step lower than "regular" guitar).

Now we're seeing 6-strings tuned to Drop-B (Forth lower) and Drop-A (Fifth lower) in metal genres (And I'm sure even lower).</comment>


Netflix CEO Thinks the Time is Ripe for Web TV - <AUTHOR> http://www.readwriteweb.com/archives/netflix_ceo_thinks_the_time_is.php <comment><USER2> Watching recorded programs at a time determined by a schedule set by a corporation is very old school...

...but continually declaring different times as the point where the transition happens from the old to the new school is just naive.

It is the same as the whole Web x.0 thing. Its more useful as a marketing tactic but you should not try to assign discrete periods of time to technologies that are continually evolving.</comment>


Hack-petya mission accomplished – Petya ransomware decryptor - <AUTHOR> https://github.com/leo-stone/hack-petya <comment><USER2> Must be pretty nice to have a son-in-law who can, oh, you know, just come over for Easter and reverse-engineer the cryptographically complex malware holding your system hostage.

<comment><USER3> Less at stake on this one, but I had a friend in college whose father was a business owner. He was stuck with some database software that all his customer records were locked in; he wanted to migrate but had no way out other than copying them all over by hand. Up until one weekend when his daughter brought home her boyfriend, who dad had regarded as a dirty hippie up until then. Turns out dirty hippie was a pretty good hacker and in the course of a few hours, he wrote a program to export dad's database into a usable format.

Moral: your significant other may not be impressed by your hacking skills, but you might win the family over for life in a few hours.

<comment><USER4> I am guessing the daughter was less impressed by the event? I mean, she went out of her way to find someone her parents disliked, and it turns out he is just what his father was looking for... :)

<comment><USER5> I realize it was a tongue in cheek comment (at least interpreted that way), but that was a serendipitous opportunity for the young lady's boyfriend. I know I've had several such opportunities with my now in laws. Regardless of the differences of opinions, nothing wins over people more than just helping when help is needed.

</comment></comment></comment></comment><comment><USER6> Jeez, thank God that malware authors are too stupid to include gnupg within their code.

I'm afraid of the moment when they get more clever. Or if they include filesystem drivers that silently encrypt every file... if done right, you can even compromise backups transparently for weeks until arming, so that backups are essentially useless too.

<comment><USER7> > so that backups are useless too

It can hardly be considered a backup if it's easily compromised from your every day computer. In a good backup configuration your computer only have read and "append only" privilages for the backup so past snapshots are safe.

Having said that not many people have this kind of config (including me).

<comment><USER8> Not sure why you're being downvoted, you make a very valid point.

<comment><USER7> I guess it's because this kind of backup doesn't mitigate an ongoing compromise of your machine (much like what the GP talked about). I don't think any backup can protect for that. However a good backup limits the damage to the timeframe of the machine being compromised (if your machine is compromised for 1 day you might only lose that day's new data).

</comment></comment></comment></comment><comment><USER9> > Last, but not least, it fires up a genetic solver which gets us the key in a > few seconds.

That's pretty impressive! On the other hand, is it a general vulnerability of Salsa that genetic solvers can break it? Sounds like a huge vulnerability.

<comment><USER10> It's a 16-bit version of Salsa20, which is far less secure. Proof: this project. I have no clue what possessed the author to do this.

Stop hand-rolling crypto, people! Ransomware needs security too. :(

<comment><USER11> My guess is that the authors wanted to ensure they could encrypt a full disk quickly.

<comment><USER12> Maybe it's just a test to see how quickly this was broken.

</comment></comment></comment></comment><comment><USER13> What's the shelf-life of one of these ransomware fix utilities? I'd be inclined to assume that if they operate by exploiting a flaw in the ransomware, the ransomware author can simply "fix" the bug and the utility no longer works.

<comment><USER14> Here the crypto used by the ransomware seems to be thoroughly and systematically broken, so while it's certainly possible that a stronger variant will appear, I have my doubts on the author's capacity to do much "better" any time soon. I'm far from being a cryptographer, but at a glance it looks so weak I have to wonder if it's deliberate.

<comment><USER15> >at a glance it looks so weak I have to wonder if it's deliberate.

Any suppositions as to why it would be deliberate?

<comment><USER14> Well, I can't say that it's deliberate, but it's definitely some "interesting" choices.

A reasonable Salsa20/20 implementation on a modest processor encrypts on the order of 400MiB/s [0][1]. So that the author went to the trouble of halving the number of rounds and changing the word-size when there are perfectly good and plenty fast off-the-shelf Salsa implementations strikes me as rather strange. Surely this is not the bottleneck on most employee's machines.

And then there's the apparently tiny keyspace used. You could argue that this makes the key more "user-friendly" (!), but just a hex representation of a random 256bit key would seem much more natural, and the poor targets are hardly in a position to complain.

[0] [https://www.cryptopp.com/benchmarks.html](https://www.cryptopp.com/benchmarks.html) [1] [https://cr.yp.to/snuffle.html](https://cr.yp.to/snuffle.html)

<comment><USER16> Actually customer service is _very_ important to these operations. They have to create trust that paying will relieve your machine of their infliction.

</comment></comment></comment></comment></comment><comment><USER17> I have the strangest urge to build a tiny user space around the malware kernel that gets booted by the infected MBR... _opens IDA_

<comment><USER18> Careful, I don't know about you but anytime I have a thought that ends with "let me just open IDA real quick" nobody sees me for 2-3 weeks minimum.

<comment><USER19> I don't know what IDA is, but you get an upvote, because I have had this exact experience so many times... so many times.

If I could have a dollar for everytime I put my head to a random problem and came out 3 months later... I'd have more than fifty dollars.

<comment><USER20> IDA is _the_ industry-standard binary disassembly tool. Expensive, so used over (dramatically) cheaper competitors like Hopper mainly by people whose company pays for a license :D

<comment><USER21> Or people who have ...disassembled the locked down original?

<comment><USER22> I got to play with some hackmes in a hackathon and my teammates got frustrated by the crippled IDA demo version that they just downloaded a pirate version.

Amusingly the readme for the pirate version said "I cracked it with IDA Pro" or something along those lines.

</comment></comment></comment></comment></comment></comment><comment><USER23> I'm guessing the ransomware uses Salsa10 because it's fast?

According to [https://www.cryptopp.com/benchmarks.html](https://www.cryptopp.com/benchmarks.html), Salta20 is 4x faster than AES - and if I understand it, Salsa10 is half the iterations.

<comment><USER24> Salsa20 / ChaCha20 are quite nice when you want to do byte-for-byte file encryption. It's a good choice in a lot of situations.

The unusually reduced number of rounds is more difficult to explain, since I expect hard drive I/O would be the bottleneck in almost any situation. Maybe it's just a little more "stealthy" to not have elevated CPU usage while the ransomware is incubating.

</comment></comment><comment><USER25> "Don't roll your own crypto" strikes again.

</comment><comment><USER26> Are there any security researchers that can comment on this? I'm very confused about the efficacy of a genetic algorithm on a hashing function. Having read some of the comments, I'm only more confused (how can the symmetric difference be a useful fitness function?).

</comment><comment><USER27> Anyone has a link to the malware sample?

<comment><USER28> Looks like someone got their hands on a sample to throw in theZoo. Also, live malware sample warning! BE VERY CAREFUL WITH THESE.

hxxps://github(dot)com/ytisf/theZoo/tree/master/malwares/Binaries/Ransomware.Petya

</comment></comment><comment><USER29> Great!

</comment><comment><USER30> HN typical question:

Why Go?</comment>


Hadoop on 5 machines vs r17 on 1 machine - <AUTHOR> http://www.rseventeen.com/blog/r17_vs_hadoop.html

<comment><USER2> ZeroVM and r17 would be great to see together local to data stores.</comment>


SpaceX runs on Linux - <AUTHOR> http://lwn.net/SubscriberLink/540368/3f653787a5e4ec49/

<comment><USER2> _For navigation, Dragon uses positional information that it receives from the ISS, along with GPS data it calculates itself. As it approaches the station, it uses imagery of the ISS and the relative size of the station to compute the distance to the station. Because it might well be in darkness, Dragon uses thermal imaging as the station is slightly warmer than the background._

That's an impressive system. I never thought about the number of safety systems and fallbacks needed to ensure safety when navigating around the ISS.</comment>