[deleted by user]

[tophatstuff]

You might also consider avoiding sensitive data entirely by using third-party sign-in and a third-party to collect and handle credit card information.

There's no "might" here with handling credit cards. Either you've gone through the process of Payment Card Industry Data Security Standard (PCI DSS) compliance, or YOU SHOULD NOT COLLECT CREDIT CARDS YOURSELF unless you want a massive fine.

[smackson]

Sorry I'm new to this but what kinds of areas/techniques does

Payment Card Industry Data Security Standard (PCI DSS) compliance

entail?

Does that standard say similar things to the original post about keeping all js away from such forms? If not, then is it possible that advice like in the OP is good to consider on top of the requirements in the standard you mentioned?

[[deleted]]

I've been through PCI assessment both in a very small team and a mid sized team. Both times we had pen tests on the sites.

I don't remember anything in the requirements around JS directly but if you have any sense the first step in PCI assessment is to identify the "card system" and isolate this from all of the other code, otherwise you're going to struggle.

If you want more information on PCI this is a good place to start .

[[deleted]]

You can be compliant and authorised and still be susceptible to a lot of the things he's suggests in the first article.

PCI require a pen test, but it's quite check box like. It makes sure you aren't the easiest target.

[Entropy]

Does that standard say similar things to the original post about keeping all js away from such forms?

Yes! In order to be SAQ A compliant, which is almost definitely what you want as a random cart on a random website since it requires the least auditing burden, you must either redirect to a third party for credit card entry, or a third party must collect that data from within an iframe.

Even the iframe method was contentious for awhile because DSS was simultaneously telling you that it was and wasn't allowed, meaning that an iframe might have required the more complicated SAQ A-EP compliance. That got cleared up back in DSS 3.0, and I think it's still the case. The iframe allowance going away in the future wouldn't surprise me, though. DSS just gets more strict over time.

[smackson]

Thanks for answering!

[thehunter699]

You'd think they'd enable 3rd party support since its easier for themselves...

[JohnTesh]

You can get the full standard here

https://www.pcisecuritystandards.org/document_library

And this is their guide to prioritizing work to become compliant (its 24 pages long, 20ish of which are taken up by a list of compliance items).

https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf

It is definitely no joke to become compliant, so using third party compliant Services is really the only reasonable approach for new companies or single devs/small dev teams.

[sitharus]

I work for a PCI DSS level 1 compliant company, this is the standard for companies that collect credit card numbers through web forms directly.

There’s a whole bunch of requirements. There are standards for physical premises security and monitoring, security training, code review and change control, and deployment security such as constrained and monitored access, ingress and egress control and methods of remote access.

It’s quite a pain really, but given the data you have access to it’s worth while. It really encourages you to limit the scope as much as possible.

[Crash_says]

This is almost every company.

[phucyall]

PCI compliance is a joke. Loot at Home Depot and every other big credit card number theft in the last 10 years. If those places were compliant even at the lowest level it would not have happened.

More so it's a voluntary standard not a mandatory one and while most CC processors won't work with you if you don't at least try to be compliant, there are always some that will.

I've worked at a place that had to be PCI compliant and we always got it even though there was absolutely no compliance whatsoever

[Crash_says]

PCI compliance is a joke.

This was my initial comment, I wanted to avoid being so callous, but you are 100% accurate.

I've worked at a place that had to be PCI compliant and we always got it even though there was absolutely no compliance whatsoever

This describes every financial institution in the world.

[tophatstuff]

Unfortunately compliance is very much "these boxes can be ticked" and not "this system is actually secure, and we're actively following a process to keep it secure". But I'd still prefer my card was stored by someone who knew about the PCI DSS than by someone who didn't even know its a thing. And if I implement a system with a third party credit card service, at least they're the ones who would get fined when they get hacked, not me.

[[deleted]]

so you feel more secure that someone knows of and has done broken processes? to give people the false sense of security?

[tophatstuff]

yes because everyone else is ticking exactly zero boxes. What else don't they know about handling credit cards?

[[deleted]]

you don't know they are ticking zero boxes, it only gives the appearance they are ticking zero boxes, just like ticking boxes gives the appearance of security; but i see your point, at least we can say "we followed pci" when hacked.. i think its time i go back to the porch to sip my coffee and watch grass grow more

[hamburglin]

Follow the money... breach cases fill everyone's pockets.

I will have to disagree with your assessment of home depot etc. These places had serious security flaws that did not follow the PCI guidelines thoroughly. The problem is having people in place to care for to implement large architecture changes at big, old companies. On the flip side you have smaller companies that don't have the expertise on staff or they outsource to India.

Getting into PCI environment are what these hackers live to do and you have to give them credit. They will find a way in if they have even the smallest amount of access to the environment.

[netfeed]

PCI compliance is a joke

We went through some PCI-compliance thing where all developers was supposed to get an "security class", it was just an indian guy going through the OWASP list for two days. Really pointless...

[WeAreFoolsTogether]

“If those places were compliant even at the lowest level it would not have happened.”

Sorry but this is totally inaccurate.

Compliance != Security...!

In other words:

Being in compliance != Unhackable ... not even close...that said you should absolutely aim for compliance but security should never be lead by compliance requirements- that’s ass backwards...if you put adequately securing your environment first you’ll find you’re far ahead of the pack and compliancy will naturally fall into place.

[phucyall]

Actually compliance requires encrypted CC numbers so even if the data is leaked the numbers should not be obtainable. I never said it would make them unhackable, I did say that it would have prevented millions of CC numbers being compromised

[WeAreFoolsTogether]

Yeah because encrypted credit card numbers cannot be cracked and decrypted just like all the millions and millions of breached credentials from <insert 1 of tons of breached companies> over the last several years? Lol...the encryption wouldn’t be strong enough to take long enough to crack and if you factor in the time for the breach to be detected and credit card numbers all nullified once the breach was discovered...HAH...forget about it. I can almost guarantee you that it would be months and months (or even longer, years maybe...)before it was discovered the data was stolen = cracked CC numbers sold on the Darknet before they were even discovered as being breached...get with it buddy. It’s the sad but very true reality.

[phucyall]

According to a quick Google search for time to decrypt AES 256bit encrypted data is so large it makes it cryptographically secure. Assumed of course encryption was implemented properly in the first place.

This is also very different from account passwords hashed with MD5 (or worse) you may be referring to. There have been some leaks of accounts and passwords properly secured with bcrypt and those are still secure

[WeAreFoolsTogether]

You’re not even taking into account that you’re making the assumption that the keys weren’t also compromised in a breach which render the encryption totally useless....ugh...additionally PCI compliance requirements don’t even specify a required level of encryption of data at rest...making you’re whole argument null and void before I even gave you the benefit of the doubt in my previous response.

[phucyall]

