JavaScript Cryptography Considered Harmful - <AUTHOR> http://matasano.com/articles/javascript-cryptography/ <comment><USER2> I disagree that just because its possible for a malicious or comprimised server to send evil javascript, javascript crypto should not be done.

You have to analyze the threat model. Take the note taking webapp they use as an example. Without javascript crypto, anyone who breaks into the server can read everyones notes. Likewise, the FBI can get a warrant and have the owner of the web application turn over everyones notes.

If they do use javascript crypto, instead of just getting a warrant for the machine, the fbi has to convince the owner of the site to modify their source code to target an individual user to steal their key. That is a significant difference. Also, the victim user has to log in again for that attack to be successful, if they just used the server for a couple weeks and left, they are safe.

Likewise, an attacker who breaks into the server can't get a dump of all the notes in the system. They again have to modify the source code which could be noticed by the owners and users and takes some level of sophistication more than the average aim and shoot attacker

So is javascript security perfect right now? no... but that doesn't mean it should be dismissed

<comment><USER3> It's not just a malicious server, an attacker can put himself between you and the perfectly secure server and then send you whatever javascript code he likes, that's the whole point. And yes, since it cannot be made secure, it should be outright dismissed.

<comment><USER4> > It's not just a malicious server

The author effectively _dismisses_ the point being about a malicious server: especially with "Just use the SSL", because, well, if you're landed on the server, SSL means squat.

The author is concerned about:

\- the unavailability of secure functions necessary for crypto (as simple as RNG, as useful as an AES call, or as complex as a full-blown PGP API with transparent, ad-hoc key management) in browsers

\- the unavailability of a secure, non-monkey-patchable runtime environment for JS crypto code to execute in, guaranteeing one can use the aforementioned functions as intended

\- the vulnerability of the code as content in the channel itself (when not using SSL) or in the browser itself (XSS and all)

All of those being legitimate causes of concerns (IOW in crypto world, gaping holes rendering client-side JS crypto untrustable)

<comment><USER5> > \- the unavailability of a secure, non-monkey-patchable runtime environment > for JS crypto code to execute in, guaranteeing one can use the > aforementioned functions as intended

That one at least can be dealt with by web workers

<comment><USER6> Worker = myMaliciousWorkerImpersonatorFunction;

