Verizon isn't in a position to figure out whether the info is being maliciously spoofed or not. There's lots of legitimate reasons to spoof the CID data so it differs from the ANI or billing data. Calls from a large business, for instance, where the outgoing lines are distinct from the incoming lines and you want the CID to refer to the number the receiver can call to reach the business. Calls from a call center serving multiple clients, too, where it's better to have the CID reflect the number assigned to that client for customer-service calls rather than the call center's outgoing-line bank. There's no way for Verizon to distinguish those cases from someone spoofing a number for malicious purposes, unless Verizon is actually the company the spoofer is using and they know who the spoofer is and what their business is.
This wasn't a problem back in the day when you needed a T1 or larger connection to be able to set CID data on outgoing calls, but nowadays anybody using SIP effectively has a direct T1 connection and can run their own PBX with all the capabilities of a commercial setup.
The problem is that the spoofing happens at the spoofer's end, and they aren't using Verizon so Verizon can't do a thing about it. You'd have to talk to the telco the spoofer uses for their line, and they have no incentive to do anything because the person complaining isn't a paying customer and the spoofer is. The only real solution is what we did with email spam with blacklists of entire providers. (NB: no it didn't eliminate email spam, but it cut it down significantly and made it a whole lot easier to filter out before the mail server had to receive it.)
My experience is that large corporations want security and compliance. What they don't want to do is actually change anything to achieve it, especially if that changing happens on anything other than their schedule. Updating dependencies to fix security issues means having to revalidate and recertify the entire software stack, after all, and they want to avoid that at all costs. They'll only grudgingly do it when some outside agency credibly threatens them with fines and penalties that exceed the cost of the recertification. This is particularly silly since if you keep up with updates regularly it's a relatively painless process that usually doesn't break anything and if it does you've got plenty of time to fix it on your schedule. It only becomes an issue when you've avoided updates for so long that your versions of the dependencies are obsolete/unsupported and the current versions have major API redesigns or have been completely replaced by something with a different API. That's when it gets painful.
This is what happens when maintenance is considered a cost center rather than a necessary aspect of earning revenue. It's like considering janitorial services to be a cost center: pretty quick your business gets filthy and nobody wants to come in the door.
Even 99% accurate is absolutely horrid for real-life situations. Let's take a case where one in a thousand items encountered are dangerous. I'm going to scale the numbers to make the results come out as integers. At 1 in 1000, if we start with 100,000 items we'll have 100 dangerous items and 99,900 non-dangerous. Of the dangerous items, the system will flag 99 as dangerous and 1 as non-dangerous. Of the non-dangerous items, the system will flag 98,901 as non-dangerous and 999 as dangerous. So out of 1,098 items flaged as dangerous, 90.98% of them will be non-dangerous. So a system that claims a 99% accuracy rate will have a 91% error rate when it comes to sounding the "Danger!" alarm. Only 9% of the time will that alarm actually indicate danger, the other 91% of the time it's a false alarm.
The above is why 5-nines (99.999% accuracy) is the baseline for workable systems.
Seriously. When someone else owns and operates your infrastructure, things like this are going to happen. When that someone earns their revenue from something other than the bill from them you pay every month, it's going to happen a lot more often because they'll be acting based on what's good for their business, not what's good for yours. This is life on any cloud platform. This was life with mainframe service bureaus back when they were the cloud platform of choice.
You have to make a call based on what the trade-offs are. Make sure you know what those trade-offs are going to be, bearing in mind that any contract you have is probably going to say the provider's only responsible for refunding your month's payment no matter what the cost to you of their mistake was. It's that that you're balancing against the cost of running your own hardware, not the monthly bill.
Webasm isn't progress, it's regress. It's a new way to run untrusted code from an unknown outside source directly on your CPU, which'll end up in the same place every other method for doing this has: being a source for an unending series of remote attacks until browser makers disable it. I'd've thought we'd've learned from previous iterations, but apparently some people are incapable of learning from other people's mistakes.
Both names are reasonable acronyms. I don't think there's anything malicious, just the normal problem when two entities pick entirely reasonable names and the acronyms collide. It'll work itself out like it always does: people will modify one or both acronyms to clear it up and MS and the Gnome project will live with it.
It shouldn't've been too hard to come up with standards. The Navy flies aircraft with folding wings daily, and we're talking the entire wing folds so the hinge and locking mechanism have to handle the full load of high-G combat maneuvers, I'd imagine the FAA could simply grab the Navy's standards and edit them down to remove the parts only relevant to combat aircraft. That'd cover the wingtip lock status indicator too, all naval folding-wing aircraft have them so the pilot knows if his wings are safe to launch with.
Exactly. Asimov's "Robots" stories are an exercise in exploring how and why the 3 Laws fail in practice. That Asimov found material for so many stories in that suggests that using the 3 Laws as the basis for programming robots is a supremely bad idea. Maybe, until we figure out AI well enough to develop machines who we can trust the way we trust other humans, we should avoid fielding machines that might need such rules.
Yes. That should though be handled by the message signature, not the encryption. If you care about the integrity of the encrypted message you should sign it (S/MIME or PGP) as well as encrypting it. The client may ignore the MDCs in the encryption, but a failed S/MIME or PGP signature on the same message will show as an error independent of that.
They don't manipulate the encrypted message itself. They manipulate the unencrypted message containing the encrypted message, adding blocks of HTML before and after it that make the encrypted message appear to be part of a URL referring to an external resource like an image. It relies on eg. the practice of many email clients of stitching together multiple HTML sections in a multi-part message into a single HTML part and rendering that instead of the original multiple parts.
The vulnerability can be mitigated externally by implementing DKIM on the sending domain. When the message is altered by the attacker, DKIM signature validation will fail and the message will be flagged as having been altered. Combined with turning off fetching of remote content (the default in most mail clients these days) it allows detection of the attack and prevents data disclosure.
If SD wins, the first question every one of those online merchants will have for them is "What's the contact point for authoritative real-time-response data on what the applicable tax rate is for any address in South Dakota?". Because if SD expects those retailers to collect sales tax, SD has to be able to tell those retailers what tax they should collect for any given transaction. For a physical retailer it's easy, the tax is determined by the retailer's physical location and the buyer's address is irrelevant. SD's proposed scheme isn't nearly so neat and tidy, and why should it be the retailer's responsibility to figure out SD's mess for them?
And no, ZIP code isn't sufficiently granular for some places. I know places where there are 2 and sometimes 3 sales tax rates within the same ZIP code because that ZIP code spans local borders (half the ZIP code's within a city and collects city plus county in addition to state sales tax, the other half lies outside the city limits and collects only county and state sales tax, and one corner of what's within the city is within an additional tax district while the rest isn't).
After SD sorts that question out, the next one will be "OK, so now that we've collected the taxes, who do we talk to at your end to get the authoritative list of where to send the checks to for each taxing authority and the determination of which taxing authorities are owed taxes at what rate for each transaction?". Followed soon by "We appreciate the amusement value of the gibbering noises and screeches, but serious guys if you want us to remit your money you need to tell us how much to remit to who.".
It's hard to design a system that's completely lacking in vulnerabilities. It's not hard, however, to design a system where the vulnerabilities are only on the end-user devices. We already have cryptosystems that don't require you to publish anything that's not safely completely public, which makes key exchanges on a single network fairly straightforward. The only complex part is if you want arbitrary parties to be able to make contact without having any data in a central address book that could be used to infer identity.
Because too many network admins don't bother to read and implement BCP 38 on top of too many network admins leaving memcached servers publicly accessible.
You're still talking about people, while the article is talking about the tools (technology) rather than people. And no matter how many ethical systems we create, no amount of ethical behavior on the part of the tool creators can force tool users to behave ethically.
And you just made my point. It's right there in the plural. If we have multiple ethical systems, which one do we impose on the tools? We can only impose one, the tool can't decide which one to apply on it's own, so how do you get everyone in the world to agree on just one of those multiple ethical systems? Hells, we can't even get everyone in any one country to agree on just one ethical system even when we're talking about a small homogeneous country like Vatican City.
Tools aren't inherently good or bad. An axe can be used to cut wood for a fireplace, or it can be used to kill someone. Or it can take the user's leg off at the knee if used carelessly. Technology and software are just tools. They make doing things more efficient. What they're applied to, however, isn't something the tool can control. It's what use the user makes of the tool that's good or bad.
And yes, that's independent of the tool. Take the atomic bomb. Supposedly good only for mass destruction, you'd think? Well yes, the bomb may be. But the exact same principles and science behind the bomb are also behind the manufacture of radioactive sources for medical imaging and the treatment of cancer. The two are inseparable, you can't make it so you can manufacture isotopes for medical uses but somehow make it so you can't manufacture a bomb. And no you can't somehow make the knowledge needed to make an atomic bomb unobtainable, because all it takes is the basic knowledge of nuclear physics and a lot of time to crunch the numbers and work through the equations.
Ethics classes are well and good, and a necessary part of any engineer's education. But in the end it comes down to this: anything capable of being useful is capable of being dangerous, and humans being humans there's always going to be someone who'll turn any tool to a bad use. The only solution I can see involves forcibly making every human being behave ethically, and I don't see any acceptable way of doing that. For one thing, even ignoring the truly evil and the criminal, we can't even agree on what "ethical" means in concrete terms. Is it ethical to ever use lethal force to defend yourself, and if so under what constraints? Is it ethical to demand that residents of a community follow the community's rules, and if so what should be the extent of the community's rule-making authority? Is it ethical to require your employees to work around potentially-dangerous equipment, and if so what are your obligations towards them when they're doing what you require of them? Given that we can't settle those sorts of disagreements I just don't see how we can define "ethical" in concrete enough terms to apply at the tool level while still allowing the tools to be useful to us.
More open-source funding won't help reduce breaches. It'd be good to have more funding for development of the basic software, but most of these breaches happen because, despite a patch to fix the vulnerability being available, these companies treat simply don't apply the available patches. Until that stops being the case, more funding for the software will merely mean the breaches happen in different places than they would've otherwise.
Oh, and don't hold the sysadmins responsible. They're at the mercy of the instructions they're given. The people who need held accountable are the executives who classify IT security as a cost center whose budget needs minimized and breaches as a public-relations problem instead of a security issue and who refuse to give the IT people enough budget and resources and authority to apply fixes promptly.
You make my point for me. If they don't care whether we see them or not, then why are the only hints we get of them vague and ambiguous sightings at a distance? You'd think we'd get clear looks at them all the time like we do airliners.
And no, we're not very impressive-looking as a species. But name one predator on this planet which successfully makes humans it's primary prey. Don't worry, I'll wait.
I'd have to think that any civilization advanced enough to have interstellar travel would at least be able to match our own ability at stealthing atmospheric craft (including basic things like turning off the running lights and not flying during the daytime when they'd be easily seen). I also know how easy it is for people to get confused about what they're seeing when they know what they're seeing, let alone when they don't. And I can't see any motivation for extraterrestrial visitors to let themselves be seen without making their presence irrefutably known.
Conclusion: people were misinterpreting perfectly ordinary things for UFOs.
NB: this doesn't preclude us having extraterrestrial visitors. It just says that if you're not one of the ones they've decided to deal with directly then you're not going to see any hint that they're around.
There is such a law, but it wasn't the FCC that got it passed. The law is the Telecommunications Act of 1996, which was passed in large part to take governance of the telecommunications industry away from the US District Court for the District of Columbia (fallout from the 1956 consent decree against AT&T) and into the FCC. That law is what gave the FCC the authority to classify services as either telecommunications services or information services.
Because security is a cost center while new features are a revenue center. The executives who ultimately decide priorities, budgets and schedules are taught to minimize costs while maximizing revenue. The results are, obviously, highly predictable if supremely disappointing.
Slashdot Mirror
Verizon isn't in a position to figure out whether the info is being maliciously spoofed or not. There's lots of legitimate reasons to spoof the CID data so it differs from the ANI or billing data. Calls from a large business, for instance, where the outgoing lines are distinct from the incoming lines and you want the CID to refer to the number the receiver can call to reach the business. Calls from a call center serving multiple clients, too, where it's better to have the CID reflect the number assigned to that client for customer-service calls rather than the call center's outgoing-line bank. There's no way for Verizon to distinguish those cases from someone spoofing a number for malicious purposes, unless Verizon is actually the company the spoofer is using and they know who the spoofer is and what their business is.
This wasn't a problem back in the day when you needed a T1 or larger connection to be able to set CID data on outgoing calls, but nowadays anybody using SIP effectively has a direct T1 connection and can run their own PBX with all the capabilities of a commercial setup.
The problem is that the spoofing happens at the spoofer's end, and they aren't using Verizon so Verizon can't do a thing about it. You'd have to talk to the telco the spoofer uses for their line, and they have no incentive to do anything because the person complaining isn't a paying customer and the spoofer is. The only real solution is what we did with email spam with blacklists of entire providers. (NB: no it didn't eliminate email spam, but it cut it down significantly and made it a whole lot easier to filter out before the mail server had to receive it.)
My experience is that large corporations want security and compliance. What they don't want to do is actually change anything to achieve it, especially if that changing happens on anything other than their schedule. Updating dependencies to fix security issues means having to revalidate and recertify the entire software stack, after all, and they want to avoid that at all costs. They'll only grudgingly do it when some outside agency credibly threatens them with fines and penalties that exceed the cost of the recertification. This is particularly silly since if you keep up with updates regularly it's a relatively painless process that usually doesn't break anything and if it does you've got plenty of time to fix it on your schedule. It only becomes an issue when you've avoided updates for so long that your versions of the dependencies are obsolete/unsupported and the current versions have major API redesigns or have been completely replaced by something with a different API. That's when it gets painful.
This is what happens when maintenance is considered a cost center rather than a necessary aspect of earning revenue. It's like considering janitorial services to be a cost center: pretty quick your business gets filthy and nobody wants to come in the door.
Even 99% accurate is absolutely horrid for real-life situations. Let's take a case where one in a thousand items encountered are dangerous. I'm going to scale the numbers to make the results come out as integers. At 1 in 1000, if we start with 100,000 items we'll have 100 dangerous items and 99,900 non-dangerous. Of the dangerous items, the system will flag 99 as dangerous and 1 as non-dangerous. Of the non-dangerous items, the system will flag 98,901 as non-dangerous and 999 as dangerous. So out of 1,098 items flaged as dangerous, 90.98% of them will be non-dangerous. So a system that claims a 99% accuracy rate will have a 91% error rate when it comes to sounding the "Danger!" alarm. Only 9% of the time will that alarm actually indicate danger, the other 91% of the time it's a false alarm.
The above is why 5-nines (99.999% accuracy) is the baseline for workable systems.
Seriously. When someone else owns and operates your infrastructure, things like this are going to happen. When that someone earns their revenue from something other than the bill from them you pay every month, it's going to happen a lot more often because they'll be acting based on what's good for their business, not what's good for yours. This is life on any cloud platform. This was life with mainframe service bureaus back when they were the cloud platform of choice.
You have to make a call based on what the trade-offs are. Make sure you know what those trade-offs are going to be, bearing in mind that any contract you have is probably going to say the provider's only responsible for refunding your month's payment no matter what the cost to you of their mistake was. It's that that you're balancing against the cost of running your own hardware, not the monthly bill.
Webasm isn't progress, it's regress. It's a new way to run untrusted code from an unknown outside source directly on your CPU, which'll end up in the same place every other method for doing this has: being a source for an unending series of remote attacks until browser makers disable it. I'd've thought we'd've learned from previous iterations, but apparently some people are incapable of learning from other people's mistakes.
Both names are reasonable acronyms. I don't think there's anything malicious, just the normal problem when two entities pick entirely reasonable names and the acronyms collide. It'll work itself out like it always does: people will modify one or both acronyms to clear it up and MS and the Gnome project will live with it.
It shouldn't've been too hard to come up with standards. The Navy flies aircraft with folding wings daily, and we're talking the entire wing folds so the hinge and locking mechanism have to handle the full load of high-G combat maneuvers, I'd imagine the FAA could simply grab the Navy's standards and edit them down to remove the parts only relevant to combat aircraft. That'd cover the wingtip lock status indicator too, all naval folding-wing aircraft have them so the pilot knows if his wings are safe to launch with.
Exactly. Asimov's "Robots" stories are an exercise in exploring how and why the 3 Laws fail in practice. That Asimov found material for so many stories in that suggests that using the 3 Laws as the basis for programming robots is a supremely bad idea. Maybe, until we figure out AI well enough to develop machines who we can trust the way we trust other humans, we should avoid fielding machines that might need such rules.
Yes. That should though be handled by the message signature, not the encryption. If you care about the integrity of the encrypted message you should sign it (S/MIME or PGP) as well as encrypting it. The client may ignore the MDCs in the encryption, but a failed S/MIME or PGP signature on the same message will show as an error independent of that.
They don't manipulate the encrypted message itself. They manipulate the unencrypted message containing the encrypted message, adding blocks of HTML before and after it that make the encrypted message appear to be part of a URL referring to an external resource like an image. It relies on eg. the practice of many email clients of stitching together multiple HTML sections in a multi-part message into a single HTML part and rendering that instead of the original multiple parts.
The vulnerability can be mitigated externally by implementing DKIM on the sending domain. When the message is altered by the attacker, DKIM signature validation will fail and the message will be flagged as having been altered. Combined with turning off fetching of remote content (the default in most mail clients these days) it allows detection of the attack and prevents data disclosure.
If SD wins, the first question every one of those online merchants will have for them is "What's the contact point for authoritative real-time-response data on what the applicable tax rate is for any address in South Dakota?". Because if SD expects those retailers to collect sales tax, SD has to be able to tell those retailers what tax they should collect for any given transaction. For a physical retailer it's easy, the tax is determined by the retailer's physical location and the buyer's address is irrelevant. SD's proposed scheme isn't nearly so neat and tidy, and why should it be the retailer's responsibility to figure out SD's mess for them?
And no, ZIP code isn't sufficiently granular for some places. I know places where there are 2 and sometimes 3 sales tax rates within the same ZIP code because that ZIP code spans local borders (half the ZIP code's within a city and collects city plus county in addition to state sales tax, the other half lies outside the city limits and collects only county and state sales tax, and one corner of what's within the city is within an additional tax district while the rest isn't).
After SD sorts that question out, the next one will be "OK, so now that we've collected the taxes, who do we talk to at your end to get the authoritative list of where to send the checks to for each taxing authority and the determination of which taxing authorities are owed taxes at what rate for each transaction?". Followed soon by "We appreciate the amusement value of the gibbering noises and screeches, but serious guys if you want us to remit your money you need to tell us how much to remit to who.".
What next, evacuating an entire shopping mall because someone wrote "Bomb" on a sticky note and slapped it on a garbage can?
It's hard to design a system that's completely lacking in vulnerabilities. It's not hard, however, to design a system where the vulnerabilities are only on the end-user devices. We already have cryptosystems that don't require you to publish anything that's not safely completely public, which makes key exchanges on a single network fairly straightforward. The only complex part is if you want arbitrary parties to be able to make contact without having any data in a central address book that could be used to infer identity.
Because too many network admins don't bother to read and implement BCP 38 on top of too many network admins leaving memcached servers publicly accessible.
Didn't we go through this before with HTML, remote content, scripts and the like in email? That worked out so well, after all.
You're still talking about people, while the article is talking about the tools (technology) rather than people. And no matter how many ethical systems we create, no amount of ethical behavior on the part of the tool creators can force tool users to behave ethically.
And you just made my point. It's right there in the plural. If we have multiple ethical systems, which one do we impose on the tools? We can only impose one, the tool can't decide which one to apply on it's own, so how do you get everyone in the world to agree on just one of those multiple ethical systems? Hells, we can't even get everyone in any one country to agree on just one ethical system even when we're talking about a small homogeneous country like Vatican City.
Tools aren't inherently good or bad. An axe can be used to cut wood for a fireplace, or it can be used to kill someone. Or it can take the user's leg off at the knee if used carelessly. Technology and software are just tools. They make doing things more efficient. What they're applied to, however, isn't something the tool can control. It's what use the user makes of the tool that's good or bad.
And yes, that's independent of the tool. Take the atomic bomb. Supposedly good only for mass destruction, you'd think? Well yes, the bomb may be. But the exact same principles and science behind the bomb are also behind the manufacture of radioactive sources for medical imaging and the treatment of cancer. The two are inseparable, you can't make it so you can manufacture isotopes for medical uses but somehow make it so you can't manufacture a bomb. And no you can't somehow make the knowledge needed to make an atomic bomb unobtainable, because all it takes is the basic knowledge of nuclear physics and a lot of time to crunch the numbers and work through the equations.
Ethics classes are well and good, and a necessary part of any engineer's education. But in the end it comes down to this: anything capable of being useful is capable of being dangerous, and humans being humans there's always going to be someone who'll turn any tool to a bad use. The only solution I can see involves forcibly making every human being behave ethically, and I don't see any acceptable way of doing that. For one thing, even ignoring the truly evil and the criminal, we can't even agree on what "ethical" means in concrete terms. Is it ethical to ever use lethal force to defend yourself, and if so under what constraints? Is it ethical to demand that residents of a community follow the community's rules, and if so what should be the extent of the community's rule-making authority? Is it ethical to require your employees to work around potentially-dangerous equipment, and if so what are your obligations towards them when they're doing what you require of them? Given that we can't settle those sorts of disagreements I just don't see how we can define "ethical" in concrete enough terms to apply at the tool level while still allowing the tools to be useful to us.
More open-source funding won't help reduce breaches. It'd be good to have more funding for development of the basic software, but most of these breaches happen because, despite a patch to fix the vulnerability being available, these companies treat simply don't apply the available patches. Until that stops being the case, more funding for the software will merely mean the breaches happen in different places than they would've otherwise.
Oh, and don't hold the sysadmins responsible. They're at the mercy of the instructions they're given. The people who need held accountable are the executives who classify IT security as a cost center whose budget needs minimized and breaches as a public-relations problem instead of a security issue and who refuse to give the IT people enough budget and resources and authority to apply fixes promptly.
You make my point for me. If they don't care whether we see them or not, then why are the only hints we get of them vague and ambiguous sightings at a distance? You'd think we'd get clear looks at them all the time like we do airliners.
And no, we're not very impressive-looking as a species. But name one predator on this planet which successfully makes humans it's primary prey. Don't worry, I'll wait.
I'd have to think that any civilization advanced enough to have interstellar travel would at least be able to match our own ability at stealthing atmospheric craft (including basic things like turning off the running lights and not flying during the daytime when they'd be easily seen). I also know how easy it is for people to get confused about what they're seeing when they know what they're seeing, let alone when they don't. And I can't see any motivation for extraterrestrial visitors to let themselves be seen without making their presence irrefutably known.
Conclusion: people were misinterpreting perfectly ordinary things for UFOs.
NB: this doesn't preclude us having extraterrestrial visitors. It just says that if you're not one of the ones they've decided to deal with directly then you're not going to see any hint that they're around.
There is such a law, but it wasn't the FCC that got it passed. The law is the Telecommunications Act of 1996, which was passed in large part to take governance of the telecommunications industry away from the US District Court for the District of Columbia (fallout from the 1956 consent decree against AT&T) and into the FCC. That law is what gave the FCC the authority to classify services as either telecommunications services or information services.
Yes, there are actual standards: https://cabforum.org/documents...
Because security is a cost center while new features are a revenue center. The executives who ultimately decide priorities, budgets and schedules are taught to minimize costs while maximizing revenue. The results are, obviously, highly predictable if supremely disappointing.