jtdowney

It was posted after your comment, but https://news.ycombinator.com/item?id=40938025 indicates that a human was in the loop.

- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.

I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption.

- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.

That is irrelevant to this project. You should read the rust kernel docs to see why.

- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.

Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux.

- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.

Linus is famous for doing fashionable things and forgoing technical decision making.

Looks like it has been available since September 2017: https://github.com/braintree/braintree-web/commit/b79008a51c...

PayPal was very early in the 2FA movement, hardware security keys were available starting in ~2008 (https://systembash.com/using-the-paypal-verisign-security-ke...). If you're referring to app based TOTP that is a relatively new option.

I was prompted to change to TOTP when I logged in.

Isn't it more like https://www.freebsd.org/cgi/man.cgi?if_bridge(4) ?

Dan went into a little more of the backstory last year during the first awarding of the Levchin prizes. If I recall correctly, he and Max had been long time acquaintances and Dan even advised Max while he was working on some of the early PayPal technology. Max told a story about Dan leaving his own birthday party to help Max debug a CSPRNG.

I've spent time with lawyers on specifically this topic. It is about who is distributing the crypto code. There is also an exemption for open source crypto code. On iOS you definitely do not need to register your app if it is just using the built in HTTPS functionality. Hire your own lawyers if you're really worried about it though.

I'm the Security Lead at Braintree. I am not sure what you're hearing in these circles. If someone could send details to security@braintreepayments.com we'd be happy to take a look.

Both Stripe and Braintree require you to use SSL (really TLS) on your checkout pages. They also both require you maintain PCI compliance (although you likely qualify for a reduce set of requirements).

To be fair, Cloudflare has no concept of how much reputation you have on HN.

I agree! I submitted it as separate item because this conversation was about rewriting iframes. Although hosted fields doesn't directly address the rewriting for now, we're looking at it closely.

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for merchants to use technologies like Content Security Policy and leverage as much of the browser security model as possible.

Visa is slow at updating their site. MasterCard is much faster, you can find their list at http://www.mastercard.com/us/company/en/docs/SP_Post_List.pd....

It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.

Ruby already has the ability to spin up a quick webserver for the current directory. This is supported through the un file in Ruby's stdlib: http://ruby-doc.org/stdlib-2.0.0/libdoc/un/rdoc/Object.html.

    ruby -run -e httpd -- --port=8080 .

It wouldn't even need to be a poorly written component. There is a good chance they would log the card number along side the transaction in their database.

The site currently negotiates for DHE-RSA-AES256-SHA, which is forward secure.

They specifically allow accounts to be created for whitehat purposes at https://www.facebook.com/whitehat/accounts/

Debian Wheezy (current stable) ships with Ruby 1.9.3-p194 + various patches [1].

[1] http://packages.debian.org/wheezy/ruby1.9.1

It actually depends on the merchant category code (MCC) of your merchant account when it is setup. Only certain category codes, such as hotels and gas stations, are allowed to capture for more than they authorize.

The purpose of client-side encryption in Braintree.js is to reduce the PCI scope for the merchant and is not the only way the data is protected. Every encrypted value is still sent over HTTPS to to the merchant's server and again over HTTPS to Braintree itself. In this chain, however, the merchant will be unable to decrypt the values submitted and can only pass them on to Braintree.

(Disclosure, I work for Braintree)

Apple's guidelines only cover purchasing digital content. You may use outside payment methods to purchase physical goods or services used outside of your application. For example this is how Uber, Hailo, Airbnb, Hotel Tonight, and Task Rabbit all manage to take payments in their current iOS applications.

(Disclosure, I work for Braintree)

The cert chain is valid for me

To be fair, they had to upgrade to a development release (1.5) of HAProxy to configure it in this way. When we introduced the broxy at Braintree that feature did not exist.

(Disclosure - I work at Braintree)

One thing the article mentions that is not correct is that "there's no need to be PCI Compliant as Stripe handles this whole process for you." While it is true that Stripe bundles the merchant account, you do still need to be PCI compliant. They even say as much in their Terms of Service (section 8): "You agree that at all times you shall be compliant with the Payment Card Industry Data Security Standards (PCI-DSS) and the Payment Application Data Security Standards (PA-DSS), as applicable."

It is very dangerous to think that just because you use a service you are not responsible for PCI compliance. Any business that accepts credit card payments needs to be sure and research what their exact relationship is with PCI.

(Disclosure, I work for Braintree)

John from Braintree here. In the case of our client-side encryption library we use sjcl (http://crypto.stanford.edu/sjcl/) to generate the symmetric keys for encryption. This library uses Ferguson and Schneier's Fortuna PRNG to generate random values. The main entropy source is crypto.getRandomValues (https://developer.mozilla.org/en-US/docs/DOM/window.crypto.g...) where it is available. In other places it uses mouse movements to provide entropy for the PRNG.

The W3C has a crypto API draft at: http://www.w3.org/TR/WebCryptoAPI/

NoMethodError: undefined method `new' for Foo:Module

You can't initialize modules, I think you meant to make Foo a class.

They seem to be over their limit with Github, pasted below as a mirror:

You probably noticed Charm had some nasty downtime a couple weeks ago.

Service quality is very important to us. If we didn't think we could do better, we wouldn't do it at all.

We've spent very generously on sysadmin services and infrastructure (nearly $100k of investment on sysadmin services/infrastructure alone). We hired the best possible, and we splurged on a redundant, powerful, and expensive server configuration from the beginning.

Now we've discovered that there's some kind of base incompatibility with Ubuntu, which is giving us kernel panics which nobody can track down. Charm has been plagued by mystery technical problems from the beginning, when we had to backport from Rails 3.x to 2.x because of massive performance slowdowns which even Rails Core members couldn't identify.

What this has really shown us is that, if we open Charm to the general public, we won't be able to provide you with the kind of service you deserve. We are a tiny team, and so far, we've had zero luck in our attempts to grow by hiring developers. Problems which are small now will only get bigger.

There are a lot of things I'm willing to take risks with, but not with your ability to provide support to customers for your business.

And so it is with a very heavy heart that we will cease operating Charm from Dec 15, for the foreseeable future.

You won't be billed again, and we'll refund your last payments.

We will gladly help you migrate your data out of Charm. Please contact us directly (support@charmhq.com) for help.

Thank you so much for taking a chance on us, and sharing our dream for a superior email interface.

I'm truly sorry to disappoint you.

Best wishes,

Amy

"Java and PHP have been around long before Ruby."

It seems like they are confusing Ruby and Rails in the first point. PHP, Java, and Ruby were all first publicly released in 1995.

From their respective Wikipedia articles:

"Lerdorf released PHP/FI as "Personal Home Page Tools (PHP Tools) version 1.0" publicly on June 8, 1995"

"Sun Microsystems released the first public implementation as Java 1.0 in 1995."

"The first public release of Ruby 0.95 was announced on Japanese domestic newsgroups on December 21, 1995."