Associate Justice Leondra Kruger said in a separate opinion that she agreed that the removal order against Yelp was invalid, but for a different reason. Hassell did not name Yelp as a defendant, so the company did not get its âoeown day in court,â Kruger said.
This is the main problem though. Yelp was not a party to the lawsuit, so it's patently unfair to bind them to the judgment between two totally other parties.
What's more, these sort of third-party orders create the incentive for sloppy or outright fraudulent behavior. For instance, Google will voluntarily de-list a webpage if a court has found it defamatory. Sounds good, but what happens is that folks will find or invent a defendant that claims to have authored the webpage and who settles the lawsuit with an admission of libel. And this is where the "not a party" thing comes in -- when a court sees a plaintiff and a defendant agreeing to a settlement, it doesn't look too hard at it because the court (rightly, in most cases) assumes the parties have represented their own interests.
So you have an entire cottage industry of reputation-management companies filing real lawsuits against fake defendants in order to either request or demand takedown.
In a few cases, the lawyers have gotten in trouble (their defense: the reputation-management company did it, and while we didn't look too hard we were also not required to), but it's a reasonable guess that many more are getting away with it. The costs are basically zero, since there's no investigation or trial. Hell, from top to bottom they've gotten these done in 4 days, which in court terms is roughly equivalent to ludicrous speed.
This is getting way TLDR, but the only legal recourse is to say that if Alice sues Bob, she can only get an order binding Bob. If she wants an order binding Carol as well, she has to give Carol proper notice, in advance, and an opportunity to scrutinize the case and be heard in court.
The shorters are the ones who set themselves up to profit from the misfortune of others, and collectively have also been working to bring about that misfortune. If it fails then it fails expensively, which discourages people from that practice thereby reducing the amount of misfortune in the world.
This is such a misunderstanding I don't even know where to begin. Taking a bet against a company is not "profiting from their misfortune", it's asserting that they scammed/tricked/fooled their way into having a much higher valuation than is properly deserved. We want folks to take those short positions as a guard against bubbles and irrational optimism.
As far as "working to bring about that misfortunate", that is true and lamentable. But it's hardly unique to those with short positions. "Pump and dump" is exactly the same scam except on the long position side. Both are unethical and illegal, and it's got nothing to do with whether you are trying to manipulate upwards or downwards.
Also, FWIW, I don't believe TSLA is overhyped, I think they are valued about right. I wouldn't short 'em, but I don't begrudge those that do.
I'm a big scooter fan, they make it possible for me to take BART instead of driving by providing a quick way to do the last mile.
But indeed I agree -- if the companies can't figure out how to work through the issues and go bankrupt, so be it. Society advances by different people trying lots of different ideas, many of which end up in the dustbin of history.
The knee-jerk-get-off-my-lawn attitude though, that I don't get.
I shouldn't have to get a cert to pop up a website, period. The fact that people like you think we should is foolish, stupid and a road to hell.
The fact appears to be that you did not understand, because you got what you want.
You do not need a cert to "pop up a website". No one is requiring that.
When a browser interacts with your website, the UI will now accurately convey to the user the true fact that the contents of this site were not protected for confidentiality or integrity in transport. That is all.
If your website truly does not require either (e.g. bash.org) then leave it as-is.
The Paris Accord was a sole-executive treaty. When Obama signed it, he really only promised to do three things:
1. Meet every five years to make new, more aggressive goals on climate change reduction. 2. Meet every five years and publish how we're doing on our climate change reduction goals. 3. Track how we're doing on climate change reduction.
Sure, but that means that the headline and byline are total nonsense. The US cannot be "behind pace to meet its commitments to emissions" if we really only promised to meet and talk about it.
IOW, you are saying that it didn't require ratification because it did not contain any substantive commitments. I accept that, but at the same time that means that it does not contain any substantive commitments.
Climate discussions typically center on the need to replace fossil-fuel power plants with technologies like wind turbines and solar panels. But a new paper in Science offers a stark reminder that there are still huge parts of the global energy system where we simply don't have affordable ways of halting greenhouse-gas emissions.
Climate change is absolutely real, and the median forecast for the harm caused is significant.
As a purely empirical matter, the world does not appear likely to greatly curb emissions. Lament this all you want, as a scientist confronted with the need to make a prediction, this is undoubtedly the case. We don't have all the means, the means we do have are expensive and there is not the political will in a number of important countries to do it, nor the geopolitical or diplomatic strength to force it upon them against their wills.
What's more, we are already at the point that negative carbon emissions are physically necessary to limit warming. That is to say, not only do we need the means and will to reduce emissions greatly, we need to as-yet-undeveloped (let alone economically scaled) ways to have gigaton-range negative emissions.
We are well past the point where we need to start researching active climate engineering as an alternative to reducing emissions. To those that say there are dangers associated with climate engineering, I would argue that the sooner we start focus on it, the better a handle of those dangers we will have before the shit hits the fan.
And while I applaud the scientific rigor and dedication of those trying to reduce emissions, I am baffled by how people that are scientifically inclined can see our repeated failure to meet each carbon target and predict that somehow next time, it will be different.
President of the United States Obama agreed to it, and by the laws of the United States, the United States agreed to it.
The law in the United States is that the President may agree to treaties only with the consent of the Senate.
[The President] shall have Power, by and with the Advice and Consent of the Senate, to make Treaties, provided two thirds of the Senators present concur;
How about Musk and his fellow space cadets pay for the airlines extra expenses whenever they're doing a launch. Or limit how many "spaceports" we really need. How about both?
The "extra" expenses come from having to share a mutually-exclusive resource to which everyone has an equally valid moral claim.
What you're essentially arguing is that because airlines used to be the only people using the airspace and got by with some particular expenses, then that gives them the right to demand the same level of service (or money to compensate) in perpetuity.
What's more, this is true even when airlines compete with other airlines. When Southwest adds a flight from ORD to SFO, the other airlines incur some additional costs due to scheduling. This might mean sitting on the tarmac at O'Hare for a few more minutes or having to slow their approach to slot in on approach. By your logic, they owe United the money for this "extra" expense.
On Windows, starting a process is expensive for two reasons: spawn semantics instead of fork semantics, and the common practice of real-time antivirus. On any system, RAM owned by a process and not shared with other processes is expensive, particularly if it causes cached disk sectors to get evicted to make room or (worse) leads to swapping.
First, real-time anti-virus is a anti-pattern. The idea that we should enumerate and scan for every single on of the billions of executable that we don't want to run instead of code-signing the couple-dozen we do want to run has always been an absurdity. It's like designing a door to your office to recognize criminals instead of giving keys to your employees.
More importantly, RAM that is not being used is sitting idle and not benefiting anyone. So in order to evaluate whether the extra memory footprint is meaningful, you'd have to see whether the typical system running Chrome is memory constrained. My experience has been that the typical system is either I/O or throughput constrained (or just insanely overspecced) rather than being short on RAM. YMMV though.
Finally, yes, the kernel can fill RAM with disk cache, but the hit rate drops fairly sharply after the first GB or so. By the time you are caching many GB, the marginal difference from evicting the LRU pages is minimal. With modern PCIe/NVMe SSDS, this is even less pronounced.
I wish Star Wars ended after original trilogy... Everything since then has been total crap.
So just to be clear, it would be preferable in your mind that they release 3 good movies in the series and then stop, rather than 3 good ones and 6-8 bad ones. even if you only watch the first 3?
I don't get it. Does the mere existence of bad sequels have a backwards-in-time effect that worsen the original?
We get it that you thought the sequels were bad, but this just doesn't make any sense.
You are 100% right, but actually it's even more mundane than that. They laid off his manager, but did not immediately assign that person's duties to another person. That person's duties then went unfilled (shock!), and when people don't do their jobs, bad stuff happens.
I've edited/condensed his overwrought prose to highlight the main events:
One morning I came to work to see that [my manager] had been laid off. He was to work from home as a contractor for the duration of a transition. I imagine due to the shock and frustration, he decided not to do much work after that. Some of that work included renewing my contract in the new system. [...] When my contract expired, the machine took over and fired me. A simple automation mistake(feature) caused everything to collapse.
So yeah, the main fault in "the machine" (why not "the HR computer systems, because no one seriously expects a company to do HR on paper anymore") was that he was not assigned a new manager, and that manager made positively aware of his new managerial responsibilities.
So, in the name of research, scientists pushed cocaine on European eels in labs for 50 days in a row, in an effort to monitor the effects of the experience on the fish.
Yeah, that's totally a sensical thing to do -- definitely no research assistants cut into the stash at all. Nope.
European eels have complex life patterns, spending 15 to 20 years in fresh or brackish water in European waterways before crossing the Atlantic Ocean to spawn in the Sargasso Sea just east of the Caribbean and the U.S. Eastern Seaboard.
Let's see, I'm going to design a creature that lives in the inland waters of one continent, then swims a quarter way around the bloody world to bonk. This is WTF even by WTF Evolution standards.
Go home evolution, you're drunk. [ But hey, want some of this lab grade cocaine? ]
My view on things was that the kernel devs should be entitled to change the API and that the plugin vendors should not be entitled to complain about the API change. This was meant only to pre-resolve any dispute over who is responsible for breakage.
Given the good reputation of kernel devs, I expect they. would not do so for light and transient reasons, but would change the API when there was a good reason to. It would be stable enough, but power to decide when improvements require a rework would lie with them.
I disagree. Stable API are good. Being able to innovate at all layers is good.
My $0.02 is that you should avoid breaking it, but sometimes you gotta. When Windows moved to the new graphics model, they broke a ton of shit. But they also greatly improved platform stability.
and then when it crashes and you can't slave it into another system to get data from it, you're hosed.
What are you talking about? You can decrypt a FileVault volume from any connected Mac machine, if you know (or can guess) the password. I've personally done this, it works fine.
As far as brute-force protection, the PBKDF is set to about 250ms. So depending on the entropy of the password could take anywhere from 20 computer days (or a few hours on a big AWS instance) to 8000 years (beyond all the computing power on planet earth).
The Lustre devs basically never played nice with the Linux Kernel devs, and Lustre never left the STAGING sub-section of the Linux Kernel because they never (in almost a decade) cleaned up the code to pass Linux Kernel code reviews.
This is a major downside of the "everything in the same source tree" Linux philosophy.
In a different universe, we could have pluggable filesystem modules that could be built against each kernel source[1] without having to get it all into the same tree. If the kernel API changed, the FS devs would have to adapt to be compatible, but at least they wouldn't have to fight with the maintainers and the maintainers wouldn't have to be bothered by their patches. It wouldn't solve a technical problem -- after all, the build system hardly gives two shits where the source comes from -- but it would solve a major human problem.
Oh well, we can dream right?
[1] Specifically not wanting ABI compatibility here. First, because down that road madness lies and second because it's not too much to ask that FS developers recompile when the kernel changes and adopt changing API. It also cuts off the crazy assertion that pluggable modules would stagnate the kernel code. It would, unless we just stipulate that kernel changes are absolutely allows to break any plugin and that the plugin has no right to a stable API.
This doesn't replace in-tree, by the way. If a contributor and the maintainer agree, then by all means put it in-tree and be done with it. This is even beneficial for the contributor because it means that anyone changing the API must go and fix/shim all his code.
if the original software is distributed under GPL the modifications must be distributed under something that is compatible with the GPL
There is no way to limit this to the GPL (or F/OSS licenses generally). If his claim is a correct. statement of law, then modifications of a copyright work are derivative works irrespective of whether they derive from a GPL original or a proprietary original.
There's no special law over just the GPL -- if GRSec (or nVidia!) create a derivative work by distributing a patch or loadable module against Linux then so too does anyone that distributes a patch or loadable module against a proprietary piece of software. And if you distribute a derivative work then you must have explicit permission from the copyright holder, which is easy in the GPL case (just comply with the terms) but very likely will not be forthcoming in the proprietary case.
Just to get this out of the way, while I disagree strongly with Bruce about the merits of his claim, I do not in any way support the defamation claim against him for saying it. A differing view is not the same as a defamatory statement.
That said, the idea that a set of modifications to a copyright product, distributed separately, constitutes a derivative work is terrible policy and is philosophically counter to the 'freedom to tinker' that the tech community holds dear. I don't know if it is is the law right now (and absent. a very expensive test case, we aren't likely to find out), but just as a matter of policy I think it would be a Very Bad Ideaâ.
Consider, for instance, a student or researcher that patches the software in a commercial digital microscope to improve image quality or performance in a fashion. Let's further suppose they release the patch under some F/OSS license both to benefit other users of the product but also as part of disclosing their methods for the purpose of scientific integrity and reproducibility. It's undisputed that the company selling the microscope retains copyright. in the original software, but under Perens' claim they also have rights to the patch as a derivative work.
To me, this cannot be right. A modification to a work, distributed separately, is not derivative. It is not a copy with some changes, it is just the changes. To say that one violates copyright without distributing a single bit of the underlying work inflates the power of rights holders at the expense of everyone else, in a regime that's already quite solicitous of the rights holders.
[ Of course, GRSecurity are not the greatest poster boys for this claim. But bad examples should not make bad policy. The claim here is a one that has broad implications beyond the individual lawsuit-happy jerks involved this time. ]
What's the appropriate client behavior when a server returns rejects a credential?
It seems like 'forget the credential and prompt the user to re-enter it' is the right thing to do. Repeating the request to the server with the same credential would just be a DOS.
If NetFlex's server is coughing up a hairball, it needs to cough up a 'temporarily unavailable' hairball so the client knows that there is nothing wrong with the request.
The reason is that often times the server and client side can be implemented using different technologies.
Indeed. If they are using different technologies, they should just share the set of test vectors used for unit testing.
But in the case where it's a client/server application both written in C#/Java/..., then indeed there's no reason that both sides cannot use the exact same library.
No, I'm asking for basic economic fairness by saying that regulations have to be neutral and objective.
What you are advocating is excluding the poor from operating taxis without paying a tribute to a rich guy that holds a medallion. I maintain that this is still bonkers.
Slashdot Mirror
You're not factually wrong, but I do think you are overestimating the intelligence of the kind of people that would steal a delivery truck.
The idea of being able to remotely change the content to "~STOLEN~" is itself is a neat idea.
This is the main problem though. Yelp was not a party to the lawsuit, so it's patently unfair to bind them to the judgment between two totally other parties.
What's more, these sort of third-party orders create the incentive for sloppy or outright fraudulent behavior. For instance, Google will voluntarily de-list a webpage if a court has found it defamatory. Sounds good, but what happens is that folks will find or invent a defendant that claims to have authored the webpage and who settles the lawsuit with an admission of libel. And this is where the "not a party" thing comes in -- when a court sees a plaintiff and a defendant agreeing to a settlement, it doesn't look too hard at it because the court (rightly, in most cases) assumes the parties have represented their own interests.
So you have an entire cottage industry of reputation-management companies filing real lawsuits against fake defendants in order to either request or demand takedown.
In a few cases, the lawyers have gotten in trouble (their defense: the reputation-management company did it, and while we didn't look too hard we were also not required to), but it's a reasonable guess that many more are getting away with it. The costs are basically zero, since there's no investigation or trial. Hell, from top to bottom they've gotten these done in 4 days, which in court terms is roughly equivalent to ludicrous speed.
This is getting way TLDR, but the only legal recourse is to say that if Alice sues Bob, she can only get an order binding Bob. If she wants an order binding Carol as well, she has to give Carol proper notice, in advance, and an opportunity to scrutinize the case and be heard in court.
Nope, I'm mostly long, including on TSLA since the low double digits.
But please continue to make assumptions about the investment positions of internet strangers, it's, uhh, endearing?
This is such a misunderstanding I don't even know where to begin. Taking a bet against a company is not "profiting from their misfortune", it's asserting that they scammed/tricked/fooled their way into having a much higher valuation than is properly deserved. We want folks to take those short positions as a guard against bubbles and irrational optimism.
As far as "working to bring about that misfortunate", that is true and lamentable. But it's hardly unique to those with short positions. "Pump and dump" is exactly the same scam except on the long position side. Both are unethical and illegal, and it's got nothing to do with whether you are trying to manipulate upwards or downwards.
Also, FWIW, I don't believe TSLA is overhyped, I think they are valued about right. I wouldn't short 'em, but I don't begrudge those that do.
I'm a big scooter fan, they make it possible for me to take BART instead of driving by providing a quick way to do the last mile.
But indeed I agree -- if the companies can't figure out how to work through the issues and go bankrupt, so be it. Society advances by different people trying lots of different ideas, many of which end up in the dustbin of history.
The knee-jerk-get-off-my-lawn attitude though, that I don't get.
The fact appears to be that you did not understand, because you got what you want.
You do not need a cert to "pop up a website". No one is requiring that.
When a browser interacts with your website, the UI will now accurately convey to the user the true fact that the contents of this site were not protected for confidentiality or integrity in transport. That is all.
If your website truly does not require either (e.g. bash.org) then leave it as-is.
Sure, but that means that the headline and byline are total nonsense. The US cannot be "behind pace to meet its commitments to emissions" if we really only promised to meet and talk about it.
IOW, you are saying that it didn't require ratification because it did not contain any substantive commitments. I accept that, but at the same time that means that it does not contain any substantive commitments.
Climate change is absolutely real, and the median forecast for the harm caused is significant.
As a purely empirical matter, the world does not appear likely to greatly curb emissions. Lament this all you want, as a scientist confronted with the need to make a prediction, this is undoubtedly the case. We don't have all the means, the means we do have are expensive and there is not the political will in a number of important countries to do it, nor the geopolitical or diplomatic strength to force it upon them against their wills.
What's more, we are already at the point that negative carbon emissions are physically necessary to limit warming. That is to say, not only do we need the means and will to reduce emissions greatly, we need to as-yet-undeveloped (let alone economically scaled) ways to have gigaton-range negative emissions.
We are well past the point where we need to start researching active climate engineering as an alternative to reducing emissions. To those that say there are dangers associated with climate engineering, I would argue that the sooner we start focus on it, the better a handle of those dangers we will have before the shit hits the fan.
And while I applaud the scientific rigor and dedication of those trying to reduce emissions, I am baffled by how people that are scientifically inclined can see our repeated failure to meet each carbon target and predict that somehow next time, it will be different.
The law in the United States is that the President may agree to treaties only with the consent of the Senate.
The "extra" expenses come from having to share a mutually-exclusive resource to which everyone has an equally valid moral claim.
What you're essentially arguing is that because airlines used to be the only people using the airspace and got by with some particular expenses, then that gives them the right to demand the same level of service (or money to compensate) in perpetuity.
What's more, this is true even when airlines compete with other airlines. When Southwest adds a flight from ORD to SFO, the other airlines incur some additional costs due to scheduling. This might mean sitting on the tarmac at O'Hare for a few more minutes or having to slow their approach to slot in on approach. By your logic, they owe United the money for this "extra" expense.
First, real-time anti-virus is a anti-pattern. The idea that we should enumerate and scan for every single on of the billions of executable that we don't want to run instead of code-signing the couple-dozen we do want to run has always been an absurdity. It's like designing a door to your office to recognize criminals instead of giving keys to your employees.
More importantly, RAM that is not being used is sitting idle and not benefiting anyone. So in order to evaluate whether the extra memory footprint is meaningful, you'd have to see whether the typical system running Chrome is memory constrained. My experience has been that the typical system is either I/O or throughput constrained (or just insanely overspecced) rather than being short on RAM. YMMV though.
Finally, yes, the kernel can fill RAM with disk cache, but the hit rate drops fairly sharply after the first GB or so. By the time you are caching many GB, the marginal difference from evicting the LRU pages is minimal. With modern PCIe/NVMe SSDS, this is even less pronounced.
So just to be clear, it would be preferable in your mind that they release 3 good movies in the series and then stop, rather than 3 good ones and 6-8 bad ones. even if you only watch the first 3?
I don't get it. Does the mere existence of bad sequels have a backwards-in-time effect that worsen the original?
We get it that you thought the sequels were bad, but this just doesn't make any sense.
What's more, folks are going on like processes are intrinsically expensive.
If most of them are idle and the IPC is not super chatty, it's not a huge burden on system resources.
You are 100% right, but actually it's even more mundane than that. They laid off his manager, but did not immediately assign that person's duties to another person. That person's duties then went unfilled (shock!), and when people don't do their jobs, bad stuff happens.
I've edited/condensed his overwrought prose to highlight the main events:
So yeah, the main fault in "the machine" (why not "the HR computer systems, because no one seriously expects a company to do HR on paper anymore") was that he was not assigned a new manager, and that manager made positively aware of his new managerial responsibilities.
Not really ground-breaking AI stuff here at all.
Yeah, that's totally a sensical thing to do -- definitely no research assistants cut into the stash at all. Nope.
Let's see, I'm going to design a creature that lives in the inland waters of one continent, then swims a quarter way around the bloody world to bonk. This is WTF even by WTF Evolution standards.
Go home evolution, you're drunk. [ But hey, want some of this lab grade cocaine? ]
Can does not imply should.
My view on things was that the kernel devs should be entitled to change the API and that the plugin vendors should not be entitled to complain about the API change. This was meant only to pre-resolve any dispute over who is responsible for breakage.
Given the good reputation of kernel devs, I expect they. would not do so for light and transient reasons, but would change the API when there was a good reason to. It would be stable enough, but power to decide when improvements require a rework would lie with them.
I disagree. Stable API are good. Being able to innovate at all layers is good.
My $0.02 is that you should avoid breaking it, but sometimes you gotta. When Windows moved to the new graphics model, they broke a ton of shit. But they also greatly improved platform stability.
Indeed. So I would stipulate that the kernel is absolutely allowed to break the plugin API at any point for any reason.
It would be courteous to announce those on some list in advance, but that's all I would even ask those guys to provide.
What are you talking about? You can decrypt a FileVault volume from any connected Mac machine, if you know (or can guess) the password. I've personally done this, it works fine.
As far as brute-force protection, the PBKDF is set to about 250ms. So depending on the entropy of the password could take anywhere from 20 computer days (or a few hours on a big AWS instance) to 8000 years (beyond all the computing power on planet earth).
This is a major downside of the "everything in the same source tree" Linux philosophy.
In a different universe, we could have pluggable filesystem modules that could be built against each kernel source[1] without having to get it all into the same tree. If the kernel API changed, the FS devs would have to adapt to be compatible, but at least they wouldn't have to fight with the maintainers and the maintainers wouldn't have to be bothered by their patches. It wouldn't solve a technical problem -- after all, the build system hardly gives two shits where the source comes from -- but it would solve a major human problem.
Oh well, we can dream right?
[1] Specifically not wanting ABI compatibility here. First, because down that road madness lies and second because it's not too much to ask that FS developers recompile when the kernel changes and adopt changing API. It also cuts off the crazy assertion that pluggable modules would stagnate the kernel code. It would, unless we just stipulate that kernel changes are absolutely allows to break any plugin and that the plugin has no right to a stable API.
This doesn't replace in-tree, by the way. If a contributor and the maintainer agree, then by all means put it in-tree and be done with it. This is even beneficial for the contributor because it means that anyone changing the API must go and fix/shim all his code.
There is no way to limit this to the GPL (or F/OSS licenses generally). If his claim is a correct. statement of law, then modifications of a copyright work are derivative works irrespective of whether they derive from a GPL original or a proprietary original.
There's no special law over just the GPL -- if GRSec (or nVidia!) create a derivative work by distributing a patch or loadable module against Linux then so too does anyone that distributes a patch or loadable module against a proprietary piece of software. And if you distribute a derivative work then you must have explicit permission from the copyright holder, which is easy in the GPL case (just comply with the terms) but very likely will not be forthcoming in the proprietary case.
Just to get this out of the way, while I disagree strongly with Bruce about the merits of his claim, I do not in any way support the defamation claim against him for saying it. A differing view is not the same as a defamatory statement.
That said, the idea that a set of modifications to a copyright product, distributed separately, constitutes a derivative work is terrible policy and is philosophically counter to the 'freedom to tinker' that the tech community holds dear. I don't know if it is is the law right now (and absent. a very expensive test case, we aren't likely to find out), but just as a matter of policy I think it would be a Very Bad Ideaâ.
Consider, for instance, a student or researcher that patches the software in a commercial digital microscope to improve image quality or performance in a fashion. Let's further suppose they release the patch under some F/OSS license both to benefit other users of the product but also as part of disclosing their methods for the purpose of scientific integrity and reproducibility. It's undisputed that the company selling the microscope retains copyright. in the original software, but under Perens' claim they also have rights to the patch as a derivative work.
To me, this cannot be right. A modification to a work, distributed separately, is not derivative. It is not a copy with some changes, it is just the changes. To say that one violates copyright without distributing a single bit of the underlying work inflates the power of rights holders at the expense of everyone else, in a regime that's already quite solicitous of the rights holders.
[ Of course, GRSecurity are not the greatest poster boys for this claim. But bad examples should not make bad policy. The claim here is a one that has broad implications beyond the individual lawsuit-happy jerks involved this time. ]
What's the appropriate client behavior when a server returns rejects a credential?
It seems like 'forget the credential and prompt the user to re-enter it' is the right thing to do. Repeating the request to the server with the same credential would just be a DOS.
If NetFlex's server is coughing up a hairball, it needs to cough up a 'temporarily unavailable' hairball so the client knows that there is nothing wrong with the request.
Indeed. If they are using different technologies, they should just share the set of test vectors used for unit testing.
But in the case where it's a client/server application both written in C#/Java/..., then indeed there's no reason that both sides cannot use the exact same library.
No, I'm asking for basic economic fairness by saying that regulations have to be neutral and objective.
What you are advocating is excluding the poor from operating taxis without paying a tribute to a rich guy that holds a medallion. I maintain that this is still bonkers.