Stripe Billing - <AUTHOR> https://stripe.com/blog/billing <comment><USER2> Stripe cofounder here.

For anyone wondering about pricing, here's our approach.

\- For new Stripe customers, this is free up to the first (lifetime) $1M of payments.

\- For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price.

\- What we've seen over Stripe's history is that customers handling _large_ amounts of revenue have been forced to pay substantial amounts for expensive third-party systems. So, we've decided to build something that we think will be better and cheaper -- and that will, over time, _increase_ the net revenue of businesses built on Stripe.

I'm sorry about any confusion in our communication around this!

<comment><USER3> Any information on support for Europe? And if support for Europe were to be in the pipeline, would it be for the whole of Europe or only specific countries? We'd love to use Stripe for billing as well, but because Stripe is an American company, we feel like as Europeans we're constantly an afterthought and would therefore prefer a European provider. What's your opinion on this?

Btw, I was at the Stripe offices 2 years ago and it was an amazing experience. I really like what Stripe has done over the years. Keep it going and thanks!

<comment><USER4> The core Stripe Billing features actually work in the EU: flexible billing, our recovery tools, and invoicing. You can use subscriptions with all of the payment methods on Stripe, including SEPA DD, ideal, and more. But as Patrick mentioned, there's a lot we can do to make the experience great for European companies and that's what we're focusing on right now. We're thinking about ways to localize the invoices, add EU specific payment methods to invoices, improve tax support, make default invoice templates EU compliant with VAT ID, and more. If you'd like to try early betas, let me know!

<comment><USER5> We're about to re-evaluate our billing system for StyleCI and as we're based in the EU, we'd love to give this a go. My email is james [at] alt-three.com

</comment></comment></comment></comment><comment><USER6> I see a new 0.4% to 0.7% fee, that is enough to make me start shopping competitors on Monday. The stripe processing fee is already high. It seems that all I get is some hosted invoice stuff.. which I could build in a weekend and not have to pay a fee on?

Thinking about it, a medium sized SaaS company billing 15 million a year. 14,000,000 *.004 = 56k a year? For the same product they already had?

Obviously it is cool if you want metering and the advanced features, but I wonder if there is a way to opt out and use the old simple stripe without the new fee - or if this is to push those users into braintree / etc?

<comment><USER7> "build in a weekend"

<comment><USER8> I'm working in my spare time on a series of articles about the curious psychology of the software development world. This one is near the top of my list!

<comment><USER9> Got an email signup for that?

</comment></comment></comment></comment><comment><USER10> CEO of Cheddar here.

I think this is a big step in the right direction for Stripe (unclear pricing aside). We've been thinking about usage based billing for a long time now. We built a bunch of apps using Stripe and found there was a lot missing if you wanted to track activity and bill for it, as well as with reporting and revenue optimization. Having not dug into the platform too far, this definitely looks like it could fill some gaps.

I will say I'm not a fan of taking a percentage for billing on top of taking a percentage on payments, though. There is risk involved for payments (chargebacks, fraud, etc), but billing is transactional. A percent there feels like a money grab to me.

The only other problem I see with this is that it all seems a bit convoluted. I get that it has to be tacked on to their existing platform. But we've found that the secret to an awesome usage based billing system was to track activity in real time, then apply automated billing to that tracked activity. It's a different approach and we're working on polishing that up and bringing it to market over the next few months.

Would love to hear more about how folks are thinking about consumption and usage based billing and pricing. I think it's the next big wave in Internet monetization, so it's important to get right.

<comment><USER4> Appreciate the kind words! To the point on pricing: believe in revenue-based business models because it's the clearest way to align our incentives with those of our customers. We want to be forced to find ways to generate more revenue, via smart recovery, better invoice payment methods, more payment method support, etc. Our fees are actually significantly less expensive than those of our competitors, and we only make money when our users make money here (instead of charging a flat fee, which can penalize companies that are bootstrapping.)

Excited to check out Cheddar when it launches!

</comment></comment><comment><USER11> Billing (recurring or one time) is a transactional activity and should be monetized as such. There should be a per invoice or per customer type of rate. This whole % of revenue seems crazy to me. There is no inherent risk involved like payment processing. You can get paid no matter what in a tx model...

Based on what I see in the market with other billing/subscription providers, they all do the same thing (rev share). Since these businesses are not the payment gateway they try to do a revenue grab with the % share.

I hoped Stripe would be able to disrupt this by already being positioned as a payment gateway and offer this on top in a transactional model....

Hope they rethink this strategy. And no first $1MM isnt going to cut it. Any serious business will see this as a growth challenge. Backend billing flows are challenging to build and once you are committed to this you are locked in for quite sometime from the roadmap perspective.

<comment><USER4> Thanks for the feedback. To your risk point -- there _is_ often risk involved, as businesses that have worked with large ACH payments know.

More broadly, we believe in revenue-based business models because it's the clearest way to align our incentives with those of our customers. We want to be forced to find ways to generate more revenue, via smart recovery, better invoice payment methods, more payment method support, etc.

<comment><USER11> Maybe you can provide clarity on ACH risk. Seems like businesses have most of the risk there.. and not the billing system (keeping the gateway out of this).

Secondly, transaction/user based models are also aligned with customer incentives. With growth, customers will execute more transactions on the system.

Frankly, Smart recovery is an area where I can see you can ask for % share. Other features like payment methods etc sound transactional again.

Finally, Stripe has a payment gateway business already. This will ensure growth on that side of the business. Optically this seems like a revenue grab. You have the opportunity to disrupt the ecosystem.

Thanks for responding to my comment. Appreciate the interaction.

<comment><USER12> Lowering revenues doesn't really align with IPO'ing, though. The issue is the VC model that will keep us trapped in this, until there are less greedy given the resources to disrupt these systems. Capitalism works well, it shouldn't necessarily have a stake in foundational systems - which is why we need governance to manage.

</comment></comment></comment></comment><comment><USER13> Yikes, I've been using Stripe subscriptions happily for a few years and now I'm upset to see they're going to be charging a fee. It's unclear if the fee starts at $1MM total revenue or $1MM/year. $1MM/total would hurt a lot of the small lifestyle businesses for no gain in service--we already had subscriptions built in to the cost and we don't need invoicing or any of the other new-fangled stuff :(

Paypal has free recurring billing. Sure it's a pain to set up but once you've built it in it works pretty damn well with little to no maintenance. If you do even a smallish amount of business through them you can set up daily sweeps into your bank account to stave off the famous Paypal "random freezing of funds" nonsense.

<comment><USER14> Did they email the announcement to you? If you already used Stripe subscriptions in the past, you'll be grandfathered in for free. This is the relevant line:

"Since you used Stripe Subscriptions in the past year, the Stripe Billing Starter plan is included in your current pricing."

<comment><USER13> Yeah, but the Starter Plan starts charging an additional fee after $1MM (yearly? total?) revenue. So it's not grandfathering in at all, we just get shunted to the temporarily-free plan that everyone else has to start on.

Edit: Since my posting this Stripe has clarified that existing customers get the Starter package at no further cost, we we _are_ grandfathered in.

<comment><USER4> (PM from Stripe) If you're an existing user of Stripe Subscriptions, you get Stripe Billing features included in your current price. (To be clear, there's no extra fees for existing users.)

<comment><USER15> No extra fees for the first million, or no extra fees period?

<comment><USER2> Period!

<comment><USER16> Dude.. you need to communicate this better to existing customers and preferably not on HN.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This thread highlights the following lesson:

When communicating important and potentially difficult to understand information: have some non-insiders read the text and ask them what they think it means.

</comment><comment><USER17> _Free for the first $1 million of recurring charges.

After that, 0.4% on recurring charges_

Does this mean recurring charges don't carry Stripe's standard 2.9% + $0.30 charge? Or is the free at first/then 0.4% _on top of_ the 2.9% + $0.30 charge?

<comment><USER18> That's better than Recurly. They take 1% plus $99/month or $299/month if you want accounting software integration. And there's no free tier.

I'm game.

<comment><USER6> Stripe already did recurring billing without a 1% though

<comment><USER18> Yeah, but now Stripe is adding in features like email invoices, presumably the ability to for customers to update payment info, etc. I don't know how much exactly has been added incrementally and how much is available in this release, but I'm optimistic that soon I will be able to phase Recurly out of our stack...If someone from Stripe wants to build a Recurly -> Stripe migration toolset, I'd love that!

<comment><USER19> As we speak, we are writing code to move from stripe to recurly/adyen.

The analytics/easy plan mgmt and email invoicing in recurly is something stripe doesn't have.

Would you advise against that ?

<comment><USER18> No, I would not advise against that. There is a reason I pay the (annoying) 1% + $99/$299 fee to Recurly.

I was hoping that this signaled that Stripe was beginning to integrate that valuable featureset into the Stripe platform.

</comment></comment></comment></comment></comment></comment><comment><USER20> Looks buggy to me. I created a test invoice and specified that it should be payable at a later date and only via ACH.

I checked the preview link and the only option to pay was by credit card. I sent the invoice anyway and the test user's credit card was immediately charged.

<comment><USER21> (Engineering Manager at Stripe Billing) Ah - sorry about that, a last minute fix caused a bug. This is now fixed in production. Thank you so much for reporting!

<comment><USER20> Thanks for the update. Am I understanding the ACH payment flow correctly:

1) Send a user an invoice

2) The user copies the auto-generated bank details and manually initiates a transfer from their bank?

<comment><USER21> That's correct - if you want to learn more specifics, we wrote a guide which is available at [https://stripe.com/docs/billing/invoices/reconciliation](https://stripe.com/docs/billing/invoices/reconciliation)

<comment><USER20> Thank you for the link.

</comment></comment></comment></comment></comment><comment><USER22> How is this any different than the subscriptions they previously offered? And what do services like Recurly do that Stripe subscriptions don't? And when is Stripe going to automatically handle sales tax?

<comment><USER22> I still have not found a single subscription solution that seamlessly handles adding sales tax and properly reporting it. Stripe does not. Recurly does not. TaxJar does not work with subscriptions. Avalara does not work with subscriptions...

