The debit card behavior is probably bank specific. I had fraudulent transactions on my debit card. The bank caught it after a few transactions, alerted me, and shutdown the card when I told them it wasn't me. I didn't get charged for any of the fraudulent transactions. I also had a restaurant charge my debit card for my bill and another customer's bill (honest mistake, not fraud). The restaurant wouldn't refund the transaction, so I disputed it with my bank, who reversed the transaction. The bank was fully set up to dispute debit card transactions from their website.
It’s bank specific but the major difference is that with credit cards you are protected by law whereas with debit cards it depends on the whims of your bank and the contract you signed with them
You call it whims, but I don't know of any bank that doesn't offer those protections. Generally the terms are that you have to report it w/i 30 or 60 days. Maybe some of the smaller credit unions?
but like the other poster, I've had people try to charge me for things that weren't mine and I've never had the problems people seem to imagine exist with debit cards.
At this point I've concluded it's a marketing scheme by the CC companies that has convinced large swathes of society that debit cards are dangerous.
Not only that, but I would argue the false sense of security of CC's makes it so people are less safe in their habits.
>You call it whims, but I don't know of any bank that doesn't offer those protections. Generally the terms are that you have to report it w/i 30 or 60 days. Maybe some of the smaller credit unions?
That's been my experience as well. Although my bank almost always declines debit card transactions if I'm more than 50 or so miles from home, making the use of credit cards much more useful when I travel.
Sure, but why deal with that uncertainty? The money is not in your account until the dispute process finishes.
With a credit card, the money never leaves your account in the first place, at least until the bill is due.
Regardless, I know I'm legally protected with any credit card I use. With a debit card, it depends on the bank's fine print as to how disputes are handled.
> The money is not in your account until the dispute process finishes.
That's not necessarily always the case.
I use a debit card for almost everything. I've been doing it this way for quite a long time now.
Both times I've filed a dispute over debit card transactions, my bank immediately put the disputed amount back into my account while they investigated the dispute.
It was inconvenient to deal with (as many things in life can be), but it was not particularly problematic.
> relying on a corporation like a bank to be nice is risky and a fragile stance (they can change ToS any instant).
Banks are a lot more tightly regulated that most other businesses, and (in my experience) don't generally have "we can change the ToS whenever we want, however we want" clauses in their customer agreements.
All the banks I've dealt with say they have to give you 30 days notice of any ToS changes, and with language like "if we reasonably consider that the change is favorable to you" (or similar).
If your bank has more leeway in changing its ToS on you, I would suggest having a look around at the terms other banks offer.
Banks have to hold up their end of the customer agreement (contract), and the terms of that agreement are enforced by contract law.
I've yet to see a bank's customer agreement wherein the contractually-defined protections for debit cards varied significantly from the legally-defined protections for credit cards. (I haven't made an exhaustive study of this, but I have read the fine print for every new bank account that I've considered.)
If you can find a customer agreement that is meaningfully different in this aspect, then: I'm all ears.
> Banks have to hold up their end of the customer agreement (contract), and the terms of that agreement are enforced by contract law.
Right, but they can change those unilaterally whenever they feel like it. Multiple times a year I'll get an updated terms of service document from this or that bank.
So you can point to a bank's a customer agreement that is meaningfully different in this aspect compared to federal requirements for credit cards, then?
Or maybe you're just spilling FUD?
Just because a thing can change, doesn't mean that it will. (It doesn't even mean that it has ever changed.)
However, I appreciate the CFPB link. Having worked in fintech I'm familiar with them.
The link does corroborate that debit card protections are weaker than credit card protections. They have with more aggressive reporting requirements (2 days) and higher potential liability ($500, or even as much as the full amount in some circumstances, though unlikely).
This document has a handy table that compares the protections side by side. As you can see, debit card protections are weaker. Scroll down to the table "Federal Protections for Unauthorized Transactions":
> They have with more aggressive reporting requirements (2 days)
between 2 days and 60. read it closer.
this is called backpedaling, as I predicted. we've now gone from "prove debit cards have federal protections!" to "but but but ... they're different!".
they're protected mr fintech family who had no idea.
But in the days between a fraudulent charge, and you reporting it, maybe you bounced a check...
There is a difference between your account balance being immediately depleted by fraud and your available credit being reduced.
> I also had a restaurant charge my debit card for my bill and another customer's bill (honest mistake, not fraud). The restaurant wouldn't refund the transaction,
I know this wasn't the point of your story, but refusing to refund the transaction takes it firmly from "honest mistake" into "fraud" territory in my book. Oops, I accidentally stole your money, my bad. No, I won't give it back. WTF?
> can anyone explain why in the US if I click unlock on the remote, it just unlocks the front door? This keeps happening on rental cars. You have to click twice on unlock to get all the doors to open.
This is likely configurable. Instructions should be in the owner's manual. It is configurable for both my and my wife's vehicles, one via the touchscreen and the other by pressing and holding unlock for 5 seconds.
This is vehicle specific. Not all 2023 vehicles behave this way. I have a current generation vehicle (same generation and tech as 2023).
- Doors stay unlocked. Eventually the engine won't start without pressing unlock on the key fob again, but the doors remain physically unlocked forever.
- Trunk is manually operated.
- It doesn't ding when starting the engine if my seatbelt it on. And I have a programmer that lets me disable the dings when my seatbelt it off. There are no dings when turning the engine off.
- Blind spot warning is configurable: Off, lights, lights + chime. The chime warning doesn't seem annoying.
- No lane keeping assistant.
- Tire pressure monitors work well. They are accurate (same pressure as multiple physical gauges I've tried). Tire pressure increases slightly when driving due to heat. They have never triggered a warning.
- I don't recall ever having to accept terms of service. It certainly hasn't happened multiple times.
I have physical knobs for volume, fan speed, and tuner. Physical buttons for everything else. No controls use resistive touch buttons. No controls are via touch screen (touchscreen has information and setting like blind spot, but not actual controls that don't have physical buttons).
I also have a 1990s vehicle, with an aftermarket touchscreen installed to support Android Auto and Apple CarPlay. The current generation vehicle is no more annoying than the 1990s one.
My wife has a 2023 model year vehicle. Many of the complaints in the post are enabled by default (auto re-lock, blind spot chime that gets confused by multiple lanes). But many of the annoying things are also configurable, including auto re-lock and blind spot.
So it is possible to pick a vehicle that isn't annoying. And I suspect most of the annoying things can be disabled.
In my experience the recruiters are great about helping you prep. They have a PDF called "Google Interview Prep Guide Site Reliability Engineer" that talks about SRE-SE vs. SRE-SWE vs. SWE, and links to books and topics to study.
Kirk McKusick's "FreeBSD Kernel Internals" course[1] was recommended to me, and it was excellent. But not cheap at $1495.
MySQL has some robust tooling in this space. Some of the tools use triggers to copy to a new table. GitHub's gh-ost[1] is probably the state of the art, and uses the binary log stream to replicate the data.
While there are a series of vulnerabilities here, none of them would be exploitable in this way if the metadata server was accessed via an IP instead of the hostname metadata.google.internal.
The metadata server is documented to be at 169.254.169.25, always[1]. But Google software (agents and libraries on VMs) resolves it by looking up metadata.google.internal. If metadata.google.internal isn't in /etc/hosts, as can be the case in containers, this can result in actual DNS lookups over the network to get an address that should be known.
AWS uses the same address for their metadata server, but accesses via the IP address and not some hostname[2].
I've seen Google managed DNS servers (in GKE clusters) fall over under the load of Google libraries querying for the metadata address[3]. I'm guessing Google wants to maintain some flexibility, which is why they are using a hostname, but there are tradeoffs.
It does not even take a lot. I run a production service on cloud run, the typical load is around 500qps, and the dns queries to resolve metadata server do fail frequently enough for this to be noticeable.
That is true, I was thinking specifically about the metadata and SSH keys. But DHCP can also set DNS servers, NTP servers, and other things that can either cause disruptions or be used to facilitate a different attack.
There might be a persistence issue, it seems like part of this attack was that the IP was persisted to /etc/hosts even after the real DHCP server took over again. But even just writing to /etc/hosts could open the door redirecting traffic to an attacker controlled server.
> Eusociality typically requires two other conditions. ... And since the ferns spread asexually on shared roots, they don’t actually exhibit an active system of resource acquisition typical of brood care.
> One key question is what defines an individual fern. If a colony can begin with a small plume of strap fronds sticking up from a few nest fronds and then spread asexually on the same roots, perhaps it is a single plant
There is a lot of talk about the amazing cooperation of these plants. And then they say it is actually one plant. Is it interesting if one plant grows different leaves at different heights?
"But Uli Ernst, a behavioral ecologist at the the Apicultural State Institute at the University of Hohenheim, Germany, adds that since older and younger ferns (their clones) live together sharing water and nutrients, one could technically call these overlapping generations and brood care." (emphasis mine)
In the same paragraph, clones, not the same plant. Strawberries clone themselves. They aren't the same plant.
"The difference, Burns says, is that the whole strawberry patch looks the same. The ferns, by contrast, differ markedly in morphology and reproduction depending on their role in the colony." (emphasis mine)
Right underneath the paragraph you were quoting, they have different roles, not just different heights.
Also,
"Drawing conclusions about staghorn social organization may ultimately hinge on the nuances of eusociality—some definitions frame the concept as more of a spectrum, notes evolutionary biologist Guy Cooper, at the University of Oxford in the UK, who was not involved in the fern study." (emphasis mine)
So I guess its significance depends on how you define "eusocial".
> The difference is that the whole strawberry patch looks the same.
In fact this depends a lot on the location, soil and age of the clones.
> The ferns, by contrast, differ markedly in morphology and reproduction depending on their role in the colony."
First of all, population is not the same as colony.
Second, many plants have auxiliary structures (temporary, marcescent or permanent). The concept of bract, thorn, nectarium or stipula is not a strange one for botanists but those are parts of one individual, not individuals in a colony.
Is well known that gametophytes and sporophytes are different individuals. Many algae and ferns have it. If we want to bend the concepts for non useful reasons, then any pregnant woman should be called an "eusocial colony" with three individuals.
What is the difference between a very cooperative colony of independent single cell organisms and a multi-cellular organism?
On practice the only difference is on the level of collaboration. You get a similar phenomenon here, it's different because those plants collaborate less than the leaves of a single plant, so we give them a different name. From that point of view, this finding is quite boring. What makes it interesting is that it's an independent evolution of collaborative behavior.
This is effectively required when open sourcing something that was previously internal. I've done it at a company. There could be company internal things that leak in old revisions of code and commit messages. Even if the latest commit on master is clean, it is really hard to know that every revisions, throughout the whole history is clean.
Good point. In such a case, I think it would still be nice if at least trying to split the total change into a few separate commits, that builds upon each other. That way the commit log could be a good start to look at for someone who wants to understand the code base.