</comment></comment></comment></comment></comment><comment><USER7> Previously: [https://news.ycombinator.com/item?id=5123165](https://news.ycombinator.com/item?id=5123165)

I think Nate Lawson does a much better job of making this argument than I did:

[http://rdist.root.org/2010/11/29/final-post-on-javascript- cr...](http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/)

<comment><AUTHOR> Sorry, I didn't notice that it was submitted previously: TFTL.

<comment><USER8> I've been thinking that it's time this article make it to the front page. If this was an old school forum, I'd ask the mods to pin it at the top. There are just too many damn discussions of JS crypto on here. It's like flowing glass all over again.

</comment></comment></comment><comment><USER9> I'm curious if anyone who worked on this article would be willing to comment on what they think of Keybase.io's client-side crypto implementation:

        > Browser crypto can be scary. Do you have an evil extension
        > installed? We can't tell. Further, have we been tortured
        > into serving you custom, targeted JavaScript? Hopefully
        > you're not that important.

        > So: only use this page if (1) you feel your browser is
        > clean and (2) a life doesn't depend on it.

[https://keybase.io/docs/server_security](https://keybase.io/docs/server_security)

<comment> mike-cardwell If you use the web based crypto from keybase.io, your key can be compromised if they are compelled to do so, or they are hacked.

The good thing about keybase is that they also provide a cli tool for interacting with the service, so your private key never needs to go near a website.

I personally use a smart card and reader, so even the cli tool couldn't read my private key if it was compromised.

I had a keybase.io account for a few days and then deleted it recently. It seemed pretty nice, but then they sent me some invitations and it dawned on me that I don't know anyone else who would use it, and it adds even more complexity on top of the existing system, so isn't going to be that useful for newbies either.

</comment></comment><comment><USER10> Since this article was written, Google released an alpha version of a JS-based crypto tool: [http://googleonlinesecurity.blogspot.com/2014/06/making- end-...](http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end- encryption-easier-to.html)

They directly address some of the arguments against JS crypto: [https://code.google.com/p/end-to-end/](https://code.google.com/p/end-to-end/)

When End to End was released I was curious if any proponents of "JS Crypto Considered Harmful" would have a response, but I didn't see one, nor do I see one here. I would be interested to see a response for why the Google approach is flawed.

<comment><USER11> "They directly address some of the arguments against JS crypto:"

And in the very first 5 words, "End-To-End is a Chrome _extension_ " (emphasis mine), they take themselves out of the domain of the original post, which is 90% about Javascript included in web pages, not Javascript in general.

<comment><USER10> From the page: "For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography."

Browser extensions are still part of the browser. They still have DOMs, for example.

Maybe the article is trying to limit itself to talking about "Web page JavaScript". But if so this isn't very clear.

</comment></comment></comment><comment><USER12> While I agree with most of the article, in light of recent events (blanket surveillance, Heartbleed), an argument could very well be made in favour of using JS crypto -- not by itself, but in addition to TLS.

> The problem is, having established a secure channel with SSL, you no longer > need Javascript cryptography; you have "real" cryptography.

Scenario 1: You run a note-storing service as described in the article. Your site is delivered through TLS, using one of the non-DHE ciphersuites. You used your CA's web interface to generate the certificate and private key, because it's simpler than generating your own CSR. An NSL with an attached gag order requires your CA to submit all generated RSA private keys to the NSA and shut up about it.

Without JavaScript crypto, the NSA is able to passively decrypt each connection and collect all of the notes' contents.

If you add JavaScript crypto (again, as described in the article), they need to either mount an active attack (which might get discovered) or find a flaw in the JS crypto (which is very much possible -- but adds work).

Scenario 2: You run any site with a login prompt. You are using OpenSSL.

Without JavaScript crypto: during a brief window of two years or so, attackers may be able to exploit Heartbleed and read unencrypted passwords that were submitted by users.

If you add JavaScript crypto, attackers may be able to exploit Heartbleed and read HMAC-digests of recently submitted user passwords. Other sensitive data might, of course, still be disclosed.

</comment><comment><USER13> Just putting this heresy out there to see what happens:

I wouldn't want anybody betting their life or freedom on browser based crypto, but if widely adopted and well implemented, maybe it is good enough to make mass surveillance significantly harder? If _everybody_ 's crypto code is being tampered with, somebody is likely to notice.

</comment><comment><USER14> Browser cryptography has its place - the simple fact is that PGP is too hard for everyday users in its current guise (your parents are not going to go to key exchange parties). And, requiring users to install binaries on their computer (which can feasibly come with auto-update) to use encryption has just as high a risk of being subverted by somebody with malicious intent who is trying to target the communications of a particular individual. (Which is harder: acting as MITM in a company's internet traffic, or breaking into the target's Windows desktop?)

Mass market encryption is a worthy goal, and browsers are a reasonable platform to achieve that goal. Educating users about not installing extensions that can filter pages in their browsers, recommending incognito mode, etc are good steps. And of course TLS should be considered a minimum requirement for transport. Browser encryption is never going to be military grade, but it's a step up over unencrypted communication.

<comment><USER7> PGP being "too hard" doesn't mean that browser crypto "has its place". As I said upthread: if there's a "#1 most common fallacious reasoning strategy" for browser crypto experts, it's this one: "we really need browser crypto to work, therefore it works". No.

<comment><USER15> _PGP being "too hard" doesn't mean that browser crypto "has its place"._

While I've always enormously respected your opinion, you seem to have a very black/white perspective, aggressively attacking and/or belittling anything that isn't an infallible solution, even if it's a significant improvement for many or most scenarios.

You don't seem terribly pragmatic in many cases. I realized that long ago in a discussion on passwords and the browser - [https://news.ycombinator.com/item?id=2000833](https://news.ycombinator.com/item?id=2000833)

So many password incidents since would have been a complete non-incident with such a solution (or _anything_ similar), so I've always remembered your raw negativity because it wasn't a perfect solution: That because it didn't solve every possible issue, it's better to solve no issues.

<comment><USER16> What's the point of a fallible solution? The only people who actually need cryptography need infallible solutions. Everyone else can rely on security by obscurity--rot13ing their text will be good enough for them.

<comment><USER15> _What 's the point of a fallible solution? The only people who actually need cryptography need infallible solutions._

There is no such thing as an infallible solution. Start with that. When you're talking about actors who are exploiting RNG weaknesses, broaden your horizons a little.

PGP needs a key file. You need to (optionally) enter a passphrase. All someone needs to do is steal your key file and circumvent your passphrase (either of which there are _countless_ mechnanisms to achieve. They aren't trivial, but if we're talking about organizations that are taking advantage of imperfect RNG generators...) and boom, PGP has been rendered a false sense of security over the history of your communications. I mean, if we're talking about rogue actors taking over servers and injecting false script, such a situation is just as viable.

Everything is on a gradient. Any simplification (such as "fallible versus infallible") is just garbage time.

Again, and I realize Ptacek is a bit of a hero around here, his words above question, but I go back to his response to that password thing, which was the moment I understood the disconnect between big security talk, and actual security. When the alternative is (and _continues to be_ ) nothing -- which is exactly the case in the password discussion -- discarding options because they don't cover every scenario is absurd. It is grossly destructive, just as it's destructive to discredit PGP because it requires access to a keyfile.

<comment><USER16> I think the difference is between attacks that are currently well-known, and are _automatable_ (attacks that are, effectively, on the cryptosystem itself)--and attacks that boil down to social-engineering/rubber-hose cryptanalysis (attacks that are, effectively, on you.)

Or, to quote cperciva's talk ([https://news.ycombinator.com/item?id=7883707](https://news.ycombinator.com/item?id=7883707)), "the purpose of cryptography is to force the US government to torture you." If a cryptosystem makes torturing you for the required information easier than attacking the cryptosystem itself, the cryptosystem is "strong enough." Any system for which this isn't true isn't doing its job.

</comment></comment></comment></comment></comment></comment><comment><USER17> The thing that perplexes me about this whole debate is that some seem to think there's no inherent trust between parties exchanging encrypted messages.

That seems to be the first important thing to establish here. Alice sends public key to Bob, Bob encrypts the data using said public key and returns the encrypted data to Alice. What guarantee does Alice have that Bob didn't turn around and also post the plain text of Alice's request to [name your favorite social network here]? By the same token, what guarantee does Bob have that Alice won't turn around and post the plain text of the response on [name your favorite social network here]?

So it seems that inherently, even in the most secure of communications, there has to be trust between the parties exchanging the messages.

Please forgive me if this is already being discussed. The thread is rather long at this point so admittedly I didn't read every part before posting this.

EDIT: for correctness, cleaned up references to bob / alice.

<comment><USER17> So to frame the question in this light, the parties exchanging encrypted messages via javascript (on top of SSL) trust that they're doing everything in their power to maintain the integrity of their systems. Do they increase the surface area where attacks could take place? Sure. But in what way is sending encrypted messages on top of SSL any less secure than sending unencrypted messages on top of SSL.

One argument seems to be that there's no need for the added layer on top of SSL. Then I would ask, so why have passwords at all? After all it's guaranteed that the communications are secure. It looks like the disconnect here is that encrypted messages on top of SSL are behaving as a mechanism to help authenticate the recipient of the messages, like a password, and not trying to act in the same way that SSL behaves as a way to secure communications between 2 parties.

</comment></comment><comment><USER18> What about browser bugs?

I'd like to suggest that the software agent that has access to your private keys should _NOT_ be in the same process as an agent that directly handles data from the internet. The reasoning is simple: defense in depth, and the principle of privilege. Really, this is no different than the idea of running a web server in a chroot(2) jail.

A proper solution that _might_ be something that can be provided in some sort of browser extension (*though it's likely to have platform-specific requirements) is to simply call gpg as an external process. It shouldn't be hard to wrap that up in an API provided by the extension.

Of course, it would be even nicer if the browser's provided that feature directly, as they could utilize platform-specific features such as a secure- password-entry UI (e.g. pinentry)

<comment> mike-cardwell I agree. It should talk directly to gpg-agent. That way, it would automatically have support for things like the Crypto Stick and smartcard readers, and wouldn't necessarily have direct access to the keys.

</comment></comment><comment><USER19> >WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems.

NSA has got the keys.

I'm an activist in a regime and extra level of indirection may slow them down.

</comment><comment><USER20> This doesn't need a long post to explain. There is a single principle which makes all browser-based JavaScript crypto completely insecure forever:

Never trust any input, nor run any code, delivered by a remote host, unless its original author's digital signature has been verified by multiple distinct trusted mirrors, and as long as there is no way to change this input or code without repeating the process.

</comment><comment><USER21> What about using the Stanford JS Crypto library through a Google Chrome plugin (in addition to SSL) for an added layer of security?

Edit: Reading on, I see that the author addressed SJCL and browser plugins separately, but I still think that most of the problems raised in the article could by solved by using them in conjunction. That gives you a secure channel for delivering peer-reviewed encryption algorithms.

</comment><comment><USER22> All attacks against JS crypto addressed assume a somewhat determined and active attacker. Although this is definitely the big problem to be concerned about, that does not mean that there is _no_ place for JavaScript cryptography as protection against casual passive eavesdroppers. The problem is that users are quick to get a false sense of security because of this, not that JavaScript crypto is utterly without use.

Having said that, the state of web cryptography is abysmal. There is work on a Web Cryptography API [1], but so far browsers only implement the part that concerns the generation of cryptographically secure random values. Even then, an attacker can use injected JavaScript to override the window.crypto functions, so they would need to be protected somehow.

The lack of secure crypto prevents a whole class of applications from coming to JavaScript. Luckily my bank offers native apps, so I can just recommend my parents to use that instead of their website.

[1]: [http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#scope- al...](http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#scope-algorithms)

<comment><USER23> > assume a somewhat determined attacker

Most CVEs that come to mind assume a somewhat determined attacker.

It takes a reasonably determined attacker to commit to rails without permission [1] or run a ten-line perl script to crash a server [2] too.

Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring.

[1]: [https://github.com/rails/rails/commit/b83965785db1eec019edf1...](https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57)

[2]: [http://www.ocert.org/advisories/ocert-2011-003.html](http://www.ocert.org/advisories/ocert-2011-003.html)

<comment><USER22> JavaScript crypto is simply not a protection against that attack model. It _is_ protection against the attack model of the passive eavesdropper. That's all I'm saying. I completely agree with what you say.

Whether you view that attack model as something worth considering depends entirely on context. But it's a valid view for many applications. As long as people don't use it with any expectations of security under active attack models, I'd say that's okay.

<comment><USER23> > protection against the attack model of the passive eavesdropper

My argument would be that trying to protect against passive attackers with JS adds nothing beyond what SSL already offers.

Which is already required as a matter of course, and already compromises the payload if SSL is broken (again).

<comment><USER14> That's not true. Client side encryption allows the server to never have to touch user-generated content, which makes defense against subpoenas (and certainly blanket wiretapping) more feasible. It doesn't defend against the NSA who want to target a particular individual, but it's better than storing all content encrypted with the same known key, or storing it unencrypted.

<comment><USER23> Which circles back to the "Javascript is hostile to cryptography" point the article makes; I welcome any expert-audited JS libraries that can accomplish secure file encryption, for example. But even assuming this blocker is overcome, any illusions are shattered by the F5 key.

As pointed out elsewhere in the thread, there are few attacks that allow you to listen in on an SSL connection's content without also allowing you to modify that content - say, with a version that pastebins your keys.

Hence my argument that JS cannot provide anything SSL lacks, plus or minus some wishful thinking. Combine this with the fact that it's impossible to protect against a MITM-modified JS payload (see the "chicken-egg problem" portion), and you have a rather uphill battle here.

</comment></comment></comment></comment></comment></comment><comment><USER24> I disagree with an assertion. There is still a reason to use <client side web- based cryptography> if TLS is enabled: The first scenario where users want to store something encrypted on a server without the server having the keys.

Now, I'm not defending JS as a method of doing this, but there is a use case.

</comment><comment><USER25> I was under the impression that client side crypto was always a bad idea, is this really news?

<comment><USER26> End-to-end encryption basically requires crypto to be done on the client side. But there are different kinds of "client side."

The JavaScript sandbox is basically impossible to lock down. The plug-in that Google is developing is a much different beast.

</comment></comment><comment><USER27> The problem with cryptography is that if a human is supposed to remember the key, the key is probably weak and could be brute-forced, and if a computer remembers the key, the computer could be compromised and the key stolen.

To me, that's the biggest issue.

</comment><comment><USER28> I would echo a lot of the comments here criticising the article title - it is (by its own admission) referring primarily to the environment in which Javascript is usually run (browsers), with very little about the language itself.

So the use of the word "Javascript" in the title is very deliberately misleading.

As for the rest of the title, [http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

Title aside, the article is informative content-wise, but I'd personally be much more interested in an actual honest review of cryptography in Javascript the language - one that, for example, didn't choose to exclude NodeJS (or similar server-side tech). Can JS on the server do cryptography right? If not, why not?

</comment><comment><AUTHOR> This topic deserves a separate entry but cf. [https://news.ycombinator.com/item?id=7900597](https://news.ycombinator.com/item?id=7900597)

</comment><comment><USER29> Ok, now what? There is _clearly_ strong demand for cryptography in client side web applications. Telling people "don't do that" isn't good enough, they're going to do it anyway. How can we make it better?

One idea: a way to bundle, hash, and optionally sign a set of HTML/CSS/JS resources (not unlike a Chrome extension). If the bundle is updated the user can be prompted. If the user desires, they can check to see if trusted individuals or groups have already reviewed the code, or review it themselves. Perhaps the code is hosted on Github (or wherever) and people can comment on questionable changes there.

<comment><USER30> A good point to start is this comment: [https://news.ycombinator.com/item?id=1951556](https://news.ycombinator.com/item?id=1951556)

<comment><USER29> These seem like pretty weak arguments to me, especially if you were able to restrict execution to resources in the bundle (maybe that means no "eval" \-- fine)

Most languages permit similar amounts of runtime dynamism, they just don't make it as easy as JavaScript. Actually, in some ways JavaScript is _better_ than other languages in this respect:

* Using closures to encapsulate "private" variables is pretty bulletproof, AFAIK.

* ES5 features like "Object.freeze" and "strict mode"

* Object-capability safe subsets of the language, e.x. Caja, SES, etc

* CommonJS-style module system

</comment></comment></comment><comment><USER31> What about JS Cryptography _over_ SSL? Another security layer to protect against those who can break SSL, or is it just useless?

<comment><USER11> Useless. If the SSL is broken, the attacker can see through to all the messages the client is being sent, and decrypt whatever the client can decrypt.

Here's the thing about why JS-in-webpage crypto is fundamentally useless. The purpose of cryptography is to, somehow, secure some sort of communication between two parties. Maybe it's as tiny as a zero-knowledge proof, maybe it's a full-on encrypted general-purpose channel like SSL/TLS provides that can send arbitrary data back and forth in real-time, maybe we're trying to send small proofs of a message's integrity via hashes or signatures, maybe we're sending messages from our past self to our future self and want it safe in the meantime "at rest", but crypto is always about some sort of communication between parties A and B (the traditional Alice and Bob, even in that last case Bob is just an older Alice wearing a mustache).

Web pages run in a sandbox in which they fundamentally become part of the server's environment briefly. They're just an extension of the server, and are essentially designed from top to bottom to ensure that the only thing a web page can access is what was sent by the same server. The only cookies a server can get are the ones it set. (Modulo some cross-internal-domain stuff, but it doesn't change my point here.) The only requests it can manipulate are the ones it sent. The only resources the web page will access are ones the server tells it to. (Yes, a server can direct you to resources on other servers, and that's actually a big deal, a big delegation of trust, and one of the trickiest corners of browser security.) The web browser forbids a page from the server from accessing the hard drive on its own, or accessing any other site's stuff, etc. Structurally, the web page is just an adjunct to the server, by design, and anywhere this property fails is considered a security hole and fixed as quickly as possible. Without any ability to access any local resources that were not themselves originated from the server (i.e., HTML local storage doesn't get you out of this, the server fully controls it), the web page has no independent identity to assert. It is totally in thrall to the server.

Note how I kept saying "web page", and not "web browser". There's a big difference; web _browsers_ are allowed to do a lot of things a web _page_ is not. Pages have a distinct execution context and security policy different from the browser.

In the crypto sense, there's no communication between a "web server" and the "web page"; it's all just one system. The web _browser_ may use SSL/TLS to communicate the necessary information to form a web page, but once that is done, the web _page_ is deliberately put into a context where it is just an adjunct to a server, and there's no distinct two parties with which to communicate anymore, from a crypto sense. This may seem counterintuitive, because we see messages flowing back and forth, but that's all internal chatter, the _browser_ functioning as an internal bus for the _page_ /server unified security context. We have turned the full power of our cryptography and security research into making web _browsers_ that enable web _pages_ to function as extensions of the web _server_. It was and is not easy.

Further, what defines "server" is not the human word or concept, which can be distracting. What defines the "server" is _whatever finally produced the bytes that were used to create the web page_. If your _browser_ isn't using TLS/SSL, that turns out to be pretty must "just whoever felt like serving some bytes to you". (If you don't think that "intercepting web requests" is practical, it is. It's off-the-shelf tech for hackers. Do not assume it is hard.) On the other hand, if SSL is properly used (and let's skip over what that means and the validity of cert authorities, etc), then you do have assurance that the bytes came from your server without anybody in between, and the web _browser_ is providing assurance to the web _page_ that it is on an uninterrupted channel.

When not using _browser_ crypto, it just doesn't matter how you spin around; the attacker owns the web _page_ , and you can't do anything about it. And when I say "own", I mean it, fully, the web page is actually functioning as an adjunct to _their_ server, and you're stuck with the results. It doesn't matter what crypto you think you're pushing to the user's browser, because what's actually happening is that the attacker is pushing _their_ crypto to the user, and its relationship to what you inteded to push is entirely and solely up to their good graces, and by definition we're pretty much talking about people without good graces. Without SSL, you have _ZERO_ control over the user's webpage, and the attacker has all of it. Unsurprisingly, there's no crypto system that can survive that restriction.

When using _browser_ crypto, SSL/TLS is providing you the maximum degree of assurance that is possible already that the channel is secure, more or less to the maximum extent the network will permit (i.e. attackers can observe byte flows or who you connect to and there's not much that can be done about that). The argument that in- _page_ crypto is useless amounts to the observation that this binary situation admits of no "threading the needle", especially in light of the fact that without SSL being used we pretty much get to assume that an attacker can do absolutely _anything_ to the data between the user and your server, and it's pretty hard to construct a crypto system that can stand up to the attacker _arbitrarily manipulating it_ on the way to user, which is what many people here are trying to do.

(Incidentally, clearly understanding the difference between the web _page_ and the web _browser_ is also important for understanding why this is particularly a problem for web pages and not so much other things. It's because web pages go through so much effort to run in a sandbox such that the server doesn't get any additional permissions it shouldn't have via sending malicious web pages.)

(There's a better blog post in here struggling to get out; this is my first attempt to put this in words. The server probably needs a page/server distinction too, for instance; the web page isn't running with the full "server" privileges, of course, it's actually also running as a "page" sort of thing too, where the browser and the server are collaborating to create a single unified security context hosted within the two of them.)

<comment><USER31> Even if it's some kind of Diffie-Hellman JS crypto?

</comment></comment></comment><comment><USER32> I submitted a Show HN yesterday what I believe a potential legitimate use case for javascript crypto (or more specifically, in-browser client-side crypto):

Bring Your Own Filesystem ([https://github.com/diafygi/byoFS](https://github.com/diafygi/byoFS))

Example chat demo: [https://diafygi.github.io/byoFS/examples/chat/](https://diafygi.github.io/byoFS/examples/chat/)

It seems like an unhosted-style app (unhosted.org) can mitigate all of the OP's concerns.

> Secure delivery of Javascript to browsers is a chicken-egg problem.

I address some this in the byoFS README[1] and again in an /r/crypto discussion[2].

Since the webapp is unhosted, the webapp is built to work when being served from anywhere, including your local filesystem. This means that you could download the webapp anonymously, inspect/audit/checksum it, then run it from your local filesystem in the browser (try it! just right click and Save As...). Alternatively, you could load it from a server that you would trust to kill itself rather than comply with a secret court-ordered compromise (e.g. Lavabit, Internet Archive, etc.).

Additionally, since the webapp is just static files, all the webapp server sees is anonymous requests (over https to prevent MITM). It doesn't know who is requesting the static files, so it would be difficult to perform a targeted malicious injection. You would have to broadcast the injection, which is generally ill-advised since it might be spotted by a vigilant third party. Most of the surveillance injection attacks that have been leaked have been targeted, so this basically cuts off that attack vector.

So, in order to compromise this webapp through injection, you'd have to hack into the trusted static server and blindly serve the injection to everyone who requests the webapp (hopefully including your target). This is basically the same attack vector you'd have to do if you were trying to inject something into a download-and-install local application.

I don't think javascript crypto is universally a good idea, but for this unhosted use case, it can limit attack vectors to the same as download-and- install local applications.

> Browser Javascript is hostile to cryptography.

True, which is why WebCryptoAPI should be prioritized, and I can stop using SJCL in byoFS. Once APIs for crypto primitives are baked into browsers, this argument disappears.

> The "view-source" transparency of Javascript is illusory.

It's certainly much better than inspecting desktop apps. Also, if your webapp is unhosted, you can certainly publish a signed hash of the static files, which can be verified after you download the app and before you run it.

One infrastructure improvement that might be very helpful would be to be able to buy an SSL certificate from a CA that is limited to a particular file hash, which the browser checks before showing the connection as "validated" (maybe a checkmark beside the https lock?).

[1] - [https://github.com/diafygi/byoFS#security-and- philosophy](https://github.com/diafygi/byoFS#security-and-philosophy)

[2] - [https://pay.reddit.com/r/crypto/comments/289w7x/bring_your_o...](https://pay.reddit.com/r/crypto/comments/289w7x/bring_your_own_chat_javascript_secure_chat_using/ci9cx7q?context=4)

</comment><comment><USER33> same submission from 3 years ago: [https://news.ycombinator.com/item?id=2935220](https://news.ycombinator.com/item?id=2935220)

</comment><comment><USER34> I've stopped reading at: "You could use SSL/TLS to solve this problem, but that's expensive and complicated."

</comment><comment><USER35> This article is all over the place.

First of all calling it "JavaScript cryptography" only to immediately correct itself "oh, we mean browser client-side scripted cryptography, not JavaScript in general, say Node.JS".

Then calling it "cryptography", when all the article talks about is hashing passwords. There's more to cryptography than hashing passwords, and not all of it is susceptible to the attacks described.

So the real title of this article is "Client-side scripted password hashing in browsers less than ideal". I know, doesn't roll off the tongue as sweetly as "JavaScript eats babies", but what you gonna do.

Third, the faulty logic of "this new technique has a bad edge case, so we should completely reject it, despite any benefits".

The article just glosses over the situation where the script is served securely and yet you hash at the client. "We already have a secure connection, anyway" the author claims. Sure, but the server still gets the plain text password, because TLS doesn't hash, it encrypts (and you can decrypt). If the server is passing the login request to a third party to check the hash, turns out it's still a good thing to hash at the client so the intermediating party can't abuse its role, without the horrid UX of OAuth. Has the author thought of that? Nope, just dismissed the potential outright.

Plain old-school TLS/SSL connections have exploitable edge-cases as well. Should we "consider them harmful"?

Intelligent conversations about security require nuanced opinions that go into when something is useful, and when it isn't, and let us make the call if it's _harmful_ or _useful_ for a given project.

Calling something "harmful" outright and only listing the cons without the pros isn't this kind of intelligent conversation. It's just counterproductive scaremongering.

<comment><USER7> This article has virtually nothing to do with password hashing, but the fact that readers routinely take that away from it is part of why I don't like it much either. We didn't promote it, or post it on HN; I think I posted it to Twitter once, and now people re-find it once a year.

I'll absolutely win an argument with you (or, I think, anyone else) about browser Javascript crypto. It's simply a bad idea. I just don't think this particular article will.

We don't reject browser Javascript crypto "despite any benefits". We reject it because those benefits are illusory. It's clear that browser crypto makes people _feel better_ , but TSA airport security also makes the majority of Americans _feel better_ too.

<comment><USER36> what about distributed as signed browser extensions?

<comment><USER26> What's that Google is working on, and it's a much better environment. The code lives on your computer all the time, and you (in theory, assuming the proper browser settings) can make sure you are using a constant version of the code that matches up with what other people are using and auditing.

You can't lock down JavaScript at all. Your browser should (in theory) tell you when a plug-in is asking to be updated and give you the option to say "nope."

In theory, you could even walk up to a brand-new (assuming uncompromised) computer and reinstall the plugin. But you would still need some way of knowing that you were installing the same version you decided to trust earlier. Recognizing checksum pictures, I guess?

</comment></comment></comment></comment><comment><USER37> Long story short, this topic won't end until XSS gets fixed. The people writing HTML don't consider XSS their problem, its been what 20 years?

Nobody even knows what 'fixing' xss would look like.

<comment><USER38> Um, the "people writing HTML" have done a lot of work to prevent XSS, by introducing Content-Security-Policy and other HTTP headers: [http://ibuildings.nl/blog/2013/03/4-http-security-headers- yo...](http://ibuildings.nl/blog/2013/03/4-http-security-headers-you-should- always-be-using)

The main problem is backwards compatibility, as older browsers don't support them, but the idea that people have their head in the sand re. XSS is complete nonsense.</comment></comment>


Ask HN: What do you use to test latency, jitter, etc. between servers? - <AUTHOR> What do people use to test various metrics between servers? (bare-metal or not). I'd imagine metrics like the following would be very useful:<p>- latency - packet loss - jitter - Bandwidth - All of the above, but with different QoS settings.<p>The data should then be able to be displayed as a checkered dashboard which gets green/yellow/red based on the various metrics. <comment><USER2> iPerf is usually enough for me though it probably isn't suitable for constant measuring if that's what you are looking for.</comment>


Show HN: Stig – A CLI tool for searching GitHub from the terminal - <AUTHOR> https://octobanana.com/software/stig <comment><AUTHOR> Hello there!

For a weekend project, I wanted to write a program that would use the C++ HTTP client library I've been working on recently. I was curious to put it to the test in a real scenario and see what works and find any pain points. I decided on making a CLI program that utilized GitHub's HTTP API to perform search queries.

Stig is a CLI tool for searching GitHub from your terminal. It has all the same sorting and filter options that are present on GitHub, and outputs coloured, formatted results to stdout.

Feedback and thoughts are welcomed!

View on my personal website - [https://octobanana.com/software/stig](https://octobanana.com/software/stig)

View on GitHub - [https://github.com/octobanana/stig](https://github.com/octobanana/stig)</comment>


Approximating CNNs with Bag-of-Local-Features Models [pdf] - <AUTHOR> https://openreview.net/pdf?id=SkfMWhAqYQ <comment><USER2> I consider the paper "ImageNet-trained CNNs are biased towards texture; increasing shape bias improves accuracy and robustness" essentially mandatory follow-up for anyone interested in this. It goes further with its conclusions and introduces a potential solution. By introducing the 'Stylized-ImageNet' dataset, they found that they can force the network to learn shape data, improving scores even on standard ImageNet and preventing this BagNet trick from working.

[https://openreview.net/forum?id=Bygh9j09KX](https://openreview.net/forum?id=Bygh9j09KX)

<comment><USER3> seems like texture training would be occur after shape training.

</comment></comment><comment><USER4> Open Review [https://openreview.net/forum?id=SkfMWhAqYQ](https://openreview.net/forum?id=SkfMWhAqYQ)

</comment><comment><AUTHOR> Short video discussing this paper: [https://www.youtube.com/watch?v=QpptSohzuDo](https://www.youtube.com/watch?v=QpptSohzuDo)

<comment><USER5> +1 for the channel. Very high signal to noise ratio channels among: Brady channel collection (numberphile, cphile etc..)

</comment></comment><comment><USER6> For anyone else who wanted it: CNN = Convolutional neural network

I somehow mis-parsed that as the news network the first time and became very confused for a moment.

</comment><comment><USER7> It seems that texture detection is for NN the simplest and easiest way to recognize objects. I guess early animal vision system used to work this way. Then predators and prey developed camouflage and mimicry, to fool texture detection NNs. So there was strong evolutionary pressure to recognize shapes, which is much harder task, but essential for survival. Probably that's why people see in the picture a cat (predator) and ConvNet recognizes most obvious thing (elephant) in terms of statistics.

<comment><USER8> I wonder if capsules are better at recognizing shapes

</comment></comment><comment><USER9> The results on this paper are 4x worse than the state of the art of a couple of years ago. Personally I think the paper oversells their results. Creating a much worse model by making it much simpler doesn't seem that interesting, to me...

<comment><USER10> The point is not about creating a new good model and getting good results, but about understanding how the CNN works. And the results of this paper yield some very interesting findings in this respect. Maybe see this two-minutes- paper video for a short explanation: [https://www.youtube.com/watch?v=QpptSohzuDo](https://www.youtube.com/watch?v=QpptSohzuDo)

</comment></comment><comment><USER11> I read this title as being the news network first which was much more interesting :)

</comment><comment><USER12> Is this closer to how real biological brains process images?

<comment><USER2> No, I imagine it's fairly simple to determine that humans use nonlocal context in image recognition.</comment></comment>


The Hydra-Light a Salt Water Lantern and Charger - <AUTHOR> https://www.kickstarter.com/projects/1993414184/the-hydra-light-pl-500-salt-water-energycell-lante <comment><USER2> Fundraisers can't be Show HNs. Please read the rules:

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


ASA Investigating No Man's Sky's Steam Advertising - <AUTHOR> https://www.rockpapershotgun.com/2016/09/28/asa-investigating-no-mans-skys-steam-advertising/ <comment><USER3> An interesting side note is that the most popular recent thread on /r/NoMansSkyTheGame/ has been about people who have stopped playing but check in daily for news.

A common theme in that sub is that the news about Hello Games is far more entertaining than the game itself.

Fundamentally, the game failed to deliver any emergent gameplay between the various procedural components. An infinite universe that's completely lifeless, waiting for for you to interact with it.

They've released 9 updates so far, mostly bug fixing, there's talk of new features in the future but I have a hard time seeing how they truly fix the game.

</comment><comment><USER4> I don't understand why it's only No Man's Sky that's being investigated. What about other known games that came out below expectations and with misleading advertisements? Watch dogs being a prime example.

<comment><USER5> ASA are reactive not proactive, it takes complaints for an investigation to be triggered.

Their standard punishment is "don't show the advert again in this form", this isn't a scary prospect for Hello Games.

<comment><USER3> > this isn't a scary prospect for Hello Games.

You're right, they have far bigger problems, I wonder if HG has a future given how tarnished their name is?

I feel sorry for Sean Murray, in hindsight he seems like a Walter Mitty character; big on dreams and when anything was suggested in an interview he let his imagination answer.

<comment><USER6> The new Peter Molyneux?

<comment><USER3> I didn't follow that debacle too closely, from what I understand Spore was too ambitious but at some level it delivered.

NMS on the other hand is just a badly designed game. Sure, there was hype and over commitment. However, the core game loop is so shallow it's borderline fraudulent.

<comment><USER7> You're thinking of Will Wright; Peter Molyneux's classic fame was Populous and Black and White, and recent controversy Godus.

<comment><USER6> Fable is the one that sticks out most in my mind. He's a very talented director and developer but I think by his own admission he hypes his own work beyond what is reasonable. I'm sure he was never doing so to deceive, but you can't talk about amazing features and then completely fail to deliver and not expect blowback.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> That's great to see happening, but any word on the situation with Steam refunds since you pretty much had to play more than an hour or whatever their refund cutoff is to determine that the game oversold itself?

<comment><USER9> The automated and entirely machine-driven refunds will reject you for too much playtime, but after that rejection you go further and get it to a human and they'll refund you.

</comment></comment><comment><USER10> It's worth noting that Elite: Dangerous is constantly improving and is definitely worth another look if you found the gameplay a bit thin when it was released. Planetary landing, multi-crew ships, fighter launch from larger ships have all been introduced.

Still no landing on earth-like planets thought :-(

<comment><USER11> When did multicrew happen? The game is on life support as the company is working on other projects. They keep missing all the deadlines.

<comment><USER12> > company is working on other projects.

This is how game development works.

You only need the senior engine engineers when you are tackling hard problems (e.g. they would have been roped in for planetary landing). You only need artists when art is being added to the game. Multicrew? Probably needs a senior network coder or two. You can't pay people to sit around and do nothing, and you can't sack people with in-depth knowledge about your IP - <USER2> you put them on another project. It's almost like consulting, but for a single entity who so happens to be yourself.

</comment></comment></comment><comment><USER13> Bleh. It is the same brouhaha that surrounds every overhyped game. This has been going on for ages.

I guess the new twist is that gamers pay up front, sometimes years ahead, and that only adds to the disappointment when the game actually comes out and is not the best thing since sliced bread.

</comment><comment><USER14> > "My hope," he tells us, "is this could give Valve a reminder/prod that they > themselves have a responsibility, they can't just blame individual > publishers, and this might help them keep future games being listed, more > honest."

Why is it Valve's responsibility? And how did Valve act inappropriately at all? AFAIK they were the first publisher/store to offer refunds for NMS after the story broke that it was largely unfinished, and aside from some wasted time on the part of the players everyone walked away relatively unscathed.

The alternative would be that Valve would have to have a review process for every game that passes through Steam, which means they would have to charge a lot more for the Steam Greenlight service. The vast, vast majority of indie developers do not do this sort of thing, and benefit greatly from the audience and ease of distribution that Steam provides. I just don't see what offloading that responsibility to Valve would accomplish, aside from setting Valve up to be a deep-pocketed lawsuit target.

<comment><USER9> > AFAIK they were the first to offer refunds

Not out of any manual action on their part. All refunds steam offered were 100% in line with their policies from before the game was released.

<comment><USER14> Manual action isn't needed when the policies are already good.

</comment></comment></comment><comment><USER15> Wow. I really wanted this game to be amazing. Hell, I've played it over 100 hours, but that's mainly because I waited so long for it to come out.

I have an 8x AMD with 32GB RAM and a Radeon 7970. Not a bad system. At 1080p it drops frames all the time. It freaks out at weird moments in game play. There is this weird tick where every alien that shows up at a space station will be the same alien. As I play it I really think about how if they hadn't hyped it, it would be fun...maybe not worth 60$...but it would be fun. I;m old. I guess I was hoping it would turn into the greatest Trade Wars 2002 ever. It's really not even close. As you move around the galaxy you really wonder sometimes...why the fsck am I doing this again? I've upgrade my person and ship to the point that they are almost indestructible to anything that I've met to this point. At first I did this alternate path through the game where you "follow the atlas"...you go through multiple solar systems chasing this thing and it gives you a shiny red orb every time that you catch up to it. Ok. Then at the last one it says..."hey, I'm the last one. Do you want to give me those stones and create a new star?"...Sure why not. You give it the stones and then it says...in text..."somewhere...out there...a new star was created. thanks for the stones dawg". That's it. I thought there would at least be a pre-rendered star-being-created animation. Nope. AND you don't have those shiny orbs anymore which were the most valuable things in the in-game economy.

At this point, I keep thinking that HG will release a patch that makes it not terrible. Seriously. I would settle for just bad at this point. I'm not like a lot of the Reddit crowd that wants to see Sean Murray hanged. I just think this was a huge wasted opportunity. If this had been a PC only game or an Xbox indie release it would have been amazing. Having to go the big time console release route made the hype really crazy. It showed, though, how intense the followers of an immersive universe sized space game would be if you could build something like a high quality 3D Trade Wars 2002.

But yeah...they should make it not suck at this point. I really try to not be critical of other people's creative work, but seriously. Make it not suck. (Some new music would be great too. I like it, but the sushi bar techno gets old after a while.)

EDIT: I hadn't watched those trailers again since the game came out. OH MY GOD. I forgot how amazing they were. There was more diversity in the first 3 minutes of that trailer than there was in 100 hours of gameplay. Jesus. Sean said in an interview that they were doing all of this generation on the client side and relying on the fact that planet creation was somehow idempotent for everyone to have the same experience. What I don't get is why, in 2016, would you even remotely try to do everything client side? As soon as someone jumps into a solar system that would be a trigger for a distributed job on a cluster to assist in generating the details. Those details would need to then be cached somewhere, but you wouldn't need to generate them again. After that some direction and story mechanics could steer people towards some pre- engineered experiences that would bring them together and drive the plot. Jesus Christ, this isn't rocket science anymore. There are text books with this stuff in it. They said "no loading screens"...I WISH THERE WERE. The stutter that the game has when transitioning between environments is worse than a loading screen.

I would have bought a new computer to play the game in those trailers. Man. What a waste.

<comment><USER16> You've ploughed over 100 hours into even though it "sucks" and you want it to be patched so it's "not terrible" anymore?

Seems like a lot of time to dedicated to something that you don't really like. Do you feel like you got value for money, given the amount of time you've spent playing it?

<comment><USER17> yep, 100 hours ?! ...and for perspective, it has been less than 2 months since release date in early August. That is a HUGE investment of time. I like the game (although I certainly haven't put 100 hours into it), it has some true innovation but its a friggin' game. How much can one expect from a computer game? You play it for a while until you get bored and then quit. 100+ hours of gameplay for $60 seems like a smashing success to me. I mean, how much time would a "great" game use up? Are we in South Park Territory (... [https://en.wikipedia.org/wiki/Make_Love,_Not_Warcraft](https://en.wikipedia.org/wiki/Make_Love,_Not_Warcraft))??

I get the feeling HG was forced to release it too early-- probably by pushy "project management professionals." Someday we may hear the juicy details of what happened.

<comment><USER13> That is still under 2 hours per day. Not that much in my books, especially if you do not watch TV or play other games...</comment></comment></comment></comment>


Investing Your First Dollar - <AUTHOR> http://blog.instavest.com/investing-your-first-dollar <comment><USER2> I feel like this is terrible advice. If you have $10,000, there are safer ways to invest it. If you are using a short blog post to plan your retirement and ultimately your future, you are in trouble!

Check out mutual funds (managed) and index funds. Get your feet wet slowly in something with a low risk. Don't jump into the stock market and just choose companies you like across different industries. This is a recipe for disaster.

Get started by _learning_ about the market instead of throwing money at it. Don't invest until you know who you're giving your money to, and what expectations you should have.

Some beginner sites that helped me out:

[http://www.mrmoneymustache.com/2011/05/18/how-to-make- money-...](http://www.mrmoneymustache.com/2011/05/18/how-to-make-money-in-the- stock-market/)

[http://www.mrmoneymustache.com/2011/06/07/where-should-i- inv...](http://www.mrmoneymustache.com/2011/06/07/where-should-i-invest-my- short-term-stash/)

[http://www.reddit.com/r/personalfinance](http://www.reddit.com/r/personalfinance)

<comment><USER3> This is, categorically, not "terrible advice". There might be better things to do, sure. The author is clearly suggesting that it's just a starting point. He/she is clearly not stating that this is a plan for life, or a plan for a large amount of money, or anything of the sort.

For many people, just getting started is a huge barrier. Index fund? What is that? Mutual fund? What is that? Buying a dozen stocks in some companies you've heard of can at least get you interested. You've got skin in the game. Now you are motivated to learn. The idea that you have to learn a whole load about it first just doesn't make sense. People are busy, it's tough to get the motivation to learn. Skin in the game is a great way to start.

<comment><USER4> It is definitely terrible advice. It sets people up for a long investing career full of behavioral errors and vain attempts to beat legions of people and machines better than you at actively trading.

<comment><USER3> No, it just gets them started. There is no mention in the piece about this being the way to invest for the long-term, so no one is getting "set" on anything. It doesn't suggest you can "beat the market" or appeal to anyone's vanity.

I believe you are underestimating the perceived complexity in investing by people who don't understand it at all. I also believe you are underestimating the amount of diversification that a dozen stocks chosen from different industries can provide. It's better to start sub-optimally than not start at all.

</comment></comment></comment></comment><comment><USER4> My first reaction is to flag and leave a snarky comment. Instead I'm going to comment and upvote.

This is terrible advice on investing and not a starting point. Hold cash? Wait for the right time? Give me a break. And then they recommend you invest with them!

I recommend The Four Pillars of Investing by William Bernstein.

[http://www.amazon.com/The-Four-Pillars-Investing- Portfolio/d...](http://www.amazon.com/The-Four-Pillars-Investing- Portfolio/dp/0071747052)

At least he isn't trying to sell you anything besides the book.

</comment><comment><USER5> Investing isn't easy - that's why I think its good to start earlier and learn quickly. This way, when you have a larger capital base, you've learned some lessons and hopefully conquered some behavioral pitfalls.</comment>


Warren Buffet is now the world's richest man - <AUTHOR> http://tech.yahoo.com/news/nm/20081010/tc_nm/us_buffett_forbes

<comment><USER2> Headline is incorrect. The article says Warren Buffet is the richest _American_ - not the richest man in the world. Second, a post like this has little to nothing to do with Hacker News.</comment>


Zero to MVP in 24 Hours with Aaron Gough from ReadMyCode (Video Interview) - <AUTHOR> http://ideatin.com/2010/06/zero-to-minimum-viable-product-mvp-in-24-hours-with-aaron-gough-from-readmycode/

<comment><USER2> Thanks for the opportunity to do this Marc! It was good fun!

<comment><AUTHOR> Same here Aaron.

Look forward to having you again in the future.</comment></comment>


The Coolest Cooler is turning into one of Kickstarter's biggest disasters - <AUTHOR> http://www.theverge.com/2015/11/18/9758214/coolest-cooler-amazon-kickstater-shipping-production-delay <comment><USER2> The creator probably felt pressure to get product on Amazon for holiday. It doesn't say anywhere in KS's TOS that creators must ship to backers before Amazon. It's amusing how many people dropped hundreds of dollars and are now livid over such a superfluous product.</comment>


Wild in the Streets: A 24-Hour Field Guide to New York City - <AUTHOR> http://www.nytimes.com/interactive/2015/07/03/nyregion/A-24-Hour-Field-Guide-to-New-York-City.html

<comment><USER2> Fun fact. There are still a few pigeon keepers in Brooklyn. It's an entire subculture, complete with political intrigue. They're known to "kidnap" each other's birds and hold them ransom. Even funnier is that there are a few falconers that keep _their_ birds just to screw with the pigeon keepers.

</comment><comment><USER3> Author is wrong about the Chicken mushrooms, they are actually one of the main beginner-safe mushrooms we have in the area.</comment>


32 Years Later, Checking in on Ogilvy's Advertising Predicitions - <AUTHOR> https://medium.com/@dannysauter/32-years-later-checking-in-on-ogilvy-s-advertising-predictions-463ce0e02628 <comment><USER2> The article ends with "0.538% batting average — exceptional by all measures."

Ignoring the extra % in there, a .538 batting average is exceptional... if you are playing baseball. In this case, you are not playing baseball. Ogilvy's predictions were barely over 50% correct, which is actually pretty bad if you think about it. The article's conclusion is completely off.

<comment><USER3> 50% isn't impressive in a binary true/false scenario, but I'd say it's impressive when making unbounded predictions.</comment></comment>


Y Combinator's Demo Day Summer 2008 - <AUTHOR> http://www.techcrunch.com/2008/08/14/y-combinators-demo-day-summer-2008/

<comment><USER2> YC should fund a start up that designs logos.

<comment><USER3> Or just get someone on comp.lang.lisp to design a logo, merely by suggestion, as I did in 2006 - for Lisp.

<comment><USER4> There's a lisp logo?

</comment></comment></comment><comment><USER5> Best of luck to all the groups presenting their work today.

</comment><comment><USER6> Frogmetrics reminds me of the little "evaluate my work" devices at the customs inspection stations in Chinese airports-- five buttons, each with a smiley (or frowny) face, with helpful captions like "inspection time too long" and "extremely satisfied".

<comment><USER7> They have those at most grocery stores now. Or, at least the ones I go to. "Was your cashier friendly today?" "Was your store clean today?"

</comment></comment><comment><USER8> Good luck guys - don't forget that its a marathon, not a race!

</comment><comment><USER9> RE: Job Alchemist - their homepage copy is impressive and persuasive. Thanks for the template :)

<comment><USER10> job syndicate is great - but jobalchemist.com could use a bit of SEO :p

<comment><USER9> I meant Job Alchemist's product homepages: startuply.com and jobsyndicate.com :)

<comment><USER11> Thanks! Job Alchemist is just a little sparse - for right now we just need a site that starts to build the parent brand.

</comment></comment></comment></comment><comment><USER12> most of those logos look so similar, are they using the same designer?

<comment><USER13> Most logos on the web look similar.

Those are just put next to each other.

</comment></comment><comment><USER14> I am very curious about Snipd, is there more information available? Any chance for an alpha invite? :)</comment>


Magento 2 Shipping per Product - <AUTHOR> https://meetanshi.com/magento-2-shipping-per-product.html <comment><AUTHOR> Magento 2 Shipping Per Product Extension helps you adding separate Flat Shipping Rate for Each Product on Magento 2 Stores.</comment>


Ask HN:Where can I find free web hosting for developers? - <AUTHOR> My daughter is just starting her career and I wanted her to be able to get some work done without setting up her laptop as a development machine. She currently uses windows and is starting to use Linux but I want her to be able to get started right away. <comment><USER2> Funny, I just looked for that. Make her take the red, not the blue pill Morpheus. Let her solve problems on her own, don't instruct, but give usefull hints. If she has or you have any question, just ask, don't be shy. I or someone else is sure there to help (just in case you/she need it).

For easy php stuff: [http://www.square7.ch/](http://www.square7.ch/)

A real shell and more: [http://shells.red-pill.eu/](http://shells.red- pill.eu/)

(Btw. I recommend SuSE or Ubuntu for the beginning, Sabayon, Gentoo or Arch later when she's good enough and wants more. But I'm sure she would perform well on a Mac too, Macs teach you to become a consumer though)

       I recommend her to NOT install LAMP or XAMP.

She should use a prebuilt appliance from [http://turnkeylinux.org](http://turnkeylinux.org) instead. That will teach her howto sftp too. KDE and Gnome integrate sftp into their "Explorer", just ask or google and you will find howto do use that without a "FTP-Client".

</comment><comment><USER3> First thought is if shes serious about being a developer

a) setting up a development system is a good and necessary skill to have for a web developer. As other posts mentioned XAMPP, WAMP, etc are good methods to do it painlessly. Having a development machine makes development way easier as you can turn on error reporting, use interactive debugging tools, etc. things that are not as possible on a 3rd party host.

b) getting some inexpensive hosting is a good thing for her career development. There are some quite reasonably priced hosting out there, I hear Dreamhost name a lot in that respect, I myself use Bluehost, quite good and inexpensive. Experience dictates to stay away from GoDaddy they are kind of the bad side of town internet wise with hard-sell pushing of services and misleading/confusing management pages.

Being a developer isn't just having everything set up and ready to "make stuff" you have to learn a little bit of how it works underneath too.

</comment><comment> antonio-R [https://www.heroku.com/](https://www.heroku.com/)

[https://www.cloudcontrol.com/](https://www.cloudcontrol.com/)

[https://www.openshift.com/](https://www.openshift.com/)

All of them allow you to host your projects.

</comment><comment><USER4> If you're looking to host static pages, [http://neocities.org/](http://neocities.org/) is great. For anything more I'd recommend Heroku.

</comment><comment><USER5> Come on, get her a real server, vps at least. If you look hard enough you can find one for $10 a month, less if you pay for a year. Do you really want her to waste her time struggling with all the crap that comes with 'free'?

Plus there is the added experience of server administration, which she should know at least a little about, if she wants to learn development.

</comment><comment><USER6> Maybe [http://neocities.org/](http://neocities.org/) for starters.

However I believe a local xampp install will be better for the long run. It's fairly effortless to install, gives a nice control panel to turn it on/off and it's very easy to edit and see your changes.

</comment><comment><USER7> If you are asking about developing in the cloud, there are two options:

[https://www.nitrous.io/](https://www.nitrous.io/) or [https://koding.com/](https://koding.com/)

On Koding it requires an invite, but I have a couple of invites.

<comment><USER8> Can you please send a Koding invite, can not find your email on the profile page, mine is firstname.lastname@example.com

</comment></comment><comment><USER9> I just started using Nitrous.IO to develop for AppEngine. It itself is not hosting but it is a free development box. [https://www.nitrous.io/join/ll8ET-M6wvU](https://www.nitrous.io/join/ll8ET-M6wvU)

</comment><comment><USER10> You can host webpages (HTML, CSS, and Javascript) free from Google Drive: [https://support.google.com/drive/answer/2881970?hl=en](https://support.google.com/drive/answer/2881970?hl=en)

</comment><comment><USER11> Heroku is pretty much standard for getting web apps up painlessly. The last things you want is for a novice to get buried under devops hell. For simply hosting static HTML/CSS/JS, I would use GitHub Pages.

</comment><comment><USER12> Here is a site I'm going to be trying out. Has PHP 5, MySQL 5, ASP.NET. It's free. [https://secure.biz.nf/order.php](https://secure.biz.nf/order.php)

</comment><comment><USER13> I'm surprised nobody mentioned this, but AWS offers one year of free EC2 usage.

</comment><comment><USER14> github, it provides hosting for her websites and source codes!

<comment><USER2> [http://bitbucket.org](http://bitbucket.org) is probably better.

<comment><USER14> I have the same opinion, but she need a web hosting too

</comment></comment></comment><comment><AUTHOR> Thank you so much!!

</comment><comment><USER15> appfog???

</comment><comment><USER16> heroku.com</comment>


Ask HN: After 2-3 years, what are your favorite Touch Bar use cases on the Mac? - <AUTHOR> <comment><USER2> I guess it's kind of nice to have Spotify controls for pause and play over other applications, but I would gladly give that up for regular keys. That's literally the only thing I can think of. I want my function keys, I want my physical volume and brightness.

</comment><comment><USER3> I have not bought a MacBook since they introduced the Touch Bar. It offends me that they got rid of it, and I refuse to pay money for their laptops until they offer me one without it. I'm about to switch entirely to Lenovo and never looking back if they don't make one without a Touch Bar by 2019.

</comment><comment><USER4> I love the Apple Pay / fingerprint reader button.

Beyond that, I do my level best to avoid touching it. The volume and brightness features are nice but it would be better to not have had it as I mis-key it all the time and it exits me from where I'm working.

</comment><comment> java-man none. please bring back the regular keys!

</comment><comment><USER5> Mostly volume & brightness. In some rare cases I use it for emoji, but it's typically faster to get them from iMessage and copy & paste. I tried with screenshots and lock screen, but I'm too used to the keyboard shortcut and I always use these.

I guess I'm not really using the touch bar a lot because I'm used to looking at the monitor vs the keyboard, which I think it's pretty common for many folks here. Maybe people used to looking at the keyboard have more uses?

</comment><comment><USER6> For me, mostly useless. I do however, enjoy using Touch ID for sudo permissions.

HT to: [https://twitter.com/cabel/status/931292107372838912](https://twitter.com/cabel/status/931292107372838912)

</comment><comment><USER7> Out of curiosity. How many of us knows that swiping sideways quickly on the volume button changes the volume?

Ditto for brightness.

<comment><USER8> It doesn't have to be quickly. It's very convenient. Just touch the volume or brightness button and keep holding, then just move your finger left or right to change the value.

<comment><USER7> No. I really mean swipe quickly. Try it out :)

</comment></comment></comment><comment><USER9> Touch ID login is super convenient, and remapping Caps Lock as a tactile Esc key has made for a much more pleasant vim experience. That's it.

</comment><comment><USER10> This

[http://vas3k.com/blog/touchbar/](http://vas3k.com/blog/touchbar/)

</comment><comment><USER11> I love using touch id instead of password for sudo.

I also accidentally hit the Siri button all the damn time, I should probably remove it or something.

</comment><comment><USER12> Touch ID, logging in</comment>


Get List of all Attachments in PDF File & Download Selected Attachment - <AUTHOR> http://saaspose.com/blog/saaspose-pdf/archive/2012/09/12/manage-attachments-in-your-pdf-files-using-saaspose-pdf-rest-api.html Saaspose development team is proud to announce the new release of Saaspose.Pdf. This new release offers a powerful collection of features that help you manage attachments in PDF files. You can download the attachments from PDF files and save them for further use. You can also get the list of all attachments within the PDF file. Using Saaspose.PDF, you can choose to get the selected attachment from PDF files. Saaspose.PDF also allows you to get the number of attachments in a PDF file. This set of features is simple to use yet yields desired results in no time. You can improve the productivity of your applications by using these features for your PDF files in the cloud. All you need is to download the desired SDK from Github.com and get started with managing the attachments of your PDF files. <comment><USER2> I work with, and write, software for managing file types, at work. Currently PDFs are something that we deal with on a daily basis. I looked at your documentation and the API looks very similar to Aspose's. Not to mention, your name seems like a play on Aspose. Are you affiliated with Aspose, or is your toolkit powered by Aspose's software?

Edit: After poking around your website a little more, I see that you are in fact Aspose (<http://saaspose.com/support/contact-us>). I only wish that your PDF library could handle extracting attachments from very large PDFs (2GB in size, etc). :)</comment>


Human body hackathon - powered by the Human API project - <AUTHOR> http://humanapi.me

<comment><USER2> Wow the Human API looks very useful and quite promising; I can think of several applications that will greatly benefit from this.

I'll definitely be keeping my eye on this.

</comment><comment><USER3> would be perfect for aggregating data from Fitbit, pebble and other wearable devices

</comment><comment><USER4> Who's behind the Human API? Run Keeper peeps or someone else?

</comment><comment><USER5> San Fransisco :|</comment>


Web Developer tool box - <AUTHOR> http://nerdi.com

<comment><USER2> You really need to have more information about what this is. Why would I give you my email if I don't know what the product does?

</comment><comment><USER3> I'd "love to learn" what this is about, before I give my email.</comment>


Ex-cop: it's "bizarre" if we can't explain to public what our snooping gear does - <AUTHOR> https://arstechnica.com/tech-policy/2017/01/how-an-ex-cop-tries-to-get-a-police-department-to-think-about-privacy/ <comment><USER2> It's refreshing to see more privacy/surveillance conversations like this one happening, but unfortunately this doesn't touch at all on government/officer overreach or corruption, which completely nerfs the content of this piece.

Show me an in-depth interview like this one where we address what happens when governments either systematically overreach (e.g. persecuting Muslims or Jews) or individual overreach (e.g. officer had a bad day, looks up your internet history, finds a felony and arrests you.)</comment>


The Expendables: Life in the French Foreign Legion (2012) - <AUTHOR> https://www.vanityfair.com/culture/2012/12/french-foreign-legion-expendables <comment><USER2> Been a few posts about the foreign legion here recently. Are people thinking about alternatives to sitting at a desk? It seems like the most extreme counter.

<comment><USER3> I think for former criminals who have finished serving their time, the Foreign Legion would be a chance for a fresh start if they chose to keep the new identity that the Foreign Legion assigns to them.

<comment><USER4> That's largely a thing of the past. You're more likely to be handed over to Interpol than anything else today.

Also, HN-ers beware -- the FFL doesn't take people without military experience, anymore.

<comment><USER5> That doesn't seem to be true: [https://www.legion- recrute.com/mdl/pages.php?id=2&titre=Les-...](https://www.legion- recrute.com/mdl/pages.php?id=2&titre=Les-conditions-d-engagement)

<comment><USER4> In practice, it _is_ true. They have a long line of candidates, and will prefer those with experience.

Source: am a reserve infantryman at 94th RI, 3rd Company. Regularly train with 2ème REP.

</comment></comment></comment></comment></comment><comment><USER6> That was a great read.

Certainly removes any romantic notions about the Legion and its place in French society.

<comment><USER7> Funnily enough, the Legion étrangère is not a romantic thing at all in France. I have in fact always found it odd that it was even a topic, mostly for Americans to be honest.

<comment><USER6> I think that owes a lot to Hollywood depictions, as the article mentions.</comment></comment></comment>


Bo Burnham, from Having Panic Attacks Onstage to Making Eighth Grade - <AUTHOR> http://www.vulture.com/2018/07/how-kanye-helped-bo-burnham-go-from-stand-up-to-eighth-grade.html <comment><AUTHOR> The discussion of the movie Eighth Grade has some interesting reflections on how modern kids interact with technology. At least as relevant, though, is hearing how Burnham is trying to break through his early success and continue to find meaning in his work.</comment>


Ask HN: Co-founders can't be convinced that we need investment - <AUTHOR> Our start-up has changed direction three times, but after more than 24 months we still do not have a saleable product or even a working prototype. Despite this situation, I can't convince my co-founders that we need external investment to shorten the time to market. Instead, they are only interested in government programs with lengthy application procedures or simply in making do with subpar equipment and tools, which also means that we constantly fail to meet deadlines. Besides, we are working without a salary, which I do not think is acceptable anymore, how should I proceed? <comment><USER2> Get something out, you aren't going to find it easy to raise money without proof you can deliver something people want. If you haven't been able to do that in 2 years, why would anyone give you money?</comment>


A Brief Guide to CLOS (1998) - <AUTHOR> http://www.aiai.ed.ac.uk/~jeff/clos-guide.html# <comment><USER2> This is a not a good guide. Avoid Graham too.

PCL is much better. Keene too. Seek out Joe Marshall's Warp Speed intro too.

<comment><USER3> For anyone not able to quickly locate the above mentioned items:-

PCL: (Practical Common Lisp): [http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/) (chapters 16 & 17)

Keene: (Object-Oriented Programming in COMMON LISP: A Programmer's Guide to CLOS): [http://www.amazon.com/Object-Oriented-Programming-COMMON- LIS...](http://www.amazon.com/Object-Oriented-Programming-COMMON-LISP- Programmers/dp/0201175894/)

Warp Speed intro: [http://xach.com/lisp/jrm-clos- guide.html](http://xach.com/lisp/jrm-clos-guide.html)

</comment></comment><comment><USER4> I just finished reading Sonya Keene's _Object-Oriented Programming in Common Lisp_ cover-to-cover. There is a _lot_ of stuff in there that just can't be covered by a brief guide for sure, a lot of pretty useful stuff, knowledge of which would quite possibly cause one to structure one's program in a substantially different way, if one knew about it. I highly recommend reading it if you intend to use CLOS for anything serious, and poring over the extended case study implementing streams is useful too, tedious though it might be. There are, however, some things that got changed between the printing of the book and the finalization of CLOS as we see in CL today. We write a _describe-object_ method instead of a _describe_ method, for example, and there is no longer a _with-added-methods_ special form.

<comment><USER5> Seconded. This is one of the best books on object oriented programming in general.</comment></comment>


Build Windows apps from your Objective-C code - <AUTHOR> https://dev.windows.com/en-US/uwp-bridges/project-islandwood <comment><USER2> Compiling Objective-C on Windows is not such a big deal. The huge thing here is that Microsoft has apparently reimplemented the Apple frameworks, because that's the only way they could port over existing iOS code.

I'm extremely curious to find out how much of UIKit is available on Windows Phone. It might be something disappointing like "well, if you stick to old pre-iOS7 methods and don't use new frameworks or AVFoundation or anything, most of your code will compile"... If they're really tracking the latest iOS on this, it's an amazing feat.

It's worth noting that Microsoft also has a companion product for Android, the "Universal Windows Platform Bridge for the Android Runtime" a.k.a. Project Astoria:

[https://dev.windows.com/en-us/uwp-bridges/project- astoria](https://dev.windows.com/en-us/uwp-bridges/project-astoria)

The difference seems to be that the iOS porting toolkit is an SDK, while the Android version is a complete runtime. So you can take an existing Android app (.apk file) and run it directly on Windows Phone, whereas the iOS app will need to be recompiled in Visual Studio.

I find the Android bridge to be the really exciting news. Now every phone vendor except Apple supports Android apps! I wrote a blog post about it a few days ago when it was announced: [http://blog.neonto.com/2015/04/29/android-is- the-new-win32-t...](http://blog.neonto.com/2015/04/29/android-is-the-new- win32-the-new-java-and-the-new-flash/)

<comment><USER3> While technically impressive, I wonder how much economical sense does it make for an iOS developer to go this route. For a small install base you open up a support front and now your code needs to work against the UIKit implementation of Windows Phone that by all likelihood will have its own bugs and limitations. You also might have planned to use Swift on iOS and this isn't possible when you want to compile your code for Windows Phone.

Edit: I meant to talk about Swift, not Swipe.

<comment><USER4> Is there any likely technical reason Microsoft won't be able to do the same with Swift in the future? As I understand (not an Apple developer) doesn't it use the same frameworks, so they can reuse that? Its syntax also looks way more similar to c# than obj c does from a quick look.

<comment><USER5> The technical reason is probably that Obj-C has multiple stable implementations (which agree almost entirely), the GNU or Clang frontends, which makes it easy to write your own implementation because you can study what those two do (in the worst case; the Obj-C part they could just do by compiling either of those two compilers).

With Swift, the compiler is closed source, so you either have to examine the code it produces or the programmers manual, which is legitimately more difficult technically.

Then there's the fact that the lawyers will have to be all over any Swift implementation, and it gets even harder.

None of this would have happened if Clang didn't exist :P The whole reason that Microsoft can do this project now is because Clang didn't exist when Apple/NeXT started development on Obj-C.

<comment><USER6> > None of this would have happened if Clang didn't exist :P The whole reason > that Microsoft can do this project now is because Clang didn't exist when > Apple/NeXT started development on Obj-C.

This paragraph is a few kinds of incorrect. I built objc code on Linux with GCC before clang existed. (gobjc is the name of the package.) Clang therefore was not the only free software objc frontend at the time of introduction. GNUstep even ran on Windows using that. There is no reason Microsoft could not have also based its efforts on GCC's objc frontend, without clang.

I believe also NeXT used GCC back in the day - I read somewhere that even then they were displeased with the fact that GPL forced them to contribute back. Also objc existed before NeXT, the were just the only notable player using it and de facto took it over.

<comment><USER5> That's my entire point; if Clang did not exist then Apple would have had to contribute the Swift frontend back with the GPL or write an entire compiler backend, as they did for Obj-C.

Now, Clang is competitive and they can keep the frontend under wraps.

Had Clang existed when Apple were implementing Obj-C, they'd have used that, there'd be no open source Obj-C frontend Microsoft wouldn't be able to do this without considerably more work.

<comment><USER6> > Had Clang existed when Apple were implementing Obj-C, they'd have used that, > there'd be no open source Obj-C frontend Microsoft wouldn't be able to do > this without considerably more work.

Ah, OK... So you mean if NeXT hadn't based their 1980s effort on GCC, i.e. if there had been a decent BSD-licensed C compiler back then.

It's worth mentioning that this was a long time ago, before a fair number of HN readers were born, and also at a time when GPL vs. BSD licensing likely wasn't as much of a topic as today. Comparing GCC with Clang when we're talking about things that happened in 1988[1] just doesn't seem to make any sense to me.

[1] Per Wikipedia's article on Objective-C, the year that NeXT's GCC changes happened.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> When I shared a link to this article in Facebook, Facebook recommended this "related link":

[http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

<comment><USER8> Is this not something that Google is truing to do with Android ?

<comment><USER7> I've never thought about it. My answer is no.

</comment></comment></comment><comment><USER9> While technically interesting (assuming they ported iOS frameworks), it's no more than a hack, UI-wise. It prompts developers to consider the UI as an afterthought; just "trust" Microsoft's _adaptation_ of another platform layout, add "minimal changes" and presto: UI work is done.

It's a sad route to follow, if you truly care about your users.

<comment><USER10> Source? I didn't think they had released any example screenshots of "converted" apps yet.

<comment><USER9> I don't think you need a source to know that either a) they do some automatic "adaptation" of the layout elements; or b) they render it as iOS does. Neither of these scenarios is optimal, nor prone to great UI work.

Anyway, my point concerns more the concept/approach than the exact implementation. "Converting" is proposed as an easy path to have your product on other platform, as opposed to doing all the due work to address differences and specificities.

</comment></comment></comment><comment><USER11> OS compatibility layers never work well. I expect this to fail within a couple of years max. It'll be used to convince people to do a quick one-time port of their iOS apps over. Microsoft won't be able to keep it with Apple's API changes so it will always be behind and crappy.

<comment><USER12> They don't have a good reputation, do they. But, it depends on how much engineering resource Microsoft dedicate (and of course, how quickly Apple evolve their APIs/applications make use of them).

</comment></comment><comment><USER13> Microsoft has been on a tear lately! I am really impressed with the direction they are going.

<comment><USER11> They've taken proven over and over again for the past 30 years that they never follow through on anything that involves cross platform compatibility so I'd take it with a healthy dose of skepticism. It just fundamentally isn't in their culture and they have a lot of old-timers there.

</comment></comment><comment><USER12> Squinting at the debugger screenshots, instance variables that are private in the 2.0 runtime are visible (e.g. instance_size). I wonder if they used the Apple runtime...

</comment><comment><USER14> Haven't we seen this before? It was called J++ and was part of the embrace, extend, extinguish campaign.

I'm shocked at some of the comments, which seem identical to the sentiment 20 years ago. This isn't a different Microsoft, if anything, this is a return to their old playbook.

<comment><USER15> The difference is that J++ was an attempt to prevent other people from simulating a "better" computer/platform on top Of Windows.

This new thing is Microsft trying to simulate a "better" computer/platform on top of iOS and Android. In this case, "better" means that it also includes Windows.

<comment><USER14> The new thing is exactly what J++ was about. Support some set of Java features, extend it with incompatable, "better" features, and finally, ensure that those features were non-portable. We're seeing the first two now, the third follows when strategically beneficial - maybe that will never happen because they've lost too much momentum.

Microsoft loves to show how they are a team player, but consistently breaks those relationships at the moment that is most beneficial to them.

What's most amazing to me is that people have been falling for it for 30 years.

</comment></comment></comment><comment><USER16> In any flourishing ecosystem, parasites eventually emerge.

This is so crass of Microsoft. I would be ashamed to work in the group that did this.

Technically? Sure, it's an accomplishment, akin to copying someone else's homework by typing it in by hand. Please notice I didn't say it's the same, I said it's akin to. Very nicely typed, good job.

But morally, it's exploitative and gutless, and it represents Microsoft giving up on the idea of finding success through innovation. Microsoft seems so pathetic now.

<comment><USER17> Would you say the same for WINE or ReactOS? Or Pages, OpenOffice and Google Docs 'copying' the docx format? Samba and SMB?

It's more about compatibility with an existing ecosystem than copying.

<comment><USER16> I'd say take those on a case by case basis. When Microsoft was an abusive monopoly and there were few choices out there (hardly the case for Apple today, which has vigorous competitors who offer plenty of working alternatives), some of these made sense, although superior products made from the ground up would have been better.

>It's more about compatibility with an existing ecosystem than copying.

Wink, wink. Right.</comment></comment></comment>


Videos may make up 84 percent of Internet traffic by 2018 - <AUTHOR> http://www.reuters.com/article/2014/06/10/us-internet-consumers-cisco-systems-idUSKBN0EL15E20140610

<comment><USER2> >Not all Internet traffic will be the same, according to the report. Internet connected medical devices, for example, would have a different data profile than video streaming, but a higher speed urgency.

That's some none too subtle bias there.

Also completely misunderstanding the issue, video files would be given special treatment over medical data if the telecoms get their way and netflix coughs up the money.</comment>


A letter to our Glass Explorers, from the head of Glass - <AUTHOR> https://plus.google.com/+GoogleGlass/posts/gUYZEZGsQ6H

<comment><AUTHOR> Interesting that she chose _not_ to wear the product for her intro message!</comment>


97 Year Old in a Tesla - <AUTHOR> https://www.youtube.com/watch?v=t6Nw6xp0NfM <comment><USER2> To repeat my YouTube comment, the touch screen screams to me as the wrong idea for driving during its demonstration.

To turn on the seat warmers you "just" click the top level button, mid level button, identify the seat you want to heat, and observe it turning red as you click it. How do you teach that to a 97 year old? Isn't a tactile static picture next to your seat of a seat on fire much easier to teach?

<comment><USER3> Are you implying that a 97 year old can't learn anymore? My 95 year old grandmother learned to use a Windows machine and an Android phone.

<comment><USER2> I have difficulty learning how to navigate a car's satellite radio touch screen. Things like understanding that Auto has AC on even though the AC light isn't on is hard to understand. Submenus and 6 pages of FM channels are also high in cognitive load. I'm 31, so frankly, no, age doesn't directly factor into it, but I've also been trying to teach students, coworkers, my parents, other adults, and grandparents how to use computer and their interfaces better for ~20 years.

There are a lot of tactile reasons that "stalks" work for lights and wipers, or that buttons press versus rotate. Or that things that do rotate click into place.</comment></comment></comment>


Di-ary – mathematical note-taking app built on Ruby on Rails, React and Redux - <AUTHOR> https://github.com/mkalygin/di-ary <comment><USER2> If it meets the guidelines, this might make a good "Show HN".

Show HN Guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Thanks for the hint! I'm new to HN, I try to bring some value to the community. I've made a new post to "Show HN".</comment></comment>


Anyone having problems accessing justin.tv? - <AUTHOR>

<comment><AUTHOR> I think they were upgrading the site.

<comment><USER2> Actually, we got slammed by approximately 150,000 13 year old girls at the same time. We hit the file descriptor limit on the load balancer - oops.

</comment></comment><comment><USER3> Anyone care?

 _I kid, I kid_ :-)</comment>


Ask HN: Where and how do I start with PHP/Ruby on Rails and JS for my project - <AUTHOR>

So I've got a few ideas for some sites that I want to build. The sites will, for the most part have user signups, data storage (material uploaded) and will need to have a rich UI.
I could probably accelerate the development by using Flex or Silverlight but I really don't want to depend on plugins for the idea I currently want to build on. It's something that has to be accessible to everyone so PHP is my current option. Especially since it has such a large community surrounding it.
About myself as a developer. I'm not a noob developer. I know programming concepts. But I am completely new to web programming. I do know web architecture and AJAX conceptually but I've never touched PHP or java script in my life.
Oh I am also not developing a web app here.
I just want a few pointers to some good resources out there that could have me applying knowledge to building this site on the go.
It is critical that I will need to know
a) site design b) AJAX c) Knowledge on implementing a site in a scalable way so that it doesn't become a monolithic block at any time. It has to support agile development d) Security. The site will include payment options so the last thing I'd want would be SQL injections into a non encrypted database and everyones personal info getting stolen. (Stop 'gawking').I need to know how to secure the site on ALL fronts e) FTP services for the site.
So yea. That was a little too much to form into a search query and I don't want to spend time right at the start looking for material that might suit my needs.
So I was hoping the HN community could help me out here by pointing me in the right direction to a bunch of tutorials that help me get into the real development ASAP.
thanks :)
edit 1- first comment I got was to look at Ruby on Rails. I've heard so much about this that I really wouldn't mind. Could people leave resources for both then? If you support Rails drop some resources for Rails here and if it's PHP well.. same thing <comment><USER2> I recommend drupal, it's the fastest launchpad for everything you want to do. It's got an impressive amount of pre-written code of various quality that are relatively easy to put together.

However if you're serious about becoming a real web developer who likes to get his hands really dirty, then I recommend avoiding PHP and going for Ruby on Rails.

<comment><AUTHOR> yeps. I enjoy having complete control over what I write. . I will look into it anyway. Ok. then... Ruby on Rails resources? Thanks! :)

edit - after looking at drupal i took off the line "Drupal might be ok for initial stages but it probably won't scale as well".

<comment><USER2> >Drupal might be ok for initial stages but it probably won't scale as well

What is that, hearsay? No, drupal scales fine. Look at the many large sites that use drupal, like the economist, whitehouse.gov and the examiner.

For RoR the standard tutorial is: <http://mislav.uniqpath.com/poignant-guide/>

<comment><USER3> The Poignant Guide is great for Ruby, which I highly recommend one has a decent understanding of before delving into Rails, but it is not very useful for Rails itself.

After understanding Ruby, <http://guides.rubyonrails.org/> is where you should go to figure out Rails.

<comment><USER2> Yeah, I just meant that's a great place to start when doing RoR, first make sure you have your Ruby covered and then moving on.</comment></comment></comment></comment></comment>


Historical view of browser usage - <AUTHOR> http://weblogs.mozillazine.org/asa/archives/2009/06/historical_view.html <comment><USER2> Well, it's obvious that the trends cannot continue to be linear indefinitely. But at the current rate, IE would drop below 50% market share in around 2 years.

</comment><comment><USER3> No Opera?</comment>


Finally! OSX Lion allows resize a window from any corner. Monumental. - <AUTHOR>

In OSX Lion, you can now Resize from any edge You can now resize a window from any side or corner.<p>Scroll to the bottom: http://www.apple.com/macosx/whats-new/features.html <comment><AUTHOR> This is historic, the most basic of window resize functionality has finally been added to MACs, after decades. Now the MAC is really a modern OS :)

<comment><USER2> W/o scrollbars?

<comment><AUTHOR> With or without scrollbars

</comment></comment></comment><comment><USER3> Also, try resizing with the option key down :-)</comment>


Microbial production of short-chain alkanes - <AUTHOR> http://www.nature.com/nature/journal/v502/n7472/full/nature12536.html

<comment><AUTHOR> The relevant part of the paper is:

"...in which the normal production of fatty acids (lipids) from glucose in E. coli is directed to converting the fats into alkanes. These new E. coli are "physical functions" (or "physical machines") that take normal inputs of glucose and produce outputs of alkanes."</comment>