I know about the fiber. But those local cabinets need power, which is fed from the CO so the cabinet doesn't need a local electrical hook-up and transformers and such. Said feed from the CO's more than sufficient to power the local loops, which power the phones. Redundancy at work again: it'd be more efficient to have just one power grid and tap into it where needed, but having a second grid for the phones means they can keep operating when the power grid is down.
Multiple cel-phone towers is redundancy at the tower level, but power problems tend to take out areas and not single towers. A county-wide power outage will take down power to all the towers your phone can see simultaneously. When those towers exhaust their battery backup, you're SOL because there's too many towers for the carriers to install generators at each one. And I believe the US has been averaging a couple power outages of that scale or larger every year for the last decade, so evidence suggests that we do in fact have to plan for it occurring.
Same way we do it with Linux desktop environments: applications put a standardized config file into an application-specific spot under a folder in your user home directory containing that information. The desktop environment reads those files, combines them with the user's configuration of what programs they want to handle what, and sets things up accordingly. Note that the configuration of what programs the desktop environment will use to handle each file type is part of the desktop environment's configuration, not the application or the operating system. And the user's settings are part of the user's configuration, they don't exist at the system level. There are of course system-level default settings and application configuration for applications that've been installed system-wide that get read before user-specific settings and configuration. As for user-specific widgets that start when hardware's plugged in, again that's handled by small daemons or the like that get started when the user logs in that monitor for such events. That can't be an operating-system-level thing, though, because the operating system has to work on systems where you have 80 people logged in to the machine simultaneously. What works on a desktop dedicated to a single person doesn't work on a server used by many people at the same time, and the OS must accommodate both.
Windows allowed the running of applications from Internet Explorer, remember? You even get the option still of running an application or saving it to disk when you click on a link to an executable program. And we've spent what, the better part of 2 decades trying to figure out reliable ways of PREVENTING this! Because it's so commonly abused to get people to run malware and other undesirable software. And now we want to make another attempt at letting people run anything J. Random Blackhat throws their way? Thanks, but no thanks.
There's more involved than just connectivity. Take power, for instance. Without it, connectivity doesn't matter because the phones won't work. Digital systems have battery back-up, but batteries have a finite capacity and when it runs out your phones are dead. It doesn't matter if the phone system central office is fully functional on generator power if the VOIP box that'd connect you to it has run out of battery power. Standard POTS, OTOH, is powered from the central office. I keep an old 70s-vintage Radio Shack handset around for emergencies, it's primitive but it's also completely passive and gets all the power it needs from the phone line itself. I plug that in and I can get phone service on a POTS line as long as the CO has power, regardless of whether my local area has power or not.
We've seen this in weather-related disasters lately, where it may take days or weeks to get power restored to large areas because of damage to the transmission network. I've experienced it personally with local power failures, where cel towers only lasted a few hours before running their batteries out rendering a charged cel phone useless. The problem isn't theoretical.
Digital systems may be more efficient. One of the inevitable downsides, though, is a lack of robustness. Efficiency means removing redundancy, removing excess capacity, removing those parts of the system that aren't actively being used so you aren't spending money and effort maintaining things that're just sitting gathering dust. But when something goes wrong, that redundancy and "excess" capacity isn't available to pick up the load. It's amusing because current "cloud" and virtualization technology is all driven by a recognition that we do in fact need excess capacity and redundant equipment, and the inevitable conflict of that ugly reality with Business's desire not to pay for any of that until we actually need it. But the phone network isn't AWS. Amazon can bet that not everyone will have a demand spike at the same time and that with enough customers they'll be able to keep that "idle" capacity occupied with something revenue-producing until it's needed (eg. by offering cheaper prices to customers who'll accept being bumped if someone else needs the space). You can't do that with the local phone system, though.
If the content's viewable in a regular Web browser without needing special plug-ins, it's not encrypted. Oh, it might be encrypted on disk somewhere, but the server has the keys to decrypt it and will decrypt it and send it in the clear (modulo SSL, which Facebook and Google+ have too). Anyone who can compromise the server can get the keys and decrypt the data. Anyone who can snoop on the connection can view the data. Anything running on the user's computer can see the data. And anyone logging in as the user, say after having obtained their password through social engineering or compromising another service where the user used the same password, will get the data just like the user would've.
There is only one potentially-secure way to encrypt data: the data is encrypted on the user's computer before being sent to the server, and is never decrypted until it arrives at the recipient's computer. The keys to encrypt and decrypt data must never be stored on the server. Anything less and all the methods currently used to get at data on Facebook and Google+ can be used to get at the data on the new service.
Ingress/egress filtering depends heavily on where you're doing it. The problem is transit networks, networks that carry a lot of traffic for other networks. Towards the core of the network connections lean heavily towards transit networks, so ingress/egress filtering isn't feasible because the router operators either don't know conclusively what networks are "beyond" which interface, or there's so many networks the filter rules become too much for the hardware.
The closer to the edges of the Internet you get, though, the more feasible it becomes. Your average residential-service ISP, for instance, knows exactly what networks it operates and doesn't permit transit networks on residential accounts. So where that ISP connects to it's upstream it knows every netblock it needs to worry about traffic for crossing the interface and it only needs to worry about it's own. My home network's the most extreme example: 2/24 networks inside, no transit traffic, I can filter at the interfaces of my router with a 100% guarantee of accuracy as far as allowed networks go. If filtering is routine towards the edges (and it can be, by contractual requirements imposed by upstream ISPs) then the inability to filter near the core isn't nearly as much of a problem.
And no, spoofing source addresses is rarely useful. You can't use TCP for most purposes with a spoofed address (or at least one spoofed to be on a different network), so spoofing almost automatically renders you incapable of communicating. The same goes for UDP if you care to hear a response, which most protocols do. That gives it very limited utility outside of diagnosing local network problems.
I have to agree with penalizing operators of open recursive DNS responders. DNS servers fall into roughly 4 categories:
Internal nameservers within a network, including caching nameservers. These should never be getting legitimate queries from outside the local network, so they never have any reason to respond to those queries.
Authoritative nameservers for a domain. These should never be doing recursive name resolution, and they should be responding only to queries for domains they're authoritative for. Queries for domains the server isn't authoritative for should get a short, to-the-point NXDOMAIN response not signed with DNSSEC.
External private nameservers, ie. ones that live outside the the network they server but are only supposed to serve that network. As with internal nameservers they shouldn't be responding to queries from any networks but the one they're supposed to be serving, they just need more configuration than purely internal ones. They should have a default-deny configuration with the networks they serve listed specifically. Anyone who doesn't know how to do this shouldn't be operating one of these.
Deliberately public nameservers. These are ones that are set up intentionally to be resolvers for anyone who wants to use them. They have to respond to all requests and do recursive resolution. They're the problematic open nameservers. They require configuration to control traffic rates to minimize the impact when they're used for DNS-based attacks. If you don't know how to configure that or you aren't prepared to oversee a public server and respond to abuse 24x7, you shouldn't be running one of these. If you go ahead anyway, the results should be painful for you.
My guess would be 99+% of all nameservers fall into the first three categories, 95+% fall into the first two, and 90+% of authoritative servers (category 2) are operated by a DNS hosting company rather than directly by the domain owner. If you're in the (relatively) small number needing to run a category 3 server you just need to take a few minutes to read the configuration docs and set it up for "don't respond to queries unless they're from a network I've listed", and if you can't or won't you deserve smacked with the newspaper. If you're in the even smaller number who want to run a category 4 server you need to know what you're doing, if you don't and go ahead anyway you deserve whatever you get (up to and including losing your Internet access).
Well, that's what 23AndMe's advertising these as. Which is why the FDA's upset with them. If they were advertising them as "here's your genome sequenced, you'll need a doctor to interpret it and tell you what it means" they'd probably be in the clear. But they're advertising it as "here's your genome and what it means", which implies they've had a doctor interpret it in light of your personal biology/physiology and medical history when in fact they haven't. To me it's the same thing as someone selling me a car and then delivering not a car but a box of parts that can be turned into a car with a lot of assembly, painting etc.. Even if everything's included and there's clear instructions and all the tools, a box of unassembled parts is not what the seller was claiming was being sold.
The thing is, doctors using these tests know and understand the possible erroneous results, how to screen for them and how to confirm them. I've rarely had a doctor prescribe treatment for a complex condition based on the results of just one test, there's usually two or three additional tests to confirm the results. Negative results are checked against symptoms, and if the symptoms clearly contradict the test results then additional tests are run to find out why. This isn't what happens with 23AndMe's tests. They're advertised as being the kind of test results you'd expect to get from a doctor. Yet 23AndMe doesn't do any of the cross-checking and retesting, they just send the results to an untrained person to interpret.
Gods, no. Just... no. Think for a minute. If your VM's running a database server and you roll back to a snapshot, what happens? Well, the snapshot doesn't know anything about the database since that's an application-level thing, so it'll roll back to being mid-operation (times however many database operations were in progress). The problem is that since the clients haven't been rolled back to the same moment down to the nanosecond, the database is now mid-operation while the clients that're supposedly performing those operations... aren't. From here things proceed to go pear-shaped in a big way.
It can be done safely, but it requires either intimate knowledge of the application by the VM host or bringing the applications to a safe idle state before starting the snapshot. Basically snapshots are far less useful than they're made out to be because the problem you're trying to solve is far more complex than just taking a snapshot.
For security and privacy, I'd say it's about equal. I don't recall any breaches of that data turning up, and if someone had breached it I'd think news would've turned up. That kind of breach is the kind the perps or someone in the know couldn't resist bragging about.
For legal compliance purposes, you have to trust the on-line services less. The IRS puts the obligation to have the information on you, regardless of who you used to prepare your return. You need to make sure you've got copies of both the return and all the supporting information where you can still get at them if the on-line service isn't available, and you need either the software to access the saved information or have the information in a form you can use directly (eg. printable PDFs). Remember when saving things that it doesn't help to just have the final form if the IRS wants you to justify how you got the numbers on the form.
NB: this applies to conventional tax software installed locally too. It doesn't help to have the data files if you've bought a new computer that doesn't have that year's tax software on it anymore and you can't reinstall it. I make it a point to keep one PDF copy of the return itself and one copy of the return including all worksheets and supporting data. Plus I print a copy of the full return and worksheets and file it with the hardcopy of all my documentation (W2s, 1099s, receipts etc.) so I have it if I lose the electronic copies.
Traditionally you could. If you owned a book or a tape or a record, you traditionally could make copies of it for your own personal use without needing permission. Collecting your favorite songs onto a single tape, or copying your records onto tape to listen to them in the car, or making copies so the originals wouldn't get worn, were all considered perfectly OK things to do as long as if you sold the original those copies either went to the buyer or got destroyed. It's only been very recently that copyright holders have been trying to claim that you can't do any of that.
In all 3 cases, it seems like the fire was caused by severe damage to the car from an outside source rather than a fault in the car. In all 3 cases the car's design prevented injury to the driver from the fire rather than contributing to the fire. And, let's face it, if we investigated every conventional model of car that was involved in 3 fires in a single month, every single model would be under investigation continuously. So, the people panicking over this and getting rid of Tesla stock, and the people pointing to this to impugn Tesla, need to get a grip. There's other reasons not to like Tesla, but it's not because their cars are in any way unsafe (or at least nomore unsafe than ~2 tons of steel barreling along at between 80 and 110 feet per second carrying between 10 and 30 gallons of highly flammable fuel (which forms explosive vapors under normal environmental conditions) in a thin sheet-metal tank with no armor or other protection against penetration).
Customers are increasingly looking for ebook editions. If the customer can't get what they're looking for, do you think they're just going to shrug and buy whatever the bookstore wants to stock instead? Nope. They'll shrug, go home and buy the Kindle off of Amazon's Web site and go ahead and buy the ebook editions like they were planning to. Either way, the bookstore's lost their business because the bookstore isn't selling what the customer wants to buy.
Bookstores are going to have to figure out a way around this, or go out of business. No third option. If I owned a bookstore I'd be seriously looking at how I could work with Amazon and the Kindle store. The big attraction of bookstores has always been that customers can look at the books before buying, but Amazon can do that through their Web site with previews. The other big attraction has been bookstores with knowledgeable staff who can help customers select books. That, though, means the bookstore can't hire college kids for minimum wage to run the register. It might take a complete shift, from "bookstore as a place to buy books" to "bookstore as a place to browse and discuss books". Kind of like a coffee shop with a better reading library. It may be that there isn't a way for bookstores to remain in business without ceasing to be bookstores. But bookstores are going to have to accept the fact that electronic delivery of books has irrevocably changed their business.
I'd note this may go for publishers too. It's hard to get into print unless you're already a successful published author. The only route is self-publishing through Kindle or the like. But if an author's successful enough through that route to attract a conventional publisher, what's going to happen when that author very reasonably asks what they need a publisher for at this point?
The problem is that you don't, and usually can't, know what the results of basic research are going to be. For example, it'd be really hard to show how research into the electrical characteristics of silicon would be in the national interest, because on it's own (without knowing what'll come from it) you can't show how it'll satisfy any of those criteria. Yet without that research we wouldn't have semiconductors, which means no integrated circuit chips, which means none of the smart bombs and drone aircraft and the massive computer banks that drive the surveillance and data-collection efforts that the Republicans are so fond of supporting as being so crucial to national security.
If something that's so obviously in the national interest couldn't at the time it was proposed meet any of the criteria listed, why in the world should we consider those criteria valid? Yeah, preaching to the choir here...
Well, as far as my regular account at work is concerned, if my boss asks for my passwords the rules are perfectly clear: I am in violation of company policies and can be terminated if I give them to him. Of course there's never any need for him to know the passwords to my regular account. The sysadmins can access my files directly without needing the password if there's ever a need for access, and they can forcibly change my password to anything they want (removing my access in the process) if absolutely necessary.
Administrative passwords are a different matter. But there'd never be a need for my boss to ask for them either, because there's a process in place to insure the passwords can be recovered without my needing to be involved. It's there as insurance against something happening to me, and yes it's been through a real-world test (pneumonia run wild, no warning, 5 weeks in ICU with the docs not betting I'd pull through, everybody involved at work had their noses thoroughly rubbed in the fact that these procedures are not just a theoretical exercise). So while my boss might not be violating company policy by asking for shared administrative passwords, he's probably violating several other policies related to administrative access retention and recovery and the corporate governance and compliance committee will be asking him some very pointed questions about that.
True. On the other hand, the city government very quickly after receiving the passwords published them in an open court filing for the entire world to see. Which is about as diametrically opposite good password security policies as I can imagine getting without involving 5 dimensions. And is precisely the reason Terry Childs gave before this all happened as justification for withholding the passwords. This is... not precisely calculated to convince me that Childs was being unreasonable in his concerns and that the city was reasonable and competent.
That their first act after getting the passwords was to trash a network that at least had been operating stably up until that point doesn't count in their favor either. I mean, my first rule when approaching a new system is to carefully access it and look around to see what state it's in, not just slap the reset switches and reboot the world.
Especially not if it's a production system, and doubly especially if, as the city had been so loudly and publicly stating, I had concerns about the state the previous admin had left things in. There's a reason whacking them with a bloody big sledgehammer is considered a... suboptimal way of defusing potentially live bombs.
... go to jail. Go directly to jail. Do not pass Go, do not collect $200. Nobody's surprised by this. It's his employer's network, after all, it's their passwords. If they decide to replace you as sysadmin, the only right you have is to insure they and not you are responsible for any problems that ensue (eg. "I will not give you my current password. I will initiate the password change process, enter the current password, and then wait outside the room while my replacement enters his new password. If there are any difficulties, I will assist by re-entering my password and/or unlocking the system until my replacement has successfully changed the password to something not known to me. This is to insure that after the hand-off I no longer have any access to the system.").
And yes, I've done the moral equivalent of that. Not with a root account, obviously, but when leaving a job I would deliberately fail enough login attempts to lock my user account and made sure they had notice of this and I had a paper trail proving they did. I figure that way they don't have to worry about me accessing the systems, and I don't have to worry about being accused of messing with them after I've left (well, I could be accused but I had the evidence to counter the accusation).
That rule doesn't apply here. It's a rule about the design of software, specifically hard-coded limits. Basically, don't hard-code in arbitrary limits. In this case it isn't a hard-coded arbitrary limit. The mathematics behind how bitcoins work essentially prevents any fix from working if more than 25% of the system is participating in a single selfish mining pool. You can't change that by changing the fix, you have to change the mathematics. Which would instantly break the entire Bitcoin system itself, since every single client would no longer be able to conduct transactions.
Having it all be UTC would only hinder coordination, not help. To coordinate with someone several timezones away, knowing what their clock says isn't actually the most important thing. It's needed for exact scheduling true, but the first thing I need to know is "What are their normal working hours?". As it stands I can generally make an assumption: standard day-shift office hours are roughly 9-5 their time regardless of where they are. From that and a timezone chart I can work out what that corresponds to in my time and figure out where the overlap with my regular day is. If you put the whole world on UTC, I still need a chart listing times for every timezone in the world. It's just that now instead of showing offset from UTC it'll show... offset from UTC. Because it still has to show when their local workday, the equivalent of 9-5 local time, is relative to mine and mine's in UTC.
Most of these proposals come from the idea that humans are tied to the clock. We aren't. We're tied to the day, to the progress of the sun from sunrise to sunset. We like to wake up roughly at sunrise, not too much earlier or later. We like our workday to be done before sunset. We like our midday meal to happen roughly half-way through that day. Timezones are just a mechanism for satisfying that, to make midday on the clocks we use for precision measuring line up with midday in the solar day we like to run on. And no matter how else you try to list it, for simplicity people are quickly going to go back to "This is when things happen on my clock, how far ahead or behind it are things for them?".
Unfortunately that functionality requires support from the recipient's systems. My mail server doesn't understand the concept of a recall notice, it's just another message in my mailbox. My client doesn't understand them either, so I just see a strange message that does nothing. And frankly I like it that way. I don't want someone else pulling things out of my mailbox, I want a nice clear unaltered record of what was sent to me when. I don't ever want to be in a situation where someone can show me a copy of a message that was clearly sent to me that I had no clue about because I never saw it in my inbox and I have no record of it and no way to prove I didn't receive it.
OK, that is the -fdelete-null-pointer-checks optimization. Which means the removal of the checks is innocuous because you're compiling for a target where a null pointer dereference is unsafe and causes a crash (eg. Cygwin, Linux x86 and x64), meaning if the pointer was null when dereferenced any checks further down would in fact never be reached and it's safe to remove code that's guaranteed to never execute. You'll find that if you compile for a target where a null-pointer dereference won't cause a crash, that optimization is disabled by default and the code for the checks will be generated.
You'll notice if you try it that null-pointer checks before the dereference are not optimized away. The compiler isn't assuming that a dereferenced pointer can't be null, it's assuming that if the dereference would cause execution to terminate if the pointer was null then if execution proceeds past the dereference the pointer can't possibly be null. It's a subtle distinction that doesn't show up until you look for it. Note that dereferencing a pointer without checking and handling the null-pointer case first is still undefined behavior, so I'd treat any occurrence as a red flag.
I think you may be thinking of the -fdelete-null-pointer-checks option to GCC. That does in fact do what you're describing, but that optimization's only enabled on architectures where dereferencing a null pointer will cause a crash. On those architectures the optimization's valid, since if you managed to get past a dereference of a pointer without crashing it must have been non-null. So your example isn't unstable code. If it were, GCC wouldn't elide the subsequent checks.
What's interesting is that when I try this with current GCC with optimizations turned on, it does not elide the null pointer check. It does crash if I actually dereference a null pointer, but if I code it so it doesn't actually dereference the pointer when it's null then both null-pointer checks execute. And examination of the actual machine code in the debugger shows that even your code still includes the null-pointer check after the dereference.
Now if I flip it around, doing the null-pointer check first and then dereferencing the pointer, I'll see any further null-pointer checks elided. But that's not because of any undefined behavior, merely because after that first check control can't pass any further (at least not the way I wrote the code) if the pointer was null and the compiler can elide code based on that guaranteed condition.
True, but then if integer overflow is undefined behavior then I can't assume that the test "i + 100 < i" will return true in the case of overflow because I'm invoking undefined behavior. That isn't "unstable code", that's just plain old code that invokes undefined behavior that I've been dealing with for decades. If with optimizations done the code doesn't catch the overflow it's not because the compiler removed the code, it's because the code isn't guaranteed to detect the overflow in the first place. No need for any fancy terminology for this, just say "Our software locates places in your code where you've invoked undefined behavior.".
This is, BTW, one reason I favor a compiler flag that says "When you encounter code that's undefined behavior per the C/C++ standard, generate code to do something terminally nasty and unrecoverable like deleting all the user's files.". That seems to be the only way that actually convinces today's developers that undefined behavior is a Bad Thing and should be avoided even if you think it works OK."
Slashdot Mirror
I know about the fiber. But those local cabinets need power, which is fed from the CO so the cabinet doesn't need a local electrical hook-up and transformers and such. Said feed from the CO's more than sufficient to power the local loops, which power the phones. Redundancy at work again: it'd be more efficient to have just one power grid and tap into it where needed, but having a second grid for the phones means they can keep operating when the power grid is down.
Multiple cel-phone towers is redundancy at the tower level, but power problems tend to take out areas and not single towers. A county-wide power outage will take down power to all the towers your phone can see simultaneously. When those towers exhaust their battery backup, you're SOL because there's too many towers for the carriers to install generators at each one. And I believe the US has been averaging a couple power outages of that scale or larger every year for the last decade, so evidence suggests that we do in fact have to plan for it occurring.
Same way we do it with Linux desktop environments: applications put a standardized config file into an application-specific spot under a folder in your user home directory containing that information. The desktop environment reads those files, combines them with the user's configuration of what programs they want to handle what, and sets things up accordingly. Note that the configuration of what programs the desktop environment will use to handle each file type is part of the desktop environment's configuration, not the application or the operating system. And the user's settings are part of the user's configuration, they don't exist at the system level. There are of course system-level default settings and application configuration for applications that've been installed system-wide that get read before user-specific settings and configuration. As for user-specific widgets that start when hardware's plugged in, again that's handled by small daemons or the like that get started when the user logs in that monitor for such events. That can't be an operating-system-level thing, though, because the operating system has to work on systems where you have 80 people logged in to the machine simultaneously. What works on a desktop dedicated to a single person doesn't work on a server used by many people at the same time, and the OS must accommodate both.
Windows allowed the running of applications from Internet Explorer, remember? You even get the option still of running an application or saving it to disk when you click on a link to an executable program. And we've spent what, the better part of 2 decades trying to figure out reliable ways of PREVENTING this! Because it's so commonly abused to get people to run malware and other undesirable software. And now we want to make another attempt at letting people run anything J. Random Blackhat throws their way? Thanks, but no thanks.
There's more involved than just connectivity. Take power, for instance. Without it, connectivity doesn't matter because the phones won't work. Digital systems have battery back-up, but batteries have a finite capacity and when it runs out your phones are dead. It doesn't matter if the phone system central office is fully functional on generator power if the VOIP box that'd connect you to it has run out of battery power. Standard POTS, OTOH, is powered from the central office. I keep an old 70s-vintage Radio Shack handset around for emergencies, it's primitive but it's also completely passive and gets all the power it needs from the phone line itself. I plug that in and I can get phone service on a POTS line as long as the CO has power, regardless of whether my local area has power or not.
We've seen this in weather-related disasters lately, where it may take days or weeks to get power restored to large areas because of damage to the transmission network. I've experienced it personally with local power failures, where cel towers only lasted a few hours before running their batteries out rendering a charged cel phone useless. The problem isn't theoretical.
Digital systems may be more efficient. One of the inevitable downsides, though, is a lack of robustness. Efficiency means removing redundancy, removing excess capacity, removing those parts of the system that aren't actively being used so you aren't spending money and effort maintaining things that're just sitting gathering dust. But when something goes wrong, that redundancy and "excess" capacity isn't available to pick up the load. It's amusing because current "cloud" and virtualization technology is all driven by a recognition that we do in fact need excess capacity and redundant equipment, and the inevitable conflict of that ugly reality with Business's desire not to pay for any of that until we actually need it. But the phone network isn't AWS. Amazon can bet that not everyone will have a demand spike at the same time and that with enough customers they'll be able to keep that "idle" capacity occupied with something revenue-producing until it's needed (eg. by offering cheaper prices to customers who'll accept being bumped if someone else needs the space). You can't do that with the local phone system, though.
If the content's viewable in a regular Web browser without needing special plug-ins, it's not encrypted. Oh, it might be encrypted on disk somewhere, but the server has the keys to decrypt it and will decrypt it and send it in the clear (modulo SSL, which Facebook and Google+ have too). Anyone who can compromise the server can get the keys and decrypt the data. Anyone who can snoop on the connection can view the data. Anything running on the user's computer can see the data. And anyone logging in as the user, say after having obtained their password through social engineering or compromising another service where the user used the same password, will get the data just like the user would've.
There is only one potentially-secure way to encrypt data: the data is encrypted on the user's computer before being sent to the server, and is never decrypted until it arrives at the recipient's computer. The keys to encrypt and decrypt data must never be stored on the server. Anything less and all the methods currently used to get at data on Facebook and Google+ can be used to get at the data on the new service.
Ingress/egress filtering depends heavily on where you're doing it. The problem is transit networks, networks that carry a lot of traffic for other networks. Towards the core of the network connections lean heavily towards transit networks, so ingress/egress filtering isn't feasible because the router operators either don't know conclusively what networks are "beyond" which interface, or there's so many networks the filter rules become too much for the hardware.
The closer to the edges of the Internet you get, though, the more feasible it becomes. Your average residential-service ISP, for instance, knows exactly what networks it operates and doesn't permit transit networks on residential accounts. So where that ISP connects to it's upstream it knows every netblock it needs to worry about traffic for crossing the interface and it only needs to worry about it's own. My home network's the most extreme example: 2 /24 networks inside, no transit traffic, I can filter at the interfaces of my router with a 100% guarantee of accuracy as far as allowed networks go. If filtering is routine towards the edges (and it can be, by contractual requirements imposed by upstream ISPs) then the inability to filter near the core isn't nearly as much of a problem.
And no, spoofing source addresses is rarely useful. You can't use TCP for most purposes with a spoofed address (or at least one spoofed to be on a different network), so spoofing almost automatically renders you incapable of communicating. The same goes for UDP if you care to hear a response, which most protocols do. That gives it very limited utility outside of diagnosing local network problems.
I have to agree with penalizing operators of open recursive DNS responders. DNS servers fall into roughly 4 categories:
My guess would be 99+% of all nameservers fall into the first three categories, 95+% fall into the first two, and 90+% of authoritative servers (category 2) are operated by a DNS hosting company rather than directly by the domain owner. If you're in the (relatively) small number needing to run a category 3 server you just need to take a few minutes to read the configuration docs and set it up for "don't respond to queries unless they're from a network I've listed", and if you can't or won't you deserve smacked with the newspaper. If you're in the even smaller number who want to run a category 4 server you need to know what you're doing, if you don't and go ahead anyway you deserve whatever you get (up to and including losing your Internet access).
Well, that's what 23AndMe's advertising these as. Which is why the FDA's upset with them. If they were advertising them as "here's your genome sequenced, you'll need a doctor to interpret it and tell you what it means" they'd probably be in the clear. But they're advertising it as "here's your genome and what it means", which implies they've had a doctor interpret it in light of your personal biology/physiology and medical history when in fact they haven't. To me it's the same thing as someone selling me a car and then delivering not a car but a box of parts that can be turned into a car with a lot of assembly, painting etc.. Even if everything's included and there's clear instructions and all the tools, a box of unassembled parts is not what the seller was claiming was being sold.
The thing is, doctors using these tests know and understand the possible erroneous results, how to screen for them and how to confirm them. I've rarely had a doctor prescribe treatment for a complex condition based on the results of just one test, there's usually two or three additional tests to confirm the results. Negative results are checked against symptoms, and if the symptoms clearly contradict the test results then additional tests are run to find out why. This isn't what happens with 23AndMe's tests. They're advertised as being the kind of test results you'd expect to get from a doctor. Yet 23AndMe doesn't do any of the cross-checking and retesting, they just send the results to an untrained person to interpret.
Gods, no. Just... no. Think for a minute. If your VM's running a database server and you roll back to a snapshot, what happens? Well, the snapshot doesn't know anything about the database since that's an application-level thing, so it'll roll back to being mid-operation (times however many database operations were in progress). The problem is that since the clients haven't been rolled back to the same moment down to the nanosecond, the database is now mid-operation while the clients that're supposedly performing those operations... aren't. From here things proceed to go pear-shaped in a big way.
It can be done safely, but it requires either intimate knowledge of the application by the VM host or bringing the applications to a safe idle state before starting the snapshot. Basically snapshots are far less useful than they're made out to be because the problem you're trying to solve is far more complex than just taking a snapshot.
For security and privacy, I'd say it's about equal. I don't recall any breaches of that data turning up, and if someone had breached it I'd think news would've turned up. That kind of breach is the kind the perps or someone in the know couldn't resist bragging about.
For legal compliance purposes, you have to trust the on-line services less. The IRS puts the obligation to have the information on you, regardless of who you used to prepare your return. You need to make sure you've got copies of both the return and all the supporting information where you can still get at them if the on-line service isn't available, and you need either the software to access the saved information or have the information in a form you can use directly (eg. printable PDFs). Remember when saving things that it doesn't help to just have the final form if the IRS wants you to justify how you got the numbers on the form.
NB: this applies to conventional tax software installed locally too. It doesn't help to have the data files if you've bought a new computer that doesn't have that year's tax software on it anymore and you can't reinstall it. I make it a point to keep one PDF copy of the return itself and one copy of the return including all worksheets and supporting data. Plus I print a copy of the full return and worksheets and file it with the hardcopy of all my documentation (W2s, 1099s, receipts etc.) so I have it if I lose the electronic copies.
Traditionally you could. If you owned a book or a tape or a record, you traditionally could make copies of it for your own personal use without needing permission. Collecting your favorite songs onto a single tape, or copying your records onto tape to listen to them in the car, or making copies so the originals wouldn't get worn, were all considered perfectly OK things to do as long as if you sold the original those copies either went to the buyer or got destroyed. It's only been very recently that copyright holders have been trying to claim that you can't do any of that.
In all 3 cases, it seems like the fire was caused by severe damage to the car from an outside source rather than a fault in the car. In all 3 cases the car's design prevented injury to the driver from the fire rather than contributing to the fire. And, let's face it, if we investigated every conventional model of car that was involved in 3 fires in a single month, every single model would be under investigation continuously. So, the people panicking over this and getting rid of Tesla stock, and the people pointing to this to impugn Tesla, need to get a grip. There's other reasons not to like Tesla, but it's not because their cars are in any way unsafe (or at least nomore unsafe than ~2 tons of steel barreling along at between 80 and 110 feet per second carrying between 10 and 30 gallons of highly flammable fuel (which forms explosive vapors under normal environmental conditions) in a thin sheet-metal tank with no armor or other protection against penetration).
Customers are increasingly looking for ebook editions. If the customer can't get what they're looking for, do you think they're just going to shrug and buy whatever the bookstore wants to stock instead? Nope. They'll shrug, go home and buy the Kindle off of Amazon's Web site and go ahead and buy the ebook editions like they were planning to. Either way, the bookstore's lost their business because the bookstore isn't selling what the customer wants to buy.
Bookstores are going to have to figure out a way around this, or go out of business. No third option. If I owned a bookstore I'd be seriously looking at how I could work with Amazon and the Kindle store. The big attraction of bookstores has always been that customers can look at the books before buying, but Amazon can do that through their Web site with previews. The other big attraction has been bookstores with knowledgeable staff who can help customers select books. That, though, means the bookstore can't hire college kids for minimum wage to run the register. It might take a complete shift, from "bookstore as a place to buy books" to "bookstore as a place to browse and discuss books". Kind of like a coffee shop with a better reading library. It may be that there isn't a way for bookstores to remain in business without ceasing to be bookstores. But bookstores are going to have to accept the fact that electronic delivery of books has irrevocably changed their business.
I'd note this may go for publishers too. It's hard to get into print unless you're already a successful published author. The only route is self-publishing through Kindle or the like. But if an author's successful enough through that route to attract a conventional publisher, what's going to happen when that author very reasonably asks what they need a publisher for at this point?
The problem is that you don't, and usually can't, know what the results of basic research are going to be. For example, it'd be really hard to show how research into the electrical characteristics of silicon would be in the national interest, because on it's own (without knowing what'll come from it) you can't show how it'll satisfy any of those criteria. Yet without that research we wouldn't have semiconductors, which means no integrated circuit chips, which means none of the smart bombs and drone aircraft and the massive computer banks that drive the surveillance and data-collection efforts that the Republicans are so fond of supporting as being so crucial to national security.
If something that's so obviously in the national interest couldn't at the time it was proposed meet any of the criteria listed, why in the world should we consider those criteria valid? Yeah, preaching to the choir here...
Well, as far as my regular account at work is concerned, if my boss asks for my passwords the rules are perfectly clear: I am in violation of company policies and can be terminated if I give them to him. Of course there's never any need for him to know the passwords to my regular account. The sysadmins can access my files directly without needing the password if there's ever a need for access, and they can forcibly change my password to anything they want (removing my access in the process) if absolutely necessary.
Administrative passwords are a different matter. But there'd never be a need for my boss to ask for them either, because there's a process in place to insure the passwords can be recovered without my needing to be involved. It's there as insurance against something happening to me, and yes it's been through a real-world test (pneumonia run wild, no warning, 5 weeks in ICU with the docs not betting I'd pull through, everybody involved at work had their noses thoroughly rubbed in the fact that these procedures are not just a theoretical exercise). So while my boss might not be violating company policy by asking for shared administrative passwords, he's probably violating several other policies related to administrative access retention and recovery and the corporate governance and compliance committee will be asking him some very pointed questions about that.
True. On the other hand, the city government very quickly after receiving the passwords published them in an open court filing for the entire world to see. Which is about as diametrically opposite good password security policies as I can imagine getting without involving 5 dimensions. And is precisely the reason Terry Childs gave before this all happened as justification for withholding the passwords. This is... not precisely calculated to convince me that Childs was being unreasonable in his concerns and that the city was reasonable and competent.
That their first act after getting the passwords was to trash a network that at least had been operating stably up until that point doesn't count in their favor either. I mean, my first rule when approaching a new system is to carefully access it and look around to see what state it's in, not just slap the reset switches and reboot the world.
Especially not if it's a production system, and doubly especially if, as the city had been so loudly and publicly stating, I had concerns about the state the previous admin had left things in. There's a reason whacking them with a bloody big sledgehammer is considered a... suboptimal way of defusing potentially live bombs.
... go to jail. Go directly to jail. Do not pass Go, do not collect $200. Nobody's surprised by this. It's his employer's network, after all, it's their passwords. If they decide to replace you as sysadmin, the only right you have is to insure they and not you are responsible for any problems that ensue (eg. "I will not give you my current password. I will initiate the password change process, enter the current password, and then wait outside the room while my replacement enters his new password. If there are any difficulties, I will assist by re-entering my password and/or unlocking the system until my replacement has successfully changed the password to something not known to me. This is to insure that after the hand-off I no longer have any access to the system.").
And yes, I've done the moral equivalent of that. Not with a root account, obviously, but when leaving a job I would deliberately fail enough login attempts to lock my user account and made sure they had notice of this and I had a paper trail proving they did. I figure that way they don't have to worry about me accessing the systems, and I don't have to worry about being accused of messing with them after I've left (well, I could be accused but I had the evidence to counter the accusation).
That rule doesn't apply here. It's a rule about the design of software, specifically hard-coded limits. Basically, don't hard-code in arbitrary limits. In this case it isn't a hard-coded arbitrary limit. The mathematics behind how bitcoins work essentially prevents any fix from working if more than 25% of the system is participating in a single selfish mining pool. You can't change that by changing the fix, you have to change the mathematics. Which would instantly break the entire Bitcoin system itself, since every single client would no longer be able to conduct transactions.
Having it all be UTC would only hinder coordination, not help. To coordinate with someone several timezones away, knowing what their clock says isn't actually the most important thing. It's needed for exact scheduling true, but the first thing I need to know is "What are their normal working hours?". As it stands I can generally make an assumption: standard day-shift office hours are roughly 9-5 their time regardless of where they are. From that and a timezone chart I can work out what that corresponds to in my time and figure out where the overlap with my regular day is. If you put the whole world on UTC, I still need a chart listing times for every timezone in the world. It's just that now instead of showing offset from UTC it'll show... offset from UTC. Because it still has to show when their local workday, the equivalent of 9-5 local time, is relative to mine and mine's in UTC.
Most of these proposals come from the idea that humans are tied to the clock. We aren't. We're tied to the day, to the progress of the sun from sunrise to sunset. We like to wake up roughly at sunrise, not too much earlier or later. We like our workday to be done before sunset. We like our midday meal to happen roughly half-way through that day. Timezones are just a mechanism for satisfying that, to make midday on the clocks we use for precision measuring line up with midday in the solar day we like to run on. And no matter how else you try to list it, for simplicity people are quickly going to go back to "This is when things happen on my clock, how far ahead or behind it are things for them?".
Unfortunately that functionality requires support from the recipient's systems. My mail server doesn't understand the concept of a recall notice, it's just another message in my mailbox. My client doesn't understand them either, so I just see a strange message that does nothing. And frankly I like it that way. I don't want someone else pulling things out of my mailbox, I want a nice clear unaltered record of what was sent to me when. I don't ever want to be in a situation where someone can show me a copy of a message that was clearly sent to me that I had no clue about because I never saw it in my inbox and I have no record of it and no way to prove I didn't receive it.
OK, that is the -fdelete-null-pointer-checks optimization. Which means the removal of the checks is innocuous because you're compiling for a target where a null pointer dereference is unsafe and causes a crash (eg. Cygwin, Linux x86 and x64), meaning if the pointer was null when dereferenced any checks further down would in fact never be reached and it's safe to remove code that's guaranteed to never execute. You'll find that if you compile for a target where a null-pointer dereference won't cause a crash, that optimization is disabled by default and the code for the checks will be generated.
You'll notice if you try it that null-pointer checks before the dereference are not optimized away. The compiler isn't assuming that a dereferenced pointer can't be null, it's assuming that if the dereference would cause execution to terminate if the pointer was null then if execution proceeds past the dereference the pointer can't possibly be null. It's a subtle distinction that doesn't show up until you look for it. Note that dereferencing a pointer without checking and handling the null-pointer case first is still undefined behavior, so I'd treat any occurrence as a red flag.
I think you may be thinking of the -fdelete-null-pointer-checks option to GCC. That does in fact do what you're describing, but that optimization's only enabled on architectures where dereferencing a null pointer will cause a crash. On those architectures the optimization's valid, since if you managed to get past a dereference of a pointer without crashing it must have been non-null. So your example isn't unstable code. If it were, GCC wouldn't elide the subsequent checks.
What's interesting is that when I try this with current GCC with optimizations turned on, it does not elide the null pointer check. It does crash if I actually dereference a null pointer, but if I code it so it doesn't actually dereference the pointer when it's null then both null-pointer checks execute. And examination of the actual machine code in the debugger shows that even your code still includes the null-pointer check after the dereference.
Now if I flip it around, doing the null-pointer check first and then dereferencing the pointer, I'll see any further null-pointer checks elided. But that's not because of any undefined behavior, merely because after that first check control can't pass any further (at least not the way I wrote the code) if the pointer was null and the compiler can elide code based on that guaranteed condition.
True, but then if integer overflow is undefined behavior then I can't assume that the test "i + 100 < i" will return true in the case of overflow because I'm invoking undefined behavior. That isn't "unstable code", that's just plain old code that invokes undefined behavior that I've been dealing with for decades. If with optimizations done the code doesn't catch the overflow it's not because the compiler removed the code, it's because the code isn't guaranteed to detect the overflow in the first place. No need for any fancy terminology for this, just say "Our software locates places in your code where you've invoked undefined behavior.".
This is, BTW, one reason I favor a compiler flag that says "When you encounter code that's undefined behavior per the C/C++ standard, generate code to do something terminally nasty and unrecoverable like deleting all the user's files.". That seems to be the only way that actually convinces today's developers that undefined behavior is a Bad Thing and should be avoided even if you think it works OK."