I don't believe they had much say in the change. They are still using the money to do what they said they'd do in their campaign, and many people are setting up their registry as their default. As far as I know they just got caught in a situation that was less than ideal (while also getting rid of some financial burden). I think they deserve an applause for running it at high cost to their business for free for years rather than be villainized because they got caught in a situation that they weren't in control of. If you donated, or are worried about what Npm, Inc. is doing (hint: so silly to feel this way) you should set your default registry to theirs (it's already set as your failover, btw).
The cynicism in this thread is so bizarre to me. No one is being evil. There's no secret foul play. Everyone go write modules and share them and be happy.
This is a common confusion. The scalenpm crowdfunding was done by the good folks who ran the npm servers for free (mostly nodejitsu) up until the recent switchover to the new infrastructure with Npm, Inc.
You can still use the nodejitsu registry for free if you'd like[1]. They arent likely to need as much scaling anymore, but there's still a big cost to running those servers. I don't think there was any foul play when it comes to the scalenpm money as I'm fairly sure they were not aware of the intent for Npm, Inc to take over default hosting.
tl;dr the money did not go to the same people, and the people who crowd funded thought they'd still be hosting npm going forward at the time.
I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):
> [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant
When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."
Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.
Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.
In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.
PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)
Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.
We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.
If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at [email protected] or to email me personally at [email protected].
(Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.
Agreed, this is what I did say several times in the article, as well as calling much of it non-scientific. Though I did cite 2 scientific studies, and some non-trivial biology, I meant the article as a personal experience piece more so than a case-study for what everyone should do.
Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad).
This varies from project to project based on needs. The checkout stuff uses sprockets-commonjs, browserify and require.js are used in other projects though. The decision is often made based on the backend (is it already ruby/sprockets?), and the needs of the project (would rebuilding the full file on each change be prohibitive). For the most part though, the build system remains transparent to all but one person (me, these days).
We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.
However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.
Hope that helps give some insight into our process and reasoning.
bentlegen _is_ an expert in third party javascript, and is correct that both domains need to opt in to a `document.domain` even if they would match with only one changing. This is to prevent this exact security exploit.
I don't believe that this is just an oversight because "people say you shouldn't use `with`". It simply cannot be optimized in the way that normal property accessors are. If you look at old IE perf, they're actually pretty close (both really slow).
Doesn't `with` have significant runtime costs? I didn't think people didn't like that one because it was a 'bad pattern' - I thought it was because it was really slow.
EDIT: I went ahead and JSPerf'd it, and it is 13x slower to run the example in the article.
A lot of times this doesn't matter, but it's not nothing.
Edit 2: Also people avoid using `with` so their minification tools have a better chance. Another thing that can be overcome, but just pointing out that it's not religious dogma that makes people avoid `with`.
Fair enough, I'm not claiming that other, much more difficult work didn't go into the feature updates. What was the reasoning for switching to semicolon-less? Why wasn't that a concern when the project started? (Apologies if I missed it in the notes.) I have no problem with projects doing one or the other, the _switch_ just doesn't fit into my brain correctly. Perhaps your tastes just changed?