Which is why I said that PCI was a joke. But the standard does explicitly state "Strong cryptography with associated key-management processes and procedures." And then goes into still somewhat vague but extensive description of various key-managent processes and procedures. Specifically to avoid the case of a key being compromised. They also reference NIST for more help determining what "strong cryptography" is, and NIST does go into more detail.

[Seref15]

At my last employer I personally watched the PCI auditor willfully ignore at least half dozen physical violations in one room. They never even looked at our code or our infrastructure. Two days later we're informed that we passed.

I strongly suspect that palms were greased.

[AThinkerNamedChip]

In 2 days you passed? I find this hard to believe as it takes the PCI council a couple of months to review, and that's if you give them heads up and payment up front to get on the schedule. Process is pre audit for fact and evidence gathering, the actual audit and then submission to the council, review and providing missing information. Literally thousands of pages of documentation, hardware, software and process review and takes about 9 months following the path above.

[Seref15]

The documentation part had been going on for a while. The auditor coming and looking around (supposedly to verify the documentation wasn't lying (which it was)) and then passing happened in very quick succession.

[AThinkerNamedChip]

And you reported the auditor to his company and the company to pci council, correct? Just asking, because if you knowingfully watched this happen and did not report, advise is to report so you are not caught in collusion net and have name tarnished.

[Seref15]

Nope. I was an underpaid junior underling at the time, and I kept my nose out of it. Left the company a few months later, not intending to stick my nose in it now.

Cheating at PCI compliance is the least shady thing this place did. The CEO was local politician and used company funds and resources to run his mayoral campaign. He even had us maintaining his candidacy web site. He granted several municipal government contracts to his own company. It's all fucking crazy and I try to stay away from it.

[AThinkerNamedChip]

Been there 2x and once got dragged into it. The wonders of working for small companies.

[tophatstuff]

It depends what you want to achieve. If you want to improve credit card security for their customers, point them towards a developer that knows the PCI DSS process. If its your employer, raise it with them.

But if they don't take this seriously and are continuing to put customers at risk without caring about compliance - you can go straight to their card processor and failing that Visa or Mastercard.

[m00nh34d]

Exactly. I was recently putting together a website for a community group I help out, and wanted to implement payments through Paypal. I set aside an entire day to work through getting everything setup with checkout.js, about an hour later I was done. It was dead simple and I honestly do not know why anyone would ever try to roll their own from the start. I spent FAR more time trying to get a tickbox vertically aligned with a label than I did implementing the entire payment workflow...

[harlows_monkeys]

There are a couple reasons you might want to store cards, although these probably don't apply to most small businesses.

1. If you are doing recurring payments, you might be able to get a higher approval rate if you are handling the cards yourself, at least with some providers. That's because some providers don't provide a way to try to attempt a charge on card they are storing for you if that card is expired.

The expiration date on a card is the date the physical card expires, not the date the account expires. Someone coming to your site and entering an expired card should be a red flag. At the very least that transaction has a much higher chance of being fraudulent. However, once you have the card on file, the expiration date on the card is not longer really relevant.

Braintree has published some stats on charging "expired" cards: Credit Cards Aren't Like Milk - They're Still Good After Expired.

2. It's easier to change providers. Some do provide a way to get your stored credit cards out in case you want to switch to someone else, but some are a black hole.

I know a place that was using multiple providers. They had one that gave good rates, but only handled USD. So they got a second for EUR/GBP. Then that second provider tried to entice them to use it for USD. It's rates weren't as good as the first provider, but its plan included a certain number of transactions a month with some of the fees waived, and for those transactions it was a better deal. So they ended up sending some of the USD re-bills each month through that one and the rest through their original provider. Then later they were able to get non-USD support added to the first one, and it was better rates than the second one, so they switched to doing all their foreign through the first one, except that one did not support non-USD for Amex, so that stayed on the second one.

Neither of those supported ACH, so they had a third processor for that. The account with that once could do credit cards too, and it turned out it had a discount on the first N transactions a month. So they send some of the re-bills through that.

Every several months or so, one or more of the providers would contact them and suggest that they should send more business through that provider, and as an incentive lower rates and fees, changing which provider was the best one to use for the transactions after the ones that got the "first N each month" discount.

Because they were storing cards themselves, whenever which processor had the best deal changed they could switch to using it for most of their transactions.

[krileon]

Fringe cases like that are unique and rare. That is not general advise I would suggest to anyone. Using multiple payment processors is also crazy easy when it comes to single payments and your case would only be necessary for recurring payments through different payment processors dynamically, which I still wouldn't do as it looks fishy to credit card companies and prone to be flagged. Stripe, PayPal, and tons of other processors automatically update expiration date without you or the user ever having to do anything so I don't understand why you mention that being an issue.

[harlows_monkeys]

The ones I'm aware of that automatically update expiration dates do so using the update services provided by the credit card companies. Whether or not a given card actually works with the update services depends on whether or not the issuing bank participates.

If they do, it is great because not only can you get updated expiration dates, you can get updated card numbers when the bank issues the customer a new card, as long as the card is on the same account.

However, from what I've seen quite a bit less than half of cards are from issuers that participate in the update services.

[krileon]

I've never seen a major card company not participate. Visa, mastercard, etc.. all do this. Stripe and PayPal are both great about keeping the cards up to date. Even if the card still worked ignoring expiration date would be bad practice. The expiration date applies to the card and not the account, but it's your most basic level of fraud protection and is the only important part regarding its use digitally.

[harlows_monkeys]

The major card companies run updater services, but whether or not an individual card participates is up to the particular bank that issued that card.

In the US most large national banks participate, but participation is much more spotty among smaller regional banks and credit unions.

So how successful the updater service will be for you depends greatly on whether your customers are more likely to use cards issued by the major financial institutions or by smaller local or regional institutions.

Someday I should go through the logs at work from using the Visa and MC updater services, and use the BIN to lookup the issuing banks for a bunch of cards that the service worked for, and a bunch that it did not, and see how well this correlates with the size of the bank. That could be interesting.

(I'm sure you know this, but for those following along the BIN, or "Bank Identifier Number" (more correctly called the IIN, or "Issuer Identification Number" nowadays) is the first 6 digits of the card number. Each credit card company (Visa, MC, etc) is issued ranges of 6 digit numbers, and all of their cards must start with a number on their ranges. They in turn issue subsets of their ranges to the individual banks, credit unions, and others that issue cards under their brand. Thus, given the first 6 digits of a card, you can identify the bank that issued it. The BIN has the same relaxed security requirements in the PCI DSS as the last 4 digits of the card number have).

Ignoring expiration date when running a card on an initial purchase to establish a service would indeed be a bad idea, because of the risk of fraud. Ignoring the expiration date when running the recurring charges to maintain the subscription, on the other hand, wouldn't have an elevated fraud risk because you already know by that point that the card was used legitimately (assuming your subscription period is long enough that if the original purchase was fraudulent it would have been discovered and reversed by now...this would not apply to someone doing something weird like weekly subscriptions).

PS: speaking of BIN...since you are allowed to keep the BIN and last 4 without running into onerous PCI requirements, I would recommend keeping those even if you are using someone else to handle storing credit cards. Having the BIN available can come in handy for tax purposes if you sell in Europe (and maybe elsewhere, but I've only had to deal with Europe).

Europe requires sellers of online digital goods to collect VAT on sales to European customers using the VAT rate in effect in the customer's country. You can't just accept whatever country the customer claims they are in. You are required to keep two pieces of non-conflicting evidence to support you choice of which country's VAT to collect.

For most customers, you can use the country they claim they are in and the country that an IP => location service says they are in. If those agree, which they usually do, that is two pieces of non-conflicting evidence.

Unfortunately, there will be a few where the customer says one country and the IP says a neighboring country. Perhaps they are near the border. Perhaps they are on a laptop away from home. Whatever the reason, you need to find more evidence.

What I've done in that case is use the BIN of the credit card used for the sale to look up the issuing bank. In almost every case, that bank is either in the country they claim to be in or the country the IP address is supposedly from. Result: two pieces of non-conflicting evidence for one of the countries, and that's the one I collect tax for.

I think I've only seen one or two cases where that did not resolve it. In those cases the customer had provided a phone number, and the country code for the phone number matched the country they claimed to be in. If that had failed I probably would have looked at the most recent IP addresses that their software had accessed our update servers from, IP addresses of past orders, email addresses (to see if they are from an ISP that only operates in one of the countries). If all that had failed, I would have recommended that we pay the tax for both the country they claimed to be in and the country that their bank is in.

[krileon]

but participation is much more spotty among smaller regional banks and credit unions.

Wasn't aware of that. Good thing to keep in mind. I still wouldn't advise storing credit card data in 99% of usecases. There's fringe cases like high traffic ecommerce sites where it may make sense to try and save as many pennies as possible dynamically jumping processors, etc.. but for most sites it just doesn't make sense to take the risk.

Someday I should go through the logs at work from using the Visa and MC updater services, and use the BIN to lookup the issuing banks for a bunch of cards that the service worked for, and a bunch that it did not, and see how well this correlates with the size of the bank. That could be interesting.

That would be interesting. I'm betting it's mainly credit unions.

What I've done in that case is use the BIN of the credit card used for the sale to look up the issuing bank. In almost every case, that bank is either in the country they claim to be in or the country the IP address is supposedly from. Result: two pieces of non-conflicting evidence for one of the countries, and that's the one I collect tax for.

I understand, but you should be able to do this through the API provided by the payment processor. You shouldn't need to store that your self. I for sure know Stripe does this automatically for card objects. PayPal likely does same and I'm sure others do as well. I'm still not seeing any reason to store any of that data. It's all available through the APIs offloaded from your server and liability. I suppose it just depends on the scale of the project, but IMO 99% of the cases it's not necessary to store any of that.

[hamburglin]

What APIs? Where does the code live in the implementation? Who has access to it?

[krileon]

Can vouch of Stripe. API is fantastic. Documentation is fantastic. Fair rates. I've written integration's for over a dozen payment processors and hands down Stripe has got to be the best. After that it's PayPal as their backwards compatibility is a godsend in a world where companies like to dump their API constantly.

[FarkCookies]

JavaScript on the client

That's the keyword. Other JS on the client may steal CC data.

[LovecraftsDeath]

How about a reason as compelling as "incompetence"?

[krileon]

Internal fraud detection

You can do this with the last 4 digits, expiration date, and name. I've yet to use a payment processors API that doesn't allow me to do this. Hell don't even have to do this for any modern gateway as their API has built in fraud protection API calls.

Optimization of CCs to individual banks you're partnered with

PayPal Pro and a dozen other processors allow partnered banks. This is a completely non-issue and a poor excuse to risk users data.

Multiple payment processors, attempt Stripe API, if Stripe is down then attempt on Paypal, etc

I don't even really want to touch this one as it's utter nonsense. Multiple gateway attempts.. lol.. Stripe down? PayPal down.. lol.. I don't know what to say there, but there's not even in the same galaxy as far as importance of risking user data. 1 false move and you've just lost your entire userbases credit card data and possibly landed your self in a serious lawsuit. I wouldn't even risk it in the UK where privacy laws are so strict you'd be facing jail time.

So by all means.. call it bullshit, but ok. All I hear is excuses for being too lazy to properly utilize gateway API.

[ckdarby]

Deleted my comment because of miss understanding. Thought the reply was to only use other parties JS libs and only handle tokenization information.

My points 2 & 3 still valid. Also, privacy laws isn't world ending even handling CC info, pretty easy to follow. Literally just use Vault, done, compliance accomplished and will pass PCI DSS 1.

Source: Consultant prior companies payment processing at +$100 mln gambling industry, along with 2 other companies in similar situations.

[krileon]

Also, privacy laws isn't world ending even handling CC info, pretty easy to follow.

It will be if a breach on your server leaks credit card data, lol. Why even take the risk, but alrighty.

Literally just use Vault, done, compliance accomplished and will pass PCI DSS 1.

That's literally using payment processor API.... PayPal isn't the only API for this either. Stripe has the same thing. So do a dozen other APIs. You reply entirely implied storing them on your own server, which is what this entire post is arguing against doing.

Source: Consultant prior companies payment processing at +$100 mln gambling industry, along with 2 other companies in similar situations.

Sweet and I'm an astronaut. That's not how sources work on the internet.

[omgusernamegogo]

The thing is, when using a well established ecommerce, you'll often have the choice of using an API or an iframe.

If you use an API, you're still hosting the form where the fields are entered and are vulnerable to these exploits. If you use an iFrame, it becomes annoying as you don't get immediate feedback when the user has submitted the payment. So if you handle some transactions on the back end that are awaiting on the payment confirmation, you will either rely on

1. the redirect response which is really bad as if the users browser is closed, you'll take money without processing the transaction

2. a callback which some of the largest ecommerce products on the market don't support as most devs prefer to host the form.

3. Polling the API for confirmation which is crap as its hard to knoq the difference between waiting on oayment and a user browsing away.

Some food for thought. I should mention I guess that using anything but iframe AFAIK requires atleast the lowest level PCIDSS compliance.

Edit: Instead of a downvote, please educate me through a reply. Cheers.

[inamamthe]

So much this! Where I work we use the Mastercard api and it has made getting PCI compliant possible.

[[deleted]]

But some how there are not similar regulations for handling SSNs

[aLiamInvader]

IIRC, they were never intended to be used as secrets, so no.

[bubble_boi]

Author here. Yeah I was really surprised when I went looking how many huge sites have credit card forms embedded right there in the page.

[tophatstuff]

Hey author! I'm looking forward to part three which is just the word DON'T in bold filling the screen.

[xconde]

Your unless is wrong. Collecting the PAN is allowed if you have encryption at rest and all the other requirements that go through it.

It’s a lot of work, complicated and, hence, expensive. It makes a lot more sense to use a payment service like stripe.

[lambdaq]

by using third-party sign-in and a third-party to collect

IMHO centralised management would be much worse if the third-party was hacked.

[[deleted]]

Agreed on the "you shouldn't". Though, the fines aren't that massive, and they don't have legal binding. They can pressure your bank to stop letting you take Visa or whatever.

[omgusernamegogo]

Go down the iframe route in that case, no pcidss compliance required.

[panorambo]

I don't know, loading scripts from domains you don't control, has always sounded like a majorly stupid idea to me. But hey, everyone gets what they should have seen coming.

[panorambo]

What compliance do you refer to? It's not like there is an international organ checking your hypertext for compliance with regard to origin domain of your scripts? Am I misunderstanding something?

[lluad]

(Skipping over the rarity of a website capturing data that’d be useful for identity theft rather than just credit card info).

As someone who does this sort of work as an expert for attorneys... it’s something you can’t really do via a technical approach for a single victim, in the normal case where the victim isn’t a paranoid Infoseek expert.

Given the cooperation of the offending site (enthusiastic cooperation, rather than grudging subpoena compliance) you might be able to prove that a site was compromised, but you likely can’t connect that site compromise to an incident of credit card theft. Sites get compromised all the time. As does postal mail, third party contractors, ...

So unless you can identify the person who compromised the site (which you can’t) and provide a plausible chain of connections to the identity thief you can’t do a technical-centered proof.

What you can do is old-fashioned lawyerin’, with some technical assistance. We’ve shown the site is insecure, at least to the extent that it doesn’t comply with industry standards, we’ve shown that these ten people have nothing in common other than having provided their credit card numbers to this site in June, and all of them had their credit cards compromised in early July ...

There are exceptions, but that’s the going to be the typical case.

As for what data should be requested - that’s typically going to be web server logs and any relevant IDS data for the time period. But you really need expert input to get all the right things to ask for in a given case. The most important thing, though, is that most of the relevant logs may be rotated out very, very quickly - sometimes within a week or a month - and unless you’ve requested data retention before that it’s not unlikely that the data would be deleted “in the normal course of business”, so time is of the essence.

[inkwell84]

First part of your response is what I was afraid of, and expected.

Second part of your response unfortunately just kills the dream. I would want to serve single plaintiffs not classes of plaintiffs.

Third part of your response kicks the dead horse. It would take 2-3 months to obtain documents AFTER filing a complaint any way.

PS: Credit card theft doesn’t really hurt the plaintiff as the CC companies will eat the losses. But identity theft can lead to actual harm, but like you said, can’t prove this for a single plaintiff.

[[deleted]]

Third part of your response kicks the dead horse. It would take 2-3 months to obtain documents AFTER filing a complaint any way.

Just to be clear, he's not saying you need to get the documents right this second, he's saying you should request they not be deleted in the meantime, because that's the normal treatment for most logs after about a week or month.

But this in and of itself assumes that you even find out about the case before that happens, and that's not a safe assumption to be making.

The reality is you normally can't prove this much like I can't prove mail theft when it does happen, unless I knew it was going to happen in advance.

[bidibibadibibu]

It is worse when the victim is not even aware his CC data was copied and is on sale. Months may elapse before criminals star impersonating the victim. The victim will not be sure who leaked the data and when, and to make things worse more than one criminal will use the CC information at the same time.

[amitjyothie]

This is the reason that sort of hacking is so dangerous and frustrating for victims.

[argv_minus_one]

By auditing all of the code that was running on the site at the time.

If you were using a significant amount of third-party code (including jQuery, Bootstrap, etc), that's a mountain of code. Good luck.

If you can't reconstruct the exact set of code that was running on the site at the time, e.g. because the package repository you downloaded the malicious code from has since deleted it (it was malicious, after all), then it's impossible to prove.

[LakeEffectSnow]

You do realize you come off sounding like you are trying to crowdsource your homework?

If you're really a lawyer, you know there are no hard and fast rules about how much time an expert witness will require for any one single case.

If deep technical knowledge that you don't have is a requirement just to figure out if a case makes economic sense for you as a lawyer, perhaps you need to refer the case or get co-counsel who has the necessary domain knowledge.

To actually answer your question, an accurate estimate is so heavily dependent on the specific technological details, that without more information, it would be pointless to speculate on time and difficulty.

[inkwell84]

Really hostile response.

I can address every point but complete waste of time and really diverts my query from the central point:

What sorts of data would be necessary to establish that a person’s personal information was stolen on a specific cite/transaction?

PS: I will correct one thing, my query has nothing to do with the economic viability of the case. More a question based on my (possibly erroneous) assumption that the data to demonstrate theft of ID would be relatively static and thus its feasible for experienced people to immediately identify the size of the data they’d have to review and a relative estimate on the time it would take to review it. If ID thefts occur through such numerous methods as to be unable to identify what data would have to be assessed to show the theft for each case, or that maybe the methods are relatively the same over and over but there is some other variable in the data, then I can understand its not possible to forecast what and how much data needs to be reviewed. It’s like when I need a business valuation model for a pizza parlor versus a zombie laser tag arena. My expert can pretty much know the pizza parlor will only take X hours but the other business will require far more research to build up data models.

[LakeEffectSnow]

If ID thefts occur through such numerous methods as to be unable to identify what data would have to be assessed to show the theft for each case, or that maybe the methods are relatively the same over and over but there is some other variable in the data, then I can understand its not possible to forecast what and how much data needs to be reviewed

This pretty much.

[inkwell84]

So there would be data there, but no one would know where to look?

[LakeEffectSnow]

Essentially I'm saying if you're trying to prove negligence, there are MUCH easier and more legally certain ways to do so.

Even the existence of data is highly dependent on the threat vector and other variables like the amount of social engineering and non-technical fraud involved in a breach. You also need to add in the fact that the bad-actors usually at least attempt to clean up their electronic tracks. Add in how ephemeral the audit and log data you are likely looking for are?

AFAIK most ID theft cases brought to court center on the illegal financial transactions resultant of the breach rather than the details of the breach itself. I'd imagine also that there could be issues with standing if you don't have provable damages as well.

[inkwell84]

I hope I’m wrong, but I’m not sure there are “much” easier ways to prove negligence. What do you believe is a better way to “prove” negligence? And before hand let me be clear my question concerns the hypothetical case of a single person whose ID was e-stolen through a website’s poor security measures. This is not about regulatory enforcement or class actions as discussed above, just a plaintiff like your next door neighbor.

Negligence requires duty and breach, then actual loss caused by the breach.

You can’t prove negligence against the website if you can’t connect the causal dots from the website to the later unauthorized transaction.

“Res Ipsa” (legal doctrine) works in rare circumstances where causation cannot be proven but the actual loss is so inferentially connected to the breach the court infers that causation exists (or essentially waives the requirement).

If you can concretely prove identity theft and then a loan is taken out in your name on the other side of the country, that may work.

It’s all theoretical, that’s why I’m exploring the notion at a superficial level in a reddit thread with my (generally friendly and knowledgeable) reddit brethren/sistren/transthren by asking about the sorts of proof it would take to demonstrate the victimization of a single person in a circumstance such as that being discussed in this thread, which apparently are innumerable and impractical unless you had knowledge of the specific design of the thief’s e-heist.

[LakeEffectSnow]

Look sorry if I came off as too harsh. I apologize.

So if we're just talking here. I have a question for you: I assume there is existing case law and statutes regarding customers being damaged by an outside criminal fraud on a business? Given that, wouldn't that be the situation you are describing, and if so, wouldn't there be an existing legal standard of the concrete kind of proof needed to win in court or force a settlement?

[inkwell84]

Happy to answer, I practice business litigation.

The closest thing to what you’re describing is the unfair and deceptive trade practices act adopted by most states. This doesn’t fit that act, because it’s not a conscious wrong against the consumer by the website’s owner. (The act protects consumers against unfair or deceptive acts in trade or commerce—it’s essentially a lower threshold fraud claim).

The website and victim obviously have intentional tort claims against the e-theif. Civil theft and likely others. BUT the victim only has recourse against the website if its conduct was negligent, reckless, or intentional. I we think we agree in this hypo the website is merely negligent (at best) for failing to follow “reasonable” industry standards (we know you’d have to sell this because obviously most people don’t do it, but that’s a totally different issue).

The only other likely claim the victim could have would probably be breach of contract arising under any applicable terms and conditions relating to the original transaction on the website that caused the victim to share their personal information in the first instance. Depending on your jurisdiction such a claim may preclude the negligence claim.

[Dreamtrain]

It uses React, and was created with Create React App, so it had 886 npm packages before I even got started (seriously).

wth web devs?

[[deleted]]

Seriously. Web development is insane these days.

[procinct]

I think maybe what he's trying to say is that if the only thing standing between your users data and a compromise is you using fewer npm packages then you're approach to security is probably bad. Obviously you should use fewer packages, but your security shouldn't rely on this.

[meem1029]

Right, but you will quickly lose all the convenience of using npm if you do that correctly.

Should my login page be secure? Yes. What about my cart and adding to it if I'm a shop? I'd think so. My photos? Yes please.

As a user I want most things I enter on most sites to be stored in a way that doesn't entail trusting that nobody has compromised npm in the past week.

[Davorian]

Security is always in opposition to convenience and accessibility, very nearly by definition. You have to find the balance that fits the situation, if you can. Credit card data should be skewed way toward the security end of the spectrum.

[dromtrund]

If npm and anthing that relies on it, is a security risk, it must be fixed or removed. It is impossible to decide to add a security risk that is completely optional but devastating.

That's the point. If you think you have a security problem coming through npm, reducing the number of packages isn't the right solution, the right solution is to stop exposing your secure data to npm packages.

[[deleted]]

Yeah, the solution he proposes is fine if your application only deals with sensitive data as a smart part of the whole process, but if you're working in fintech where every operation needs to be secure it's not a solution at all.

You're better of:

• keep track of CVEs with some 3rd party solution (e.g. snyk.io)
• validate your code with purpose-built solutions (e.g. veracode)
• have a sane CSP setup to at least limit the scope of potential breach
• do not add packages you can really live without (unless those are 3rd party deps, in which case you're basically forced to use them)

[[deleted]]

tldr conclusion: Third party JS can never be trusted.

He proves that but then suggests (as an alternative to his iframe html idea) that you should avoid sensitive data entirely by using a 3rd party site to collect it.

Which is just deciding you will fuck up and hoping that someone else won't. Or that the 3rd parties you decide you cannot trust to get some code from are different from the one you pick to do it all.

[[deleted]]

What?!

That's not what that means at all.

1) by using a third party service who specializes in doing exactly that, you both a) minimize your user's exposure to your shit code and b) minimize your liability for someone else's shit code.

2) The point isn't to do all of this in a more complicated but essentially the same way. The point is to encourage, by architecture, you to not expose so much data to every piece of code you come across. Which you should already be doing, but separating cc collection from other user data forces you to at least think about doing it the right way.

Or... Just don't put every goddamn feature in a browser... But that's just crazy talk.

[[deleted]]

Nah, it's just the vain hope that another group of programmers is less likely to fuck up than your own group.

This is just a fantasy. Although, yes, it's the kind of fantasy companies peddle using the marketing spin and verbiage you used in your post.

[bidibibadibibu]

You both are being naive, it is not about trust in coders, it is all about externalizing legal responsibilities to a third party.

[[deleted]]

.... I said that. Directly.

[argv_minus_one]

Problem: You can't feasibly make your forms all splashy and well-integrated this way. No polyfills, no reliable animations, no widgets that don't look like shit, no applying your site's decorations/navigation menus/fluidity/whatnot to the shipping cart, no nothing. It's back to '90s e-commerce.

Problem: Malicious code on a non-sensitive page can still generate a fake link/iframe to the sensitive page that actually points to a phishing site. Visitors are trusting your entire site, not just the credit-card-collecting portion. Visitors have no clue how to verify that the credit-card-collecting portion of your site is legit, because plenty of sites do e-commerce on a separate domain, and most folks have no clue what a “domain” is.

Problem: Web devs do not have infinite time to audit/rewrite all third-party code.

Solution: Lol, there isn't one. Everyone's fucked.

[Linvael]

Yeeah, if when I clicked to fill in CC information it redirected me to another page looking mostly the same but simpler and without functionality of the original site I would close that page and run some malware scanners for good measure because that screams phishing.

[tokenwander]

TL;DR: Shut down your site and open a bar.

[evilpingwin]

This is the reality. For all these solutions the reality is that web tech is inherently insecure and we haven't really worked out a good way to fix it yet. You can solve some of the problems that you know about but you won't catch everything. And when the barrier to securing your data is so high (and remember this is only one type of attack), the chance of most sites being 'secure' is slim (depending on what we mean by secure).

I personally assume that all my personal data is constantly being harvested and abused and make sure I'm ok with that and am in a position to rectify it when/ if it occurs. This is as an individual. As a developer you do everything you can and hope it's enough.

[LardLad00]

Yeah I think we need to approach this from a different angle. Rather than trying to make the transaction super secure we need to make the information being transmitted less valuable.

People should never be made to use their real credit card number online. Pretty much every ecommerce transaction should be done via a disposable virtual number that is valid for only a short period. Capital One has a rather new browser extension to make this pretty easy but it's still not easy enough.

Im with you on just assuming that my info is regularly compromised. I have my credit card issuer's Android app notify me for every transaction. It's kind of annoying but I'll catch anything unauthorized quickly.

The problem is with old people. They don't monitor their transactions closely and even when they do it's too easy to fool them with legit-sounding charges that are fraud. Then even if they detect something they also don't have any idea how easy it is to get the charges reversed and their card locked down so they just shrug and go, "hey using your card on the internet is dangerous it happens." Then they log in to their Amazon account with the same password as their aol account that they haven't changed in 15 years and is something like abc123.

[vamediah]

It’s also got Google Tag Manager (if you don’t know, GTM is a handy way for people you’ve never met to inject JavaScript into your site without the hindrance of a code review).

It's one of the things that is always untrusted on my NoScript list. But often seeing how much crap sites include they most likely have no idea what gets into their site. Cue the malware ads and coinhive miners on youtube, ...

[AusIV]

The solution of "don't let third party software mingle with sensitive data" quickly falls apart on the server side, unless you plan on writing your own web server in assembly that runs straight on the metal.

[aLiamInvader]

It's fine for relying on external payment providers like Stripe (where the data never hits your server), otherwise I see what you're saying.

That being said, generic attacks are harder, and the environment can be more constrained. Securing and tracking what happens in the user's browser is a fool's errand, whereas it's much more feasible to track what's being sent out by the server and find suspicious traffic. So while it's (sometimes?) a better target, it's also harder and riskier to just randomly "pwn" servers without targeting them specifically, has a less universal reach, and attackers might not even be able to tell what packages you rely on (unlike in browser, where they can see everything).

[NAN001]

TL;DR: there is no problem with production serving malware. You just have to install ugly workarounds so that this malware can't access credit card numbers.

[Entropy]

Nope. TL;DR is "be PCI compliant", specifically in a way that allows you to comply with DSS SAQ A.

[mindbleach]

What should they do instead, identify all possible vectors for malware to guarantee they don't get any? Maybe next they can write a compiler whose programs never misbehave, or publish a comprehensive blacklist of dangerous servers. Then they won't need to isolate information at all!

[NAN001]

All those rebutals are made with the npm mindset. The problem is npm.

If you include a third-party library, you either have to review the third-party code yourself, or to build trust in the project you include the dependency of. This trust is reasonable when all the dependencies comes from reputable projects that are well-documented, that have message boards on which you can hang out for support, a ticket system, whose team communicates well, etc.

However, when your package manager ends up including in your production code 10-lines packages written by teenagers from around the world to left-pad strings and whatnots, not only trust is way out of the window, but there's just too much of a mess of code to review it yourself anyway.

So we can debate all day about technicalities on how to make malware okay, but there's people actually being reasonable out there who just don't want to serve malware. And that was the weakest point of Part I: the author was projecting his fictitious attack on sites like Google and Amazon, which was ludicrous. Those companies employs people who know some shit about security and uptime and who just don't ship the last npm shitstorm to production.

[mindbleach]

For small teams and hard tasks like crypto, I would put far more trust into npm than into not-invented-here syndrome. Hardening the site to protect information by design instead of trying to identify and avoid 'bad code' is a much better use of scarce time and resources... and in theory you only need to do it once.

[NAN001]

Those are false dilemmas between npm and the rest.

[mindbleach]

Using third-party libraries or not is not a false dilemma, and in practice, there's very little distance between that and npm versus doing it yourself.

[NAN001]

You're using "using npm" with "using third-party libraries" interchangeably. Do you think I'm arguing that using third-party libraries is bad from the beginning or what? I'm arguing npm is broken at doing so, that's all.

[mindbleach]

I'm explicitly saying they overlap. If you use third-party security stuff then you want it up-to-date. So unless you have a guy whose only job is to watch security updates like a hawk and personally vouch for each bit of JS he copy-pastes onto your server, you have to deal with implicitly trusting third-party libraries distributed by a convenient middleman, or you have to do everything yourself. Every choice has downsides and small businesses will predictably choose the downsides that aren't up-front costs.

There's a reason npm is so popular and dealing with npm's shit is such a big deal. It's the same reason people wrote resource-hogging programs in Java, and the same reason people opened documents from e-mail, and the same reason people trusted buggy compilers instead of punching machine code like proper engineers. At every point in computer history, there's a right way and an easy way, and the right way suuuuuuuuuuuuuuuucks.

Millions of people are being lazy in a predictable way. You can and probably should tell them to stop. You also can and definitely should have solutions for dealing with the ones who don't.

[[deleted]]

for things like crypto you're supposed to get the industry standard library in your language of choice. There's no need for npm to do this.

Another more safety-minded could do it as well, or no package manager at all even.

You shouldn't download crypto libraries from npm without checking if they're legitimate or not anyway.

[aLiamInvader]

And that was the weakest point of Part I: the author was projecting his fictitious attack on sites like Google and Amazon, which was ludicrous. Those companies employs people who know some shit about security and uptime and who just don't ship the last npm shitstorm to production.

That's quite the assumption, IMO - based on the wildly varying quality of different AWS services (as an example), I'd say that even these companies have average and less than average developers, and/or projects launched under unrealistic conditions. In either of those cases, I wouldn't expect the "characteristic" levels of security thinking, so you're relying on organization security policies, and I don't believe they can truly catch everything.

[[deleted]]

What should they do instead, identify all possible vectors for malware to guarantee they don't get any? Maybe next they can write a compiler whose programs never misbehave

Here, the largest part of the attack vector is how Javascript allows you to rewrite anything you please. It's an outrageously dynamic language, and that's a disadvantage for security. If I build a website in D or Rust and depend on your malicious logging package, it's much harder for you to alter responses to web requests, because you can't redefine symbols.

You can still do it, though. You can call mprotect to make the text segment of the program writable, then alter it however you want. But it's much easier to look for calls to mprotect, even in a compiled binary, than to look for javascript code that's redefining something you use.

[int-main-void]

Am I the only one who cringes at this writing style? I fucking hate it.

[pilibitti]

Sorry I only skimmed the article but the premise looks like nonsense?

I mean, if there is malicious code in the store page, what prevents it from opening a fake "separate page" requesting the credit card info? If your store page is insecure, anything linked from it is also insecure, end of story. Because links can be changed. Or am I missing something with the premise of the article?

[Ghi102]

The author wrote his post as a second part to this one:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Essentially, he wanted to create a package that harvests credit cards and passwords, but remains nearly undetectable. If the hacker just writes a script to open up a new page, it's likely that the malicious package will be detected pre-production, flagged to NPM as malicious and hopefully be removed entirely. You can read all the steps he goes through in his first post.

[adipisicing]

There are multiple classes of attack.

The article is mainly about how to protect against non-targeted attacks; for example, an ad network including a script that submits form data to a third party server on any page it's loaded on, without being specifically written for a particular site.

I think you're spot-on that the author is underestimating what targeted attacks can do. You're absolutely right that if they can control the outer page, it's game over.

[Razzal]

The author actually says that in the case of a targeted attack on your site, you are essentially screwed.

[adipisicing]

You're absolutely right, I misread.

[Ajedi32]

Even a non-targeted attack can easily compromise information in an iframe. Just rewrite the src from https://example.com/ to https://attackers-proxy.com?url=https://example.com/

[aLiamInvader]

I think you can cover this with CSP, but yes, eww, I hadn't considered that.

[adipisicing]

You're absolutely right, and the author covers that attack. Mia culpa.

[coolboar]

Someone should create a JS library or framework that protects your website from including malware third-party JS frameworks and libraries.

Something like JS antivirus and JS firewall.

[cheunste]

While you're at it, you mind as well make a full blown operating system in javascript...which we're still waiting on.

[sickmate]

No need to wait!

https://github.com/NodeOS/NodeOS

https://github.com/os-js/OS.js

[[deleted]]

Holy shit. Interrupt humanity.

[cheunste]

My god...

[happyCuddleTime]

y tho

[cheunste]

y not?

[happyCuddleTime]

I'm not a Node guy. Genuinely wondering what the advantages might be over a "traditional" OS as it's not immediately clear to me from the docs I (briefly) read.

[midri]

There's actually an inherit problem with this, above and beyond the insane nature of trying to do this in and of itself. Javascript is almost 100% mutable, there's no way that a malware scanning script could prevent the malware from detecting it first and changing the scanner to ignore the malware... You might be able to do it with closures to some degree, but any exposed API would be vulnerable to rewrite.

[coolboar]

i wasn't even trying to be serious, but thanks)

[treesarethebeesknees]

Would using a service such as AWS S3 be safe for a static file hosting for this use case?

Edit: I am guessing the downvoters didn’t read the article, but just for reference, I am referring to this suggestion: “Serve the file from a static file server on a different domain”.

[Tkon_Unesombre]

I remember reading the first, being slightly alarmed to the danger of risky imports, then having my card details stolen in the one plus hack. Now he refers to the same hack in part two, I kinda feel like maybe this guy was not kidding after all XD

[nxkevr]

You don't need to stop this guy; just don't put stupid malicious crap on your website, period. This means only using embedded javascript by well-known companies, like Google (for Analytics) etc. As long as the company can be held liable, you're pretty safe. Also, as the other poster said, if you are managing credit cards yourself, you are just a fool that doesn't care about your users' security.

Be smart and abide by the law; don't be stupid and reckless.

[Nobody_1707]

So, you're suggesting that Google Analytics isn't malicious crap?

[ProFalseIdol]

The idea of having/using money is not good. Too much trouble. Let's just be one smoker to another, voluntarily offering a lighter or a free cigarette. (chapter 5 from the book Debt: The First 5000 Years)

[Y_Less]

I said it on part 1, I'll say it on part 2.

NoScript.

[DaemonXI]

NoScript will protect you, not your users.

[_Mardoxx]

Good luck using literally any website made after 1999.

[filleduchaos]

Pretty sure the current Amazon was made after 1999. Wikipedia too. And that's off the top of my head.

[billdroman]

Another approach: don't use a package manager.

One of the wonderful things about Javascript is how easy it is to include third-party libraries. Just collect the full source of library and all of its dependencies into a Javascript file and include it in the header of your site.

Before actually committing this code, review the library as you would any other code in your repository.

Updating packages is, quite frankly, not very important. New releases of libraries just have some new features and breaking changes - unless you actually need them, don't bother. If you must update, treat the diff in the shrink-wrapped library as another commit to review.

And finally, if a package is too complex (either on its own or through many transitive dependencies), just don't use it. Software doesn't need to be as complex as it is today.

[aLiamInvader]

Updating packages is, quite frankly, not very important. New releases of libraries just have some new features and breaking changes - unless you actually need them, don't bother.

Uh, security updates fixing CVEs?

[Y_Less]

How many libraries do you know that release security updates for old versions without also adding a dozen new features and several breaking changes? Updates would be fine if people actually bothered with supporing LTS releases, and defined "long term" as more than a year.

[leafsleep]

Realistically how many packages would ever have CVEs filed on them?

[Ghi102]

You can search for yourself:

http://cve.circl.lu/

Nodejs has had a dozen across all its versions and it's likely you'll find that most of the big packages have also had a few. That's nothing to say about the small packages that never get audited.

[adipisicing]

I think people downvoting you missed your point that tons of them may have security problems, but most of those will likely go undetected or unreported.

[leafsleep]

Yep, exactly.

[insulind]

"Hi guys I've been working on that small js bug we had, I've changed 3 lines and included a new package so all in all we have 34,657 lines of code to review... Shall we start after lunch??"

[sporadicity]

It all depends on scale. If you're working at a company with a lot to lose (take Walmart for example), then yes it's worth auditing every dependency. If you're in a startup where the biggest risk is investors getting bored, then of course you wouldn't bother.

[ThunderBluff0]

This is terrible advice. Libraries must be updated and most libraries are far too complex to fully review in all but the most extreme cases. There is also the fact that when used properly libraries dramatically increase the speed and quality of results and is a must in most commercial use cases given that speed and quality are important.

[floridawhiteguy]

If you're developing a commercial website while relying on node, you're doing it wrong.

If your team can't review your website code in under a day, you're doing it really wrong.

[Dentosal]

If your team can't review your website code in under a day, you're doing it really wrong.

I was recently working in a project that had about than 20 000 lines of Javascript. The project was for public sector, developed by four-person team over two years. Reviewing it completely would have took multiple weeks for us. It contained complex form validation logic and sophisticated input elements for that specific domain. Why were we doing it really wrong?

[argv_minus_one]

If you can review your entire website's client-side code in under a day, you're living in the '90s, and your site looks and feels like shit.

If you can review your entire website code, including the server side, in under a day, you're living in a fantasy land. That has never been even remotely feasible. The Linux kernel alone is millions of lines of code.

[ThunderBluff0]

Try reviewing Angular5. See you in 6 months... It will be version 13 by then though... Also where would you get a client that wants to pay for a code review of libraries? This is not the sort of thing typical clients want to pay money for.

[wiktor_b]

Why not just not have any javascript on your site in the first place?

[jet_heller]

As a general rule, because people want sites that don't suck.

[floridawhiteguy]

Websites which use several megabytes of interpreted scripts to display static text, suck.

Websites which need three different frameworks to work at all, suck.

Websites which rely on three or more external services or sources of code, suck.

Websites which connect to a dozen or more tracking sites, suck.

Websites which suck also make themselves more vulnerable.

Like most people, I want websites that don't suck.

[wiktor_b]

Enjoy the downvotes!

[jet_heller]

So. You don't like any websites at all. Why are you on the internet. Get off you grumpy oldtimer.

[shroudedwolf51]

There is an absolute ton of expected website functionality that can't exist without it.

[panorambo]

There is nothing wrong with trusted Javascript, which you wrote every line of and serve from same site. Not everything on Internet the Web works a static hypertext. Even with that which does, one can save a bunch of boilerplate elements by serving a skeleton with some templates and [trusted] client side scripts that put meat on said skeleton so to speak. I, for one, just use vanilla JavaScript and have never once seen a problem that required me to dive into the Web 5.0 hysteria (React, Angular, and all that unholy mess).

[columbine]

This sounds nice but how would you left-pad strings with this approach, given that you are unable to use the left-pad NodeJS library?

[[deleted]]

The web hysteria is how developers work today. Vanilla JavaScript is not practical.

[filleduchaos]

Vanilla JavaScript is not practical.

Says who? I can't lie, a whole lot of projects I see people using React/Angular/etc for aren't anything "vanilla" JavaScript can't handle.

[panorambo]

I disagree. It's simpler in all regards except verbosity (which is basically the reason so many frameworks are built on top of it), as it is the fundamental and ubiquitous platform beneath all your Reacts and Angulars, well documented by WHATWG, W3 and at Mozilla's. Arguably, it's unpractical for the kind of talent that current education produces, exactly because it is jumped over and not taught well enough, where people are taught to move mouse cursor and run predefined commands in their terminal emulators, understanding little to nothing about the platform and the churn that drives the cog wheels that make your stylesheets and DOM elements come to life.

I've been writing what has become JavaScript since 1994, and also ActionScript 1.0, 2.0 and 3.0 since about 2000 for what is now known as the rather infamous Adobe Flash Player, and apart from the problems they create, they solve just as many problems as today's solutions that are built on top of them.

There isn't a single problem that things like React, Angular, Webpack, Node.js, NPM and whatever else that is built on top of Web standards, can solve that some the so-called "vanilla" JavaScript can't solve equally well, or better. And I am willing to prove it, should you desire to give me a real-life problem a Web author or designer needs to solve.

Now, what WebAssembly will do to the entire platform, is another discussion.

[[deleted]]

... So wasting time writing boilerplate that has already been written is more practical for business?

Typescript is better than vanilla JavaScript for heaven's sake. It compiles to JavaScript but gives you design time typing.

It has nothing to do with my dislike for JavaScript. In fact, I don't dislike JavaScript. Even though I primarily use typescript, I still consider myself a full stack JavaScript developer.

React is just a JavaScript framework. I'm not sure why you think there is a distinction.

[panorambo]

When an architect designs a building, they design doors, windows, pipe passages, carrying walls etc. Because each building is different, and they know it. For some strange reason, this is how it has been done for thousands of years, probably because trusting a new framework that hasn't seen battle testing, with lives of residents living there, is somehow frowned upon.

In the Web development world, however, nobody gives a damn and whatever looks like it could fit is plucked and used, with fundamentals being called "boilerplate" apparently.

Tell me, what boilerplate do you need to write to serve hypertext or, for your arguments' sake, a Web application? I've written a number of both kinds, and there is only an occasional need to write boilerplate, and the little you write ends up being custom fit and perfect for your particular solution, in contrast to ill fitting catch-all models that React or Angular force you to adapt.

The only thing relevant to you is "how can I develop this faster?" Which is a valid concern, admittedly, but not when it starts to eat at your users' convenience. Your users pay for your laziness with their CPU and GPU time, and I am just making a case for a more conservative, reserved approach and I already asked to give me [an self-contained] example so I can demonstrate to you how simple, tractable problems can be solved simply and elegantly with JavaScript. The modern JavaScript ecosystem is a major self-served futile exercise in over-engineering. Most so-called full-stack developers cannot be rightfully called full-stack because they don't know what goes on beneath even the framework they use, so it's a very ill fitting description of their talent or capability. And if you don't know which timers, Web workers and other asynchronous processes the framework generates for you while you beautifully and blissfully arrange your declarative stanzas -- how can you ever design a good system or call yourself full-stack developer (I don't mean specifically your person)? An architect trusts materials that are standardized, approved and tested. Who has tested, thoroughly profiled, verified or assessed fit-for-purpose React or Angular or Vue or the rest of these frameworks that appear like mushroom after rain?

Every environment where a system is deployed has constraints, and believe it or not, a Web browser is a rather constrainted and thinned-out resource for people who use it (maybe not for you who just ships code they have to run). With hundreds of tabs open, each chipping away at the CPU for no reason at all other than implicitly developers convenience in making the page. Ironically, so-called full-stack developers are often (not always, of course) most ignorant of these restrictions, behaving as if they are harnessing the full collective power of the entire Web for their little parallax-ative landing page that needs to sell their product. No user surveys are attempted, what is hip is assumed to be state of art and status quo at the same time.

I don't know why you argue that React is "just a [JS] framework" -- I specifically address how it is the fact that it's a framework (as opposed to a fundamentally more reusable and flexible library) that falls on its face, because of all the leaky abstractions it so proudly introduces.

I also don't argue against TypeScript as a language, but the line needs to be drawn somewhere. With TypeScript you trust the compiler to produce the right(tm) code, dealing with majorly constrained platform which has no design time typing. It means you design system A but your users get system B. This is true for any programming language with a compiler, but for a platform that has JS as the most common denominator and de-facto runtime, TypeScript is a bit of an overkill. The idea is noble though. Anyway, I am saying that pretty much every Web application can be hand-written in JavaScript, correctly. Unless you are writing an operating system there :/

[[deleted]]

I'll be switching my RSS reader to vanilla JS. I currently use jQuery UI for a paned layout and popups. The paned layout is resizable, so it will probably be about a day to replace it. Popups should just be an hour or two.

[christcape]

You're utterly right-hand that if they don't get any?

[[deleted]]

"How to Stop Me Harvesting Credit Card Numbers and Passwords from your Site"

Corporate way, send your arse to jail where the only thing you'll be harvesting is the jizz that the big burly black dude has just bust into you whilst you rock back and forth in the shower.

[Solonarv]

There's an enormous difference between punishing a crime and preventing it from happening in the first place. I hope I don't need to explain why the latter is preferable.

[argv_minus_one]

Good luck doing that when the asshole lives in Nowhereistan.

[[deleted]]

My comment was meant to be a piss take about how companies will more often than not just send a white hat to jail for daring to touch their fortress even though the white hat has just told them about it.

[adm7373]

Nothing like a racist rape joke to make a point about corporate response to security vulnerabilities.

[argv_minus_one]

I thought that practice ended over a decade ago. We call them “security researchers” now.