What are people doing?

<comment><USER23> _What are people doing?_

With my UK small business hat on: Sometimes, it is just easier and cheaper to build it yourself than to rely on an outsourced service that doesn't do exactly what you need.

We have a database table of VAT rates per country with starting dates when they come into effect. All customer accounts are tied to a specific country, so all payments or subscriptions for an account can look up the current rate from the database and apply tax as necessary.

All successful payments (one-off or recurring) are recorded in our DB, triggered by webhooks from the various payment services we use. The DB records include all the tax information that applied at the time of the payment, including things like country and proof-of-location as required under EU VAT rules, and also including generating a sequential ID for each payment to comply with the rules there. This is also the point at which we do any necessary currency conversion calculations, and we then generate and send customers an email automatically with all the same details.

A little scripting looks up the necessary sales and tax figures from the database for the various VAT returns we are required to file for UK and for other EU customers.

The significant limitations are mostly around keeping that VAT rates table up- to-date (I know of no acceptable automated method for doing this, so we just have to review the information manually at frequent intervals) and around handling money repaid (refunds, or if we do ever get a chargeback or similar). As far as I'm aware, none of the automated services is even close to getting these things right either, so we're still no worse off having to do a few things by hand in these relatively rare situations.

Setting that lot up was a decent chunk of work, particularly all the hassle around EU VAT, which we had to retrofit in at least one case I can recall. However, it's certainly achievable for an average developer within a few days.

<comment><USER24> Smells like a service someone should make and sell. VAAS - VAT-as-a-service

<comment><USER23> That's what businesses like Avalara are trying to do, but the EU VAT rules are such a mess that even the specialist businesses trying to do it still haven't nailed it several years later.

</comment></comment></comment></comment></comment><comment><USER25> I think most difficult problem is still proper accounting. I'm with a client right now, based in Europe and we had >really good time< integrating Recurly with Stripe and use it as their payment provider, but we got stuck when we figured out that there was a need to hire an accountant to handle the cancelations for us.

Having a service like Cleverbridge [1] / Avangate [2], where they end-up having someone to manage this for them for a bigger % of the sale, was the better deal.

Not sure how the startup-scene will solve this, but it's actually still really hard to do this properly.

My best solution would be to have Stripe doing whole-sale solution, where they invoice customers and you simply invoice them each month.

It just takes too much efforts to do this >legally< in Europe if you are on your own.

