Last I checked, the Federal Government didn't run any of the root nameservers so I can't see any way they could be considered to belong to the US (as opposed to the private companies that own them). Not that owning the roots would mean much, since all they do is identify the (privately-owned) nameservers belonging to the various (privately-owned) registries that control the top-level domains. The only TLDs owned by the US Government (ie. the US Government operates the registries for them) are.gov and.mil, and the changes to IANA won't change how those two registries operate.
And amusingly the politicians have it backwards: ICANN already manages IANA, the change will be to remove IANA from ICANN control and make it an independent authority in it's own right. IANA was put under ICANN control in 1998, after the death of Jon Postel who basically had been IANA up until then (a controlling authority for assigning IP address blocks, well-known port numbers, AS numbers and other technical identifiers was absolutely necessary for the Internet to function, and since nobody else was doing it Jon essentially arrogated to himself the authority to handle it).
HTTP has had this forever: challenge/response authentication. There's one problem with it though: it requires storing the plaintext password on the server so it can be used to encrypt the challenge to check against the client's response. I don't know of any challenge/response algorithm that works with one-way hashes of passwords.
My approach would be to dump IoT devices in their own dedicated subnet and exclude that subnet from forwarding across the router. That reduces the exposure to just the router, and I can monitor the iptables logs for dropped packets to/from that subnet that represent attempts to do something suspicious. Configuration doesn't have to be hard, instead of plugging devices directly into the router's switch you plug devices in to external switches, connect those switches to router ports and set each port to what kind of devices hang off it. That'd control the VLAN setup to give each kind of device (WiFi, LAN, IoT) it's own virtual interface. Configuration for the firewall, DHCP, DNS etc. follows from that (you may not want to allow the IoT subnet access to external DNS, for instance). This takes a bit to set up in the firmware, but the DD-WRT/OpenWRT firmware all the major router manufacturers seem to use for their consumer routers has all the tools and then some and once the user interface is there using the functionality isn't that hard.
The White House is hesitating over making any accusations along these lines because they know full well that if you make those accusations you'd better be able to back them up and the evidence to back them up is almost impossible to get. We may know that the Russians are behind it, but I doubt we've got the evidence to actually prove it to any acceptable standard and if we go off making official accusations without being able to prove them we're going to look like fools.
I don't know about elsewhere, but in California when you buy any sort of large electronics (TV, computer, monitor, etc.) there's a recycling fee added as a line item on the receipt to cover recycling the device when it's discarded. Recyclers in California should be getting paid for every device they take with money that's already been collected for that purpose. Maybe that recycling fee needs to be increased and applied nation-wide, with payment going only to those recyclers who actually recycle the equipment and can prove it.
Besides, it should be an SRV record, not a TXT record, so that it can include what host and port the API endpoint is at without having to parse free-form text.
Pokemon Go will probably follow the same path as Ingress has. Most players will be casual, but the really dedicated will be really dedicated. They'll probably introduce something akin to Ingress' Anomalies, which'll be big cash cows as players treat them as a holiday splurge-type thing.
This'll work fine for very simple apps, ones that only require standardized functionality. But then, with an app like that, do you really need to develop a custom one for any reason other than branding/appearance? And it'll work for disposable apps, ones that do the current job but don't need to be maintained or enhanced down the road. That's been true forever, it's why spreadsheets and word processors had macro languages so secretaries and accountants could do simple operations and calculations without needing to have the programming team get involved. But the moment you start dealing with an app with complex functionality that has to be changed, enhanced and extended over time, that's when you'll discover that you need software engineers. It's the same reason anybody who can grab a hammer and saw can cobble together a sawhorse that'll work for one job, but you need someone who understands architecture and construction to build a house that's expected to last for decades.
Those conversions look like cases where the column type during import was left at "General" instead of being set to "Text" as it should have been, telling Excel to try and infer the actual type from the format of the column's contents. It's an awkward situation where the user should be telling Excel what the data type for each column is, but it's not strictly Excel's fault for doing what the user told it to do. IMO Excel should be either changed to not have a default type and to not allow an import until the user's selected a type for each column, or it should throw up an error if it infers different data types for a column for different rows.
They won't automate software development until they come up with a system that can handle creating correct software from incomplete and partially erroneous specifications which don't remain constant between the start of development and delivery. At best they'll be able to automate some of the tedious boilerplate coding.
Big problem here: a lot of software where the functionality could be reused can't be reused because it wasn't written for reuse. It'll have a lot of instance-specific code scattered throughout, for example logging functions that're specific to the system it was first written to run in. The result is it's easier and faster to write it from scratch than to try and remove the instance-specific code from the original source to make it suitable for use somewhere else. An open-source policy doesn't need just a mandate for reuse, it needs a mandate for making software reusable at the time it's written. That, unfortunately, is something any developer can tell you is really hard to get management to agree to.
That's easy to check. During an election you pick a sample of random precincts, set their actual ballots aside and in their place submit an identically-sized set of ballots which are randomly-generated but known. Have those random ballots created and checked/counted by independent groups so it'd be infeasible for any one entity to control both the vote-counting software and the random-ballot generation process. If the reported count for those precincts isn't exactly identical to the known count, there's been tampering with the counting software. Then you can submit the actual ballots for those precincts as a correction, replacing the random ballot counts, and proceed as usual.
The problem isn't so much that the ballot itself isn't secure, it's that the authentication of the voter isn't reliable so the identity of whoever cast the ballot isn't secure. The only ways to make that authentication reliable involve encoding the identity of the voter into the cast ballot, which blows away the whole idea of secret ballots so nobody can confirm how you voted.
It's possible to do it, but you'd need a) a state-issued smartcard with a unique key-pair assigned to that specific individual capable of encrypting and signing arbitrary blocks of data, and b) a front-end system that'd accept the voter-signed ballot, verify the signature and contents, strip the voter's signature and replace it with one from the election authority, and this system would have to be trusted not to record anything tying voter identities to ballots and verifiable so that anybody could confirm that not only was the system actually trustable but that the running software was generated from the verified code. That's a non-trivial system to set up.
In these companies' position, I'd respond "Sure, we'll provide a way to block infringing content. You'll merely have to present a judgment from a court of competent jurisdiction stating that that content has been found to be infringing. We aren't a court, we're not going to hear cases and make rulings like one.". When the whines start, I'd go "Oh, you want it blocked because you allege it's infringing? OK, we can do that. We'll block any content that anyone alleges infringes on their copyrights until presented with a court ruling saying it isn't infringing. But again we aren't a court, we will not get into the business of hearing cases and making rulings on whether the evidence supports the allegation or not.".
The recommendation doesn't make sense. Yes, your phone may not always be in your possession. That would rule out software authenticators too, since they reside on the same phone that may not always be in your possession. Even dedicated hardware tokens may not always be in your possession, they can be lost or stolen just like a phone. So if not being always in your possession is the criteria, then all of the NIST's recommended methods fail to meet it.
As for VoIP lines, yes they can be intercepted. They do however share one characteristic with cel-phone lines: they don't normally share a path with the network connection being authenticated except possibly at the user's ISP and computer (if the VoIP line terminates on their computer as opposed to their cel phone). That limits the ability of a single attacker to intercept and alter both paths, which is the central facet of what 2FA does.
Ultimately the only secure 2FA is a dedicated hardware token that requires biometric authentication to function. Anything less than that is insecure, the question being merely whether the insecurity reaches the point of being unacceptable.
Or it may be related to the reliability of recovering from backups. Backups are intended to recover from catastrophic failures, not mere accidental deletion of messages, so recovery of any particular message can be problematic. Even if the message was stored long enough to be caught in a backup, incremental backups mean it may take searching a month's worth of backups to find the exact one that backed up that message. Fail to scan a large enough range and you won't find the message even if it's backed up. If the message was received and then deleted before the next backup run then it may not be on any backup, and there's no way to distinguish not finding it because it wasn't backed up from not finding it because you didn't search the right set of backups. Explaining all that to ordinary users is all but impossible, so from a service-level standpoint it makes more sense to not bring backups up at all and simply say "If you deleted it, we can't recover it.". That, users can comprehend even if they don't agree with it.
A request from a court for discovery is a completely different matter not limited by the service level provided to users, so it makes sense that Yahoo may be able to produce a message in response to a discovery request that it won't recover in response to a user request simply because they don't want to argue with every user whose message never made it into a backup or who wants them to go back through 5 years worth of backups to find it.
Flywheel storage. Pretty much the equivalent of the pumped-water storage used in conjunction with hydroelectric plants. Use excess power to spin up the flywheels, use the flywheels to drive generators when you've a power deficit to make up. The companies who make diesel locomotives have lots of experience with the basic motor-generator tech needed.
A friend reports it's only people logging in through Nintendo's Pokemon Trainer accounts who are having problems, players using Google accounts are OK. That'd point to a problem in Nintendo's login servers rather than the Pokemon Go game servers themselves.
So, fair use threatens the survival of their businesses. In other news, the automobile threatened the survival of the buggy-whip manufacturers and the integrated-circuit chip threatened the survival of the makers of vacuum tubes.
It was the employer that wrote the at-will terms into the agreement. If they don't like their own terms, Not My Problem. For me it depends on two things: how satisfied or annoyed I am at my current position, and how anxious the new position is to have me start. If I'm relatively happy with my managers and co-workers and it's just that the new position's offering me better pay or different work, I'm going to push for 2 weeks notice before I start the new position just out of courtesy. If my current employer's willing to write a certain amount of notice to me into the agreement (ie. they won't let me go without at least X weeks notice), I'm definitely going to insist on giving at least that much notice before leaving. OTOH if my current employer insists on being able to let people go at any time for any reason with no notice, I'm going to be less than insistent on giving them notice. If I'm annoyed with them, and especially if the new position wants me right away, I'm not going to lose any sleep about giving them exactly as much notice as they give employees being let go (that is, none at all). The only consideration for me will be making the departure clean on my side, all my personal stuff cleared out, company data on my workstation safely backed up where my manager knows to find it if they need it, sensitive information that the company doesn't need (eg. passwords to linked-directly-to-me accounts needed for work, SSH/SSL/x.509 private keys) wiped, etc. etc..
If an employer has a problem with that, I suggest they review the idea that I'll grant them exactly the consideration they grant employees. If they don't consider their terms acceptable, it's entirely within their power to change them. If they expect me to grant them consideration without granting anything in return, I refer them to the acronym "TANSTAAFL".
It's a service processor. No big deal in itself, we had them as far back as mainframes go. The VAX-11/780 I worked on/with in college in the early 80s had a small PDP-11 (an LSI-11/23) in the bottom as a service processor. I'd be more worried about a much more direct avenue of attack: microcode updates. Every Windows system and most Linux boxes include the packages to take the latest firmware updates from Intel and AMD and download them into the CPU during system boot. If Intel wants to put something malicious into the chip, all it has to do is issue a firmware update with it and it'll get near-100% coverage. If a bad guy has the keys to sign an IME binary, they also have the keys to sign a firmware update.
More likely than "radicalization" is that he was simply someone with mental problems and a history of spousal abuse and violent behavior who bought into the current rhetoric (originating from Trump, Cruz, Limbaugh and other extreme right-wing sources) against the LGBT community. In his eyes it gave him an excuse to do what he wanted to do, and now we have to clean up the mess.
The problem is that in waterfall both the requirements and the timeframes are set by product owners and sales, with developer estimates of the time needed being ignored. Which is what results in developers getting fed up and deciding that "I'm willing to be accountable for meeting my estimates, meeting your estimates is your problem".
As far as having no product vision or plan, reality is that you can have a very solid product vision and plan and it'll still turn out part-way through that your customers simply don't want what you envisioned and planned on and you're going to have to change your vision and plan. That's what usually causes requirements changes, and the business has to react to that because there's no future for a business selling something the customer doesn't want to buy.
I want to know who at Tinder thought it was a good idea to allow that age range any access at all in the first place. I know why they thought it was, but I can't imagine the idea ever ending well no matter what restrictions were placed on it (at least as far as the law's concerned anyway, I'm sure the kids thought it was a dandy idea but they don't get a say in that).
That already exists. It's called ccTLDs, and each country has one..us is the one assigned to the USA,.uk is assigned to the United Kingdom,.ru to Russia and so on. Each one could create the 2LDs you describe, but not all of them actually do.
Slashdot Mirror
Last I checked, the Federal Government didn't run any of the root nameservers so I can't see any way they could be considered to belong to the US (as opposed to the private companies that own them). Not that owning the roots would mean much, since all they do is identify the (privately-owned) nameservers belonging to the various (privately-owned) registries that control the top-level domains. The only TLDs owned by the US Government (ie. the US Government operates the registries for them) are .gov and .mil, and the changes to IANA won't change how those two registries operate.
And amusingly the politicians have it backwards: ICANN already manages IANA, the change will be to remove IANA from ICANN control and make it an independent authority in it's own right. IANA was put under ICANN control in 1998, after the death of Jon Postel who basically had been IANA up until then (a controlling authority for assigning IP address blocks, well-known port numbers, AS numbers and other technical identifiers was absolutely necessary for the Internet to function, and since nobody else was doing it Jon essentially arrogated to himself the authority to handle it).
HTTP has had this forever: challenge/response authentication. There's one problem with it though: it requires storing the plaintext password on the server so it can be used to encrypt the challenge to check against the client's response. I don't know of any challenge/response algorithm that works with one-way hashes of passwords.
My approach would be to dump IoT devices in their own dedicated subnet and exclude that subnet from forwarding across the router. That reduces the exposure to just the router, and I can monitor the iptables logs for dropped packets to/from that subnet that represent attempts to do something suspicious. Configuration doesn't have to be hard, instead of plugging devices directly into the router's switch you plug devices in to external switches, connect those switches to router ports and set each port to what kind of devices hang off it. That'd control the VLAN setup to give each kind of device (WiFi, LAN, IoT) it's own virtual interface. Configuration for the firewall, DHCP, DNS etc. follows from that (you may not want to allow the IoT subnet access to external DNS, for instance). This takes a bit to set up in the firmware, but the DD-WRT/OpenWRT firmware all the major router manufacturers seem to use for their consumer routers has all the tools and then some and once the user interface is there using the functionality isn't that hard.
The White House is hesitating over making any accusations along these lines because they know full well that if you make those accusations you'd better be able to back them up and the evidence to back them up is almost impossible to get. We may know that the Russians are behind it, but I doubt we've got the evidence to actually prove it to any acceptable standard and if we go off making official accusations without being able to prove them we're going to look like fools.
I don't know about elsewhere, but in California when you buy any sort of large electronics (TV, computer, monitor, etc.) there's a recycling fee added as a line item on the receipt to cover recycling the device when it's discarded. Recyclers in California should be getting paid for every device they take with money that's already been collected for that purpose. Maybe that recycling fee needs to be increased and applied nation-wide, with payment going only to those recyclers who actually recycle the equipment and can prove it.
Besides, it should be an SRV record, not a TXT record, so that it can include what host and port the API endpoint is at without having to parse free-form text.
Pokemon Go will probably follow the same path as Ingress has. Most players will be casual, but the really dedicated will be really dedicated. They'll probably introduce something akin to Ingress' Anomalies, which'll be big cash cows as players treat them as a holiday splurge-type thing.
This'll work fine for very simple apps, ones that only require standardized functionality. But then, with an app like that, do you really need to develop a custom one for any reason other than branding/appearance? And it'll work for disposable apps, ones that do the current job but don't need to be maintained or enhanced down the road. That's been true forever, it's why spreadsheets and word processors had macro languages so secretaries and accountants could do simple operations and calculations without needing to have the programming team get involved. But the moment you start dealing with an app with complex functionality that has to be changed, enhanced and extended over time, that's when you'll discover that you need software engineers. It's the same reason anybody who can grab a hammer and saw can cobble together a sawhorse that'll work for one job, but you need someone who understands architecture and construction to build a house that's expected to last for decades.
Those conversions look like cases where the column type during import was left at "General" instead of being set to "Text" as it should have been, telling Excel to try and infer the actual type from the format of the column's contents. It's an awkward situation where the user should be telling Excel what the data type for each column is, but it's not strictly Excel's fault for doing what the user told it to do. IMO Excel should be either changed to not have a default type and to not allow an import until the user's selected a type for each column, or it should throw up an error if it infers different data types for a column for different rows.
They won't automate software development until they come up with a system that can handle creating correct software from incomplete and partially erroneous specifications which don't remain constant between the start of development and delivery. At best they'll be able to automate some of the tedious boilerplate coding.
Big problem here: a lot of software where the functionality could be reused can't be reused because it wasn't written for reuse. It'll have a lot of instance-specific code scattered throughout, for example logging functions that're specific to the system it was first written to run in. The result is it's easier and faster to write it from scratch than to try and remove the instance-specific code from the original source to make it suitable for use somewhere else. An open-source policy doesn't need just a mandate for reuse, it needs a mandate for making software reusable at the time it's written. That, unfortunately, is something any developer can tell you is really hard to get management to agree to.
That's easy to check. During an election you pick a sample of random precincts, set their actual ballots aside and in their place submit an identically-sized set of ballots which are randomly-generated but known. Have those random ballots created and checked/counted by independent groups so it'd be infeasible for any one entity to control both the vote-counting software and the random-ballot generation process. If the reported count for those precincts isn't exactly identical to the known count, there's been tampering with the counting software. Then you can submit the actual ballots for those precincts as a correction, replacing the random ballot counts, and proceed as usual.
The problem isn't so much that the ballot itself isn't secure, it's that the authentication of the voter isn't reliable so the identity of whoever cast the ballot isn't secure. The only ways to make that authentication reliable involve encoding the identity of the voter into the cast ballot, which blows away the whole idea of secret ballots so nobody can confirm how you voted.
It's possible to do it, but you'd need a) a state-issued smartcard with a unique key-pair assigned to that specific individual capable of encrypting and signing arbitrary blocks of data, and b) a front-end system that'd accept the voter-signed ballot, verify the signature and contents, strip the voter's signature and replace it with one from the election authority, and this system would have to be trusted not to record anything tying voter identities to ballots and verifiable so that anybody could confirm that not only was the system actually trustable but that the running software was generated from the verified code. That's a non-trivial system to set up.
In these companies' position, I'd respond "Sure, we'll provide a way to block infringing content. You'll merely have to present a judgment from a court of competent jurisdiction stating that that content has been found to be infringing. We aren't a court, we're not going to hear cases and make rulings like one.". When the whines start, I'd go "Oh, you want it blocked because you allege it's infringing? OK, we can do that. We'll block any content that anyone alleges infringes on their copyrights until presented with a court ruling saying it isn't infringing. But again we aren't a court, we will not get into the business of hearing cases and making rulings on whether the evidence supports the allegation or not.".
The recommendation doesn't make sense. Yes, your phone may not always be in your possession. That would rule out software authenticators too, since they reside on the same phone that may not always be in your possession. Even dedicated hardware tokens may not always be in your possession, they can be lost or stolen just like a phone. So if not being always in your possession is the criteria, then all of the NIST's recommended methods fail to meet it.
As for VoIP lines, yes they can be intercepted. They do however share one characteristic with cel-phone lines: they don't normally share a path with the network connection being authenticated except possibly at the user's ISP and computer (if the VoIP line terminates on their computer as opposed to their cel phone). That limits the ability of a single attacker to intercept and alter both paths, which is the central facet of what 2FA does.
Ultimately the only secure 2FA is a dedicated hardware token that requires biometric authentication to function. Anything less than that is insecure, the question being merely whether the insecurity reaches the point of being unacceptable.
Or it may be related to the reliability of recovering from backups. Backups are intended to recover from catastrophic failures, not mere accidental deletion of messages, so recovery of any particular message can be problematic. Even if the message was stored long enough to be caught in a backup, incremental backups mean it may take searching a month's worth of backups to find the exact one that backed up that message. Fail to scan a large enough range and you won't find the message even if it's backed up. If the message was received and then deleted before the next backup run then it may not be on any backup, and there's no way to distinguish not finding it because it wasn't backed up from not finding it because you didn't search the right set of backups. Explaining all that to ordinary users is all but impossible, so from a service-level standpoint it makes more sense to not bring backups up at all and simply say "If you deleted it, we can't recover it.". That, users can comprehend even if they don't agree with it.
A request from a court for discovery is a completely different matter not limited by the service level provided to users, so it makes sense that Yahoo may be able to produce a message in response to a discovery request that it won't recover in response to a user request simply because they don't want to argue with every user whose message never made it into a backup or who wants them to go back through 5 years worth of backups to find it.
Flywheel storage. Pretty much the equivalent of the pumped-water storage used in conjunction with hydroelectric plants. Use excess power to spin up the flywheels, use the flywheels to drive generators when you've a power deficit to make up. The companies who make diesel locomotives have lots of experience with the basic motor-generator tech needed.
A friend reports it's only people logging in through Nintendo's Pokemon Trainer accounts who are having problems, players using Google accounts are OK. That'd point to a problem in Nintendo's login servers rather than the Pokemon Go game servers themselves.
So, fair use threatens the survival of their businesses. In other news, the automobile threatened the survival of the buggy-whip manufacturers and the integrated-circuit chip threatened the survival of the makers of vacuum tubes.
It was the employer that wrote the at-will terms into the agreement. If they don't like their own terms, Not My Problem. For me it depends on two things: how satisfied or annoyed I am at my current position, and how anxious the new position is to have me start. If I'm relatively happy with my managers and co-workers and it's just that the new position's offering me better pay or different work, I'm going to push for 2 weeks notice before I start the new position just out of courtesy. If my current employer's willing to write a certain amount of notice to me into the agreement (ie. they won't let me go without at least X weeks notice), I'm definitely going to insist on giving at least that much notice before leaving. OTOH if my current employer insists on being able to let people go at any time for any reason with no notice, I'm going to be less than insistent on giving them notice. If I'm annoyed with them, and especially if the new position wants me right away, I'm not going to lose any sleep about giving them exactly as much notice as they give employees being let go (that is, none at all). The only consideration for me will be making the departure clean on my side, all my personal stuff cleared out, company data on my workstation safely backed up where my manager knows to find it if they need it, sensitive information that the company doesn't need (eg. passwords to linked-directly-to-me accounts needed for work, SSH/SSL/x.509 private keys) wiped, etc. etc..
If an employer has a problem with that, I suggest they review the idea that I'll grant them exactly the consideration they grant employees. If they don't consider their terms acceptable, it's entirely within their power to change them. If they expect me to grant them consideration without granting anything in return, I refer them to the acronym "TANSTAAFL".
It's a service processor. No big deal in itself, we had them as far back as mainframes go. The VAX-11/780 I worked on/with in college in the early 80s had a small PDP-11 (an LSI-11/23) in the bottom as a service processor. I'd be more worried about a much more direct avenue of attack: microcode updates. Every Windows system and most Linux boxes include the packages to take the latest firmware updates from Intel and AMD and download them into the CPU during system boot. If Intel wants to put something malicious into the chip, all it has to do is issue a firmware update with it and it'll get near-100% coverage. If a bad guy has the keys to sign an IME binary, they also have the keys to sign a firmware update.
More likely than "radicalization" is that he was simply someone with mental problems and a history of spousal abuse and violent behavior who bought into the current rhetoric (originating from Trump, Cruz, Limbaugh and other extreme right-wing sources) against the LGBT community. In his eyes it gave him an excuse to do what he wanted to do, and now we have to clean up the mess.
The problem is that in waterfall both the requirements and the timeframes are set by product owners and sales, with developer estimates of the time needed being ignored. Which is what results in developers getting fed up and deciding that "I'm willing to be accountable for meeting my estimates, meeting your estimates is your problem".
As far as having no product vision or plan, reality is that you can have a very solid product vision and plan and it'll still turn out part-way through that your customers simply don't want what you envisioned and planned on and you're going to have to change your vision and plan. That's what usually causes requirements changes, and the business has to react to that because there's no future for a business selling something the customer doesn't want to buy.
I want to know who at Tinder thought it was a good idea to allow that age range any access at all in the first place. I know why they thought it was, but I can't imagine the idea ever ending well no matter what restrictions were placed on it (at least as far as the law's concerned anyway, I'm sure the kids thought it was a dandy idea but they don't get a say in that).
That already exists. It's called ccTLDs, and each country has one. .us is the one assigned to the USA, .uk is assigned to the United Kingdom, .ru to Russia and so on. Each one could create the 2LDs you describe, but not all of them actually do.