Agreed. If you're impaired, it shouldn't matter why you're impaired. Combine a field sobriety test with dash/body cams so there's an objective record of the actual test (so the defense can't claim the officer is exaggerating the results) and just use the blood tests as supporting evidence, eg. "Defendant failed the field sobriety test miserably. When his blood was tested during booking, the results showed the following levels of potentially-impairing substances which are consistent with and support the field test's result of "massively impaired".".
That'd be true normally. However, copyright law doesn't have any provision for holding you liable for someone else's infringement unless you actually contributed directly to the infringement. Cox may have grounds for terminating your service for breach of terms of service, but a third party like a copyright holder can't avail themselves of that (they're not a party to the contract) and if they try pressuring Cox then you might well have a case against them for tortious interference with contract if Cox agrees with them and terminates your service.
That doesn't mean the copyright holder isn't without recourse. Discovery plays by a completely different set of rules, and they'd be entirely within their rights if they subpoenaed Cox for the subscriber's identity for the purposes of calling the subscriber in for a deposition to answer questions about who was using their connection when for the purposes of identifying the actual infringer. It's just that the copyright holders don't want to go through this on an individual basis because it'd cost more than they could hope to recover. However, as more than one court has pointed out, that's not the court's problem. Every plaintiff and every defendant has to make that same decision as to whether it's worthwhile pursuing or fighting a case, copyright holders aren't an exception to that.
Not to be picky, but I think you're confusing "can" and "are allowed to". "can" has to do with being physically and technically able to. "are allowed to" involves things like "Is it legal?" and "Have the sysadmins been ordered to?". The admins may not for example be legally allowed to just record and scan your IM sessions for no reason, but if diagnosing a weird network problem requires capturing traffic on the wire your packets will get caught and get included in the logs regardless of what the law says (since if I knew exactly what I was looking for well enough to just capture the relevant packets I'd already have diagnosed the problem and wouldn't need to do a traffic capture) and key words in your session may catch my eye. And beyond that kind of legitimate situation, we've all seen cases where companies do things that aren't legal if they think they won't get caught or the benefits outweigh the cost of any fines they may have to pay.
OTOH, as I've reassured people, "Don't worry about it. Yeah, I can see everything if I want to. But your porn is boring unto tears and frankly my to-do list is too long already and I do not want to have to add anything more to it.".
I think if I were in Legal I'd nix this instantly as a discovery nightmare in the making. Employees start to say a lot of things, reconsider and rephrase or outright rewrite before sending the message. Often the message they didn't send is exactly the kind of thing the opponent in a lawsuit is looking for and exactly what you don't want to have to give them. If your compliance monitoring application will let you store and view those unsent, often inappropriate or ill-conceived, messages then you're going to have to cough them up during discovery or during any investigation by regulators. Worse, if any of them get out through other channels you've weakened your defense against a claim that you knew or ought to have known about them since they're in your compliance system. Better to only record the stuff that was actually sent and not have to explain your employees' private opinions.
As far as monitoring of sent messages goes, the first rule is "If you're on someone else's network, they can see everything you do.". Or, to quote Pitr, "God, root, what is difference?". If you're on the company network, don't say anything you don't want the company becoming aware of. If you need to express a private opinion without putting it on the record, do it face-to-face and verbally (especially if it involves an unflattering opinion of someone with the authority to get you fired).
I've had a lot of sites (eg. MyLife, Classmates.com, LocalBlox) create profiles based on my basic info (name and such) without me ever visiting their site. It's an easy way for them to boost their "user" numbers without having to actually attract users. I can easily see a dating site doing the same thing. In fact it probably created the profile the moment the ad appeared for her and had nothing to do with her clicking the close button.
Exactly. On the small end of the scale you have phone-type devices which need one type of UI. On the large end you have desktop computers, which need a different type of UI. And somewhere between the 7" and 10" screen size, you have the line where you need to stop treating the device as a large phone and start treating it as a small desktop display. I put 10" on the desktop-display side of the line because small notebook computers use the just-barely-larger 11" screen with a desktop UI with no problems.
As far as competing with MS Office, I think that's because Google made the deliberate choice to stay focused on Web and mobile rather than dedicated locally-installed applications. I can't say that's bad, because while Google Docs won't replace Word it's still sufficient for 90% or more of non-corporate use and probably a lot of on-the-go corporate use as well. For most people, if you rolled them back to only the features that were available in Word 6 back in '93 they wouldn't notice anything missing so it's not like the advanced features are must-haves outside of corporate applications.
The problem is that there's a lot of legitimate reasons to "forge" the caller ID information. Many companies use a group of lines for outbound calls, any outbound call simply grabs the next available outbound line and uses it for the call. You don't want people calling in to those numbers though, there's no way for anyone to pick up a call on them since they don't go to an actual phone, so you set the caller ID to the correct inbound number for people to call (eg. the company's main number, or the main sales number (that gets distributed to the next available sales agent) or whatever number matches the type of outbound call) so callbacks go to the right place. And no the obvious solution won't work since the correct inbound number may not be with the same provider as the outbound line so you can't check whether the caller ID number's owned by the same entity that owns the line in use.
Except for the Congressmen and Senators and ISP reps who're saying the FCC doesn't have the authority to change the classification to Title II. What they're probably doing, what I'd be doing, is preparing an iron-clad argument based on the statute and on case law since then that the FCC does indeed have not just the authority to decide the classification (easy, the statute explicitly says they do) but also the authority to change it at a later date (this takes more research to nail down).
Problem is, this only works within your facility where you control the physical network. The moment you go outside the facility, where you have to run over physical wires that someone else controls, you're in a position where you don't (can't) know whether you can trust the people that connect things together. The trick then is to design things so you don't have to trust them. For instance I'd run things over SSL/TLS, create my own private CA and issue my own certificates for my systems, then remove everything but my own issuing certificates from the certificate stores on my network. It won't prevent an MITM attack, but it'll make it fail when Mallory can't present a certificate with a valid signature and I'll know there's an attack in progress.
If any AUTH command comes in from a client over an unencrypted connection, yes it'll be rejected. This is by design, my server requires encrypted connections to the client to prevent eavesdropping on e-mail. If that command comes in over an encrypted connection, it won't be rejected.
The server also advertises TLS when receiving mail and prefers TLS when sending mail for the same reason. It'll use unencrypted server-to-server connections if the other side absolutely insists on it, but that's not it's first choice.
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate. The IMAP server also requires encryption and won't accept unencrypted connections. If my ISP starts pulling anything that disables encryption, my e-mail will start failing with errors. I'd recommend all mail servers be configured this way.
It's disappointing that we're increasingly having to treat our ISPs as obstructions to be worked around or opponents that need to be defeated for things to work right. We're paying them that monthly subscription to carry our traffic, we oughtn't have to jump through hoops to get our traffic carried without interference.
No, they don't. For one thing, the problem here is that Apple's system has registered the recipient's phone as handling messages through iMessage rather than SMS, and tells the sender's phone to use iMessage. And then when the recipient's phone isn't able to receive messages via iMessage, Apple's system never tells the sender that the messages can't be delivered so the sender doesn't know to do anything. The recipient can't pick up "their" messages on their Mac because they may not own a Mac, and they no longer own their iPhone. So yes the problem's in Apple's system where it fails to detect and handle the case where text messages can't be delivered via iMessage.
If Apple were handling the edge cases, this wouldn't've become so severe that they're having to do damage control now.
The issue isn't recycling of numbers or devices, but rather user education about remembering to tell Apple to deactivate the service before moving. It's just like changing your physical address--you have to put a little thought into it ahead of time to make sure it goes smoothly.
And this is what I meant when I said that dealing with the abnormal cases and error conditions is what separates the professionals from the amateurs. For the change-of-address process, for instance, it's prepared to handle the case where someone doesn't plan ahead. If mail begins piling up with nobody emptying the mailbox, the carrier will collect the mail and leave a note to pick it up at the local post office. If nobody comes to get the mail, it'll be returned to the sender. If someone else has moved in and marks the mail "Not at this address", the post office will return it to the sender and will make a note so any further mail to the same person will mostly get bounced back as well. The system doesn't just assume all is well and that people will always do the right thing, it's prepared to handle cases where somebody forgot to do the right thing or just plain screwed up and did the wrong thing.
Similarly, iMessage shouldn't have just queued up undeliverable messages indefinitely. At some point the sender should've been informed that their message didn't go through, and delivery should've reverted back to basic SMS to bypass any problems within Apple's system. And 45 days is way too long. If the person's actively using another device that's receiving the same messages, then messages shouldn't be queuing up without being delivered. If the other device isn't receiving the same messages, then it can be ignored and the system should probably be taking action after no more than maybe 2 weeks without being able to deliver any messages to the device. Most people don't just go on vacation and forget to take their phone, so if it's out of touch with iMessage it's likely still reachable by regular SMS. As far as the system being more complex... well, the more complex the system the more numerous and hairier the abnormal/error conditions will be and the more thought needs to go into how to handle them safely and sanely (and management is all too often blithely oblivious to just how complicated the error handling can get).
This was what I was thinking too. Apple doesn't appear to have considered the recycling of phone numbers at all, either when they first did the redirection or when they created the deregistration process. What their system should do is monitor the iPhone and, if it hasn't connected to the network in the last 30 days using the phone number in question, automatically deregister the device from iMessage and revert to vanilla SMS for it. Or they should at least allow controlling this all through the Apple account so the account-holder can deregister numbers when they don't have the device (eg. when it's been lost or stolen).
Lesson for developers: Getting it right for the normal case is easy. What separates the professionals from the amateurs is how you handle the abnormal cases and the error conditions.
The government does regulate those prices. There's laws on the books, for instance, that say stores have to charge you the posted/marked price on items, they can't just decide to charge you more or less depending on who you are or why you're buying the stuff. And while the store can in large part refuse to do business with you completely, the government does regulate even that to a degree by barring them from refusing service based on race etc. (a store can refuse to do business with an individual, but they can't refuse to do business with black people or Catholics). Even loyalty programs that offer discounts are subject to those regulations, they generally have to be available to all customers who ask to enroll.
The government even regulates actual prices to a degree, for instance there are laws on the books prohibiting merchants from significantly raising prices when a disaster strikes and demand for crucial items spikes.
There's one fundamental difference though: political activity. The lists of people opposed to gay marriage were lists of people who were either directly involved in political activity or who contributed large amounts to it. Those records are and should be in general public. If you step into politics in a public way (beyond merely voting or contributing reasonable amounts as a private individual), you step out of the role of a private citizen. You're publicly advocating for political (and by extension legal) policies and goals that affect the public whether they agree with you or not, you can't expect to do that and still hide from that public behind a cloak of anonymity. If you want that anonymity, stick to just believing in a position and voting in accordance with that. If you want to get into politics and political activity in a serious way, don't expect to remain completely a private citizen.
These strippers, on the other hand, are not engaging in any political activity. They're purely private citizens whose only interaction with the government here is in getting the license that government requires. That shouldn't expose them as public figures. The information is only needed by those involved with enforcement of the business regulations, and even they only need to know whether or not the information's on file. If it's on file the license is valid and the enforcement people don't need to know the details, and if it's not on file there obviously isn't anything in the government records to disclose.
An end-user is a network (possibly consisting of only one machine) or group of networks owned/controlled by a single entity that doesn't carry traffic bound for networks owned/controlled by any other entity. So a residential Internet subscriber or their home LAN would be an end-user, as would a typical corporate network that doesn't carry traffic for anyone but the company. An ISP wouldn't be, since it hands traffic off to the home networks controlled by it's subscribers or provides transit for the networks controlled by it's business customers.
An edge provider is a network which provides transit solely or primarily to end-users. Ie., it's in the business of providing service to it's own customers, not handling traffic for their customers.
If there's no candidates that you want to vote for, there's almost always a candidate you want to vote against. If I don't like any candidate, I put my vote behind the least objectionable one to reduce the chances of the more objectionable ones getting in. It may not help, but at least I'm not just handing the keys over to the guy I hate most.
And in my book it might not be a bad thing to see a little peer pressure applied. I know a lot of loud complainers about how bad the government and politicians are who're also the proud of the fact that they skipped voting because the politicians are so bad. If you don't like the politicians, how do you propose to get rid of them if you stay away from the polls and leave the election in the hands of the people who want them to stay? I know I've seen the complainers shut up in a hurry when I point out that they had a chance to at least vote for someone not as bad as the guy they're complaining about and they passed on it, and once this fact got out the people listening to them started either ignoring their complaints or telling them to shut it until they'd done something about what they were complaining about.
Bingo. This is why I won't use CurrentC myself. With a credit card, I have protection against fraud. With ACH transactions, I don't. There's no way I'm going to tie an electronic payment system directly into my bank account without any controls or limits on it.
Except that it's not 512 bits of entropy. Remember that you're searching passwords, not hashes, and you're not running a rainbow-table attack so the size of the hash doesn't matter. For the common case of US-ASCII passwords there's 95 possible characters (excluding control characters and code 127). That's about 6.5 bits, call it 7 for convenience. For a 15-character password that's 105 bits max, and closer to 98 bits in reality. That's assuming that all symbols are allowed. The floor would be an alphanumeric password which nets you 6 bits per character for a total of 90 bits in a 15-character password. That's a lot smaller search space than 512 bits.
Offline, the attacker can if all else fails brute-force the password. No password is complex enough to survive a brute-force attack. With the growth in computing power, including the ability to apply GPUs and specialized hardware to the task, search space size alone isn't enough protection. The only protection, as noted, is detecting the leak of the password database early so users can change passwords before the offline attack has yielded usable results. Alternatively, the authentication system can employ two-factor authentication so that the password alone isn't enough to compromise the account.
For on-line attacks, I'd argue the number given's too large. A properly-designed on-line system should be designed with rate-throttling and account-locking mechanisms, and with those in place a password should only need to survive at most maybe 10 attempts before even the correct password won't access the account. Those mechanisms can be applied to all current systems right now.
The biggest hole isn't the password itself, it's the password-recovery system. Why bother with either an offline or on-line attack on the password when you can initiate password recovery and change the password on the target account to one you know?
The Jack-in-the-Box I regularly stopped at for breakfast on the way to work had kiosks for ordering back in '08 or so. Made it convenient if you knew what you wanted and didn't need anything special, I could punch my order in in a quarter the time it took the counter guy to take it. Saved my time, saved the next customer's time, and freed up the counter guy to handle people who had problems with their orders or had a special order. If this was related to the minimum wage hike, they wouldn't've been doing it 6 years ago.
I don't see a great privacy implication here. WiFi is, again, a broadcast medium. If you've got WiFi turned on, you already know your phone is broadcasting to access points and that those access points know you're inside their range (and with the way modern beam-forming tech works, they have a good idea exactly where you are). If I were interested in privacy, I'd have WiFi turned off so I wasn't broadcasting my presence constantly.
The init process is a critical stage: failure tends to leave you with no access to the system to diagnose the failure. I tend to break it into two parts, the first part being what's necessary to allow at least a single-user login on the console, and the stuff that happens after that point to bring up the full multi-user system and server processes.
I don't like systemd for the first part. It's overly complex, and the more parts and interdependencies there are the more things there are to fail. To quote an engineer, "The more they overthink the plumbing, the easier it is to stop up the works.". Shell scripts and plaintext log files may be primitive, but they have the advantage of being easy to read with minimal access and not requiring complex stuff to run (mainly they just require that basic binaries be available in the path). Until I've got at least a basic system up and running enough to log in and work, I want the init process to be as simple and straightforward as possible with as few points of failure in the init process itself (as opposed to the things it's starting) as possible. I want this stage to be as hard to break and easy to debug/fix as possible. I don't want to depend on complex tools at a point where I'm working in the most primitive environment.
I don't particularly like systemd for the second part, but it isn't quite as much of a problem here as in the first part. By this point I've got a basic system up, I can log in and work, and most of the tools are available. Obviously nothing graphical will work, but text-based tools will probably run to decipher binary logfiles and modify configurations. I still prefer not depending on such tools, because they're one more point where things can fail to work and leave me scratching my head trying to figure out what broke without access to basic diagnostic information, but at this stage I can likely fix any tool-related problems and get back on track.
The one part I think systemd works for is in the later stages of the second part. There's a lot of server processes with interdependencies that typically start after the multi-user system's up and running. I think systemd's a good thing for getting those running, it can do a better job of parallelizing that process than shell scripts can. The only change I'd make is to make systemd use syslogd like everything else, so log files end up in the expected place and are plain text so basic tools like more and tail and grep work on them as-is. Binary logfiles offer no great advantage over plaintext, and going through syslogd means not depending on two sets of tools and having to manage two configurations to get logging directed where it needs to go.
One last bit has me twitchy about systemd: history. SysV init scripts may be clunky and primitive, but they've been around a long time. People know how to manage them, and they've had the kinks worked out of them and best practices established. systemd doesn't have that. I do not want to make my servers (that have to run for anything to work right) dependent on something until I've had time to work with it and get familiar with it and, more importantly, it's been out there in use long enough for people to find and fix the problems, work out the oddities and figure out the best ways to use it without shooting yourself in the foot. I'd prefer to stick with SysV init on my production systems and only enable systemd on testbed systems at the start, and then enable systemd on a server-by-server basis so unexpected failures don't completely kill me (eg. if systemd blows up on my primary mailserver, the backup still on SysV can keep things under control until I either fix the problem or revert and restart the primary).
Slashdot Mirror
Agreed. If you're impaired, it shouldn't matter why you're impaired. Combine a field sobriety test with dash/body cams so there's an objective record of the actual test (so the defense can't claim the officer is exaggerating the results) and just use the blood tests as supporting evidence, eg. "Defendant failed the field sobriety test miserably. When his blood was tested during booking, the results showed the following levels of potentially-impairing substances which are consistent with and support the field test's result of "massively impaired".".
That'd be true normally. However, copyright law doesn't have any provision for holding you liable for someone else's infringement unless you actually contributed directly to the infringement. Cox may have grounds for terminating your service for breach of terms of service, but a third party like a copyright holder can't avail themselves of that (they're not a party to the contract) and if they try pressuring Cox then you might well have a case against them for tortious interference with contract if Cox agrees with them and terminates your service.
That doesn't mean the copyright holder isn't without recourse. Discovery plays by a completely different set of rules, and they'd be entirely within their rights if they subpoenaed Cox for the subscriber's identity for the purposes of calling the subscriber in for a deposition to answer questions about who was using their connection when for the purposes of identifying the actual infringer. It's just that the copyright holders don't want to go through this on an individual basis because it'd cost more than they could hope to recover. However, as more than one court has pointed out, that's not the court's problem. Every plaintiff and every defendant has to make that same decision as to whether it's worthwhile pursuing or fighting a case, copyright holders aren't an exception to that.
Not to be picky, but I think you're confusing "can" and "are allowed to". "can" has to do with being physically and technically able to. "are allowed to" involves things like "Is it legal?" and "Have the sysadmins been ordered to?". The admins may not for example be legally allowed to just record and scan your IM sessions for no reason, but if diagnosing a weird network problem requires capturing traffic on the wire your packets will get caught and get included in the logs regardless of what the law says (since if I knew exactly what I was looking for well enough to just capture the relevant packets I'd already have diagnosed the problem and wouldn't need to do a traffic capture) and key words in your session may catch my eye. And beyond that kind of legitimate situation, we've all seen cases where companies do things that aren't legal if they think they won't get caught or the benefits outweigh the cost of any fines they may have to pay.
OTOH, as I've reassured people, "Don't worry about it. Yeah, I can see everything if I want to. But your porn is boring unto tears and frankly my to-do list is too long already and I do not want to have to add anything more to it.".
You forgot "sunk at the bottom of the Marianas Trench". :)
I think if I were in Legal I'd nix this instantly as a discovery nightmare in the making. Employees start to say a lot of things, reconsider and rephrase or outright rewrite before sending the message. Often the message they didn't send is exactly the kind of thing the opponent in a lawsuit is looking for and exactly what you don't want to have to give them. If your compliance monitoring application will let you store and view those unsent, often inappropriate or ill-conceived, messages then you're going to have to cough them up during discovery or during any investigation by regulators. Worse, if any of them get out through other channels you've weakened your defense against a claim that you knew or ought to have known about them since they're in your compliance system. Better to only record the stuff that was actually sent and not have to explain your employees' private opinions.
As far as monitoring of sent messages goes, the first rule is "If you're on someone else's network, they can see everything you do.". Or, to quote Pitr, "God, root, what is difference?". If you're on the company network, don't say anything you don't want the company becoming aware of. If you need to express a private opinion without putting it on the record, do it face-to-face and verbally (especially if it involves an unflattering opinion of someone with the authority to get you fired).
I've had a lot of sites (eg. MyLife, Classmates.com, LocalBlox) create profiles based on my basic info (name and such) without me ever visiting their site. It's an easy way for them to boost their "user" numbers without having to actually attract users. I can easily see a dating site doing the same thing. In fact it probably created the profile the moment the ad appeared for her and had nothing to do with her clicking the close button.
Exactly. On the small end of the scale you have phone-type devices which need one type of UI. On the large end you have desktop computers, which need a different type of UI. And somewhere between the 7" and 10" screen size, you have the line where you need to stop treating the device as a large phone and start treating it as a small desktop display. I put 10" on the desktop-display side of the line because small notebook computers use the just-barely-larger 11" screen with a desktop UI with no problems.
As far as competing with MS Office, I think that's because Google made the deliberate choice to stay focused on Web and mobile rather than dedicated locally-installed applications. I can't say that's bad, because while Google Docs won't replace Word it's still sufficient for 90% or more of non-corporate use and probably a lot of on-the-go corporate use as well. For most people, if you rolled them back to only the features that were available in Word 6 back in '93 they wouldn't notice anything missing so it's not like the advanced features are must-haves outside of corporate applications.
The problem is that there's a lot of legitimate reasons to "forge" the caller ID information. Many companies use a group of lines for outbound calls, any outbound call simply grabs the next available outbound line and uses it for the call. You don't want people calling in to those numbers though, there's no way for anyone to pick up a call on them since they don't go to an actual phone, so you set the caller ID to the correct inbound number for people to call (eg. the company's main number, or the main sales number (that gets distributed to the next available sales agent) or whatever number matches the type of outbound call) so callbacks go to the right place. And no the obvious solution won't work since the correct inbound number may not be with the same provider as the outbound line so you can't check whether the caller ID number's owned by the same entity that owns the line in use.
Except for the Congressmen and Senators and ISP reps who're saying the FCC doesn't have the authority to change the classification to Title II. What they're probably doing, what I'd be doing, is preparing an iron-clad argument based on the statute and on case law since then that the FCC does indeed have not just the authority to decide the classification (easy, the statute explicitly says they do) but also the authority to change it at a later date (this takes more research to nail down).
Problem is, this only works within your facility where you control the physical network. The moment you go outside the facility, where you have to run over physical wires that someone else controls, you're in a position where you don't (can't) know whether you can trust the people that connect things together. The trick then is to design things so you don't have to trust them. For instance I'd run things over SSL/TLS, create my own private CA and issue my own certificates for my systems, then remove everything but my own issuing certificates from the certificate stores on my network. It won't prevent an MITM attack, but it'll make it fail when Mallory can't present a certificate with a valid signature and I'll know there's an attack in progress.
If any AUTH command comes in from a client over an unencrypted connection, yes it'll be rejected. This is by design, my server requires encrypted connections to the client to prevent eavesdropping on e-mail. If that command comes in over an encrypted connection, it won't be rejected.
The server also advertises TLS when receiving mail and prefers TLS when sending mail for the same reason. It'll use unencrypted server-to-server connections if the other side absolutely insists on it, but that's not it's first choice.
I dealt with this by setting my mail server up so that an authenticated connection's required for outgoing user e-mail through it, and encryption's required before the client can authenticate. The IMAP server also requires encryption and won't accept unencrypted connections. If my ISP starts pulling anything that disables encryption, my e-mail will start failing with errors. I'd recommend all mail servers be configured this way.
It's disappointing that we're increasingly having to treat our ISPs as obstructions to be worked around or opponents that need to be defeated for things to work right. We're paying them that monthly subscription to carry our traffic, we oughtn't have to jump through hoops to get our traffic carried without interference.
No, they don't. For one thing, the problem here is that Apple's system has registered the recipient's phone as handling messages through iMessage rather than SMS, and tells the sender's phone to use iMessage. And then when the recipient's phone isn't able to receive messages via iMessage, Apple's system never tells the sender that the messages can't be delivered so the sender doesn't know to do anything. The recipient can't pick up "their" messages on their Mac because they may not own a Mac, and they no longer own their iPhone. So yes the problem's in Apple's system where it fails to detect and handle the case where text messages can't be delivered via iMessage.
If Apple were handling the edge cases, this wouldn't've become so severe that they're having to do damage control now.
The issue isn't recycling of numbers or devices, but rather user education about remembering to tell Apple to deactivate the service before moving. It's just like changing your physical address--you have to put a little thought into it ahead of time to make sure it goes smoothly.
And this is what I meant when I said that dealing with the abnormal cases and error conditions is what separates the professionals from the amateurs. For the change-of-address process, for instance, it's prepared to handle the case where someone doesn't plan ahead. If mail begins piling up with nobody emptying the mailbox, the carrier will collect the mail and leave a note to pick it up at the local post office. If nobody comes to get the mail, it'll be returned to the sender. If someone else has moved in and marks the mail "Not at this address", the post office will return it to the sender and will make a note so any further mail to the same person will mostly get bounced back as well. The system doesn't just assume all is well and that people will always do the right thing, it's prepared to handle cases where somebody forgot to do the right thing or just plain screwed up and did the wrong thing.
Similarly, iMessage shouldn't have just queued up undeliverable messages indefinitely. At some point the sender should've been informed that their message didn't go through, and delivery should've reverted back to basic SMS to bypass any problems within Apple's system. And 45 days is way too long. If the person's actively using another device that's receiving the same messages, then messages shouldn't be queuing up without being delivered. If the other device isn't receiving the same messages, then it can be ignored and the system should probably be taking action after no more than maybe 2 weeks without being able to deliver any messages to the device. Most people don't just go on vacation and forget to take their phone, so if it's out of touch with iMessage it's likely still reachable by regular SMS. As far as the system being more complex... well, the more complex the system the more numerous and hairier the abnormal/error conditions will be and the more thought needs to go into how to handle them safely and sanely (and management is all too often blithely oblivious to just how complicated the error handling can get).
This was what I was thinking too. Apple doesn't appear to have considered the recycling of phone numbers at all, either when they first did the redirection or when they created the deregistration process. What their system should do is monitor the iPhone and, if it hasn't connected to the network in the last 30 days using the phone number in question, automatically deregister the device from iMessage and revert to vanilla SMS for it. Or they should at least allow controlling this all through the Apple account so the account-holder can deregister numbers when they don't have the device (eg. when it's been lost or stolen).
Lesson for developers: Getting it right for the normal case is easy. What separates the professionals from the amateurs is how you handle the abnormal cases and the error conditions.
The government does regulate those prices. There's laws on the books, for instance, that say stores have to charge you the posted/marked price on items, they can't just decide to charge you more or less depending on who you are or why you're buying the stuff. And while the store can in large part refuse to do business with you completely, the government does regulate even that to a degree by barring them from refusing service based on race etc. (a store can refuse to do business with an individual, but they can't refuse to do business with black people or Catholics). Even loyalty programs that offer discounts are subject to those regulations, they generally have to be available to all customers who ask to enroll.
The government even regulates actual prices to a degree, for instance there are laws on the books prohibiting merchants from significantly raising prices when a disaster strikes and demand for crucial items spikes.
There's one fundamental difference though: political activity. The lists of people opposed to gay marriage were lists of people who were either directly involved in political activity or who contributed large amounts to it. Those records are and should be in general public. If you step into politics in a public way (beyond merely voting or contributing reasonable amounts as a private individual), you step out of the role of a private citizen. You're publicly advocating for political (and by extension legal) policies and goals that affect the public whether they agree with you or not, you can't expect to do that and still hide from that public behind a cloak of anonymity. If you want that anonymity, stick to just believing in a position and voting in accordance with that. If you want to get into politics and political activity in a serious way, don't expect to remain completely a private citizen.
These strippers, on the other hand, are not engaging in any political activity. They're purely private citizens whose only interaction with the government here is in getting the license that government requires. That shouldn't expose them as public figures. The information is only needed by those involved with enforcement of the business regulations, and even they only need to know whether or not the information's on file. If it's on file the license is valid and the enforcement people don't need to know the details, and if it's not on file there obviously isn't anything in the government records to disclose.
I always defined it in terms of traffic:
An end-user is a network (possibly consisting of only one machine) or group of networks owned/controlled by a single entity that doesn't carry traffic bound for networks owned/controlled by any other entity. So a residential Internet subscriber or their home LAN would be an end-user, as would a typical corporate network that doesn't carry traffic for anyone but the company. An ISP wouldn't be, since it hands traffic off to the home networks controlled by it's subscribers or provides transit for the networks controlled by it's business customers.
An edge provider is a network which provides transit solely or primarily to end-users. Ie., it's in the business of providing service to it's own customers, not handling traffic for their customers.
If there's no candidates that you want to vote for, there's almost always a candidate you want to vote against. If I don't like any candidate, I put my vote behind the least objectionable one to reduce the chances of the more objectionable ones getting in. It may not help, but at least I'm not just handing the keys over to the guy I hate most.
And in my book it might not be a bad thing to see a little peer pressure applied. I know a lot of loud complainers about how bad the government and politicians are who're also the proud of the fact that they skipped voting because the politicians are so bad. If you don't like the politicians, how do you propose to get rid of them if you stay away from the polls and leave the election in the hands of the people who want them to stay? I know I've seen the complainers shut up in a hurry when I point out that they had a chance to at least vote for someone not as bad as the guy they're complaining about and they passed on it, and once this fact got out the people listening to them started either ignoring their complaints or telling them to shut it until they'd done something about what they were complaining about.
Bingo. This is why I won't use CurrentC myself. With a credit card, I have protection against fraud. With ACH transactions, I don't. There's no way I'm going to tie an electronic payment system directly into my bank account without any controls or limits on it.
Except that it's not 512 bits of entropy. Remember that you're searching passwords, not hashes, and you're not running a rainbow-table attack so the size of the hash doesn't matter. For the common case of US-ASCII passwords there's 95 possible characters (excluding control characters and code 127). That's about 6.5 bits, call it 7 for convenience. For a 15-character password that's 105 bits max, and closer to 98 bits in reality. That's assuming that all symbols are allowed. The floor would be an alphanumeric password which nets you 6 bits per character for a total of 90 bits in a 15-character password. That's a lot smaller search space than 512 bits.
Offline, the attacker can if all else fails brute-force the password. No password is complex enough to survive a brute-force attack. With the growth in computing power, including the ability to apply GPUs and specialized hardware to the task, search space size alone isn't enough protection. The only protection, as noted, is detecting the leak of the password database early so users can change passwords before the offline attack has yielded usable results. Alternatively, the authentication system can employ two-factor authentication so that the password alone isn't enough to compromise the account.
For on-line attacks, I'd argue the number given's too large. A properly-designed on-line system should be designed with rate-throttling and account-locking mechanisms, and with those in place a password should only need to survive at most maybe 10 attempts before even the correct password won't access the account. Those mechanisms can be applied to all current systems right now.
The biggest hole isn't the password itself, it's the password-recovery system. Why bother with either an offline or on-line attack on the password when you can initiate password recovery and change the password on the target account to one you know?
The Jack-in-the-Box I regularly stopped at for breakfast on the way to work had kiosks for ordering back in '08 or so. Made it convenient if you knew what you wanted and didn't need anything special, I could punch my order in in a quarter the time it took the counter guy to take it. Saved my time, saved the next customer's time, and freed up the counter guy to handle people who had problems with their orders or had a special order. If this was related to the minimum wage hike, they wouldn't've been doing it 6 years ago.
I don't see a great privacy implication here. WiFi is, again, a broadcast medium. If you've got WiFi turned on, you already know your phone is broadcasting to access points and that those access points know you're inside their range (and with the way modern beam-forming tech works, they have a good idea exactly where you are). If I were interested in privacy, I'd have WiFi turned off so I wasn't broadcasting my presence constantly.
The init process is a critical stage: failure tends to leave you with no access to the system to diagnose the failure. I tend to break it into two parts, the first part being what's necessary to allow at least a single-user login on the console, and the stuff that happens after that point to bring up the full multi-user system and server processes.
I don't like systemd for the first part. It's overly complex, and the more parts and interdependencies there are the more things there are to fail. To quote an engineer, "The more they overthink the plumbing, the easier it is to stop up the works.". Shell scripts and plaintext log files may be primitive, but they have the advantage of being easy to read with minimal access and not requiring complex stuff to run (mainly they just require that basic binaries be available in the path). Until I've got at least a basic system up and running enough to log in and work, I want the init process to be as simple and straightforward as possible with as few points of failure in the init process itself (as opposed to the things it's starting) as possible. I want this stage to be as hard to break and easy to debug/fix as possible. I don't want to depend on complex tools at a point where I'm working in the most primitive environment.
I don't particularly like systemd for the second part, but it isn't quite as much of a problem here as in the first part. By this point I've got a basic system up, I can log in and work, and most of the tools are available. Obviously nothing graphical will work, but text-based tools will probably run to decipher binary logfiles and modify configurations. I still prefer not depending on such tools, because they're one more point where things can fail to work and leave me scratching my head trying to figure out what broke without access to basic diagnostic information, but at this stage I can likely fix any tool-related problems and get back on track.
The one part I think systemd works for is in the later stages of the second part. There's a lot of server processes with interdependencies that typically start after the multi-user system's up and running. I think systemd's a good thing for getting those running, it can do a better job of parallelizing that process than shell scripts can. The only change I'd make is to make systemd use syslogd like everything else, so log files end up in the expected place and are plain text so basic tools like more and tail and grep work on them as-is. Binary logfiles offer no great advantage over plaintext, and going through syslogd means not depending on two sets of tools and having to manage two configurations to get logging directed where it needs to go.
One last bit has me twitchy about systemd: history. SysV init scripts may be clunky and primitive, but they've been around a long time. People know how to manage them, and they've had the kinks worked out of them and best practices established. systemd doesn't have that. I do not want to make my servers (that have to run for anything to work right) dependent on something until I've had time to work with it and get familiar with it and, more importantly, it's been out there in use long enough for people to find and fix the problems, work out the oddities and figure out the best ways to use it without shooting yourself in the foot. I'd prefer to stick with SysV init on my production systems and only enable systemd on testbed systems at the start, and then enable systemd on a server-by-server basis so unexpected failures don't completely kill me (eg. if systemd blows up on my primary mailserver, the backup still on SysV can keep things under control until I either fix the problem or revert and restart the primary).