If you can't or won't pay your employees a living wage, you can't afford to run a business.
If an owner eliminates tips and raises prices to the exact amount required to make up for it, the total cost to the consumer will be higher because the price of food is subject to sales tax but the tip isn't.
For instance:
$9.09 burger, with some arbitrary 'base wage' $0.90 sales tax $2 tip ------- $12 out of the customer's pocket
$11.09 burger, where $2 goes to higher wages versus above $1.11 sales tax ------ $12.20 out of the the customer's pocket.
In an industry with such awful margins, that's a big deal. It's a strong incentive not to go tip-less..
... And I'm not sure he's ever stated concisely hat what the problems are.
I'm also really not impressed by the 'apologize for the internet thing', like the world would be better if everyone snarked for the New Yorker instead of building things. The
But if my neighbor leaves his hose on and floods his back yard, I will knock on his door and ask if he is building a pond or made a mistake. If it's a pond, I will smile and say "OK great!".
If it's not intentional, then it's not at all my fault that he is an idiot and left the hose on. But I will have done the right thing, rather than you seeming to think that "Well, if anyone ever is an idiot and leaves a hose on that means he's actually building a pond".
Quiz: A client wants to connect to a remote endpoint without a passive network observer being able to learn the identity of the endpoint. Is this "malware talking to the control server" or "banned application attempting to evade ISP-enforced censorship"?
Well obviously it's neither/both because there is no damned difference. As far as the transport layer is concerned, an application is an application. If you make it a desirable property that clients can conceal the true identity of the remote endpoint then you sweep in both.
Maybe this will change if we get adoption of RFC 3514 though.
Doesn't that depend on whether it was coded that way intentionally or by error?
By your logic, a SQL injection where a web form causes arbitrary commands to be executed against a database is not a vulnerability either because it's "coded to work that way". I think in more clear terms, if it grants the user permissions in excess of those specified by the design, then it's clearly a vulnerability.
So to go back to these bunch of idiots, it seems that they might have intended to make each request available only to the recipient.
I reread my comment very closely, and I don't see where I indicated that I think his actions were criminal. To me, it seems quite clear from what I actually wrote that all the parties involved were quite stupid in their own various ways. But please do point out where I inadvertently gave the wrong impression that I think his actions were criminal and I would be happy to correct it.
I would also like to add that I have a decent understanding not only of digital communications, but of the ethics of responsible disclosure and how they should be applied by security researchers that find (even very stupid) vulnerabilities.
Responsible disclosure is a fundamental principle of ethical security work. It balances the need to give the vendor a time window to fix it, the right of the public to know, and the researcher's right to publish their findings.
Also, I think it's amusing that you think I'm apologizing for the stupid authorities by calling both the authorities and the kid stupid, when the entire point of my post is that stupidity is neither finite nor conserved. Saying that he is dumb does not imply they are any less dumb. Everyone is dumb! Yay!
Just because the government is guilty of criminal stupidity doesn't make every other party more correct. Because (hear me out) sometimes everyone involved in a situation is pretty stupid all at once.
The government was criminally negligent in not securing resources. The kid was criminally stupid in not reporting the vulnerability through the responsible disclosure contact The government was probably criminally negligent in not publicizing the security contact The kid was criminally stupid in archiving the data instead of working towards fixing the problem
Stupidity isn't finite, one party having more of it doesn't make the rest have less. It's an infinitely renewable resource.
You are very confused. The RtbF is the right to demand that others remove or delist content that they created about you. For instance, let's say a journalist from the BBC wrote an article detailing your white collar fraud conviction and subsequent appeal. In any reasonable sense, we could say that this article belongs to the BBC.
The Right to be Forgotten says that John Disley has the right to make Google delist this article so that it does not show up when someone searches for his name. It's not his article, it's not Google's article -- the article belongs to the BBC but the RtBF says that he has the right to have Google delist it.
It is very confused to equate this with the idea that if John Disley writes an email, it's at least plausible that he could request that it be deleted by the recipient after reading it.
[ Note: the BBC helpfully publishes a list of all RtbF articles so you can see for yourself what sort of things are requested to be delisted and make your own informed decision. ]
Well, you're not really asking that the system never have priority over the user. You're asking that your interactive task have priority over everything else. The system is responsible for reading what you type on the keyboard, for example, so in that case the system should have a very high priority so that it can service your interactive task.
If only it was so simple, but in fact it's far worse than this. Not only does the OP want the interactive task to have priority to all possible resources over everything else, but that this priority inherits from this task to every task that is blocking it, including those access over all possible inter-task-communication methods. At the very minimum, it means that all of those IPC mechanisms need to be 'priority aware' and the kernel needs to arbitrate this correctly. It also means that all tasks must migrate away from any IPC mechanisms that don't have the structure to encapsulate the concept of a 'blocking request' -- shmem probably has to go.
In other words, it's not enough to give my topmost process the highest priority to the disk, but if that process reaches to any other process, say a system service, then that process must, for the lifetime when it is services the request from the topmost process, also (temporarily) be granted highest disk priority. In a POSIXy world where processes often connect via (local, not AF) sockets, this means that the socket mechanism itself needs to somehow figure out if the request is blocking or if it is 'background priority'.
The fixed costs of regulation are spread against the total scale of the business being regulated. The larger the fixed costs, the more this implicitly helps the largest incumbents and disadvantages upstarts with small market share.
The GDPR is 261 pages of incomprehensible legalese (and people still can't figure basic questions about it), which will cost you the same in lawyer fees to understand whether you have 1M customers or 1B.
So yeah, Facebook has no damned problem if you regulate and probably stands to gain in the long terms whatever they lose in the short term.
Of course you can. Did you ever read the damned FIDO specification?!
If you did, you'd realize that FIDO does not directly bind the biometric with the webpage. Rather it creates a asymmetric key pair (separate for each verifier) that allows the verifier to do a challenge response. This lets the verifier verify that the person trying to log in is the same person that associated the public key with the account at the time of enrollment.
The biometric part only enters into the stage in terms of protecting the private key. Some implementations can, for instance, put the private key on a dongle-thingy and require a fingerprint to allow a single signature to be produced. Others might be like YubiKey and just require you to press the button to confirm you are physically in possession. If you'd like, you can write a fully conforming implementation that holds the public key encrypted
In all cases, you can easily revoke the credential from the webpage just by asking them to forget the public key associated to the account (or even nuke all keys associated to the account).
Honestly, the answer to the question "can people be this idiotic" is usually no. I mean, sure idiotic things happen, but to think that a major consortium of big players didn't think through the most obvious concerns about revocation or compromise is just nonsense.
Back Page was actually providing a way for sex workers to operate without criminals managing them.
It was also providing a way for criminals that "manage" sex workers to more efficiently sell them. And it's not just regressive laws that allow pimps, it's also the fact that it is cheaper and easier to coerce the vulnerable with drugs/threats/violence than to deal with people that demand their rights.
Why can't we get it in our heads that the real world does not operate according to a narrative. BackPage was both empowering for independent sex workers (a good thing) and empowering for violent pimps (a bad thing). It was neither wholly good nor wholly evil.
I'm all for legalizing prostitution, having rigorous protection for sex workers and the whole progress shebang, but I'm not at all convinced that the majority of what happened on BP was above-board.
I'm going to assume you're a smart dude, so I think it's fairly clear that you know that just because the spec is not released publicly does not mean that it does not exist.
Gee, that would date this code to about the same time we were doing the POSIX standards that codified a (then) 20 year old Unix interface.
Gee, that didn't define an entire GUI/Windowing system.
Don't get me wrong, I love POSIX as much as the next guy, but it's a far more limited thing than WIN32. The closest NIX comparison would be GTK, I think.
Which just moves the problem to how you deliver the PIN associated to the new card.
But sure, once you've established that you can transmit the PIN from the bank to the (correct) customer without anyone else reading it, then you can use that to solve other problems:-)
4.Can there be transparent, accountable oversight from an independently constituted ethics board or similar entity with both the power to veto aspects of the program and the power to bring public transparency to issues where necessary or appropriate?
What in the world are they smoking (and can I get some, it must be goooood shiiiit)? In what reality do they believe that the design of military systems is subject to veto from a non-democratically- accountable entity? From where does this board derive any mandate to be making public policy?
I'm not against the goal here of having some ethics review. But there's a large gap between 'there should be an ethics board' and 'some dudes in Silicon Valley self-appointed themselves to veto the decisions of our elected government'.
I read through TFA and the submitted patch, but it's not actual clear what the flaw was. I figured/. would like to some full description rather than vague handwaving.
In the sense that it doesn't have anything to do with the underlying technology at all. It's a weakness in the activation/verification scheme in that it verifies that the cardholder received something, not that they have received the genuine card.
An easy way to 'close the loop' would be to perform the activation at an ATM that could verify the authenticity of the chip. Then the 'activation' of the card would be tied to positive proof that the rightful owner had possession of it.
Probably due to lack of desire/effort. A business can get by just fine without targeting a specific audience in order to have strategic focus on their core customers.
This is like saying that Budweiser is out of touch with craft beer consumers, even though microbrew is clearly better than mass produced.
According to the FCC's investigation, the outage began after a Level 3 employee entered phone numbers suspected of malicious activity in the company's network management software.
No, the outage began years ago when someone created a process in which a human being manually enters data directly into a production system.
I swear, if I had a nickel for every time a major fuckup was root caused to "human error in a process that should have never had a human factor to begin with", I could buy a house in the Bay Area.
For more than a decade, we've been beyond the point where competent folks can secure their machines. The challenge now is to make it the default behavior so that anyone can run a secure user machine without effort.
Besides being excellent for the incompetent, accomplishing this challenge also frees up the competent to apply their competence to other tasks. That is, it's a benefit for everyone the intellectual effort required to accomplish a task is reduced.
Someone said the measure of civilization is the number of things you can do without thinking about them. My hope is that, in time, secure computing becomes one of those things.
Slashdot Mirror
If you can't or won't pay your employees a living wage, you can't afford to run a business.
If an owner eliminates tips and raises prices to the exact amount required to make up for it, the total cost to the consumer will be higher because the price of food is subject to sales tax but the tip isn't.
For instance:
$9.09 burger, with some arbitrary 'base wage'
$0.90 sales tax
$2 tip
-------
$12 out of the customer's pocket
$11.09 burger, where $2 goes to higher wages versus above
$1.11 sales tax
------
$12.20 out of the the customer's pocket.
In an industry with such awful margins, that's a big deal. It's a strong incentive not to go tip-less..
... And I'm not sure he's ever stated concisely hat what the problems are.
I'm also really not impressed by the 'apologize for the internet thing', like the world would be better if everyone snarked for the New Yorker instead of building things. The
I agree it's not the fault of the hacker.
But if my neighbor leaves his hose on and floods his back yard, I will knock on his door and ask if he is building a pond or made a mistake. If it's a pond, I will smile and say "OK great!".
If it's not intentional, then it's not at all my fault that he is an idiot and left the hose on. But I will have done the right thing, rather than you seeming to think that "Well, if anyone ever is an idiot and leaves a hose on that means he's actually building a pond".
Quiz: A client wants to connect to a remote endpoint without a passive network observer being able to learn the identity of the endpoint. Is this "malware talking to the control server" or "banned application attempting to evade ISP-enforced censorship"?
Well obviously it's neither/both because there is no damned difference. As far as the transport layer is concerned, an application is an application. If you make it a desirable property that clients can conceal the true identity of the remote endpoint then you sweep in both.
Maybe this will change if we get adoption of RFC 3514 though.
Responsible disclosure would err on the side of reporting it in case of doubt.
Eh, I have no knowledge of Canadian law and won't comment on it, but responsible disclosure is an ethical standard, not a legal one.
Doesn't that depend on whether it was coded that way intentionally or by error?
By your logic, a SQL injection where a web form causes arbitrary commands to be executed against a database is not a vulnerability either because it's "coded to work that way". I think in more clear terms, if it grants the user permissions in excess of those specified by the design, then it's clearly a vulnerability.
So to go back to these bunch of idiots, it seems that they might have intended to make each request available only to the recipient.
Hello rude internet stranger!
I reread my comment very closely, and I don't see where I indicated that I think his actions were criminal. To me, it seems quite clear from what I actually wrote that all the parties involved were quite stupid in their own various ways. But please do point out where I inadvertently gave the wrong impression that I think his actions were criminal and I would be happy to correct it.
I would also like to add that I have a decent understanding not only of digital communications, but of the ethics of responsible disclosure and how they should be applied by security researchers that find (even very stupid) vulnerabilities.
Responsible disclosure is a fundamental principle of ethical security work. It balances the need to give the vendor a time window to fix it, the right of the public to know, and the researcher's right to publish their findings.
Also, I think it's amusing that you think I'm apologizing for the stupid authorities by calling both the authorities and the kid stupid, when the entire point of my post is that stupidity is neither finite nor conserved. Saying that he is dumb does not imply they are any less dumb. Everyone is dumb! Yay!
Just because the government is guilty of criminal stupidity doesn't make every other party more correct. Because (hear me out) sometimes everyone involved in a situation is pretty stupid all at once.
The government was criminally negligent in not securing resources.
The kid was criminally stupid in not reporting the vulnerability through the responsible disclosure contact
The government was probably criminally negligent in not publicizing the security contact
The kid was criminally stupid in archiving the data instead of working towards fixing the problem
Stupidity isn't finite, one party having more of it doesn't make the rest have less. It's an infinitely renewable resource.
You are very confused. The RtbF is the right to demand that others remove or delist content that they created about you. For instance, let's say a journalist from the BBC wrote an article detailing your white collar fraud conviction and subsequent appeal. In any reasonable sense, we could say that this article belongs to the BBC.
The Right to be Forgotten says that John Disley has the right to make Google delist this article so that it does not show up when someone searches for his name. It's not his article, it's not Google's article -- the article belongs to the BBC but the RtBF says that he has the right to have Google delist it.
It is very confused to equate this with the idea that if John Disley writes an email, it's at least plausible that he could request that it be deleted by the recipient after reading it.
[ Note: the BBC helpfully publishes a list of all RtbF articles so you can see for yourself what sort of things are requested to be delisted and make your own informed decision. ]
Well, you're not really asking that the system never have priority over the user. You're asking that your interactive task have priority over everything else. The system is responsible for reading what you type on the keyboard, for example, so in that case the system should have a very high priority so that it can service your interactive task.
If only it was so simple, but in fact it's far worse than this. Not only does the OP want the interactive task to have priority to all possible resources over everything else, but that this priority inherits from this task to every task that is blocking it, including those access over all possible inter-task-communication methods. At the very minimum, it means that all of those IPC mechanisms need to be 'priority aware' and the kernel needs to arbitrate this correctly. It also means that all tasks must migrate away from any IPC mechanisms that don't have the structure to encapsulate the concept of a 'blocking request' -- shmem probably has to go.
In other words, it's not enough to give my topmost process the highest priority to the disk, but if that process reaches to any other process, say a system service, then that process must, for the lifetime when it is services the request from the topmost process, also (temporarily) be granted highest disk priority. In a POSIXy world where processes often connect via (local, not AF) sockets, this means that the socket mechanism itself needs to somehow figure out if the request is blocking or if it is 'background priority'.
The fixed costs of regulation are spread against the total scale of the business being regulated. The larger the fixed costs, the more this implicitly helps the largest incumbents and disadvantages upstarts with small market share.
The GDPR is 261 pages of incomprehensible legalese (and people still can't figure basic questions about it), which will cost you the same in lawyer fees to understand whether you have 1M customers or 1B.
So yeah, Facebook has no damned problem if you regulate and probably stands to gain in the long terms whatever they lose in the short term.
Of course you can. Did you ever read the damned FIDO specification?!
If you did, you'd realize that FIDO does not directly bind the biometric with the webpage. Rather it creates a asymmetric key pair (separate for each verifier) that allows the verifier to do a challenge response. This lets the verifier verify that the person trying to log in is the same person that associated the public key with the account at the time of enrollment.
The biometric part only enters into the stage in terms of protecting the private key. Some implementations can, for instance, put the private key on a dongle-thingy and require a fingerprint to allow a single signature to be produced. Others might be like YubiKey and just require you to press the button to confirm you are physically in possession. If you'd like, you can write a fully conforming implementation that holds the public key encrypted
In all cases, you can easily revoke the credential from the webpage just by asking them to forget the public key associated to the account (or even nuke all keys associated to the account).
Honestly, the answer to the question "can people be this idiotic" is usually no. I mean, sure idiotic things happen, but to think that a major consortium of big players didn't think through the most obvious concerns about revocation or compromise is just nonsense.
Back Page was actually providing a way for sex workers to operate without criminals managing them.
It was also providing a way for criminals that "manage" sex workers to more efficiently sell them. And it's not just regressive laws that allow pimps, it's also the fact that it is cheaper and easier to coerce the vulnerable with drugs/threats/violence than to deal with people that demand their rights.
Why can't we get it in our heads that the real world does not operate according to a narrative. BackPage was both empowering for independent sex workers (a good thing) and empowering for violent pimps (a bad thing). It was neither wholly good nor wholly evil.
I'm all for legalizing prostitution, having rigorous protection for sex workers and the whole progress shebang, but I'm not at all convinced that the majority of what happened on BP was above-board.
I'm going to assume you're a smart dude, so I think it's fairly clear that you know that just because the spec is not released publicly does not mean that it does not exist.
Possible explanation #1: they intentionally killed the functionality of third party chips.
Possible explanation #2: some third party chips were not actually up to spec in some subtle way, which wasn't an issue before.
Both seem fairly plausible. I didn't see anything in TFA that gave a solid reason to believe one or other.
Gee, that would date this code to about the same time we were doing the POSIX standards that codified a (then) 20 year old Unix interface.
Gee, that didn't define an entire GUI/Windowing system.
Don't get me wrong, I love POSIX as much as the next guy, but it's a far more limited thing than WIN32. The closest NIX comparison would be GTK, I think.
Which just moves the problem to how you deliver the PIN associated to the new card.
But sure, once you've established that you can transmit the PIN from the bank to the (correct) customer without anyone else reading it, then you can use that to solve other problems :-)
4.Can there be transparent, accountable oversight from an independently constituted ethics board or similar entity with both the power to veto aspects of the program and the power to bring public transparency to issues where necessary or appropriate?
What in the world are they smoking (and can I get some, it must be goooood shiiiit)? In what reality do they believe that the design of military systems is subject to veto from a non-democratically- accountable entity? From where does this board derive any mandate to be making public policy?
I'm not against the goal here of having some ethics review. But there's a large gap between 'there should be an ethics board' and 'some dudes in Silicon Valley self-appointed themselves to veto the decisions of our elected government'.
I read through TFA and the submitted patch, but it's not actual clear what the flaw was. I figured /. would like to some full description rather than vague handwaving.
In the sense that it doesn't have anything to do with the underlying technology at all. It's a weakness in the activation/verification scheme in that it verifies that the cardholder received something, not that they have received the genuine card.
An easy way to 'close the loop' would be to perform the activation at an ATM that could verify the authenticity of the chip. Then the 'activation' of the card would be tied to positive proof that the rightful owner had possession of it.
They are out of touch with what geeks want.
Probably due to lack of desire/effort. A business can get by just fine without targeting a specific audience in order to have strategic focus on their core customers.
This is like saying that Budweiser is out of touch with craft beer consumers, even though microbrew is clearly better than mass produced.
No, the outage began years ago when someone created a process in which a human being manually enters data directly into a production system.
I swear, if I had a nickel for every time a major fuckup was root caused to "human error in a process that should have never had a human factor to begin with", I could buy a house in the Bay Area.
True, but honestly, what good is that?
For more than a decade, we've been beyond the point where competent folks can secure their machines. The challenge now is to make it the default behavior so that anyone can run a secure user machine without effort.
Besides being excellent for the incompetent, accomplishing this challenge also frees up the competent to apply their competence to other tasks. That is, it's a benefit for everyone the intellectual effort required to accomplish a task is reduced.
Someone said the measure of civilization is the number of things you can do without thinking about them. My hope is that, in time, secure computing becomes one of those things.