Startups Selling to Other Startups: A House of Cards? - <AUTHOR> http://techcrunch.com/2016/02/11/startups-selling-to-other-startups-a-house-of-cards/ <comment><USER2> Are there any good data sources on how much money is actively in play for this scenario across the industry?

I hear a lot of doom and gloom "the apocalypse is upon us" headlines, but I have yet to see numbers that show that all of these overly-funded startups without sustainable businesses going _poof_ will have a massive impact on the broader picture (or the public markets outside of a few edge cases that are already seeing corrections).

Sure some people will be out of jobs, and that really sucks, but the market is still hot and they will be scooped up into companies that are doing just fine. Are there really enough people employed by unsustainable startups to do sizable damage to the economy or the housing market should they all disappear overnight?

Serious question--I've seen lots of hearsay, but little actual data on this specific aspect of things.

<comment><USER3> Facebook and Google's combined revenue grew by $14 billion in 2015 compared to the year earlier. We are hardly in "the apocalypse". Internet properties as a whole are still growing even if many smaller ones are not, and the big gorillas still want to grow and have the money to make large acquisitions.

<comment><USER4> But, a substantial portion of their revenues come from startups paying them for advertising. If the lake dries up, the river will get lower as well.

<comment><USER5> _But, a substantial portion of their revenues come from startups paying them for advertising_

Total VC funding in the US is on the order of $50 billion per year. If you assume 20% of that goes straight to advertising, which is unlikely, that's $10 billion. Facebook and Google sell about $100 billion a year worth of ads.

I would guess that Google and Facebook have less than 1% of their revenue concentrated in VC-funded startups. They simply don't have enough money to matter relative to the size of the broader economy. It is not 1999 -- Yahoo is not making headlines with money it got from startups whose valuation is driven by Yahoo making headlines.

People in the startup community think the startup community is co-extensive with the tech industry. AppAmaGooFaceSoft beg to differ.

<comment><USER6> You are missing the broader system.

It's about #theCapitalCycle of an entire ecosystem...#theUnicornEconomy

<comment><USER2> Please elucidate us then, with data, as to what that broader system is and how patio11 (who gave some pretty compelling numbers) was wrong.

<comment><USER6> Already did.

