USA has Visa, Mastercard, Discover, and AmEx. Each of which try to entice their customers by offering better rewards programs. Though AmEx isn't taken everywhere (notably Costco) and Discover is hit and miss as well.
It's funny, because the Costco credit card used to be AmEx. IIRC Costco Canada only takes Mastercard, which is funny since the US Costco credit card is Visa, so you can't use the US Costco CC to pay in a Canadian Costco.
You actually can use the Costco US Visa at Canadian Costco, they’ve got a special exemption for it. (And vice-versa, you can use the Canadian Costco Mastercard at American Costco.)
The rewards programs are the anti-competitive lock-in.
Visa and Mastercard charge high fees because their dominant market position forces merchants to accept them. Then they use part of the fees to bribe customers with rewards programs.
A new payment network doesn't have leverage against merchants so can't charge the same high fees and therefore can't offer the same rewards programs, but then they can't get consumers to use their card, which is what they would need in order to get any leverage.
The rewards programs are a grift. The price of everything goes up by 3% and if you get a rewards card you get 1-2% of it back, therefore you get one. Then you're still out the other 1-2% you wouldn't have been if the market was competitive, the people who don't get one get punished by being out the entire 3% (which inhibits competitors with lower fees), and Visa and Mastercard suck billions of dollars out of the economy into their Scrooge McDuck money bin because consumers have been defrauded into thinking this arrangement is to their advantage.
Even being aware of all that, I don't feel I've been defrauded. I don't have to carry around a wad of cash that can be lost or stolen, and on the rare occasions that I need to I can get the help of the credit card company in recovering money when I actually get defrauded.
This is a great argument for forcing network interop. Akin to net neutrality, allow card companies to transit over the network for reasonable rates. This removes any networks ability to squeeze things like this
It depends where the division is, I guess. It always feels a bit heavy-handed to force private companies to interoperate within their infrastructure. That being said, I don't really know a better way to do it.
Having terminals be more universal would be good, but good luck replacing old ones and convincing entrenched market participants to offer them..
The newer generation of products like BNPL are even worse; they often contractually prevent merchants from charging a surcharge commensurate with the cost of accepting that payment method.
It's the card network using their excessive leverage as a result of a lack of competition that allows the issuing bank to charge such high fees. Because if you accept Visa, you have to accept every Visa.
Not sure where to start here. You could have found Honey advertised basically anywhere on the internet, not just YouTube. YouTube users are common across most of the developed world at this point, so it's probable that there are millions of YouTube users that are more intelligent than you or me. And what you said implies you do differing levels of due diligence for the services you sign up for depending on the platform you heard about them from, which is ill advised; regardless of where one found out about Honey, you should have questions about how their business works. Someone who has been around the block a couple times would have deduced that a business that clips coupons for you is doing something to make money, and since it's not obvious what that thing is, it's almost certainly something shady.
On the other hand, my team slapped 3 servers down in a datacenter, had each of them configured in a Proxmox cluster within a few hours. Some 8-10 hours later we had a fully configured kubernetes cluster running within Proxmox VMs, where the VMs and k8s cluster are created and configured using an automation workflow that we have running in GitHub Actions. An hour or two worth of work later we had several deployments running on it and serving requests.
Kubernetes is not simple. In fact it's even more complex than just running an executable with your linux distro's init system. The difference in my mind is that it's more complex for the system maintainer, but less complex for the person deploying workloads to it.
And that's before exploring all the benefits of kubernetes-ecosystem tooling like the Prometheus operator for k8s, or the horizontally scalable Loki deployments, for centrally collecting infrastructure and application metrics, and logs. In my mind, making the most of these kinds of tools, things start to look a bit easier even for the systems maintainers.
Not trying to discount your workplace too much. But I'd wager there's a few people that are maybe not owning up to the fact that it's their first time messing around with kubernetes.
As long as your organisation can cleanly either a) split the responsibility for the platform from the responsibility for the apps that run on it, and fund it properly, or b) do the exact opposite and accommodate all the responsibility for the platform into the app team, I can see it working.
The problems start when you're somewhere between those two points. If you've got a "throw it over the wall to ops" type organisation, it's going to go bad. If you've got an underfunded platform team so the app team has to pick up some of the slack, it's going to go bad. If the app team have to ask permission from the platform team before doing anything interesting, it's going to go bad.
The problem is that a lot of organisations will look at k8s and think it means something it doesn't. If you weren't willing to fund a platform team before k8s, I'd be sceptical that moving to it is going to end well.
I don't know that I agree that it's crazy. Any time I see a base64 encoded string, I decode it, because I want to know what's in there and what I'm working with. Don't use b64 if it's something you don't want me to see. Obfuscation isn't even the point of b64, because if it were, their strings would be less instantly recognizable.
The decoded b64 just being an offset integer is like high school level programming. Of course I'm going to send whatever offset I want and assume that's what the API author is allowing me to do. Especially if I'm in the shoes of a frontend engineer, and my Jira ticket says, "design a pagination UI element that allows the user to select a page of results." Now if that Jira ticket was impossible from the API, I'm going to go to my team and ask if the alternative (the "load more" button element) approach is acceptable or if we should butt heads with backend.
Decoding b64 isn't crazy, spending billions of dollars on a super computer to crack RSA encryption on a pagination token to discover that it's just an encrypted offset integer is crazy.
edit: Misinformation, the below user is mostly correct. It IS still less secure than a properly validated TLS connection though.
The certificate is expired, your traffic to and from that site is not encrypted. If it were the case that your traffic could still be encrypted, what would even be the point of expiring the certificate?
You're correct that you can still access it, over an unencrypted connection, however.
An expired certificate still encrypts your traffic. You might have to change settings or click through a scary warning in your browser, but other than that a certificate doesn't magically quit working as soon as it expires. The expiration date is arbitrary.
You are correct, I had to do a bit of research. Because Chrome even explicitly states that traffic to a site with an expired certificate is unencrypted. But I guess that's mostly to scare you, because the truth is that it just opens you up to potential MitM attacks and other similar issues with regular ole HTTP, but traffic between you and an unverifiable identity is at least TLS encrypted.
(Tested with Chromium, at https://expired.badssl.com) It says "Not Secure" on the left side of the address bar. It says "Privacy error" as the tab title. And then the body of the page:
<bold>Your connection is not private</bold>
Attackers might be trying to steal your information from expired.badssl.com (for example, passwords, messages, or credit cards). Learn more about this warning
net::ERR_CERT_DATE_INVALID
- "As published on: africa.cgtn.com, Friday 18 October, 2024."
I can confirm the OP text is indeed identical to the text on that CGTN article (Chinese state-owned media). This is simple plagiarism—among other things.
edit: On that tangent, CGTN Africa itself plagiarized Oxfam's press release—it's obviously the same text, run through an LLM for rephrasing. It's SEO spam all the way down!
The cash back rewards is not, as far as I know, actually all that good in comparison to its competitors like American Express. Giving a month to pay off a balance I believe is referred to as a "grace period" which is pretty common place in credit cards. A month is nice, but I believe most cards are usually around 4 weeks. But the UI for the card's online banking is fairly attractive, especially if you're already an iPhone user, which I imagine most Apple card holders would be.
> The cash back rewards is not, as far as I know, actually all that good in comparison to its competitors like American Express.
There are definitely cards with better rewards, but few with such a straightforward and simple cash back program. Also, the rewards are not bad by any means. I also like the tight integration with the high yield savings account, which again is not the best rate possible, but makes up for it with the UI of its software and overall simplicity and ease of use.
> Giving a month to pay off a balance I believe is referred to as a "grace period" which is pretty common place in credit cards. A month is nice, but I believe most cards are usually around 4 weeks.
I'm talking about the actual due date, not the grace period which is a different thing entirely. You have until the last day of the following month to pay off the balance to avoid incurring interest, which is different than any other credit card I've ever used. Usually the due dates are a specific day of the month which often changes every month.
Most credit cards have the due date on the same day every month. You can also change it online to to another day of the month if that's something you care about. Personally I just set up autopay from a brokerage account and never think about when anything is due. Why would it matter?
It’s not a huge deal on its own but it’s part of the overall “user friendly” nature of the card as a whole. Having the whole balance be due at the end of the month just makes it easier for me to use it as my “daily driver” rewards credit card.
