That statement is only supportable if vegans had a policy of annihilating meat-eating humans, which seems anathema to the vegan philosophy.
So maybe we can qualify that by saying "one day, no human will eat meat harvested from unethical or otherwise ecologically destructive livestock-farming practices."
> One could still run a numbers station? There's no way to prove the code words have any meaning beyond what is obvious.
I'm not so sure one could, legally. A number station would broadcast regularly a one-way communications, with no clear meaning. Here's an excerpt of the law from FCC part 97, which is actually surprisingly short and readable. It prohibits:
"messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.
(5) Communications, on a regular basis, which could reasonably be furnished alternatively through other radio services.
(b) An amateur station shall not engage in any form of broadcasting, nor may an amateur station transmit one-way communications except as specifically provided in these rules..."
The drug may end up in the manure, and the parasites may encounter it there at a marginally-lethal dose. When the parasite progresses further in its life cycle, its offspring may be resistant when they infect the next livestock animal.
Most parasites have a life-cycle that includes time spent outside the preferred host animal, including in zoonotic species that may not have symptomatic infections. They may acquire resistance in any stage, in any place they encountered the drug.
For AWS, as fully remote, for ridiculously high compensation, yes. Otherwise, no.
As a user, I have observed product searching and sorting to remain in a nigh-unusable state for decades now. I cannot fathom how such a state could be permitted to persist in any well-managed development team.
As a laborer, I have followed journalism covering treatment of workers, both in warehouses and on delivery routes. This led me to classify Amazon as a sociopathic corporation.
As a software professional, I have been repeatedly pinged by recruiters who seem to have no awareness of my value, or how much of my time Amazon's hiring process proposes to waste. And reports of working conditions seem strongly dependent on a random (to me) assignment to a specific team. Turnover and retention varies wildly.
I think "unsubscribe" should only be offered after a customer has been charged. Before that, it should be "cancel" or "annul".
For instance, if there is a "free trial" period, wait until after that expires, and the customer has been charged, before offering an "unsubscribe".
But aside from the hair-splitting, yes, you are absolutely correct. If I have instant buyer's remorse, I should be able to click it away just as instantly.
"Canceling" a free trial means the trial ends immediately.
"Unsubscribing" during a free trial means the trial continues, but you are no longer subscribed so when the free part of your subscription runs out it won't automatically renew.
None of that language is has a standard legal or regulatory definition, across the US. They are not precise terms, at least not yet. They are frequently used colloquially in ways that contradict your suggestion.
I'm not saying your definitions are bad, or wrong... Quite the contrary, I think your ideas are great!
But the specific terms & definitions aren't what really matter, are they? We just need standard language, with specified legal meaning, that consumers can invoke to make service providers jump to task.
If just with previous password, then yeah, that's fine, but more then likely they are saying with the previous N passwords, which would require storing the previous N passwords in some kind of plain text or easily reversible form. Even if those old passwords are useless at that point (which might not be the case for something like a laptop that hasn't talked to the domain controller and learned that the password has been updated or something), it's still dangerous (what if they used that password on a vendor's site, or on their own banking login...)
The password-change form should be using a password field, and that should not be allowing any code or scripts to grab the plaintext stored in it.
If the code that compares your current password to the new password can read the plaintext of your passwords, so too could a malicious program.
Using HTML input type="password" alone is not sufficient protection. The same steps that protect password changes from malicious attackers must necessarily protect them enforcement of bad IT security policy.
At the time of a password change, the server still has your old password hash stored, and in the process of changing it, you are sending both your old password and new password. The server can verify both that your new password and old password differ enough while also verifying that the old password you sent it is valid.
It can go either way. There are certainly are creepy demands from bad managers. But there also are extroverted people that like to talk. They like to talk so much, that as an introvert myself, I find it exhausting. But that doesn't mean they are being coerced. That is just how that style of person is wired.