[https://medium.com/@alexanderbcampbell/more-than-500bn-of- we...](https://medium.com/@alexanderbcampbell/more-than-500bn-of-wealth-has- been-created-on-paper-by-the-unicorn-economy-f5a56514a0c1)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> "By 1998, Yahoo was the beneficiary of a de facto Ponzi scheme. Investors were excited about the Internet. One reason they were excited was Yahoo's revenue growth. So they invested in new Internet startups. The startups then used the money to buy ads on Yahoo to get traffic. Which caused yet more revenue growth for Yahoo, and further convinced investors the Internet was worth investing in."

[http://www.paulgraham.com/yahoo.html](http://www.paulgraham.com/yahoo.html)

</comment><comment><USER8> On hand they say if everyone is digging for gold, start selling shovels. Everyone is doing start-ups, maybe sell them dashboards, log aggregation services, api testing tools, virtual whiteboards and such.

On the other hand, if you sell to just a few, now your own volatile future is coupled with theirs. You might run out of cash, hire bad people, make bad decisions -- the company fails, and that chance is now multiplied by the chance that other company make bad decisions, bad investors, burn through all the cash etc.

So it seems the answer is to just sell to a lot of startups, to spread your risk. That might end up like the sub-prime mortgage crisis. The risks everyone thought were decoupled from each other, weren't actually. So when start-ups start imploding and investors start looking at ... I don't know solar, hyperloop, or robots, the panic spreads etc.

<comment><USER9> I think where the shovel/pickaxe analogy breaks down with startups is that they often think their tech is part of their secret sauce when really they're just doing standard things in an interesting vertical, but still insist on reinventing the implementation to justify using up their funding to match the target runway/projections.

</comment></comment><comment><USER10> I don't think that any startup wants to sell to other startups forever. However, in general startups are early adopters, so it makes sense to start there in a vertical-by-vertical approach. No startup can sell a future "billion dollar" vision to investors with a market constrained to just other startups. A startup is differentiated from other businesses by growth prospects and potential, and a startup must grow outside of the startup market to survive. A landing page may not signal long-term vision, but the plan to disrupt a broader market exists in most of the companies.

Some degree of a "House of Cards" certainly exists. Look at Y Combinator - part of its value is being able to sell within the network to other YC startup companies. At demo day, many of the logos on the "current customers" / "traction" slides are other YC companies. When a company doubles in size every year, almost everything breaks - from HR to communication to hiring - so, of course it make sense to start sales with customers whose pains are so dire that the sales cycle is days instead of months. The customers may be startups, but revenue is still revenue. A startup is defined by growth, though, and at some point leads in the startup market get exhausted and a company must search for prospects beyond other startups to continue growth.

Breaking out of a single vertical, whether it's selling to other startups, a market outside of San Francisco, or even a product that doesn't cater to just high-end consumers is the key to making it huge. Uber started in a niche market - high-end on-demand chauffeur services to people who could afford their own car, but Uber managed to go beyond that vertical. Shyp just shut down Miami - that's a far bigger signal than the health of their SF market. Can Mattermark find a market outside of tech investors? That's the key to justifying their valuation. Many startups will not develop a repeatable growth strategy outside of other startups, but alas many startups do not succeed.

No startup can continue the growth prospects that define them as a startup by just selling in a narrow market, whether it's startups, San Francisco, or on- demand black cars. There's low-hanging fruit in any approach, and the ability to continue growth beyond that defines success.

</comment><comment><USER11> Doesn't SV seem just a bit too... incestuous at this point.

There's a whole wide world of people and businesses that could benefit from software.

<comment><USER12> so go invest in one? Oh that's right, neither you nor anybody else invests in other than hot SV startups. You're voting with your dollars here. No seriously - if you're not writing checks you can't complain about what the recipients of those checks have to do to get the money. You're acting like they have a choice.

<comment><USER13> How exactly do you invest in a startup, and how can you see their financials? It's not like they're listed on NASDAQ. And how would you know your shares are secure, without bringing in lawyers? Investing in a startup seems complicated to me.

<comment><USER14> For starters, you need to be an accredited investor [1]. If you don't make more than $200,000 a year or have a net worth exceeding $1 million, those are the intermediate goals to aim for.

[1] [http://www.investopedia.com/terms/a/accreditedinvestor.asp](http://www.investopedia.com/terms/a/accreditedinvestor.asp)

<comment><USER12> this changed recently! :) I believe your information is now out of date.

</comment></comment></comment></comment></comment><comment><USER15> If you're a startup, never waste time talking to or doing deals with other startups.

<comment><USER16> I understand your concern, but depending on what product(s) you are selling, startups (and by startups I am referring to the PG definition of startups) are actually great customers for a couple of different reasons:

\- Willing to try new products that help them focus their (limited) resources on their core product.

\- No legacy integration issues.

\- Generally high quality employees that provide strong product feedback.

\- Willing to move quickly.

The downside is of course that they may not have a lot of money and in total, usually represent only a very small part of the market, so you have to use the initial feedback / momentum you got from your work with startups to move into more traditional customer segments, but they are still a great way to get started. The risk is of course that you end up building a product that _only_ works for startups, but as long as you understand that risk and validated that the problem you are solving is not exclusive to the startup community, in my experience you should not avoid working with (reasonable) startups.

</comment></comment><comment><USER17> Other startups seem like a natural starting point to sell B2B software to. At least if you take the Crossing the Chasm point of view (which can be argued against for B2B I suppose). I'd say Innovators or Early Adopters in the B2B domain are very likely to be other startups a fact that is somewhat ignored in the post. At least it might be a bit dangerous to assume that you can simply sell to more established companies instead.

</comment><comment><USER18> Interesting to see the author list AWS and Twilio as money saving services.

Do executatives actually believe AWS and Twilio are saving them money? That seems like the least sensible reason to use the services.

I thought the AWS/Twilio value was based on the fact that most companies don't have the know-how or time to recruit or manage or build their own infrastructure, and it's better to spend more so you can focus on your core competency.

<comment> lloyd-christmas Paying $1k for a service is cheaper than paying $70k for a person. That seems pretty sensible to me. They don't care about how it gets done, just how much it costs to get it done.

<comment><USER19> aah that would explain why many code based startups have horrible design-by- accretion architecture. Just throw more servers at it. I bet the multiplier effect will start to exhibit in all sorts of interesting ways quite early on.

<comment> lloyd-christmas Early growth is typically more important than scaleability. What's to scale if you don't have any customers? It will probably cost more in the long run to achieve the same goal, but that assumes you make it to the long run from both starting positions.

Regardless, I don't think the causality exists to the extent you're describing. It's no different than any open source dependency. Sure, I know how the functions in underscore work. That doesn't mean I need to take the time to roll a deep clone. Saving time and money doesn't imply cheap and broken.

<comment><USER19> Yeah I'm feeling a bit jaded from seeing stuff that was decade old technical debt that's never been maintained, yet critical to the code's operation. At some point early on when you do have customers you want the reengineering crew in otherwise you will end up with a monster which requires far more bodies and stress to maintain than otherwise necessary. but I see a lot of places where they don't seem to care about stress and bodies piling up.</comment></comment></comment></comment></comment>


Show HN: Mobile feedback your users will love - <AUTHOR> http://audobox.com

<comment><USER2> This seems really smart. It would be fun if the author could post some metrics here. I'd be really curious if you guys ran a split test of audio vs text feedback to see how the numbers change. It seems obvious this will lower the barrier for many people to leave feedback. If you have hard numbers on this that are convincing, they should definitely be front-and-center on your website.

One potential concern is that spoken feedback on the whole will be less precise and clear than written feedback. In general though I've found feedback from users is generally pretty poor on the signal to noise ratio anyway, giving only broad strokes of where problems are, so this might not matter. As a fun bonus with audio feedback you can pick up their tone of voice to gauge just how pissed off and frustrated they really are!

<comment><AUTHOR> From our pseudo-scientific testing, we got ~5x voice feedback over email feedback. We're still early in the process, so we don't have any rock-solid numbers.

One advantage we found from spoken feedback is that on mobile, people tend to be unwilling to type out a very detailed report, whereas that same level of detail is pretty fast to say.

And yeah — you can definitely tell how happy (or unhappy) they are with the product :)

<comment><USER3> Interesting.

Im curious, Are you also getting blank audio files?

<comment><AUTHOR> We only upload files that are at least two seconds long to prevent exactly this problem.

</comment></comment></comment></comment><comment><USER4> This is such a great idea. I love how much you've worked to ensure it takes the least number of taps possible to send feedback.

One suggestion: show a meter or light or any kind of feedback that the user is being loud enough. I suspect your #1 problem with bad user-submitted feedback will be "couldn't really hear anything".

<comment><USER5> Good suggestion- that may be worth adding.

Anecdotally, though, we've been using this ourselves for a while without seeing that. People seem to get that they should speak clearly.

</comment></comment><comment><USER6> We used to have a similar in-house developed audio feedback in one of our apps [1]. The engagement rate was low. We replaced it with the standard email feedback and we got an order of magnitude more feedback. Plus with email, you automatically get the ability to answer back and communicate with the customer. In my opinion users prefer UX concepts they are used to, even if they are less efficient. But it probably also depends on the app type and its audience. So best to test it for yourself and see what works.

There was also a startup doing this [2]. Looks inactive since their iOS SDK is "coming soon" for already a year.

[1] [http://focusofmyday.com](http://focusofmyday.com) [2] [http://saygent.com/](http://saygent.com/)

<comment><AUTHOR> Great to know — thanks for the info. We got a sharp rise in feedback when we were using this in our app, but like you say, it's probably to some extent dependent on the particular app.

</comment></comment><comment><USER7> Are you sure users are comfortable actually speaking out loud?

I feel there's some kind of "sound barrier": we're used to typing and swiping and rotating but we rarely get to talk without immediate feedback...

<comment><USER8> I'm definitely not. Most places I'm using my mobile device, rather than a Real Computer, are because I'm in some public setting: on the street, in a restaurant, on a bus. Not good places to record a monologue.

<comment><USER9> At the same time, the thing in your hand is also a phone.

<comment><USER10> These days, I would prefer to say that the thing in your hand _has_ a phone app, and for many people that app gets very little use.

</comment></comment></comment></comment><comment><USER11> Interesting. I think this is a good idea seeing as how I kind of do this already except with voice transcribe on the keyboard.

Unlike a text report though where users can edit or take a moment to collect their thoughts, I think voice feedback will create alot of recordings where people are unprepared and thus unable to structure deeper more meaningful feedback.

That said, I am curious on how many users accidentally release their hold or submit multiple feedbacks as they add more info?

</comment><comment><USER12> We used to have a similar feedback system and tried it with our in-house development & QA but it didn't work well. Giving feedback takes lot of writing and rewriting, with traditional writing, users can review and make corrections but with audio users will have to delete and start everything from scratch again. This is our personnel experience, you may be seeing better results as your target audience is different.

</comment><comment><USER13> I've been proven wrong before, but I'm very skeptical that something which requires the user to speak at the phone will convert well.

</comment><comment><USER14> gathering reliable feedback in-app is a nagging problem. i'm excited to see audobox on iOS soon.</comment>


Analyzing stock-based compensation for Twitter and Facebook employees - <AUTHOR> https://medium.com/@fwiwm2c/stock-based-compensation-facebook-vs-twitter-b0ec1f88f791#.i2seqoq01 <comment><USER2> Action Jack is focusing on sales, per the conjoined triangles of success. This is pretty telling.

<comment><USER3> But to get the best sales people you have to give them something easy to sell!

Doesn't sound like Twitter is easy to sell compared to FB.

<comment><AUTHOR> Author here. That seems reasonable. However, spending 5x/revenue $ seems a lot more. Twitter could also spend some of that money on getting more eng hires to make their advertising product easier to sell vs only focussing on sales/marketing. Also, Twitter's biggest challenges have been on the user growth side - so it was surprising to me to see that their SBC spend on R&D is trending lower vs their sales/marketing spend.

</comment></comment></comment><comment><USER4> Twitter's product is significantly less complex than Facebook's. A 1:1 comparison of engineering compensation proportions isn't very relevant.

Additionally, it's not like 100% of their MAU problems can be solved from engineering -- there are significant gains to be made from Marketing, and they can certainly leverage their current engineering talent (which is substantial) to work on product feature tweaks which will generate more stickiness.

</comment><comment><USER5> I'd be really interested in seeing some additional data in this analysis, although it might be hard to come by.

For example, what are the demographics of FB's marketing/sales team vs. Twitter's? I'd be willing to bet on average that younger sales and marketing employees are willing to accept more SBC vs. salary because they have a higher risk tolerance and might be a bit less skeptical. Senior sales and marketing people have more expenses, families, etc. and I'd be surprised if many of them are willing to accept a lottery ticket and its associated tax burden in lieu of guaranteed cash and simplified taxes.

Additionally, without comparing the commission/bonus structure, I think there's a big missing piece of this picture. When you are a market leader and have an easy product to sell, you have less incentive to offer massive commissions than if market sentiment shows you to be on your way out and you need to be aggressive to court strong candidates away from "an easy sell."

Lastly, I'd be curious as to the average tenure of these various functional groups. If equity comes with vesting periods, cliffs, etc., do people stick around long enough to capture all of that SBC? If data says no, that might be an incentive to offer more to groups that are statistically more likely to leave a lot of it on the table.

</comment><comment><USER6> I think analyzing only two companies is too short sighted, it would be better if you benchmarked against 5-10. It could be that twitter is in line with other companies and facebook is actually high - suggesting FB R&D staff get higher comp in SBC than their peers. Also there is little talk about head count, which drives SBC ratios such as this. Another - why compare sbc to revenue, you should compare to expenses. I think the author brings up some good points but is missing key analysis.

</comment><comment><USER7> Could it be that Facebook is just a more compelling platform to advertise on, so they have less need for salespeople to shove it down their customers' throats, as opposed to Twitter?

<comment><USER2> Facebook is definitely a more compelling advertising platform... Given that, Twitter should be doubling down on engineering a better one. That is what I find surprising about these metrics, if they are accurate. Granting the most SBC to Sales & Marketing seems like an admission of product failure.

<comment><AUTHOR> That was exactly the point I was trying to point out. FB is definitely a more compelling ad platform. However, Twitter's biggest challenges (since the IPO) have been wrt user growth. As such, I would have expected them to double down on their product/eng resourcing and build more compelling products vs spending large amount of $$ on their sales/marketing teams. Also, the recent trend is a concern as well where product/eng SBC spend (which was already low as a % vs FB) is going down while sales is going up.

</comment></comment></comment><comment><USER8> journalist get's 5 numbers and keeps massaging them ad nausea

<comment><USER9> You will get downvoted but are still correct</comment></comment>


On Mozilla's forced SSL - <AUTHOR> http://cryto.net/~joepie91/blog/2015/05/01/on-mozillas-forced-ssl/

<comment><USER2> Someone in the other thread had a genius solution to this:

\- All domains should now come free with a domain certificate.

Seriously, this entire problem set is solved by that one single change. It is one of these ideas that once you hear it you cannot un-hear it. We already know (and as this blog post says) that domain certificates have zero cost associated with creating them, so just bundle it with domain registration and soon competition in that space will force the additional cost to near zero (in particular if it is required).

This is a much better solution to "Let's Encrypt" because it scales better, and we don't have all of our eggs in one basket.

So who do we lobby to make this happen?

PS - Domain registrars won't fight this too hard as their customers will be "forced" to buy a "bundled" domain cert'. I am just hopeful that even if initial prices would be higher, eventually the additional cost will be absorbed into the domain registration itself.

<comment><USER3> > All domains should now come free with a domain certificate.

So, every domain registrar should also be a trusted CA?

<comment><USER2> If they meet the requirements other CAs meet, sure, why not? But otherwise they'd have to find a CA to do the signing on their behalf.

</comment></comment></comment><comment><USER4> This post has an incomplete and somewhat dismissive take on certificate pinning.

It's true that pinning involves a degree of trust on the certificate presented on the first connection, and that is a weakness.

But that weakness is mitigated. Browsers also rely on the CA signatures for that certificate (pinning _augments_ CAs, but doesn't replace them).

The potency of pinning is subtle, because nobody trusts CAs (and shouldn't!). You have to think beyond just your browser, and you have to grok that CAs are a finite resource for your adversaries. _You_ trust the CA-signed pinned cert for an HPKP site on the first connection. But other browsers have had that pin cached, and when the pin is tampered with, they _don 't_ trust it. When they see the broken pin, they can do more than just not trust the connection: they can also relay the evidence that a CA is implicated in signing a certificate that breaks a pin.

Google won't say so specifically, but it's not unlikely that some of the last few CAs to have been burned by trying to sign Google sites were caught because of pinning.

Pinning protects more than individual browsers; it also uses the installed base of pinning browsers to protect _everyone_ , not just those using pinning browsers, by turning them into a global surveillance system for compromised CAs.

</comment><comment><USER5> "problems that absolutely need solving _before_ a forced global deployment of TLS can happen"

I'm all for this switch to SSL. But there's no way Mozilla's announcement will effect global deployment of TLS... not with 11.7% market share (NetMarketShare.com, [https://www.netmarketshare.com/browser-market- share.aspx?qpr...](https://www.netmarketshare.com/browser-market- share.aspx?qprid=0&qpcustomd=0)).

The realist in me says this will just frustrate developers as staunch advocates of Firefox pester for working services while higher-ups refuse to justify the cost to suit a possible minority userbase. These users being forced to either switch browser or move service provider.

<comment><USER6> Chromium/Chrome have already proposed a step in the same direction, pushing your market share figure up to 37.4%. [1]

[1] [https://www.chromium.org/Home/chromium-security/marking- http...](https://www.chromium.org/Home/chromium-security/marking-http-as-non- secure)

<comment><USER7> Another related step from the Chromium developers:

[https://groups.google.com/a/chromium.org/forum/#!topic/blink...](https://groups.google.com/a/chromium.org/forum/#!topic/blink- dev/2LXKVWYkOus/discussion)

</comment></comment></comment><comment><USER8> > I do not believe that there is data that is "not important enough to > encrypt".

I _do_ believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. So why encrypt it? The benefit is that we can trust that static content really did come from that domain and wasn't changed by a MitM, but this can be solved by simply including a signature of the content rather than encrypting everything.

SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Signing static content is essentially free, since we can pre-compute them.

If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :)

<comment><AUTHOR> Author here.

> I do believe this. When I visit a static web page over SSL people sniffing > my connection are almost always going to have a good idea of which domain > I'm looking at (either by IP, or the DNS requests I just fired off, etc.), > so the attackers know what content I'm seeing.

The domain is not the same as the content. Far from it. Aside from that, a site being 'static' is not a meaningful data point here.

> SSL is really not cheap CPU wise; it can limit the usefulness of a small, > personal, cheap VPS for hosting even moderately popular content.

Being somebody who runs a HTTPS-only PDF hosting site off such a cheap VPS, I disagree. It does not make a meaningful impact on resource usage.

I'm quite sure you could easily run a static site HTTPS-only from even a LowEndSpirit VPS - these are €3 per _year_.

> If the writer really does believe everything should be encrypted (this > necessarily includes metadata), then I assume he would advocate Mozilla > deprecate supporting for non-Tor connections? :)

No, I do not. Tor is yet another dependency that needs to be available, and there are significant usability (and privacy!) concerns with routing all traffic over Tor.

"Everything should be encrypted" does not come at any cost. There are real- world problems that need solving before this can be made a reality. Just disabling non-TLS connections does not cut it.

<comment><USER8> > The domain is not the same as the content. Far from it. Aside from that, a > site being 'static' is not a meaningful data point here.

For a lot of web pages this is true, but what about sites like restaurant webpages? They have very few actual pages on their site, and they don't change depending on who is making the request. If I request the site over HTTPS, anybody that is sniffing my traffic will know that I'm visiting that domain and thus can request the content themselves. The encryption here is not providing anything.

If you are sending/receiving personalized data, e.g. logins, search requests, etc., then you should be encrypting the requests. You would still be encrypting huge amounts of data for no reason, the CSS and static images used on the site are not being transmitted with or based on any personalized data, so any sniffer will already know that these resources would have been downloaded by you anyway (and I don't care if an attacker sees the CSS of a page I'm looking at anyway).

Requesting these static resources over plain HTTP, but authenticated via hashes or signatures, doesn't provide an attacker with any information they wouldn't already have.

> No, I do not. Tor is yet another dependency that needs to be available, and > there are significant usability (and privacy!) concerns with routing all > traffic over Tor.

And yet Tor is the only way to actually protect against sniffers tracking which domains you visit. If we really care about encrypting all the content - including non-personalized, static content - then I don't see why we wouldn't also care about protecting the domains we visit.

> "Everything should be encrypted" does not come at any cost. There are real- > world problems that need solving before this can be made a reality. Just > disabling non-TLS connections does not cut it.

I totally agree with this. However I think I come to a different conclusion.

TLS is usable precisely because of its insecurity that we have to trust so many CAs. The key problem with any encryption architecture is key distribution, more often than not the more secure the key distribution the less usable the end product is. Its (relatively) easy to get a TLS certificate for your domain that everyone else will trust, but precisely because its so easy makes TLS very vulnerable to malicious certificates.

For the most part TLS is fine, it offers a certain level of security, but is still vulnerable. I'm happy to rely on TLS when browsing google search, online shopping etc, however I'm not particularly comfortable with using it for online banking, and I certainly wouldn't trust it for secure person-person communication.

So instead of trying to fix TLS, I think we should have more choice for the different levels of security I desire: 1\. No personalised data is being transmitted either way => I only need to authenticate the remote content, not encrypt it. 2\. Personalized, but not particularly confidential information being transmitted, e.g. google search, shopping, logins for sites where its not the end of the world if they get stolen => TLS, there's a chance stuff will get intercepted, but it is convenient. 3\. Highly confidential information is being transmitted => Some other protocol or cert distribution mechanism, e.g. for online banking I might only trust a certificate given to me directly by my bank IRL.

<comment><AUTHOR> > For a lot of web pages this is true, but what about sites like restaurant > webpages? They have very few actual pages on their site, and they don't > change depending on who is making the request. If I request the site over > HTTPS, anybody that is sniffing my traffic will know that I'm visiting that > domain and thus can request the content themselves. The encryption here is > not providing anything.

The value of encryption as a whole increases when _everything_ is encrypted, because it is harder for an adversary to distinguish "important" traffic from "unimportant traffic". It may not matter for that domain alone, but it certainly matters in the bigger picture. It significantly increases adversary cost.

> If you are sending/receiving personalized data, e.g. logins, search > requests, etc., then you should be encrypting the requests. You would still > be encrypting huge amounts of data for no reason, the CSS and static images > used on the site are not being transmitted with or based on any personalized > data, so any sniffer will already know that these resources would have been > downloaded by you anyway (and I don't care if an attacker sees the CSS of a > page I'm looking at anyway). Requesting these static resources over plain > HTTP, but authenticated via hashes or signatures, doesn't provide an > attacker with any information they wouldn't already have.

False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on _every_ page.

> And yet Tor is the only way to actually protect against sniffers tracking > which domains you visit. If we really care about encrypting all the content > - including non-personalized, static content - then I don't see why we > wouldn't also care about protecting the domains we visit.

It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity.

> I totally agree with this. However I think I come to a different conclusion. > [...]

Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better.

The "different levels" you suggest are pretty much already implemented as such, except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have.

<comment><USER8> > The value of encryption as a whole increases when everything is encrypted, > because it is harder for an adversary to distinguish "important" traffic > from "unimportant traffic".

Except you can classify a lot of traffic as unimportant by domain. If someone is trying to steal my bank account information encrypting all my other traffic isn't going to help. The easiest attack against TLS is to get a valid cert and then MitM, at which point it doesn't matter how much traffic you're sending to that domain.

I would also be interested in knowing if sending more encrypted data down a TLS channel actually makes it harder to brute force; considering the tendencies for browsers to connection pool there will probably be (relatively) few actual distinct TLS connections.

> False. Assets can leak very easily, disclosing what content you are looking > at. Just identify which assets are not loaded on every page.

Assets are cached by the browser, making it impossible to know if a newly downloaded page included those assets or not. Only downloading assets in plain that are on the root page or on the majority of pages mitigates this attack.

(Also irrespective of if you used TLS, if you requested the HTML over TLS and it included hashes for all its static content you would have a much stronger guarantee over authenticity of downloaded assets if they came from CDNs. Hashing also makes caching much nicer and friendlier.)

This feels more like an argument along the lines of "its not really worth having a separate method for doing authentication without encryption, it complicates things and probably won't be able to be used very often", which is perfectly valid and an argument I'm sympathetic to. It just doesn't support the notion that all data is important.

> It's not. The exit node still sees your traffic - and this is also why > routing everything over Tor is a terrible idea (and incidentally, the same > reason devices like the Anonabox are fundamentally broken). If you tunnel > personally identifying traffic along with "anonymous" traffic, you're > "contaminating" the anonymous traffic with your identity.

But you can tunnel TLS through Tor(?) The idea behind using Tor here is to stop attackers from being able to trivially tell which domains you're looking at.

> Saying that TLS is "not entirely useless" is a very poor argument for not > working on making it better.

My, probably badly worded, point is that its not as easy as saying "lets make it better". Making TLS more secure means coming up with a way of issuing certificates in a more trusted fashion; I don't see how you do that without making it harder to get a cert.

The only other tech I'm aware of that is trying to address this is Perspective, but even that is not perfect.

> The "different levels" you suggest are pretty much already implemented as > such...

Browsers are getting better at supporting pinning, but I don't think any allow you to manually add domains? Its not something that has been advertised and encouraged. My bank certainly doesn't advertise its certs fingerprints in their branches.

> ...except there is no "authenticate but don't encrypt" level, because it's > not a useful or desirable level to have.

And I disagree with you, obviously.

Unless there are actual, provable, benefits to enforcing encryption everywhere, I don't like the idea of anyone removing the ability for me to make the choice. If you think all data should be encrypted, by all means encrypt all your data.

Personally, I don't care if an attacker knows what BBC articles I read. Yes, I know all the dangers that might befall me, but I've made an informed choice based on a risk analysis of my current situation and, well, I just really don't care one way or the other.

<comment><AUTHOR> The quotes are getting very long, so I'm just going to respond directly to points without quoting here.

You seem to be oversimplifying the notion of "privacy" to "stuff like bank details". That is incorrect. _Any_ kind of browsing data that a user does not want exposed to third parties falls under this banner. For some that's just their bank details, for others that's every single site they visit.

The point is that you can't decide for other people what is "private" to them. Therefore, the only acceptable solution is to make privacy opt-out - and that is done by encrypting everything by default.

Asset caching depends heavily on the site, and on whether different pages use unique assets. A cache is not a security feature, was not designed as such, and should not be treated as such.

Yes, you can tunnel TLS over Tor. It doesn't afford you any additional confidentiality. Your domains are still being leaked, just in a different place - and routing everything over Tor _still_ exposes you to the same traffic correlation issues, just now it's domains that are being correlated rather than all request/response data.

Making TLS more secure entails removing the requirement of 'trust' as much as possible. That does not necessarily translate to it being harder to obtain certificates. A good example of this are hidden services - it's trivial to obtain an .onion identifier, yet since it's self-authenticating, it does not require trusting a third party.

The real problem with your argument shows itself in your very last paragraph - "Personally, I don't care [...]". You are extending your own personal point of view to _everybody else on the internet_ , and it doesn't work that way. Others _will_ have different privacy requirements, and those should be accomodated to.

Just because you don't care, that doesn't mean you get to decide that nobody else cares either.

EDIT: Also, just to emphasize this: I am _not_ arguing that encryption should be _forced_. I'm arguing that it should be _default_. That is something very different.

</comment></comment></comment></comment></comment></comment><comment><USER9> So, under this scheme, what is the best practice for dealing with all the web servers in devices such as printers, routers, copiers, embedded systems, etc.? Quite a lot of these have no provision and, in quite a few cases, not the cpu power to do https.

<comment><USER10> most printers/routers/copiers offer HTTPS from what I've seen. Sometimes it's on by default, usually not. They just use self-generated, self-signed certificates. There are problems with that, but CPU power isnt one of them.

<comment><USER11> My experience with large numbers of smart powerstrips is that they support ssh and https, but it's not reliable. Their telnet and http is reliable. I don't know why this is the case, but there you have it.

<comment><USER12> Smart _powerstrips_ are still a minority of connected devices.

Printers, routers, etc — anything that can afford a $5 ARM or MIPS core — have plenty enough power to allow TLS access.

Getting a certificate for each of them to provide a Web interface is another story.

In corporate environment the IT department will probably install their own certificates, automatically trusted by corporate browsers. Home-oriented devices will probably use massively-copied certificates instead of unique ones. It's not as secure as a per-device unique certificate, but definitely more secure than no encryption at all.

<comment><USER10> But it mandates that you click through an SSL warning, which no user should ever have to do unless they are actually testing SSL-related stuff. Otherwise, it's just teaching everyone bad practices.

<comment><USER12> If self-signed certs are accepted silently and shown as "not secure", the way plain HTTP is accepted and shown (per [https://news.ycombinator.com/item?id=9472037](https://news.ycombinator.com/item?id=9472037) proposal), the user won't need to click through anything.

Self-signed HTTPS is in no way less secure than unencrypted HTTPS.

</comment></comment></comment></comment></comment></comment><comment><USER13> There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. That way, website owners who want to keep their status quo, can just add a self signed cert and their users will be none the wiser.

For https there are two major objectives. 1) Prevent MITM attacks. 2) Prevent snooping from passive monitoring. Self-signed certs can prevent #2, which the IETF has adopted as a Best Current Practice ([https://tools.ietf.org/html/rfc7258](https://tools.ietf.org/html/rfc7258)). I'm much more in favor of trying to at least do one of the two objectives of https, rather than refusing to do anything until we are able to do both objectives.

Here's a proposed way of phasing this plan in over time:

1\. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the globe icon, not the lock icon). This would allow website owners to choose to block passive surveillance without causing any cost to them or any problems for their users.

2\. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The self signed certs would still be the globe icon. The would incentivize website owners to at least start blocking passive surveillance if they want to keep the same user experience as previous. Also, this new icon wouldn't be loud or intrusive to the user.

3\. Late-2016: Change the unlocked icon for http sites to a yellow icon. Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of frameworks like wordpress including tutorials on how to use it. This increased uptake of free authenticated https, plus the ability to still use self-signed certs for unauthenticated https (remember, this still blocks passive adversaries), would allow website owners enough alternative options to start switching to https. The yellow icon would push most over the edge.

4\. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, most websites should already have switched to https (authenticated or self-signed), so now it's time to drive the nail in the coffin and kill http on any production site with a red icon.

5\. Late-2018: Show a warning for http sites. This experience would be similar to the self-signed cert experience now, where users have to manually choose to continue. Developers building websites would still be able to choose to continue to load their dev sites, but no production website would in their right mind choose to use http only.

Here's two relevant Bugzilla bugs:

Self-signed certificates are treated as errors: [https://bugzilla.mozilla.org/show_bug.cgi?id=431386](https://bugzilla.mozilla.org/show_bug.cgi?id=431386)

Switch generic icon to negative feedback for non-https sites: [https://bugzilla.mozilla.org/show_bug.cgi?id=1041087](https://bugzilla.mozilla.org/show_bug.cgi?id=1041087)

<comment><USER14> > 5\. Late-2018: Show a warning for http sites.

Honest question: Why would I show a warning for a http-only site which only displays photos from my latest vacation? (assuming said photos are hosted on my blog). Or random thoughts of mine about tramway-spotting? (again, assuming said rumblings happen on my blog)

IMHO this kills a large portion of the open-web.

<comment><USER15> * Your website can be manipulated to contain anything: it could be a script attacking another website (Baidu vs GitHub), it could be a sneaky redirect to a phishing page (tab-nabbing), or just a ton of nasty tracking ads injected by an ISP.

* There are still sites that should use HTTPS, but don't. Browsers can't know whether these are just holiday photos, or photos that are privacy sensitive or can even cause a visit from the secret police in some countries. It's better to err on the side of security.

</comment></comment></comment><comment><USER16> Progress is never easy.

Firefox will be a forcing function for fixing the most critical issues raised in the blog post.

</comment><comment><USER17> Author appears to not be aware of the upcoming free SSL certificate service from Mozilla, the EFF and more - [https://letsencrypt.org/](https://letsencrypt.org/)

<comment><AUTHOR> Did you actually read the article? I've dedicated an entire section of the article to Let's Encrypt.</comment></comment>


Amsterdam fights overtourism: Go see rest of the Netherlands - <AUTHOR> https://edition.cnn.com/travel/article/amsterdam-overtourism/index.html <comment><USER2> Well, nobody cares for the rest of the Netherlands. Nobody cares for Amsterdam either, they come for the weed, and maybe a couple of museums you can see in a day.

(Where nobody is a colloquial term for "few people").

<comment><USER3> As a Canadian, I can buy pot from my provincial government. And they'll deliver it to me for free if I buy enough.

Going to the Netherlands to buy it seems a bit of unnecessary effort. Canadians have other reasons that make it worthwhile - we have a very strong war-time connection, and there are a number of tributes to our little corner of the Earth that are absolutely worth visiting. It's really humbling.

<comment><USER2> > _Going to the Netherlands to buy it seems a bit of unnecessary effort._

That's because you're Canadian, an ocean away and with legal pot (from what you say). Canada is not a major source of tourism for the Netherlands.

To put it in perspective, in a year Germany had 5 million tourists to The Netherlands, UK 2.2 million, the US 1.4 million, and Canada a mere 180,000. Or compare to 17 million tourists a year from Europe alone.</comment></comment></comment>


Why Tumblr Was a Massive Steal for Yahoo - <AUTHOR> http://allthingsd.com/20130524/why-tumblr-was-a-massive-steal-for-yahoo/

<comment><USER2> Seems like the article is making a case for Yahoo buying Pinterest, not Tumblr. Correct me if I'm wrong but aren't Tumblr posts generally without context?

</comment><comment><USER3> As I skimmed the article, I naturally read the headlines:

#2: Readers are far more valuable than writers.

#3: Valuable content is king.

Well which is it? You don't get content without writers, do you?

<comment><USER4> Correct. You want the right writers, though, and Tumblr has attracted an interesting set. You don't want too much garbage/noise on Tumblr, and so far (at least for me) this is the case. FB and Twitter have a lot of noise.

I respect Adam Rifkin's opinions a lot, partially because he's a great person and partially because he's the best-networked person in the world. <http://tech.fortune.cnn.com/tag/adam-rifkin/> I may be wrong, but I feel like the second title qualifies him to maybe see things that others don't.</comment></comment>


Response from Pitchfork Regarding Tumblr Subdomain - <AUTHOR> http://pitchfork.tumblr.com/post/393233651/dear-tumblr-community

<comment><USER2> I can see why Tumblr though it was abandoned:

From March 14, 2009:

      DON'T FOLLOW ME

      I AM NOT A REAL TUMBLE BLOG, I AM USED AS A FILTER
      SINCE TUMBLR TOOK AWAY MY REAL FILTER.

From Nov 18, 2009:

      I Have Found The Tumblr Filter

      This Filter is Obsolete

How can this guy claim (with a straight face) that he was actually using this as a blog, when he has _posts_ on the blog explicitly stating that it _is not a blog_?

Personally, I think there is enough blame to go around:

* Meaghan is probably trying to cover her ass because she over-stepped herself in removing this blog without notification to the user because she though it was abandoned.

* Tumbldore is just using this to generate drama and publicity. It's also possible that Tumbldore is just a giant troll that had this whopper of a piece of bait dumped onto his lap, so now he's just going to milk it for all it's worth.

</comment><comment><USER3> The original owner of pitchfork.tumblr.com has his own response with a screenshot of an email from Tumblr stating that they didn't ask him before reassigning it:

[http://tumbledore.tumblr.com/post/393276231/this-is-in- respo...](http://tumbledore.tumblr.com/post/393276231/this-is-in-response-to- me-being-libeled-by-a)

<comment><USER4> From Tumblr's TOS: "Tumblr reserves the right to remove any Subscriber Content from the Site, suspend or terminate Subscriber's right to use the Services at any time, or pursue any other remedy or relief available to Tumblr and/or the Site under equity or law, for any reason...or for no reason at all."

Just because they can, does it mean they should have? It doesn't seem like a fair assumption that the account is abandoned if there are a few posts form the past year, especially when Tumblr didn't contact the user (assuming they did not).

It sucks, but you get what you pay for.

I can't say that the original owner has made the best case for himself. Throwing around terms like "libel" and "exercise my right" is off-putting and makes it hard to empathize with him.

</comment></comment><comment><USER5> November 18, 2009 isn't exactly what I'd call inactive. Sure it wasn't super recent, but still, it's less than 3 months ago.

<comment><USER6> If you've posted five times in a year, and the last one sounds like you've decided your blog is obsolete, then it's not an instance of somebody abandoning a longrunning thing. It looks like somebody gave the service a few tries and gave up.

<comment><USER7> People often "give up" on a site a few times before they become a regular user. I do this all the time; For example, I signed up for HN "675 days ago" but I think I might have made 1 or 2 comments in the first 200 days.

</comment></comment></comment><comment><USER8> Yeah, I can't say I feel all that sorry for this guy. He got his 15 minutes of HN fame, if that's what he was after.

This is a more interesting to me as a Pitchfork copyright/trademark issue: <http://pitchforked.com/> (Context here: <http://twitter.com/zachklein/status/9188476155> )

I hope the guy doesn't get the smackdown after just building the site, but who knows. (A lawyer knows.)

</comment><comment><USER9> Personally, I'm all for ridding the internet of name-squatters, though Tumblr really should have deleted all of the old data first. I think Pitchfork Media's response is fair and more than I would have expected.

</comment><comment><USER10> It sound like they did not try very hard to contact anyone, this is pretty bad even from a free service. If this was a facebook or google doinging this there would be a huge shitstorm from you guys.

<comment><USER11> When the user says he isn't using the URL anymore, and tells people not to use it... that's pretty definitive in my mind.

</comment></comment><comment><USER12> Correct me if I am wrong, but you cannot trademark the name of an everyday object, such as a pitchfork, and then have rights to any use of the word in a domain.

So do they have the rights to pitchfork.wordpress.com, pitchfork.heroku.com and pitchfork.github.com ? Of course not.

This is not about IP, this is about a company doing their friends a favor. I will now stay away from tumblr. If I cease posting for a few months they could take my domain away.

<comment><USER2> > _Correct me if I am wrong, but you cannot trademark the name of an everyday > object, such as a pitchfork, and then have rights to any use of the word in > a domain._

You _can_ trademark the name of an everyday object. See 'Apple' computers vs 'Apple' the music label. Now they only have a trademark dispute is someone in their industry has the apple.com or apple.github.com or whatever (e.g. if Microsoft or Dell registered apple.wordpress.com, Apple might have a case to take it away from them do to brand confusion -- which was the original reason for trademarks).

<comment><USER12> I did not say you cannot trademark an everyday object, I said trademark it for all uses.

Microsoft could register apple.wordpress.com and use it to blog about apples (the fruit).

Edit: Spelling

</comment></comment></comment><comment><USER13> Rule #1: own your domains

\- Tumblr: <http://www.tumblr.com/docs/custom_domains>

\- FeedBurner MyBrand: <http://feedburner.google.com/fb/a/mybrand>

</comment><comment><USER14> A refreshingly drama-free resolution to the affair.

<comment><USER15> Except it's not a resolution. Tumblr's response ([http://meaghano.com/post/393246405/tumbledore-ive-run- pitchf...](http://meaghano.com/post/393246405/tumbledore-ive-run-pitchfork- tumblr-com-for)) totally contradicts it.

<comment><USER16> There is only 1 contradiction: the part about notifying the original owner through email. There is really no way to verify this since the screenshot of the email may have been forged.

The part about having 0 posts was explained by Meaghan all the way at the bottom of the page. The RSS feed shows deleted posts.

I found this comment thread amusing though. [http://meaghano.com/post/393246405/tumbledore-ive-run- pitchf...](http://meaghano.com/post/393246405/tumbledore-ive-run-pitchfork- tumblr-com-for#comment-34786194)

<comment><USER7> Well, Pitchfork claimed that the subdomain was handed over by tumblr 10 minutes after their inquiry. That would imply that it would have been impossible for tumblr to have sent a "72-hour notice" mail.

Also, it appears that the person was actively using the account as a filter (following people and reading news), so the "inactive" part seems to be a contradiction as well.

</comment></comment></comment></comment><comment><USER17> i dont care what he was using it for. he registered it. he should be able to sit on it and let it die.

thats my opinion... taking it away under any circumstance is sketchy in my opinion.

</comment><comment><USER18> Bottom line- who here will put anything they care about on Tumblr now?

Exactly.

</comment><comment><USER19> Is pitchfork too poor to get a blog on their own domain? Why they gotta be taking domains from other people?</comment>


JP Morgan economists warn climate crisis is threat to human race - <AUTHOR> https://www.theguardian.com/environment/2020/feb/21/jp-morgan-economists-warn-climate-crisis-threat-human-race <comment><USER2> Not just JP Morgan, but plenty of economists and even fund managers and traders know of this threat. Here's another example: [https://www.barrons.com/articles/jeremy-grantham-called- the-...](https://www.barrons.com/articles/jeremy-grantham-called-the- financial-crisis-he-has-another-warning-for-investors-51581532462)

The problem has never been whether most people believe in climate change and its damaging effects. The problem has always been politics.

</comment><comment><USER3> A few weeks ago I read Naomi Klein's "This Changes Everything." She specifically mentions how the bailout - after the 2008 crash - was a missed opportunity; that WS' behavior could been nudged or more. Given what was at risk, it's difficult to disagree.

[https://www.theguardian.com/books/2014/sep/22/this- changes-e...](https://www.theguardian.com/books/2014/sep/22/this-changes- everything-review-naomi-klein-john-gray)

<comment><USER4> > I read Naomi Klein's "This Changes Everything.

The The Shock Doctrine: The Rise of Disaster Capitalism is another insightful book of hers, I highly recommend it, it was written in 2008 as the financial crisis happened: [https://www.amazon.com/Shock-Doctrine-Rise-Disaster- Capitali...](https://www.amazon.com/Shock-Doctrine-Rise-Disaster- Capitalism/dp/0312427999)

</comment></comment><comment><USER5> Duplicate

[https://news.ycombinator.com/item?id=22386096](https://news.ycombinator.com/item?id=22386096)

</comment><comment><USER6> "FIRM ACTS AS A PLACEMENT AGENT IN THE IFC'S $152 MILLION BOND TO PROTECT FORESTS AND DEEPEN CARBON-CREDIT MARKETS"

[https://www.jpmorgan.com/country/US/en/detail/1320553563765](https://www.jpmorgan.com/country/US/en/detail/1320553563765)

<comment><USER7> Much as pointing out potential conflicts is always helpful, it's worth noting that most companies won't dive into a market unless upside exists.

In this case, looks like JPM is betting that the world will get a hold of itself, which would make this product a bit more... productive.

</comment></comment><comment><USER8> In all the distrust and misinformation out there around this subject, it's refreshing whenever I see finance people talk in these terms. They are pragmatic to a fault, and wouldn't make statements like these lightly.

<comment><USER4> > They are pragmatic to a fault, and wouldn't make statements like these > lightly.

The situation is dire, but lets not discount these are the very same people responsible for the derivatives scandal that plunged the global economy into disrepute, and profited very handsomely from it with bail outs and bonuses for their utter failure to exercise sound financial behaviour. So lets not place the very same people capable of creating their own catastrophic global crisis on pedestals.

With that said, consider how big their carbon footprint is in just the creation, maintenance and upkeep of their legacy system, which really only 'works' 5 days out of the week.

If they want to be taken serious, knowing they will never correct the malfeasance they call a business model, they should give little to no interest loans on startups and small businesses that help offset global climate change.

They won't and instead you'll see Jamie Diamond on TV alongside Blankfiend et al at Davos making these empty latitudes without so much as hesitating when they board their private jets whilst eating exotic food and drinks procured from all over the World.

Pragmatists? Hardly, opportunistic parasites willing to cling onto whatever narrative suits them, of course.

<comment><USER8> I didn't mean to put them on pedestals; I really did mean "to a fault". Usually it's a fault. What I'm saying is that they don't mess around when it comes to their own self-interest. So if _even they_ are worried about this, we all should be.

</comment></comment></comment><comment><USER9> Those things from big banks always remind me of the quote from Big Short: "Yeah, I think you mean that you've secured a net short position yourselves. So you're free to mark my swaps accurately for once because it's now in your interest to do so."</comment>


Mozilla and Epic Announce Unreal Engine for the Web - <AUTHOR> https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/ <comment><USER2> For everyone saying that the claim that asm.js runs everywhere is invalid, because only in browsers that implement the optimization will it be feasible, remember that most games are built to scale performance. On browsers that don't implement the asm.js optimizations, the game could feasibly turn off visual effects and scale down the game so that it runs, just not as pretty or realistic.

There's a huge difference between "this game only runs in this one browser that implements this full VM" and "this games runs everywhere, but only with maximum graphics & physics in browsers that implement the asm.js optimizations".

<comment><USER3> 'There's a huge difference between "this game only runs in this one browser that implements this full VM" and "this games runs everywhere, but only with maximum graphics & physics in browsers that implement the asm.js optimizations".'

That's quite a bit of marketing here.

If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and it's not obvious to me within the confines of JS if you can actually do better than 1.5x), people would switch to a browser that supports NaCl (first the hardcore gamers, then the rest of us). Your argument only makes sense if asm.js and NaCl are at performance parity.

Note that people still write native iOS games, even though they could run everywhere if they did it in JS.

<comment><USER4> > If NaCl is capable of reaching 1.1x performance while asm.js is at 2x (and > it's not obvious to me within the confines of JS if you can actually do > better than 1.5x), people would switch to a browser that supports NaCl > (first the hardcore gamers, then the rest of us).

NaCl is not portable. asm.js is. You should compare PNaCl and asm.js.

> and it's not obvious to me within the confines of JS if you can actually do > better than 1.5x

Why not? Is there a technical reason?

<comment><USER5> > _NaCl is not portable. asm.js is. You should compare PNaCl and asm.js._

NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON, SSE, and other architecture-specific hardware features that make substantial differences in performance.

So why shouldn't you compare NaCL to asm.js?

PNaCL is there to cover the case where we move past ARM and x86, in which case it provides the ability to target new architectures from existing deployed code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries, optimized for a given client.

<comment><USER6> > NaCL covers the only architectures that are likely to matter for phones and > desktops for the next 5+ years: ARM and x86.

This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM.

> PNaCL is there to cover the case where we move past ARM and x86

That, too, but more importantly, it exists to let you run the same code (delivered as LLVM bitcode) on supported platforms, including x86 and ARM, instead of having to deliver separately-compiled code for each supported platform, as is the case for NaCl. That's what the "P" ("Portable") is about -- the code delivered runs on any PNaCl engine, unlike the case with NaCl where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM.

You seem to have confused what PNaCl does now (experimental toolchain inside the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe bitcode to native code piece of the toolchain from the SDK side into the client side, so all you deliver to the client is the platform-agnosti .pexe rather than the platform-specific .nexe.)

<comment><USER5> > _This is misleading. NaCl exists for both these platforms, but it doesn't > support running the same code on each; NaCl lets you run native x86-compiled > code on x86 and native ARM-compiled code on ARM._

I didn't intend for this to be misleading -- the option to deploy code specific to each architecture is a _benefit_.

It means you can take advantage of the architecture's specific features (such as NEON and SSE).

<comment><USER6> > I didn't intend for this to be misleading -- running code specific to each > architecture is a benefit.

 _Permitting_ it may be a benefit in some cases,

 _Being limited to_ it, as NaCl is until client-side PNaCl is ready, is a disadvantage.

Which is why Google is not enabling NaCl by default on the web (i.e., outside of the Chrome Web Store) until client-side PNaCl is ready -- they don't want needless proliferation of non-portable NaCl code on the web. And, I suspect, they want to make the .pexe-to-.nexe process as efficient, in terms of code generation, as possible, so as to minimize the scope of cases where specific- platform-targetting is necessary.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I feel like an old fart for not buying into the push for the browser to be an OS or game system.

In my mind, no matter how optimized the browser becomes, it will always be slower than natively-compiled code. And in the 3d gaming world, where the faster code always has the greatest potential for the best game engines, the browser will always lose.

My instinct tells me that there will be a huge push for webgl games, some initial adoption and frameworks, etc. The result will be that web developers will realize how fucking complex graphics engines are (I'm writing one now...nothing in webdev compares to it) and will give up. And I can't see graphics developers in the game industry incentivized enough to fully make the jump to the browser (why would they want to write game code that is distributed to everyone in raw source form?)

<comment><USER8> I expect most serious developers will stick with engines like Unity, which let you run games in a browser with a plugin, but also compile and distribute them in standard ways on every popular desktop and mobile platform.

Unity Web Player is easy to install, and it's an increasingly common requirement for a lot of games. It's a barrier, but only a small one.

<comment><USER9> >I expect most serious developers will stick with engines like Unity

They should stick with engines and frameworks like Unity. Coding raw JS and WebGL is ugly. But there's no reason why Unity cannot compile down to something like asm.js and webGL. In fact, I believe Unity already lets you compile to a swf, which gives you great performance and doesn't require any extra plugins (besides Flash).

>Unity Web Player is easy to install, and it's an increasingly common requirement for a lot of games. It's a barrier, but only a small one.

It's an insurmountable barrier.

<comment><USER10> "...It's an insurmountable barrier..."

Why do you say so? Why is it a small barrier or an insurmountable barrier?

Genuinely interested in the answers there.

Just seems to me that there are a lot of Flash games, Unity games and Java games. I mean, if Minecraft or BSG Online is any indication... technology doesn't really stop your average gamer. But maybe I'm wrong???

<comment><USER11> I have developed a couple of unity based browsergames and i can Tell from experience that you loose a sibstantial amount of users at the plugin installation, especially for games that target a more casual market. Unity compiling to asm.js would be huge!

</comment></comment></comment></comment></comment><comment><USER12> (on Scaling) Games usually scaled based on GPU power, but not so much on the core game logic, AI, etc. Any CPU processing that actually affects gameplay outcome (e.g. collision detection) cannot really be disabled and scaled. Otherwise, you end up playing a _different game_ based on your machine, not a game that only looks uglier or plays choppy.

This demo looks great, but all I see are environments rendered. I didn't see any firefights between lots of player models or vehicles, no Havok/PhysX/Bullet, I didn't see any enemy AI running. I did see some frame rate hitching. It's not the first time someone's had environments (sans game) running, see for example Quake3 (<http://media.tojicode.com/q3bsp/>). Even the Rage Engine got an environment renderer ported to the Web.

There's a danger in overselling stuff. When I helped port Quake2 to the Web (GwtQuake), I didn't have any illusions about being able to run something like Crysis or Call of Duty series in the the browser in JS, or consume the same resource requirements. I mean, I thought it would be possible, but a hideous waste of system resources.

There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly). I see the same parallels today, pushing the idea that a dynamically typed language with some extra 'hints' is going to match a language that gives full control over memory, SIMD, layout, threading, etc.

This is not to say that asm.js couldn't do most of the 'casual' games you see today (e.g. Ridiculous Fishing on iOS, Angry Birds, etc), and most of the Flash games, I'm totally onboard with using it for that, but I think it's a mistake to push this as a real solution for bringing triple-A FPSes to the web.

And what of Mobile? Can this even run Infinity Blade on a recent smartphone? What would be the different in battery life between an iOS version and an asm.js version?

<comment><USER4> > It's not the first time someone's had environments (sans game) running, see > for example Quake3 (<http://media.tojicode.com/q3bsp/>).

Quake 3 was released in 1999. Unreal Engine 3 is a current and top-of-the-line engine for AAA games.

> There was a time when Sun was marketing Java and pushing heavily on this > idea that it would one day meet or beat C/C++ performance, but it never > quite got there after 2 decades (yes, in some circumstances it comes close, > in others, it fairs badly).

This is totally different. asm.js is just a backwards compatible encoding of a different, much lower-level language. In fact, that lower-level language is in direct correspondence with the intermediate representation of a production- quality C++ compiler (clang)!

Sun never tried something like asm.js for Java; rather they claimed that the _full language_ would be as fast as C and C++.

> memory, SIMD, layout, threading

asm.js gives full control over memory and full control over layout, with the exception of stuff like mmap() and mprotect() and self-modifying code.

SIMD is something that RiverTrail/ParallelArray can do. It should be added to asm.js.

As for threading, I'm personally in favor of an extension to allow a typed array to be shared between workers, races and all, with some primitives to allow synchronization. Not everybody is OK with this, but I personally believe we aren't likely to get to native performance without it. (Again, this is just my personal opinion; many disagree on whether a racy typed array is necessary.)

<comment><USER12> You can polyfill SIMD, but you can't polyfill threads. Once you add shared memory between workers, you've effectively violated the premise that asm.js will run everywhere, even places that don't understand it.

In that case, you've got a portable intermediate representation of opcodes in a bloated legacy format, that is now incompatible with legacy runtimes. Why use JS format then?

<comment><USER4> Apps could feature detect threading and fall back to single-threaded mode for compatibility with non-asm browsers if it's not supported.

Regarding the claim that asm.js is "bloated": [http://mozakai.blogspot.com/2011/11/code-size-when- compiling...](http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to- javascript.html)

</comment></comment></comment></comment><comment><USER13> This is huge! I do PR in the gaming industry and have been waiting a long time to see a platform that could bring serious game development to the browser. I was expecting it to be Unity, but I'm convinced this is a bigger milestone. Epic is an awesome company with awesome tech and partnering directly with Mozilla is a stroke of genius.

Can't wait to see the games that will come out of this marriage.

<comment><USER14> Native-like games in browsers with little or no use of plugins may be game- changing for the game industry.

<comment><USER15> Given the size of game assets these days, that could be a big UX problem

(in places which don't have Google Fiber)

<comment><USER16> Presumably, game developers would serve up the game to the browser via localStorage. This would make the experience very similar to Steam today, where you download the game, then play it.

<comment><USER17> You could even design the game to be downloaded in chunks. Download the first level, and while playing, download the second in the background. This reduces downloads and load times.

</comment></comment></comment></comment></comment><comment><USER18> Disclaimer: I worked on the original Flash version of this same demo two years ago.

Big congratulations to Mozilla for pulling this off. Feels good to have such a great demo, doesn't it? :) But a lot of the credit also needs to go to Epic for having such an amazingly scalable and portable engine and providing the AAA assets!

One issue is that the game experience does not translate as easily as the wow factor. You will need quite a bit more to go to the first shipping and profitable game built with this tech. Don't rest now :) With Flash + 3D we actually ended up seeing the most successful games not being based on straight native ports but built from scratch with the new environment in mind. Things like caching, startup time, and wide reach are crucial to an in browser game but are not needed for a demo like this.

Still really amazing! Keep up the good work and the fight for the open web!

</comment><comment><USER19> I was wondering what the end goal of asm.js was - and the ability to run games in your browser at near-desktop speeds is _very_ impressive.

Now, how long until Chrome supports it...

<comment><USER20> As soon as they find a way to put ads in it...

<comment><USER21> Chrome has supported NaCl for a long time, which is quite a bit saner than asm.js

<comment><USER22> You show up on every NaCl-related thread claiming it is awesome and asm.js is crap, but that's as far as it goes - you never explain _why_. You're basically wasting time because what you say is never actionable. Please defend your opinions - inform us!

<comment><USER21> (P)NaCl exposes pretty much the same environment and tool chain devs get writing native apps. Predictable performance, decent debugging, etc. One can even decide to use platform-specific features if strictly necessary.

The problem it has is that it is largely opaque to the JITs in browser engines (even PNaCl, since JS JITs have nothing to do with llvm). One way to fix that would be to define a simple byte code as a compilation target and have people compile to that, in addition to compilation to JS with emacripten. The end result would be, in my opinion, much cleaner than the ugly hacks in asm.js

Furthermore, by design, asm.js will always need guards in the generated code, thus some overhead that can never be fully removed (although JITs will help with this). In particular, one can write "x = +x" in JS, but then change the type of x, thus invalidating the invariant. A guard will be needed to guarantee correctness, since asm.js is a subset of JS, but the outer set still exists.

It seems to me that web technologies are getting more and more crazy. To me it appeared obvious that asm.js is not a nice approach, but I can see many people disagree.

<comment><USER23> You are mistaken, there are no type guards within asm.js- verified/compiled/linked code. Read more at <http://asmjs.org/>.

/be

</comment></comment></comment></comment></comment></comment><comment><USER24> Unreal? Bah, real gamers play Quake! (As in 199Xs flame wars.)

<https://github.com/SiPlus/WebQuake> was released some weeks ago. It is a whole different league in terms of technological features but it is a free open-source engine. You can play it at <http://webquake.quaddicted.com/>

There is also a port of Sauerbraten, another free engine, <https://developer.mozilla.org/en-US/demos/detail/bananabread>

</comment><comment><USER25> The thing that I think people are getting confused about is, even though asm.js is faster, you actually don't need asm.js to get native code running the browser. The new engines in Chrome and Firefox already compile to native code.

Asm.js is just a way to ensure that your code always get optimized as much as possible.

I really don't think that asm.js is necessary to bring 3d gaming to the web. WebGL performs very well as long as you take advantage of the graphics hardware. I'm not a fan of asm.js actually, since if I wanted to write low- level code I would just stick with C++. I'm on the web to take advantage of things like JavaScript and CoffeeScript.

I think the way to get to the sweet spot for 3d gaming and applications in the browser is to 1) make sure that WebGL is well supported on as many platforms as possible and 2) take advantage of the built-in networking, instant-on factor, openness, general webiness, and scripting capabilities of the web platform. By 'instant-on factor' I mean that games can load up very quickly after hitting a URL. By 'general webiness' I mean, for example, you can start a game at the end of the work day, later the evening continue from your house -- you aren't tied to a particular machine. Also the web has all of the HTML5 features which could really come in handy for innovative browser-based operating systems or 3d applications.

Also, if you take advantage of things like procedurally generated textures and geometry, people won't even have to wait for stuff like loading textures.

Asm.js is cool but its not really necessary and not my thing. We just need good WebGL support.

Another feature that 3d browser-based games and applications could take advantage of is WebRTC.

The point being that if you take advantage of easy-to-use web APIs and libraries like WebWorkers, WebRTC, Three.js, CopperLicht, web-based languages like CoffeeScript, etc. then the web platform can offer game developers productivity advantages.

<comment><USER9> >I really don't think that asm.js is necessary to bring 3d gaming to the web.

It helps ... a lot. WebGL gives you GPU access which will largely drive your graphics engine, but there's still tons of places where CPU performance matters (e.g. physics and AI). Asm.js and WebGL are complementary.

>I'm on the web to take advantage of things like JavaScript and CoffeeScript.

And asm.js prevents this how? If you're coding in CoffeeScript, you already have a necessary compile step to do. Are you telling me you wouldn't want the CoffeeScript compiler to give you extra performance by including asm.js heuristics?

<comment><USER25> Yeah there are tons of places that CPU performance matters, but my point is that Mozilla and WebKit's engines are doing a good job of native compilation already.

If you could make a CoffeeScript compiler that would output asm.js, then great. But I'm not sure that's possible. I think that you either have to go from C/C++ code through the emscripten or right directly using the asm.js stuff in JavaScript.

<comment><USER26> Or LLJS: [http://jlongster.com/Compiling-LLJS-to-asm.js,-Now- Available...](http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available-)

</comment></comment></comment></comment><comment><USER27> I worked at a company that developed 3D interactive language and culture software with speech recognition, virtual humans, etc - one of our biggest issues was that customers aren't interested in installing desktop software anymore. We were able to make pretty decent web products using Unity, although our desktop products were still far superior. Good to see 3D on the web edging ever closer to becoming standard.

</comment><comment><USER28> Are you sure this is even correct? The github project for that 3d demo (<https://github.com/kripken/BananaBread/>) says the 3d engine is "Cube 2/Sauerbraten 3D", not Unreal.

It seems like the Unreal Engine facebook just posted a link to that video and people are thinking it is Unreal Engine.

<comment><USER29> BananaBread is a different 3d engine, it's what most of the development work of emscripten has been focused on. The UnrealEngine demo is a separate demo done by compiling the UnrealEngine codebase to asm.js using emscripten.

<comment><USER28> Wow, I must be really dumb to have not noticed the Unreal Engine demo video. I only saw the BananaBread one. Thanks.

</comment></comment></comment><comment><USER30> We will need a really good caching/disk space management system before this could really be used for much, is anyone working on that?

<comment><USER31> Conveniently, this email [1] has been sent today by Jonas Sicking from Mozilla. It basically pinpoints all the problems developers using appcache experience, and proposes a starting point to go towards a good caching system for the web. Rest assured people are working on that actively.

[1]: [http://lists.w3.org/Archives/Public/public- webapps/2013JanMa...](http://lists.w3.org/Archives/Public/public- webapps/2013JanMar/0977.html)

</comment></comment><comment><USER32> I'm curious what the performance is like in Chrome or Safari (which do not have asm.js support.)

If performance is acceptable in Chrome/Safari then that helps sell the idea that the web is ready for 3D games now.

If the performance isn't acceptable then that helps to make the case for asm.js.

<comment><USER33> Mozilla has already showed asm.js is 3-6x slower in Chrome, which doesn't support it right now.

<comment><USER32> Yeah they showed a benchmark was 3-6x slower. That's all well and good. I wanna see what the real world implications are. Here's this cool Unreal demo running with asm.js support, it looks great.

Now let me run it in Chrome or Safari and see if it's even remotely passable or not.

</comment></comment></comment><comment><USER34> We pitched this to Epic in 2007 when our platform helped bring id Software's Quake online... on any browser.

Included an "app garden" for the mod community around Unreal engine, clans, ladders, and real-time tournaments with automatic server propagation.

We shutdown due to high infrastructure costs and notorious "2 week" => 2 year game delays.

</comment><comment><USER15> What was the actual reason why Mozilla could not implement NaCL?

Why cannot multiple technologies compete among users on their merits?

<comment><USER35> Mozilla doesn't want to implement NaCL because most of the people involved in the project feel that the hardware-architecture-dependence this would introduce to the web is a really bad idea.

Mozilla could not implement PNaCL (which would not have that drawback) because it doesn't exist yet.

<comment><USER6> > Mozilla could not implement PNaCL (which would not have that drawback) > because it doesn't exist yet.

PNaCl doesn't exist yet? That's funny, because its both in the current Native Client SDK _and_ has been in Chrome stable (disabled by default) since, well, I'm not sure, but at least since the last major version, which is the first time I noticed the setting.

<comment><USER35> Except it still requires you to serve up architecture-specific things for now, as far as I can tell.

<comment><USER6> > Except it still requires you to serve up architecture-specific things for > now, as far as I can tell.

PNaCl doesn't require that. The fact that PNaCl is not enabled by default on the client makes that a practical requirement when using NaCl, but "is not enabled by default in Chrome" isn't the same thing as "does not exist". Particularly, the fact that PNaCl isn't enabled by default in Chrome, unlike the claimed fact that it doesn't exist, is no barrier to Mozilla incorporating it.

<comment><USER35> Uh... if it's not "existing" enough to enable in Chrome, what makes you think it's "existing" enough to enable in Mozilla?

But also, see the Pepper discussions through these various threads. "Existing" for PNaCl also includes being specified enough to actually be implementable, which runs straight into Pepper.

<comment><USER6> > if it's not "existing" enough to enable in Chrome?

It exists, is included in Chrome, and users can enable it. Its not enabled by default, but it definitely exists and is deployed in the stable version of Chrome (and not just the most recent stable version.)

> what makes you think it's "existing" enough to enable in Mozilla?

There's a difference between "Mozilla can't use PNaCl because it doesn't exist" and "Mozilla doesn't want to use PNaCl because it hasn't reached the maturity point where Google is ready to enable it by default in Chrome".

The first relies on a false premise. The second doesn't (though its still a false _statement_ ; Mozilla doesn't want to use PNaCl because they are committed to JavaScript-as-the-engine-of-behavior for the browser; their primary objection to every other alternative is that it isn't JavaScript. This is a perfectly legitimate preference, and there is no need to confuse the issue with false explanations.)

> "Existing" for PNaCl also includes being specified enough to actually be > implementable, which runs straight into Pepper.

No, that's not what "existing" means.

That's not to say that issues with the degree to which the Pepper API is well- specified aren't potentially the basis for legitimate opposition to using Pepper+PNaCl in browsers, its just completely nonsense to say that PNaCl _doesn't exist_ (when it manifestly does and is widely distributed). If you want to argue that Pepper is underspecified, then argue that Pepper is underspecified, not that PNaCl doesn't exist. Because the first may or may not be a legitimate argument, but the second is just nonsense.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> I don't fully understand, is this equal to NaCl or webgl/canvas?

<comment><USER37> This Unreal Engine3 port uses WebGL and asm.js.

<comment><USER38> asm.js paying dividends already, performance is always useful. But the larger problem is cross platform gaming, so hopefully webkit and others get something like this. The problem is Chrome has NaCl, Microsoft has their designs I am sure, we still need WebGL support which I am sure isn't coming.

For now Unity, Flash and general html5/canvas is still a better cross platform solution. If this leads to browser mobile games though that are native speeds, then we have something.

<comment><USER39> asm.js is just a subset of JavaScript, so it works in all browsers already, unlike those "alternatives" you mentioned.

<comment><USER15> Does it work at full speed without OdinMonkey?

<comment><USER39> No (well more accurately, "it depends on how good TI works without the restrictions"). Won't matter for most games, see also points made elsewhere here.

</comment></comment></comment></comment></comment></comment><comment><USER40> Nice!! I've been planning on implementing the UT99 equivalent of QuakeLive at <http://www.globalunreal.com> for quite some time now. I've already made a new ping compensation mod, so all that's left is automating pretty much everything via the web. Although, I highly doubt I'll go 100% in the browser using WebGL. It'll most likely just be a wrapper that makes UT appear to be controlled by the browser when it's actually just running natively. This is all very cool stuff though. I could see it being quite powerful/useful in the future.

<comment> Aco- I might be able to help aid you in your efforts if you're interested. I have been involved with the modding & hacking communities of the unreal engine for the past 13 years now. I was one of the lead developers for the full conversion mod Unreal Tournament Revolution which ported UT99 gameplay to the unreal 2.5 engine. I've worked on various anticheat teams and released the first unreal engine hook PoC back in 2000. So if you're interested reply to this with an email, I would love to help you in any way that I can.

<comment><USER40> Ha! It's Aco. Small world! I actually wasn't around UT99 back when you were, but things are chugging along better now than they have in a looong time since I made newnet. If I recall, you were actually the guy who told everyone newnet wasn't possible for UT99!

At any rate, hit me up on irc.globalgamers.net #iPug and #uPug (#tdmpickups and #mlut are dead).

</comment></comment></comment><comment><USER41> Soon all this tricks with CSS and HTML will obsolete, all will be replaced by canvas, with frameworks, engines, SDK, etc.

<comment><USER42> I'm waiting for someone to implement a web browser in canvas. Wait, now that I think about it, it has probably been done already.

<comment><USER43> This was an april fool's joke from last year: [http://badassjs.com/post/20294238453/webkit-js-yes-it-has- fi...](http://badassjs.com/post/20294238453/webkit-js-yes-it-has-finally- happened-browser)

In the non-joke category, Mozilla created a JavaScript interpreter written in JavaScript (to test new language features): <https://github.com/mozilla/narcissus/>

</comment></comment></comment><comment><USER44> One of the interesting projects that Nortel was developing before they went into bankruptcy protection was web.alive. It is a 3D collaboration platform built on the Unreal engine. The biggest problem was that it only supported windows and required a pretty big plugin that needed to be updated regularily. Avaya still sells it, and I think this could really make a big difference for customer adoption. <http://avayalive.com/Engage/>

</comment><comment><USER45> I am tempted to say that 'this is not indicating the death of native platform games'

By the time we would see UE4 on the web, developers will be trying to achieve VR graphics in UE5....

Look at your surroundings people. We are far from achieving that kind of graphics and environment on our native systems. We are far from emulating the environment, we live in. For that we will always need a great native system + very fast native programming languages (like C\C++)

<comment><USER46> > For that we will always need a great native system + very fast native > programming languages (like C\C++)

When you're talking about graphics, this really isn't true at all. 99% of what matters there happens on the GPU, not CPU, and that's not going down, it's only going up as GPGPU stuff gets bigger. The days of CPU-bound games are, by and large, behind us.

<comment><USER45> 'optimise the GPU for max performance'

I bet you will hear this kind of statement in the future, when more general purpose work will be done by the GPU. We already have C++AMP, and I bet, in the future, CPU's will be GPU like.

<comment><USER47> I often imagine offloading everything to GPU is the realistic solution to workaround the mess of standards...

</comment></comment></comment></comment><comment><USER3> Top youtube comment: "There's nothing about the Unreal Engine 3 on both emscripten and hacks.mozilla" (<https://www.youtube.com/watch?v=XsyogXtyU9o>)

Even though the major legwork is in emscripten, somehow the focus is on asm.js. Feels like really heavy marketing.

<comment><USER48> It's natural that newer things get more attention.

Emscripten's been well known for months.

asm.js has been well known for weeks.

A working implementation of asm.js (OdinMonkey) has been well known for days.

A demo showing Unreal running on OdinMonkey has been well known for hours.

</comment></comment><comment><USER49> I have a question about asm.js. My understanding is that it's only useful for (static typed language) -> asm.js, is that correct? It doesn't make sense for (dynamic languag) -> asm.js because there's no type information to optimize with.

</comment><comment><USER50> Am I the only one who finds Unreal powered games for kinda slow, sluggish and with "weird" movement? Latest two titles that I've tried - Dishonored and especially Borderlands 2 compared to Rage are hm... crappy... on 660TI

</comment><comment><USER51> The one thing i don't like about the lowlevel compiled js stuff is the complete absence of threads. There is no way to get real game-like performance on a modern multi-core CPU in a single threaded language.

</comment><comment><USER52> Is the idea with asm.js to write in C/C++ and convert it to Javascript? It sounds like I should relearn C++ because it's the one thing that will run everywhere. Android, iOS, and now the web.

<comment><USER53> The idea is to have an llvm backend targeting a weird subset of javascript that happens to get optimized really well. As far as I have heard, there are already other languages that target emscripten via llvm, and I'm sure there will be more when asm.js gets big. I don't think you'll be stuck with C++.

</comment></comment><comment><USER33> Is this using WebGL. If so then I guess games will be limited to OpenGL ES 2.0 API, until WebGL gets updated to a more advanced graphics API level.

<comment><USER54> OpenGL ES 2.0 is still the safest bet, as it is what most mobile devices support. Though devices with GLES 3.0 are appearing, driver support is still subpar. I agree it may be time to look at bumping the API level.

</comment></comment><comment><USER55> Does this mean that the source will be available for anyone playing the game, even if obfuscated?

It should open interesting possibilities.

<comment><USER56> I mean the assembly has always been available. I'm not sure asm.js would be any more readable.

</comment></comment><comment><USER57> This might go even beyond gaming. First and third person interfaces for the web.

</comment><comment><USER58> "but can it run Crysis?"

<comment><USER59> It should be theoretically possible. Crysis is written in C/C++ IIRC (well you program engine in those two languages).</comment></comment>