1 : [https://www.cleverbridge.com/corporate/](https://www.cleverbridge.com/corporate/)

2 : [http://www.avangate.com](http://www.avangate.com)

<comment><USER4> (Stripe PM here) We're actually working on exactly this problem right now. :) More to come in the next couple months, if you're interested in beta testing let me know! (firstname.lastname@example.com)

</comment></comment><comment><USER26> >We're also introducing a new feature: smart retry logic. It's powered by the same machine learning infrastructure behind Stripe Radar. Our algorithms train on data across the billions of payments in the Stripe network to predict the right way to retry failed payments.

As someone who is completely oblivious to how payments work behind the scenes (for the most part) could someone please explain how this became necessary?

<comment><USER27> I used to work on billing and a bit of payments stuff for a large SaaS company, so I have some experience with this.

When you charge a credit or debit card, send a bunch of messages that end up going to an organization called a payment processor. Payment processors do stuff like make sure your account has enough money/remaining credit and also have fraud checks and other security features. Sometimes, the payment processor rejects a payment because of insufficient funds, suspected fraud, their system being down or a malformed request. Unfortunately, a lot of this stuff is pretty archaic and there are a few layers between your servers and the processor, so it's very hard to debug. On your end, you could simply retry payments if they get rejected, but that might lead to a set of ping pong failures that might even trip fraud alerts to the customer. You can also have retry logic that uses an exponential backoff, just like any other request. That's a reasonable strategy, but you can probably do better.If you're a big company, involuntary credit card churn is actually a pretty sizeable source of churn for you. 99% transaction completion rate sounds pretty good until you realize it means a guaranteed 1% churn rate (assuming people don't sign up again), which is not insignificant. You really want to get this as low as possible.

Enter Stripe: Stripe has handled a very very large number of payments, and they probably have really comprehensive data about failure rates. This allows them to identify patterns and come up with some rules around retries. A simple (fully hypothetical) example is: If a transaction is declined for insufficient funds, retry again on the 15th and the last day of the month (usually when people get paid). These rules can get really complicated. We had some rules that were as complex as "If the cardholder is in Spain, and the card is Amex, retry in three days before 5pm if it's a weekday, otherwise wait until Tuesday."

Overall, this is a pretty nice feature for large customers with high transaction volumes. We did the data analysis/rule generation ourselves and hand rolled the retry logic in our system, but offering it as a built-in service is a convenient (albiet probably expensive) perk.

<comment><USER28> Woah, TIL. Thanks for the comprehensive response, tschwimmer.

</comment></comment></comment><comment><USER29> People are focusing a lot on invoicing but the real power here is that you can create multi-part and tiered billing schemes now. Imagine something like "$100 a month and $10 per user" \-- that was not possible using Stripe subscriptions without your customer getting two invoices. Honestly, it was laughably bad.

<comment><USER30> It was possible, using one off charges with a webhook.

</comment></comment><comment><USER31> If anyone from Stripe is here, question: We currently use Chargebee for all our subscription and Stripe to actually process the payments. With Chargebee V3 [1] we've just dropped in their js and then we get an overlay/pop-up for both subscription and then subscription management, like editing subscription, invoicing etc. Is this a replacement for Chargebee on the integration and coding side that we get without work? [2] We'd like to reduce the number of services we integrate with and if Stripe Billing provides this, then we would like to directly use it.

[1] [https://www.chargebee.com/docs/checkout-v3.html](https://www.chargebee.com/docs/checkout-v3.html) [2] [https://www.chargebee.com/docs/assets/screenshots/images/cha...](https://www.chargebee.com/docs/assets/screenshots/images/chargebee- checkout-portal-v3/why-checkout.png)

<comment><USER32> As far as I can tell this is just dashboard and api only. But I guess they're moving towards that. Ironic as the connect partners that helped them grow are now having their toes be stepped on. Not a nice way to play. Burn the community who helped you get there in the first place.

Turn and burn it seems

<comment><USER33> You can't expect that Stripe doesn't expand their feature set. Seeing that there are hundreds of services built around stripe ([https://stripe.com/works- with/types/stripe-extensions](https://stripe.com/works-with/types/stripe- extensions)) it's really expected that some of them will be cannibalized eventually.

Subscription billing has been in Stripe for many years... it's just been very weak until now. Totally makes sense for them to work on this and if you built a subscription billing company on top of Stripe you should have known it was only a matter of time before theirs got better.

<comment><USER32> They're also shooting themselves in the foot. They're without a doubt less competitively positioned from a developer POV now. In my opinion. Even from a startup who isn't technical. More percentages just get scary when you have people like Braintree keeping it simple...

Also Stripe still rely on their partners to drive business to them at the end of the day. No denying that it's a big part of their funnel. A startup looking at their offering cold now will just be confused as well. What even is it? Some people think it's a checkout when it's not. It's just s slightly more advanced subscription api with a price tag.

Also by cannibalising their partners will dry up their eco system. Chances are the partners do a better job as they're focused on it. Can't be perfect at everything.

I'll see what they have to say on the call I have with them tomorrow.

<comment><USER32> To be clear there is no doubt it's a sensible direction and a great product but charging for it is not IMO. Superior product will drive more business to them regardless. The market of payment gateways is competitive already.

But congrats and good job Stripe. Just reconsider the pricing.

</comment></comment></comment></comment></comment><comment><USER34> Just received an Email saying this "replaces Stripe Subscriptions", what does that mean exactly? e.g. what happens with our existing Customers and their active subscriptions?

IMO this is a poor communication and confusing announcement with lots of open/unanswered questions for existing Customers, which is unlike what I've come to expect from Stripe.

<comment><USER4> (PM for Stripe Billing here!) If you're an existing user of Stripe Subscriptions, you can continue as you were! Your existing integration will still work as before and your customers won't be impacted.

That said, you'll also get access to all of the new tools as well -- would love for you to try them (and see if it improves your experience!) If you go to the Dashboard, we walk you through what changed in detail -- let me know if that helps, or feel free to send me an email at any point: email@example.com

<comment><USER35> > If you're an existing user of Stripe Subscriptions, you can continue as you > were!

But what if I'm an existing user, and about to start a new business? Honestly, this sucks.

<comment><USER4> Shoot me an email with the details? I'll see what we can do!

</comment></comment></comment></comment><comment><USER36> Current Stripe customer that is now very confused.

<comment><USER37> It's basically an automated recurring billing service that you can use whether you run a static monthly subscription service ($9/mo per user), or if you are using a metered approach, such as $0.02 cents per SMS, and then do that on a recurring basis.

So if you think about the 3 or so standard business models for SaaS, per user, per usage, or per tier (standard, pro, advanced) - this provides for all of that in an automated fashion.

<comment><USER36> Stripe is supposed to be a back-end API, not a front-end API. I don't want them taking over my payflows and confusing users.

<comment><USER38> So don't use it? _shrugs_

</comment></comment></comment></comment><comment><USER39> What companies does this hurt? Recurly? Zuora (which recently had an IPO)? Chargify? The truly interesting feature to me is the credit card recapture part which updates automatically cards that are re-issued.

<comment><USER40> Hasn't Stripe supported updating card expirations for a while now?

<comment><USER38> It does. [https://stripe.com/blog/smarter-saved- cards](https://stripe.com/blog/smarter-saved-cards)

</comment></comment></comment><comment><USER41> This is extremely disappointing. For my business this means an additional 0.4%-0.7% fee added onto a service I currently use for free justified by features that I cannot use for compliance purposes. This new invoicing process does not qualify as an exempt financial service for a covered entity. (see subsection 1179 of HIPAA)

So unless they are now willing to sign a business associates agreement I just got a price hike for a feature that would cause fines so large they would close my business. This is going to be a PR nightmare for stripe. They have destroyed all of their goodwill, and now I will have to start considering competitors. If anyone from Stripe is here in the comments I would love to chat (email is in profile)

<comment><USER4> (PM from Stripe) If you're an existing user, there's no extra fees, even if you are past the $1M lifetime threshold. For existing Stripe Subscriptions users, Stripe Billing is included in your current price. (You should have received an email about this earlier today, but you can always ping me (email@example.com))

<comment><USER41> Tara as a forewarning gmail marked your message as spam in my inbox. I would expect a lot of people to have the same experience. Second the messaging is not clear if you are indeed offering a grandfather clause for existing customers you need to state that clearly. Using the term "included" is ambiguous and I interpreted it in the same manner as a tip being included on a check. (meaning we've already added it, not that we didn't charge you)

<comment><USER4> Appreciate the heads up, we definitely should have improved the email wording here. In case the email went to spam, there's also two notifications on this in the Dashboard -- check in your notifications section.

</comment></comment></comment></comment><comment><USER42> So... "Subscriptions" is now 3.3% + 30c for new clients, for a bunch of features that used to be 2.9% + 30c, along with different billing models, "smart recovery," and automatic card updater (which I swear was already a feature they'd implemented.)

This feels like a very backdoor way to raise their rates for their subscription service because they felt like they were undercharging and they need more margin, and masking it with a couple of features that they're claiming can help make it worth it. (And sure, first $1M free, but still.)

I kind of wish there was a "standard" tier that kept it at the normal rate and maintained parity with the features we had yesterday for 2.9%...

</comment><comment><USER32> As a connect platform partner this is a bit of a blow as this impacts our customer acquisition funnel, we drive customers to Stripe and then they use us.

I have been talking with Tara who has been very helpful on this matter but wanted to pitch in here.

I think from a connect platform partner stand point it comes across as a bit inconsiderate almost.

I have already seen some people immediately put off considering using Stripe now due to the additional fees and complexity. It just doesn't seem to sit well.

The Subscriptions API was the main reason for Stripe's success and now it's being charged for, why not charge for the dashboard usage and leave the api users alone?

</comment><comment><USER43> First $1 million for the lifetime of the account I assume, not per year?

Seems odd that they announce a fee increase without any notice to existing customers.

Also I found their wording very confusing - I had a few seconds that I was very worried I'd have to migrate something or other. Poor communication wording on Stripe's part. C'mon, guys.

</comment><comment><USER44> Having used Chargebee for a long time I would say that this problem space is much larger than it first appears. There are a lot of boxes to tick before a solution like this does all the stuff you'll need it to (but have no idea about).

<comment><USER45> I'm in the midst of integrating Chargebee. Do you feel like this new offering is a good replacement for Chargebee? I don't know what I don't know yet.

<comment><USER44> Nothing is a good replacement for Chargebee - stay the course there!

Don't get me wrong. I love Stripe, and we use it for handling all the payments. Over time I'm sure this billing offering will grow in functionality but it's unlikely to even get close to feature parity with Chargebee.

Many days from now you're going to have this internal monologue while in Chargebee; _" Noooo, I have to do this really weird thing with promotional credits and coupons and pro-rating and adjusting subscriptions all at the same time and there's no way... oh, wait, that all works. And it showed me everything that was going to happen on screen before hand so I could double check. Just. Amazing."_

</comment></comment></comment><comment><USER46> Can anyone explain me why Stripe is so hyped on HN ? It's the most expensive card processing service I know. I am using one where I pay 1.9% for all my clients and another for EU clients where I pay only 1.7%.

I don't see anything in their offer that is worth paying additional 1.2% of my business to card payment processor.

<comment><USER47> (Stripe here) Stripe's pricing varies depending on the country you're doing business from. If useful, you can see our pricing for businesses in the UK here, which starts at 1.4% + 20p for European cards: [https://stripe.com/gb/pricing](https://stripe.com/gb/pricing)

<comment><USER46> I am not from UK but I live in EU. I can't use Stripe at all:

"Once Stripe is supported in your country, you'll be able to accept payments from customers anywhere in the world."

<comment><USER47> We operate in 25 countries today and our pricing varies by country. We're not everywhere yet, but we're working on it: [https://stripe.com/global](https://stripe.com/global)

</comment></comment></comment></comment><comment><USER48> OK, this is brilliant:

"Behind the scenes, Stripe now generates a unique virtual bank account number for each of your customers, which keeps your company's banking details private. Any payments received appear in your Stripe balance and invoices are automatically reconciled and marked as closed."

</comment><comment><USER49> I have 1000+ active customer subscriptions on Stripe. Does it mean that my fees have just increased 0.4%?

</comment><comment><USER50> Everyone here is complaining about price, so let me offer a counterpoint.

My understanding is that 2.9% + 30 cents is barely above what you would expect the credit card networks themselves to be charging Stripe. The margins are razor thin. If you have beef with this percentage of your revenue being taken, it's with the credit cards.

Adding a .4% fee on top is likely cheaper than using a separate service on top, like Chargify/Recurly/Chargebee. (Sure, if you had already built your own stuff on top of Stripe, you don't see this tradeoff as real. But all of those are legitimate businesses, suggesting there's a huge market out there of people who don't prioritize eng time like you.)

.4% isn't nothing, but put it in context of a functioning SaaS business with product priorities, especially when you think about expensive it is to hire software engineering talent. It's going to be a fraction of a fully loaded engineer's time that is probably best dedicated to other parts of the business. (Fully loaded = take a salary, add 30% for taxes and benefits, plus ammortized recruiting fees.) A one-time or occasional integration project frees up engineering to focus on other stuff and enables other teams to work on their own.

</comment><comment><USER51> Somewhat off-topic question, but how do others handle the need to create an invoice that corresponds to a Stripe charge? We've been using Stripe Subscriptions (I guess, now Stripe Billing) to auto-charge customers, and we separately define recurring invoices in QuickBooks Online. It's a clumsy process, but I'm assuming all Stripes Billing users have to solve it. Is there a better way to handle?

<comment><USER52> We use Quaderno to generate invoices for our Stripe charges. Quaderno integrates well with Stripe.

</comment></comment><comment><USER53> This is awesome, congrats! I'd love to be able to send invoice emails, and/or retrieve links for invoice PDFs and list those in your application for download (or re-sending of email). Seems a bit bizarre as the infrastructure for emails, and generation of the PDFs are clearly in place, just missing the bits to tie those two together.

</comment><comment><USER54> Awesome job on making it easy to add usage based plans. I've found Stripe's customer service to be a notch above the rest.

Request to folks at Stripe ( @pc / @tarstarr ) : Please do something to protect small business owners against fraudulent payments (i.e. with stolen cards). Even if they follow all recommended practices by Stripe, it's very likely that there are a handful of stolen cards that will fly under the radar and hit them negatively.

I'd say if the merchant is not at fault due to a stolen card being used on their site, they should not get penalized for it. The chargeback fee is one thing, the worse part is the dispute rate going up. This threatens the existence of any business if their account is suspended by Stripe.

</comment><comment><USER55> I understand how handy are solutions like stripe, but at least in Europe you can have a payment gateway from your bank just like they can give you a handheld device, and the rates are way cheaper, I just looked one which is 0.50%, six time less than stripe.

<comment><USER56> Can you name some payment gateways from banks? I would like to read up on this.

</comment></comment><comment><USER57> I'm so excited about this. We were looking into Recurly, but the migration from Stripe to them seemed like a huge hassle. Not sure yet, but it looks like this will allow us to unify all billing in 1 place, without a large dev or monthly cost. #awesome

</comment><comment><USER58> If I may take advantage of the numerous highly knowledgeable people in the industry here — has anyone recommendations for accepting payments from the UAE?

We use Stripe to receive card payments there in AED and then need to pay this money out again in AED. As Stripe don't settle in AED the funds get converted to USD and then we have to convert them to AED again to pay out.

Stripe charge 2% conversion fee over market rates to convert the funds. What's most annoying is AED is pegged to USD and there's no conversion risk, yet Stripe charge the conversion fee anyway. So we pay 2.9% or 3.4% (can't remember which it is off the top of my head) international card fee, 2% Fx to USD and another few % back to AED :-€

</comment><comment><USER59> Well, this is all a bit cheeky. Backed Stripe for so long now, kinda lost touch with the options. What are some other decent recurring payment processors that support Asia Pacific, specifically Australia/New Zealand?

<comment><USER30> Pin Payments for a local solution or Braintree?

</comment></comment><comment><USER60> A really cool touch is that those animated examples of pricing and other elements are actually animated html elements, not GIFs or video files. Again really slick touch from designers at Stripe.

</comment><comment><USER61> Looks like a nice improvement. There's some very bizzare design decisions with Subscriptions, so hopefully this will start making things more flexible.

</comment><comment><USER62> I'd love something like this that handled in-app purchased subscriptions. There's a bunch of annoying parts of dealing with the app store SDK's & verifying transactions, handling refunds etc. We have a combination of online credit card purchases and in-app ones, it seems like there's an opening for some tool to handle the in-app part as well.

</comment><comment><USER63> I've been waiting for the invoicing piece for a long time. We currently use PayPal invoices (and will probably continue to do so), but for those customers who can't use PayPal, this is fantastic!

We've been using Plasso's payment form service, but they just changed how that works, so this came along at exactly the right time.

</comment><comment><USER64> Billing systems are hard. Building a system to serve as the billing system for N clients? Wow. Kudos to all involved.

</comment><comment><USER65> How does this work in the case where the majority of your customers currently pay by direct-debit/cheque? This is certainly the case for us, but we have long been looking for a affordable solution to have them managed with some sort of managed subscription engine

</comment><comment><USER66> Does this support international wire transfers as an invoice payment method?

If so, that's a killer feature for us, as US-based customers have other options including simply mailing a check; it is our international customers exclusively who are interested in wire transfer...

</comment><comment><USER67> How does Stripe auto-recovery compare to a service like Stunning? Does it make it redundant?

<comment><USER4> (PM of Billing from Stripe here) Tools like Stunning, and the many other extensions that work with Stripe, are very complementary to Stripe Billing. As you'd expect from Stripe, we've taken an API-first approach, so that our partners can actually take advantage of our recovery tools when building their solutions. We expect that particular businesses will want to use both!

<comment><USER19> @tarstarr can you email invoices?

Also do you have multi currency subscriptions? Or do i need to create a pro_monthly_euro, expert_yearly_dollar subscription ?

<comment><USER4> Hey! Yes you can email invoices to your users (finally!) We heard that feature request so many times. :)

Re: multicurrency subs -- we thought about this quite a bit. At the moment you'd need to create a plan per currency, with our reasoning being that you'd want to control the FX rates on your own (and setting a price internationally is a very intentional decision.) That said, how can we make this easier? This launch is a start of our investment in this space, really interested in feature requests.

<comment><USER68> Would be great if the "Pay in Full" button on the invoices used the same color that is set under Business Settings > Customer Emails > Customize Design.

</comment></comment></comment></comment></comment><comment><USER69> Under invoices there are two new documents "Invoice PDF" and "Receipt PDF" which are different from the standard e-mail receipts. Are these documents emailed to the customer automatically? Is there a way to control this?

</comment><comment><USER70> Not sure how I feel about it. One of my existing plan got duplicated for some reason.

</comment><comment><USER71> This seems like an excellent move for Stripe. Lowering the barrier to entry for anyone trying to get into the SaaS (or really Anything-aaS) field by making recurring billing easier strikes me a great move for their bottom line.

</comment><comment><USER72> I see interest here in the new invoicing feature. My question is, if your accounting system can send electronic invoices (Quickbooks does), why do you need Stripe? Especially if it's more expensive?

</comment><comment><USER73> Woaah there! 2.9% + $0.30?! I just changed my provider because their 1.45% (+ $0!) was way too expensive compared to the competition. Do Stripe provide a bag of gold at every Christmas?!

<comment><USER74> Where were you getting 1.45% fixed, and where did you get a cheaper rate (for USD transactions).

</comment></comment><comment><USER75> Sweet another service I can't use because I'm Canadian, but wont get access to their Atlas program because I don't qualify. I'll have to take another approach.

<comment><USER76> (I work at Stripe and am also Canadian!) It looks like you might have applied for Stripe Atlas when we were in a small private beta and we've greatly expanded the businesses we can support. Please feel free to apply to Atlas again, or you can email me us at email@example.com.

<comment><USER75> Thank you, I sent an email with some questions.

Thanks

</comment></comment></comment><comment><USER77> I wish this had existed a year ago when we shifted from primarily doing everything through Stripe to Chargify for metered billing, invoicing and dunning.

</comment><comment><USER78> Will Stripe include free Billing for companies that have negotiated a volume discount?

<comment><USER4> Yes, if you're an existing user, no matter your current rate, you'll get Billing for free at your current price.

</comment></comment><comment><USER79> can anyone comment on support for purchase orders which a lot of companies use to recognise or initiate a purchase? it seems to still be the only thing that needs to be manual in that process....

</comment><comment><USER80> Still no way to cleanly pause/unpause subscriptions? Why not?

</comment><comment><USER81> Skeptical a bit about "usage-based" billing and interested to hear others' thoughts. Isn't a major profit-driver for many subscription-based businesses the breakage?

</comment><comment><USER82> That's really awesome. Chargebee is spammy in my experience. Bad kind of spam. Glad Stripe is replacing them.

<comment><USER83> care explaining how?

</comment></comment><comment><USER84> how does this compare to ChargeBee?

</comment><comment><USER85> Stripe now begins to turn into Paypal.

Soon: 4 versions of APIs working simultaneously, with a different mix of missing features in each one of them, and no docs.

<comment><USER38> Bit quick on the slippery slope are you?

Whatever makes you say something so absurd?</comment></comment>


On Saying No - The Power of Simply Answering, "No." - <AUTHOR> http://www.esquire.com/features/influence/say-no-0508?click=main_sr

<comment><USER2> The subtler point of this article is that a simple no is a good test of your authority- service personnel, students, people he had power over; they had to except his "no." Girlfriend? Not so much.

The power in question isn't the added power of using the word- it's the way the word reveals the power dynamics at play. He didn't gain more authority by using the word; the word revealed to him his authority and its limits.

<comment><USER3> > they had to except his "no."

They didn't. They could have asked for explanations, justifications, clarifications. He might have given them or not, might have continued the conversation or not (as he notes he did with a student), but that doesn't mean they _had_ to accept his "no" for an answer.

<comment><USER2> Well, yes, they could have asked for any number of things, but the end decision still rested with him. Which means, yes, actually, they did have to accept his "no." If he refused to answer any further questions except with "no," they would have to accept that too.

I don't mean accept in the sense of "be at peace with the decision." I mean accept in the sense of "there ain't shit you can do about it, kiddo."

</comment></comment></comment><comment><USER4> It's a persuasive article, and I appreciate the point being made. An important part was that he thought about his decisions, and when he decided the answer was no, that's what he delivered. He didn't always say no, but when it was appropriate, he made sure he did say it.

The last section tied it up well, however. You have to know when to stop. You have to apply intelligence.

It requires thought, as well as discipline and persistence.

</comment><comment><USER5> I think some of the article is compelling, but when he's talking about service personnel he just sounds like a jerk. A waiter who asks whether he wants fresh ground pepper is "attempting to dominate the transaction"? Taking care of you is a waiter's _job_.

<comment><USER6> When dealing with service personnel one can morph a simple "no." into a "No, thank you." Polite but similarly final.

<comment><USER5> Exactly, and not as disdainful of someone who is just trying to be friendly and do their job.

<comment><USER7> I don't see anything disdainful or rude about just saying "No." even without a "thank you." It all depends on how you say it.

<comment><USER5> It doesn't have to be, but the attitude of the author is that he is standing up to someone who is trying to "dominate a transaction." With that mindset, "no" is bound to come off as rude.

</comment></comment></comment></comment></comment><comment><USER8> " _But when he really did ask if he and a couple of buddies could have a few beers at my house, I just said no. No follow-up, no prevarication, no buddying up for a sympathy injection._ "

While I see the purpose of a clear 'No', in some cases, it just seems like it's rather jerkish even if said in a nice tone. How hard is it to say instead, "No, and that is final; my reason is such and such, just so that you know"? I know that I would be accepting of the latter answer, but questioning of a pure "No", since it would seem as though he was just being instantly judgemental.

<comment><USER9> True. The guy who brought his kids up with a proper understanding of rhetoric definitely did a better educational job.

The kids of Dr. No, however, will grow up being people who can't express themselves, and inevitably provoke conflict by being obstinate and seeing themselves mostly in the right because of their authority.

They will not value reason.

<comment><USER10> I might be inclined to think that someone who can't give a straight answer is going to have trouble expressing himself.

</comment></comment></comment><comment><USER11> Being a software engineer often means that you are in the job of fending off well-meaning, but unreasonable requests from clients on a continual basis. Learning how to say "No" repeatedly without coming across as lazy or a jerk is an extremely important skill. I read "The Power of a Positive No" by William Ury (of "Getting to Yes" fame) looking for wisdom in that area. Now, I recommend it to every engineer (and manager) that I know. If everyone read Ury's books, the world would be a much happier, smoother-running place.

</comment><comment><USER12> A "No" could have prevented <http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaster>

<comment><USER13> Sure, and it could have also prevented any positive achievement you might like to name.

</comment></comment><comment><USER14> The title get's it right. "No" is about power.

I prefer "yes", which is less about power and more about getting things done.

Interesting article. Will I ignore OP's advice and keep doing what I always have?

Yes.

<comment><USER15> On the getting things done. In the company where I did internship last year there was completely different attitude. People were urged to use "Yes, if..." instead of "No, because...". Not surprisingly this is the most successful EDA company.

<comment><USER16> On the contrary, no to superfluous bullshit is a powerful tool for getting stuff done. Someone I know likes to just say _I'm bored now_ and walk out of pointless meetings.

<comment><USER17> Well, "I'm bored now" hasn't come up, but I sure have said "I don't think I'm contributing to this meeting anymore" and walked out. Fortunately, that gets light bonus points for me with my boss, which makes it easier.

Also, remember that phrasing; even without my particular boss that is likely to make a point with any sensibly-business-minded boss.

</comment></comment></comment></comment><comment><USER18> Also, try using "fine" as a way of consenting to something rather than "yes"

It conveys the same certainty and closure as "no"

<comment><AUTHOR> I've personally taken a dislike to using two phrases with people, "fine" and "whatever". Both of them, generally, have a negative connotation to them. Especially when talking to a girlfriend/significant other, it just feels crude.

<comment><USER19> This is very true. My wife particularly hates "fine" and "sure".

</comment></comment></comment><comment><USER20> This is what I've always done.

Are there really people out there who feel the need to explain themselves to carwash attendants and waiters???

<comment><USER21> I think it depends on how helpful the person is being. Saying no to carwash guy is easy, but "can I take that bag for you" suggests a sincere effort to make my expereince more pleasurable as well as an effort to go out of the way to do the best job, not just any passable job. This usually gets "no, thanks" or "thanks, I'll mananage".

Now after reading this article I'm not sure if my reaction is adequate in the latter case.</comment></comment>


Physics Offers Explanation to Why Time Flies as We Get Older - <AUTHOR> https://www.studyfinds.org/days-gone-by-physics-offers-explanation-to-why-time-flies-as-we-get-older/ <comment><USER2> Time is an illusion. Tea-Time doubly so.</comment>


Capsule Shield: A Docker Alternative for the JVM - <AUTHOR> http://blog.paralleluniverse.co/2015/10/08/container-capsules/ <comment><USER2> [Disclaimer: Bias as I work for HashiCorp]

We designed Nomad[1], our scheduler, with this in mind. Nomad has the concept of "task drivers" and one of those task drivers is "java." A task driver provides isolation using things like cgroups automatically, without you having to containerize your application. This makes sense for applications that are already _mostly_ "containers" (in the abstract sense): Java JARs, statically linked binaries, VMs, etc.

If you compile a fat JAR you can schedule it directly with Nomad, and Nomad will handle the isolation and resource constraints. Pretty nifty!

And, I noticed Capsule talks about OSv. Nomad can also deploy "VMs" natively on top of Qemu so you can deploy that as well.

The coolest thing perhaps is that you can mix and match this stuff: you can deploy JARs alongside containers alongside VMs and Nomad handles the binpacking and resource constraints for you. And this is why I bring up this plug for us.

[1]: [https://nomadproject.io/docs/drivers/index.html](https://nomadproject.io/docs/drivers/index.html)

<comment><AUTHOR> > If you compile a fat JAR you can schedule it directly with Nomad

That JAR better be a capsule, then :) Non-capsule fat JARs don't have enough information to configure the JVM, don't support native dependencies and in too many cases simply don't work.

</comment></comment><comment><USER3> For me, this misses the point of Docker.

These days, production and dev environments are extremely heterogenous. We're already running a database written in C, a messaging queue written in a JVM language and a front-end API written in Node and all while serving our static assets from a generic web server. And we're starting to explore Go and Rust for more specialized components. Docker allows me to abstract away all the platform-specific issues and treat all my infrastructure components as if they're homogenous. Docker compose can bring up my entire dev stack. Docker swarm or any of the other orchestration services (ECS, Kubernetes, Nomad, Fleet, etc) can manage my entire production deployment.

A JVM-specific option is really a step backwards. Using that, I'd now have to go back to treating my JVM components differently from everything else. The whole point of Docker, for me, is that none of my diverse infrastructure components needs special consideration.

<comment><AUTHOR> I work on Capsule.

It's not about philosophy but pragmatism. Most organizations are mostly Java, and even if Java doesn't make up 90% of the components, it makes up 90% of the deployments because that's what the core business software uses. Such organizations get to use a a rather crude tool that takes away some of the power of their technology stack. Why not use a slimmer, faster, less-hassle tool for the majority of your deploys?

And if we want to talk philosophy, Docker really mixes two separate issues -- portable packaging and isolation. Capsule separates them. If you want, you can launch a capsule inside a Docker container. If you want, you can directly launch it in a more convenient container simply by launching it with Shield (or outside a container by running it directly). As Shield will be open- container-compatible, there's no reason why Docker and Shield shouldn't play together. And remember, Capsule requires zero additional tools on top of what developers use anyway (it's just a plain Maven Central library that you stick in your JAR with your build tool).

<comment><USER3> You live in a much more Java-centric world than I do. Your world seems similar to the one I inhabited for well over a decade (I wrote Java code professionally from 1997-2012), but with the rise of microservices, I'm seeing almost no interest in creating any new Java code. The JVM isn't going away...there's plenty of Scala and even some Clojure. But there's also a move towards newer platforms like Node and Go. And there's even been a rediscovery of platforms like Ruby and Python when the performance penalty doesn't come into play.

Docker enables everything to play nicely together. Capsule seems to double down on the old, monoculture way of developing. For people that want to do that, I'm sure your solution is an excellent product. But my own perspective, which may be skewed by being in the bay area, is that those people are the minority, not the majority.

<comment><AUTHOR> > there's plenty of Scala and even some Clojure. But there's also a move > towards newer platforms like Node and Go. And there's even been a > rediscovery of platforms like Ruby and Python when the performance penalty > doesn't come into play.

I won't say what you're saying isn't real, but it is happening on a completely different scale than the size of the Java ecosystem. Even on the JVM, what you see as "plenty of Scala" doesn't even amount to 5% -- not that it matters, but it's just an example of why I think your view is skewed.

The size of the Go ecosystem is hardly 1% of that of the JVM (rough estimate), and while Node.js/Python are "a thing" (and are the only languages/platforms of those you mentioned that are used to a substantial amount outside of startups), they are still tiny compared to the use of the JVM. Even in Silicon Valley (which is in itself a very small portion of the software world), the large "webby" application companies (with the notable exception of Facebook) are JVM shops: Amazon, Google, eBay, Twitter, Netflix are either entirely JVM or predominantly JVM, and even Facebook is making growing use of the Java.

Most of the shifts you're seeing is among non-JVM technologies. It's mostly Pythonists that switch to Go and Rubyists that switch to Elixir/Node.js, etc.. The JVM was never the biggest player in the "fast application development" arena -- at the beginning there was VB, and then Perl, and then Python/Ruby and so forth. I see no signs that there is greater movement away from the JVM -- mostly among those who realize they're better served by the "fast dev" platforms even at the cost of performance -- than towards it -- by those realizing they need the best the industry can offer in terms of performance/monitorability/tooling even at the cost of slower development.

</comment></comment></comment></comment><comment><USER4> I've spent some time in the past few weeks trying to rebuild a bunch of uberjars as capsules, and have found it not suitable for production server use. The main promise for me is that rather than shipping 100M+ uberjars, we can ship just our code (~5MB) and have the capsule download its dependencies on startup. This sounds pretty nice in theory: your boxes can cache your dependencies (and transitive dependencies) and new deploys only need to update the new stuff (generally just your code).

But there are a bunch of ways capsule makes this difficult, particularly in the context of a mono-repo with a bunch of internal libraries. Capsule lacks a real transitive dependency management system, so you're stuck bypassing it entirely and having your build system compute the complete graph of transitive dependencies and write it in the jar manifest.

Even worse, on every start up capsule will open all the jars that have already been cached to validate checksums, which can take many minutes if you have a lot of dependencies.

The idea is really solid. I just wish the implementation were better.

<comment><USER5> I think fetching dependencies at run time is a bad idea. The more dynamism and complexity you have at run time, the more ways there are for something to go wrong. For maximum robustness, I think a good rule is to never do at run time what you can do at build time. So in that respect, a fat jar is better. Also, in princple a fat-jar deployment should start faster, because (given an appropriately optimized JVM implementation) the system can just map one file into memory and go.

So why not just use a fat jar, as you were before?

<comment><AUTHOR> Capsule by itself does not fetch dependencies at runtime. But because Capsule is so flexible, we have a caplet[1] that you can choose to use that does.

And a capsule _is_ a fat jar. Non-capsule fat jars frequently just don't work: they can create resolution conflicts which requires shadowing and even that can fail, they don't support native dependencies, and most importantly they require a startup script as they don't set up JVM options.

[1]: [http://www.capsule.io/caplets/](http://www.capsule.io/caplets/)

</comment></comment></comment><comment><USER6> So its basically a reinvention of the servlet container model. Shield equals tomcat or one of the other servlet container apps. Caplets equal war file packaged applications. Have I missed something?

<comment><AUTHOR> Capsule does not resemble servlet containers and WAR files at all. You can think of Capsule as a fat jar that always works and contains a startup script (which is declarative and placed in the JAR's manifest). It is a packaging solution. It isn't a deployment _format_ (like a WAR), but a JAR that can configure the JVM that runs it.

And while the word "container" is used here, we mean a different kind of containers -- those that give you virtualization and app isolation at the OS level[1]. So there is no container -- like a sevlet container -- that hosts multiple applications, and no specific programming model.

[1]: [https://en.wikipedia.org/wiki/Operating-system- level_virtual...](https://en.wikipedia.org/wiki/Operating-system- level_virtualization)

<comment><USER6> An, that's interesting. So can it be used to overcome the memory leak problems of traditional servlet containers, because every app is a system process whose memory is released by the OS and not by the container.

<comment><AUTHOR> Well, it's completely orthogonal, really. Capsule makes it very easy to package and deploy single-app servlet containers (like, say, Jetty), but if you wanted to you could also package JBoss as a single capsule JAR. If it can run on the JVM -- it can be packaged with Capsule (and if not, let us know and we'll fix it!)

<comment><USER6> Thanks for the explanation. I will definitely try Capsule.

</comment></comment></comment></comment></comment><comment><USER7> > Docker is a terrific product, but as a general-purpose solution, is simply > too blunt an instrument for the deployment and management of JVM application > containers

Why?

> Image management, logging and monitoring present challenges to general- > purpose container solutions, but are non-issues for the JVM.

WTF? Java applications can be a pain to set up. Jars here, jars there, Maven, Ant, XML configuration, its all a big mess. If someone can do all that for me and say "here's my Docker image that just works" I would say issue solved.

> Docker images are big and contain full-blown operating systems as they are > meant to run arbitrary applications: managing their archival and evolution > can become a serious hassle. On the other hand JVM applications need nothing > more than a JVM and a kernel

This person seems to have a serious lack of understanding of Docker. Your Docker image does not need to contain a "full-blown operating system" \- it is perfectly acceptable for it to contain just the strict dependencies of the program (the JVM) you are running. On my system java links against libpthrad, libdl, libz and libc.

> Linking: Java already supports customized domain-name resolution, so > Docker's solution of modifying the container's hosts file is unnecessary

Does he even get what linking is about? Linking is a way of sharing configuration between containers...so the mysql host:port on one container is available as a convenient environment variable or /etc/hosts on another. What has this got to do with Java's DNS custom support?

> Monitoring and Management: The JVM has its own rich monitoring and > management API, JMX

And Docker is somehow preventing you from using this?

This post reeks of Java elitism and written by people who didn't even bother trying to understand the technology they are claiming is inferior or not applicable to a True Java approach.

<comment><AUTHOR> I am sorry you feel hurt, but you have misunderstood the post. Docker really is great -- and like the post says, it really does let you do everything you want. But for JVM applications, Capsule is much easier and faster, requires fewer steps and fewer tools, and launches containers that are more secure and easier to monitor and manage. Docker doesn't prevent you from doing all that (well, except for the security bit), but it does add extra work and an extra layer of inconvenience compared to Capsules. Capsules are a JAR file built by your chosen build-tool that require no set up, configuration etc.. You can launch them as a simple executable JAR, or, if you wish, optionally launch them in a container. Docker isn't inferior by any means. It is simply less streamlined -- _for the JVM_ \-- than a solution that is specifically tailored for the JVM. That's it.

</comment></comment><comment><USER8> you kinda lost me at this:

"Docker images are big and contain full-blown operating systems as they are meant to run arbitrary applications"

because it's exactly how you are not supposed to use docker, you are supposed to include only what you need and you most definitely do not need a full operating system inside a container that runs on a full operating system.

back to Java: our base java docker images are around 70MB, see this to see how, I'm not involved in it: [https://github.com/delitescere/docker- zulu](https://github.com/delitescere/docker-zulu)

Yes, still bigger than the uberjar but that's the not point

<comment><AUTHOR> Even if you optimize or images and layer them in such a way that they share dependencies, you still need to create them, which is much slower than not creating them, _and_ requires an extra tool, _and_ requires handling management and logging less conveniently. You don't need Docker for containers, and the JVM has better packaging solutions than Docker. Why add an extra tool and an extra step for _less_ convenience?

<comment><USER8> you are missing the point of my comment which is: your "Footprint" is factually wrong

<comment><AUTHOR> I don't think so. For the same amount of work you get a much higher footprint. Want smaller footprint? Start grouping your dependencies into layers -- namely, extra work.

When I say that something is higher footprint or worse performance etc., I mean that that's what you get for the same amount of work compared to your point of comparison, not that it's impossible to make it better if you work harder.

<comment><USER8> ok but that's not what you wrote. I quoted verbatim what you wrote and it's not correct, Docker images do not "contain full-blown operating systems as they are meant to run arbitrary applications" unless you decide to put a full- blown operating systems in them but that's your choice, you definitely don't have to and everyone recommends not to

<comment><AUTHOR> Fair enough. Clarified in the post.

</comment></comment></comment></comment></comment></comment><comment><USER9> I think it's a step backwards if platform specific containers like Capsule pick up. Nodeck and Gontainer next?

It's more productive to develop general containers that solve issues with logging etc. for all platforms, not for just one.

<comment><AUTHOR> Docker isn't a container -- it's a packaging solution for containers. Capsule is another packaging solution that can be launched in the same kind of container. Also, the JVM isn't _a_ platform; it's the biggest platform by a very wide margin for server-side applications.

So the containers are still general, and you use them for all platforms and they all interoperate. I just see no sense in requiring an extra, inconvenient packaging step for a platform that already packages applications well.

</comment></comment><comment><USER10> Meanwhile others use JavaEE. Supported by multiple vendors and multiple open source options, easy to use, well-tested and battle-hardened.

Oh: and it has a secret feature - pragmatic and friendly developers.

</comment><comment><USER11> Do you really need just a JVM and a Kernel? You must need a filesystem too. How do you connect to a database?

<comment><USER12> Filesystems run inside kernels (normally).

<comment><AUTHOR> Very true, although technically I'm not sure the JVM requires a filesystem. The class loader for application classes is a URLClassLoader that can load classes over the network, so the only problem is the boostrap class-loader, and I'm sure that could be taken-care-of, too (might require a JNI wrapper).

</comment></comment></comment><comment><USER13> > "BONUS: Capsule OSv"

That could be something decent. I'd be interested to know what performance benefits you get from using Capsule to manage OSv. Does anyone have a JVM- based Docker app they could use for comparison?

<comment><USER12> The performance boost for using OSv can be pretty significant if you _can_ use it (it's a rather specialised tool). You're effectively using the hypervisor as a kernel. If you mean "a docker based app on OSv" then the answer is almost certainly no, as OSv is an operating system that's designed to only run one or two apps at once. It's not a regular operating system at all. I don't think Docker would likely even start on it.

<comment><USER5> I think it would be more interesting to compare a JVm app running on OSV inside a VM to the same JVM app running in a Docker-compatible container on bare metal. In both cases you effectively have a single process running on a kernel, without the extra kernel in between (as in the common case of an app running on a general-purpose OS in a VM). But virtualization probably still has extra overhead. And of course, the hypervisor offers lower-level abstractions to the VM than a general-purpose kernel would offer to a container; for example, for storage, you get a block device rather than a filesystem.

Note that I said Docker-compatible. One alternative to the Docker Engine itself would be Joyent's Triton, which uses Illumos rather than Linux as the kernel (while still supporting Linux binaries), so it doesn't have the security problems of Linux namespaces + cgroups.

</comment></comment></comment><comment><USER14> I do not like fat jars. We use JVM + mvn + appassembler and pack the output into docker images. Not a big deal.</comment>


9th Circuit holds that scraping a public website does not violate the CFAA [pdf] - <AUTHOR> http://cdn.ca9.uscourts.gov/datastore/opinions/2019/09/09/17-16783.pdf <comment><USER2> This action does more than that. The court left the preliminary injunction against LinkedIn in place: "The district court granted hiQ's motion. It ordered LinkedIn to withdraw its cease-and-desist letter, to remove any existing technical barriers to hiQ's access to public profiles, and to _refrain from putting in place any legal or technical measures with the effect of blocking hiQ's access to public profiles. "_

So LinkedIn is prohibited from blocking hiQ's access by technical means. That's a strong holding. If this case is eventually decided in favor of hiQ, scrapers can no longer be blocked. Throttled a little, maybe, but no more than other users doing a comparable query rate.

<comment><USER3> Not allowing the CFAA to be (ab)used to attempt to make scraping illegal makes sense.

However, how is it reasonable to force a web site to serve its contents to a third-party company, without being allowed to make a decision whether to serve it or not? Serving the web site costs money, and the scraper surely isn't going to generate ad income...

<comment><USER4> Ugh, yeah, the more I think about this ruling, the less I like it.

It's actually pretty insane to _force_ a site to serve content. I think both parties are in the wrong here - HiQ for assuming they're entitled to receive a response from LinkedIn's webservers, and LinkedIn for abusing the CFAA to try to deny service rather than figure out a technical solution to their business problem.

In my view:

* The data is public, and free of copyright. If you're a scraper and can get it, you haven't done anything wrong.

* The servers serving the data are still under LinkedIn's control, and they have no obligation or public duty to always serve that content. They could just as well block you based on your IP or other characteristics. If they want to discriminate and try to only let Google's scrapers access the data - what's wrong with that? Scraper brand is not a protected class. Tough taters if your business model "depends" on your ability to successfully make requests to another uninvolved company's webservers.

If I were the judge, I'd throw this out and let LinkedIn/HiQ duke it out themselves - they deserve each other.

<comment><USER5> I would argue that under spirit of net neutrality you either serve your site to everyone equally(the public facing part) or to no one.

Hosting costs money, servers cost money.. but maybe create a public facing API that is way cheaper and easier to use than scraping your website? I see that ruling in positive light that it might promote more open and structured access to the public facing data.

<comment><USER6> Why should you be forced to serve content to people who won't look at your ads?

<comment><USER7> Like disabled users with screen-readers?

<comment><USER8> I suppose we can give them a pass if they solve a bunch of captchas.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Considering the kind of _private_ scraping and selling tactics LinkedIn has been chronically guilty of (and not just the ordinary "growth hack" stuff: "LinkedIn violated data protection by using 18M email addresses of non-members to buy targeted ads on Facebook" [1]), it's satisfying to see LinkedIn lose this.

[1] [https://techcrunch.com/2018/11/24/linkedin-ireland-data- prot...](https://techcrunch.com/2018/11/24/linkedin-ireland-data-protection/)

<comment><USER10> I feel like this is a really common theme I've seen several times. Something like "Music Lyric site X sues Google for embedding their lyrics in the results directly" which is funny because site X got the lyrics by scraping them from other sites.

Plus Google only exists from scraping content, but I believe their TOS includes "don't scrape our content".

I find it really funny that the scrapers are battling scrapers - like guys you only exist because you do THE EXACT SAME THING

<comment><USER11> > Plus Google only exists from scraping content, but I believe their TOS > includes "don't scrape our content".

Yes. This is EXTREMELY frustrating.

Of all companies to prevent scraping, Google is the most ironic.

Especially since their goal is to organize the world's information, it shocks me that there's no way to get access to this organized information from machine to machine.

<comment><USER12> Perhaps this issue will be recognised in some of the antitrust investigations.

If I am not mistaken, they no longer claim "organize the world's information" as their goal.

<comment><USER13> But it still is:

> [https://about.google/](https://about.google/)

"Our mission is to organize the world's information and make it universally accessible and useful."

<comment><USER12> Appears I am mistaken. Cheers.

</comment></comment></comment></comment></comment></comment><comment><USER14> > LinkedIn has taken steps to protect the data on its website from what it > perceives as misuse or misappropriation. The instructions in LinkedIn's > "robots.txt" file—a text file used by website owners to communicate with > search engine crawlers and other web robots—prohibit access to LinkedIn > servers via automated bots, except that certain entities, like the Google > search engine, have express permission from LinkedIn for bot access.

Not a big fan of weev, but this sure seems like he got screwed if he was just enumerating public web pages and went to jail for it.[1]

[1] [https://en.wikipedia.org/wiki/Weev#AT&T_data_breach](https://en.wikipedia.org/wiki/Weev#AT&T_data_breach)

<comment><USER15> Not saying the court made the right call but for that case the big issue for the court was the pages were clearly not intended for the public and the defendant knew it.

<comment><USER16> I believe the salient issue is whether or not there were effective access controls, not whether or not a page could be reasonably interpreted as intended to be non-public.

<comment><USER17> The real issue here is somewhere between both you and GP. What is required to trigger the CFAA?

Does accessing a page the site owner doesn't want you to violate the CFAA or do you need to hack through access controls?

<comment><USER18> As a real-world analogue: you can indeed be guilty of trespassing on someone's property even if you don't have to jump over any fences or pick any locks to get there. In some places, they don't even have to have a "no trespassing" sign. Simply being present on someone else's property without an invitation from them is illegal, and no, an open door does not count as an invitation.

<comment><USER19> You generally can't be charged with trespass unless you refuse to leave when told to do so.

An open door to a home is different, but unfenced property is 100% not trespass until you refuse to leave.

<comment><USER18> That's not true at all. If you are aware that the property you are accessing is not meant for your use, you can be charged with trespassing regardless of if you have specifically been asked to leave or not.

It's even possible to be guilty of trespass even if you weren't aware that you weren't allowed on the land. This is negligent trespassing.

<comment><USER20> Negligence only applies I'm situations where a reasonable person should have known. You're only able to be charged with trespassing whilst being unaware if you were to so ridiculously unaware of your surroundings that any reasonable person in the same situation _would_ have known that they were trespassing.

If a public park blends into somebodies private lawn you can't be charged with tresspassing for stepping over the line.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> hiQ asked the court for a preliminary injunction to stop Linkedin from denying them access, won it, and this is the result of Linkedin's appeal of that injunction. This is not the end of the case.

The title is wrong. The 9th Circuit just ruled that hiQ has a decent enough argument to move forward. The question of whether them scraping a public site can violate the CFAA is not settled.

> We therefore conclude that hiQ has raised a serious question as to whether > the reference to access "without authorization" limits the scope of the > statutory coverage to computer information for which authorization or access > permission, such as password authentication, is generally required

> The data hiQ seeks to access is not owned by LinkedIn and has not been > demarcated by LinkedIn as private using such an authorization system. HiQ > has therefore raised serious questions about whether LinkedIn may invoke the > CFAA to preempt hiQ's possibly meritorious tortious interference claim.

Note the tone of the language used in the ruling. The judge makes it pretty clear that nothing is final here.

<comment><USER21> AP seems to be saying differently. [https://apnews.com/1e1cacd92df74f48846e8bce5237b97d](https://apnews.com/1e1cacd92df74f48846e8bce5237b97d)

<comment><USER22> I think I would trust the opinion itself over a random AP reporter.

</comment></comment></comment><comment><USER4> A good decision was reached, but it's a little worrying that the emphasis in the ruling was mostly about a weighing of business interests rather than affirming a right to access public information. If HiQ's business model had not been jeopardized by LinkedIn's business desire to block them, I fear this court could have easily gone the other way. I'd really love to see a ruling that solidifies the right of someone to access publicly available data without fear of repercussions. If this case makes it to SCOTUS, I would hope the ruling is predicated on that rather than business harm.

Key paragraphs from the ruling:

> In short, even if some users retain some privacy interests in their > information notwithstanding their decision to make their profiles public, we > cannot, on the record before us, conclude that those interests—or more > specifically, LinkedIn's interest in preventing hiQ from scraping those > profiles—are significant enough to outweigh hiQ's interest in continuing its > business, which depends on accessing, analyzing, and communicating > information derived from public LinkedIn profiles.

> Nor do the other harms asserted by LinkedIn tip the balance of harms with > regard to preliminary relief. LinkedIn invokes an interest in preventing > "free riders" from using profiles posted on its platform. But LinkedIn has > no protected property interest in the data contributed by its users, as the > users retain ownership over their profiles. And as to the publicly available > profiles, the users quite evidently intend them to be accessed by others, > including for commercial purposes—for example, by employers seeking to hire > individuals with certain credentials. Of course, LinkedIn could satisfy its > "free rider" concern by eliminating the public access option, albeit at a > cost to the preferences of many users and, possibly, to its own bottom line.

<comment><USER23> > If HiQ's business model had not been jeopardized

I think this is more about validating hiQ's legal standing in the case.

</comment></comment><comment><USER24> This case is so ridiculous on multiple fronts that although this procedural ruling (injunction) seems technically correct (to allow the case to proceed to actual court), it could just as well have been thrown out with no difference in or ultimate harm to the parties.

First, LinkedIn makes the claim that its users have a right to privacy against scraping by such a 3rd party. That's laughable. As the court saw, their whole business model is made on people sharing their profiles broadly and mostly to the public.

Secondly, HiQ claims that LinkedIn's efforts to stop it from using the data are tortious interference. That's bold -- suppose someone is taking your assets (you believe illegally) and selling them to others -- can you imagine the gall that the person taking your assets can sue you for interfering with their subsequent sale of your assets?

Finally, that LinkedIn resorted to using the computer fraud and anti-terrorism statutes to make their argument is ridiculous.

So much craziness to go around. I would've just tossed the case, but I guess there is the whole bit about due process... Maybe HiQ will fail anyway at the next substantive trial, but what a waste of time.

<comment><USER25> > suppose someone is taking your assets

Except that, in the digital sense, it's only copied. They now have it, but you didn't lose your assets or money besides the <$0.001 it costs to serve each web page.

> So much craziness to go around.

I agree - I haven't read through the entire thing, but it looks like, instead of saying "you can't scrape", they could implicity give a license to users for personal and business use, but not be allowed the reselling of the data (of course carefully worded to allow the likes of Recruiters and whatnot to do so). It's like trying to argue that the DMCA says you can't create a torrent file of some movie.

</comment></comment><comment><USER26> Would that ruling mean that sites could no longer refuse to show content based on how they're accessed? For example, sites that won't load if the browser is in headless mode, or sites that depend on javascript as a way of blocking wget/curl.

<comment><USER27> I have a scraper for a site that used to offer an API for their publicly available site but removed the API with no warning. The info is still available to the general public, but only through their website. I created a scraper for the public page, but shortly after they switched to loading some public information through Javascript so my HTML scraper couldn't see it anymore. I ended up having to write an application around Selenium to load the Javascript and import this public information. I'm just waiting for them to start randomizing the CSS classes to make scraping even harder. The content is static, even as data changes on the server it does not refresh on the page unless you reload the page.

There is no reason why your page should refuse to load _plain text_ without Javascript enabled.

<comment><USER28> > There is no reason why your page should refuse to load plain text without > Javascript enabled.

Sure there is. You prefer writing javascript and you want to serve your site through a CDN.

You might not think that's a _good_ reason, but that's certainly a reason.

<comment><USER29> Until the ADA comes along and demands you create an accessible to the blind site.

I've often wondered when the laws would start to be applied and I think its coming

<comment><USER30> I have a website that's a full page map. I care about accessibility - is there any way I can make this meaningfully accessible to the blind?

<comment><USER31> Look at WCAG 2 (web content accessiblity guidelines) they specify tags and elements common screen readers will understand to help make you site accessible.

This is a really good resource: [https://accessibility.18f.gov/](https://accessibility.18f.gov/)

A lot of frameworks now have some accessiblity built in if you add the correct attributes.

</comment></comment></comment></comment></comment></comment><comment><USER32> That's awesome news. Thanks also to the EFF for all the work they are doing to ensure fair use is still a thing. We'll ([https://serpapi.com](https://serpapi.com)) be donating next year.

</comment><comment><USER33> This is actually bad, would not it be better if sites would be allowed to block crawlers? I don't see what is the legal basis for forbidding to ban scrapers. Is there a law that a site must serve pages for anyone?

<comment><USER12> There is no legal basis for "forbidding to ban scrapers".

The question is whether there is any legal basis for banning scrapers, i.e., for blocking hiQ. In other words, if hiQ keeps scraping, are they violating anyone's rights and/or breaking the law by doing that?

As long as that remains a legitimate, open question, then hiQ can argue they should be allowed to keep scraping without incurring civil or criminal liability. That is the purpose of the injunction. There could be no legal basis for blocking hiQ. Until that question is resolved, hiQ can keep on scraping.

</comment></comment><comment><USER9> Considering the kind of _private_ scraping and selling tactics LinkedIn has been chronically guilty of (and not just the ordinary "growth hack" stuff: "LinkedIn violated data protection by using 18M email addresses of non-members to buy targeted ads on Facebook" [1]), it's satisfying to see LinkedIn lose this.

[1] [https://techcrunch.com/2018/11/24/linkedin-ireland-data- prot...](https://techcrunch.com/2018/11/24/linkedin-ireland-data-protection/)

</comment><comment><USER34> So the champion of the public internet turns out to be a company that scrapes your social media, MLs it and sells the results to your HR dept?

I'm reminded of Dave Chapelle's Halle Berry routine...

</comment><comment><USER35> _In short, even if some users retain some privacy interests in their information notwithstanding their decision to make their profiles public, we cannot, on the record before us, conclude that those interests—or more specifically, LinkedIn's interest in preventing hiQ from scraping those profiles—are significant enough to outweigh hiQ's interest in continuing its business, which depends on accessing, analyzing, and communicating information derived from public LinkedIn profiles._

Reasonable. If a platform helps you make information of an individual public, then why it should matter for the platform how the market uses that public information?

</comment><comment><USER23> On how this case relates to the CFAA:

We therefore conclude that hiQ has raised a serious question as to whether the reference to access "without authorization" limits the scope of the statutory coverage to computer information for which authorization or access permission, such as password authentication, is generally required. Put differently, the CFAA contemplates the existence of three kinds of computer information: (1) information for which access is open to the general public and permission is not required, (2) information for which authorization is required and has been given, and (3) information for which authorization is required but has not been given (or, in the case of the prohibition on exceeding authorized access, has not been given for the part of the system accessed).

Public LinkedIn profiles, available to anyone with an Internet connection, fall into the first category. With regard to such information, the "breaking and entering" analogue invoked so frequently during congressional consideration has no application, and the concept of "without authorization" is inapt.

</comment><comment><USER36> Volokh take is an interesting read [1]

I am curious how quickly most pages get put behind authorization. With the wording of this ruling you could pretty much go snap up any blog side (say like medium) and more. I wonder what kind of services would come out of that, having the data in a format it can be more easier parsed/analyzed?

so every ecommerce site is fair game? I assume most are already being scraped but I cannot imagine having to be in an environment where many of your connections are not people

[1] [https://reason.com/2019/09/09/scraping-a-public-website- does...](https://reason.com/2019/09/09/scraping-a-public-website-doesnt- violate-the-cfaa-ninth-circuit-mostly-holds/)

<comment><USER37> Hmm - I think a key in the ruling here was that LinkedIn maintains no copyright claim on these pages. Users on LinkedIn retain ownership of their profile data. Compare that to a blog and maybe copyright could come into play? Not a lawyer just thinking out loud...

</comment></comment><comment><USER38> RIP Aaron Swartz

</comment><comment><USER39> Even if LinkedIn loses and scrapers can no longer be blocked, they still just switched to putting all profiles behind an authwall, or at least it's very hard to not get an authwall. So could HiQ even carry on if they won anyway?

<comment><USER40> I'm not very familiar with neither LinkedIn nor HiQ, but what would be the problem with logging in before scraping?

<comment><USER17> The reason the pages are public to begin with is that Google will only scrape public pages for search indexing. LinkedIn wants to provide the pages ONLY to google, so they tried telling hiQ to stop scraping without any physical blockers (so as to not impede google's scraper).

If LinkedIn loses this case they (and others) might try to get Google to change their policy (either use auth or some whitelisted IP addresses or something).

</comment></comment></comment><comment><USER41> Best hope that hiQ prevails. The slope slips very fast without LinkedIn's defeat. If LinkedIn prevails, the "EULA" has the force of criminal law and not just an agreement that lacks the meeting of the minds.

</comment><comment><USER42> This is a weird case, as it turns the question of scraping on its head. Normally you'd think "am I allowed to scrape?", but instead the question becomes "am I allowed to prevent scraping?".

Anyways, I disagree with the court's judgment here. The users have consented that their data be used in accordance with LinkedIn's privacy policy. Even if it is publicly posted does not mean that the user has relinquished control over their personal information for another company to do with as they wish.

</comment><comment><USER43> how about websites using nonsense css-classes usually autogenerated through frameworks that make scrapping difficult ? I'm sure this ruling doesn't cover that case ? well globally I wish authorities would rule that public data should be published in computer accessible format e.g pdf's for humans and xblr's / csv for machines e.g in financial reports. lots of data in pdf's that costs a ton to mine. & tools like AWS Textract are hardly up to task.

</comment><comment><USER44> eBay had better lawyers than LinkedIn:

[https://casetext.com/case/ebay-v-bidders- edge](https://casetext.com/case/ebay-v-bidders-edge)

I'm glad this court ruled it wasn't a violation of CFAA. But using trespass to prevent it seems reasonable. A private business should be allowed to restrict certain kinds of use of its resources (servers, bandwidth, etc), especially if it is beyond typical use. But if the load is typical and doesn't actually harm LinkedIn, it seems less reasonable to restrict them. If LinkedIn doesn't want automated access to their data because it is too much of a load on their servers, then they should be required to ban ALL automated access, including Google's bots. Of course they want Google's bots because that sends them traffic.

Another reason I think it was stupid for LinkedIn to use CFAA is that it sets them up to _be_ a protected computer system, with protected information. If that is the case, it seems they could be liable for disclosing the information to someone a user didn't want, like a stalked. It's rather dumb: LI is claiming they host protected information, but it is only protected against someone that might compete with them.

<comment><USER45> > If LinkedIn doesn't want automated access to their data because it is too > much of a load on their servers, then they should be required to ban ALL > automated access, including Google's bots. Of course they want Google's bots > because that sends them traffic.

By that logic, I should have access to linked premium features for free. Why should linkedin give more data to people who pay?

</comment></comment><comment><USER46> Great, finally. Don't pretend the information is public and then block access to it.

It's either private and inaccessible, or it's free for all to use.

</comment><comment><USER47> Does this have implications for other scraping? (E.g. [https://techcrunch.com/2019/05/20/instagram-influencer- celeb...](https://techcrunch.com/2019/05/20/instagram-influencer-celebrity- accounts-scraped/))

<comment><USER48> Or this other case [https://gizmodo.com/instagram-boots-ad-partner-hyp3r-for- rep...](https://gizmodo.com/instagram-boots-ad-partner-hyp3r-for-reportedly- scrapin-1837051804)

</comment></comment><comment><USER49> LinkedIn is a public website? Every time I click from DDG it shows a login page and zero content.

</comment><comment><USER50> A choice quote:

> In recognizing that the CFAA is best understood as an anti-intrusion statute > and not as a "misappropriation statute," Nosal I, 676 F.3d at 857–58, we > rejected the contract-based interpretation of the CFAA's "without > authorization" provision adopted by some of our sister circuits. Compare > Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058, 1067 (9th Cir. 2016), > cert. denied, 138 S. Ct. 313 (2017) ("[A] violation of the terms of use of a > website—without more— cannot establish liability under the CFAA."); Nosal I, > 676 F.3d at 862 ("We remain unpersuaded by the decisions of our sister > circuits that interpret the CFAA broadly to cover violations of corporate > computer use restrictions or violations of a duty of loyalty."), with EF > Cultural Travel BV v. Explorica, Inc., 274 F.3d 577, 583–84 (1st Cir. 2001) > (holding that violations of a confidentiality agreement or other contractual > restraints could give rise to a claim for unauthorized access under the > CFAA); United States v. Rodriguez, 628 F.3d 1258, 1263 (11th Cir. 2010) > (holding that a defendant "exceeds authorized access" when violating > policies governing authorized use of databases).

And:

> As one prominent commentator has put it, "an authentication requirement, > such as a password gate, is needed to create the necessary barrier that > divides open spaces from closed spaces on the Web." Orin S. Kerr, Norms of > Computer Trespass, 116 Colum. L. Rev. 1143, 1161 (2016). Moreover, elsewhere > in the statute, password fraud is cited as a means by which a computer may > be accessed without authorization, see 18 U.S.C. § 1030(a)(6),12 bolstering > the idea that authorization is only required for password-protected sites or > sites that otherwise prevent the general public from viewing the > information.

My layman's (IANAL) interpretation of preliminary injunctions are that the case is far from over, and this could be overturned at any time as more deliberation is done (assuming LinkedIn wants to keep throwing money at that relatively slim possibility). But now this research has been done, and future courts have the ability to look to these references and lines of reasoning all in one place.

EDIT: [https://twitter.com/OrinKerr/status/1171116153948626944?ref_...](https://twitter.com/OrinKerr/status/1171116153948626944?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet) is an analysis by the law professor cited above:

> BIG NEWS: 9th Circuit holds that scraping a public website likely does not > violate the CFAA, even after website owner prohibits with a cease-and-desist > letter; language strongly suggests CFAA only applies to bypassing > authentication. Blog post up soon. > [http://cdn.ca9.uscourts.gov/datastore/opinions/2019/09/09/17...](http://cdn.ca9.uscourts.gov/datastore/opinions/2019/09/09/17-16783.pdf) > #N

<comment><USER51> The post is now here:

[https://reason.com/2019/09/09/scraping-a-public-website- does...](https://reason.com/2019/09/09/scraping-a-public-website-doesnt- violate-the-cfaa-ninth-circuit-mostly-holds/)

</comment></comment><comment><USER52> I got 80,000 recipes from allrecipes.com... glad to know it was legal

</comment><comment><USER53> Sweet, I scraped a bit of data and have been holding off on putting it on to my web app.

I think I'll transform the data a bit before putting it up there.

</comment><comment><USER54> What if hiQ were to then go and sell the information that's been scraped from public profiles? Would this be considered illegal?

<comment><USER55> I would assume the data would still be covered by copyright meaning they could use that data and maybe create and sell derivative works, but not just scrape and publish.

<comment><USER56> Pictures and such are covered by copyright, but mere facts are not (at least in the US): [https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._R...](https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co).

<comment><USER57> Collections of facts are copyrightable. Which is why you can go out and make a map of your local area but you may not copy the data from google maps. You may end up with the exact same data and that is ok because you both copied the same facts but if there is a mistake on google maps (Perhaps placed as a trap) then you can be caught if your map has the same mistake.

<comment><USER56> Only the _creative aspects_ of those collections of facts are copyrightable. You can definitively copy from Google Maps, just like Feist could copy from Rural; what you can't copy are the aspects of the maps that require creativity.

As for trap streets, they don't help as much as you think; as we've seen, simply showing that copying occurred is not enough. There was a theory that the trap streets - since they were invented, not facts - could themselves be copyrighted, but in _Alexandria Drafting Co. v. Amsterdam_ , the courts said that copying a few trap streets among a bunch of facts was too minimal to be considered infringement.

</comment></comment></comment></comment></comment><comment><USER58> I have never heard of a 'cause-and-desist' letter before. Odd spelling mistake for such a document.

</comment><comment><USER59> Congrats Darren! Can't wait for your next one to come out of stealth mode.

</comment><comment><USER60> Flagged for misleading title.

<comment><USER4> Would you mind suggesting a more accurate title?

<comment><USER50> 9th Circuit issues injunction preventing LinkedIn from blocking hiQ's scraping of public pages

(IANAL but this seems like a reasonable summary of the first paragraph of the document.)

</comment></comment></comment><comment><USER61> This is a great opinion. But the 9th circuit is arguably still ~atypical.

</comment><comment><USER62> Of course it isn't, it's known as implicit authorisation.

</comment><comment><USER63> In tangentially related news, Reid Hoffman, LinkedIn co-founder, spent some time last week defending Ito's connections to pedophile Epstein.

[https://twitter.com/anandwrites/status/1169952673988300800](https://twitter.com/anandwrites/status/1169952673988300800)</comment>


Instagram comes to Windows Phone Store without in-app image capture or video - <AUTHOR> http://www.engadget.com/2013/11/20/instagram-waze-windows-phone/ <comment><AUTHOR> "Still, the addition of official support by Instagram is a good indicator of health for Windows Phone."

What? It took 3 years for them to develop a camera app that can't take photos and this is a good indication of health?</comment>


Microsoft Paint in JavaScript - <AUTHOR> https://github.com/1j01/jspaint <comment><USER2> The fill tool doesn't appear to work properly</comment>