I don't necessarily agree with read the fine print (personally).
My counter proposal: see a legal (or financial adviser), and have professionals
read the fine print for you, if you are signing a contract, or taking conditional compensation
of any sort, not just stock.
My reason for this counter proposal, is the average person on the street may not be sufficiently
equipped to fully understand all implications of the fine print.
It's complicated enough that you may need a legal review of your contract by a lawyer to tell you
what the fine print actually means.
And you need a review to help determine/have explained to you the possible/probable tax consequences of signing the deal also, so you can make an informed decision.
For example, based on what kind of options you are receiving, based on the contract, do these count as qualified stock options, or are they going to be treated by the gov't as non-qualified -- do you have an immediate salary/employee tax liability when you receive the options, or do you have the employee tax and social security liabilities for the options when you exercise them?
Etc. All questions that have to be answered by your financial advisers working for you, and ultimately effect what income you have to report.
Yes, I am aware of those. Under a RFC eliminating TLDs longer than 3 characters, those would be allowed to continue to operate, for backwards compatibility, but DNS servers and DNS resolvers would not be required to resolve them, they'd fall under a:
"A DNS resolver must not attempt to resolve a domain for a TLD containing more than 3 characters.
However, a DNS resolver MAY attempt to resolve domains in the.INFO,.COOP,.ASIA,.AERO,.JOBS,.MOBI,.NAME,.MUSEUM, and.TRAVEL TLDs, as a temporary exception for backwards compatibility with prior versions of the Domain Name System implementation.
Yes, if you treat them like cogs, you can inflate the balance sheets for a couple of quarters. Then it all goes to hell.
Eh? I have heard it reported many times that Google treats their technical staff like cogs, and developers are considered interchangeable parts by the management.
If everything's supposed to go to hell, then how can you explain Google's continued success?
Maybe not all managers that treat people as "cogs" do so in the same fashion?
Using what you describe, you have produced random unusable gibberish on the output.
Not really. If you generate some random data and transmit it over the quantum channel, both endpoints to the communication have the shared quantum secret, with an agreed upon hash, and agreed upon method of using the data and proper synchronization of the two data streams, they will both come up with the same thing, and the recipient will be able to inverse a simple XOR.
The whole point of quantum crypto is it can't be brute forced.
But using standard crypto over non-quantum channel of course can be brute forced, when it is standard
and quantum channel is used only for distributing the initial keys.
The quantum channel is basically wasted.... instead of using the quantum properties to secure the communication,
it's just a fancy key rollover system.
Maybe so... The string Kibi is really close to Kibo. Perhaps the folks on alt.religion.kibology could have some insight
into what the strategy of Kibo's kibibots would be:-)
Then there is a second dirty secret: Quantum signaling is only for key distribution. The actual communication is done with conventional block ciphers like AES. This completely invalidates the concept, even if you assume Quantum signaling to be eavesdropper-proof, because RSA/ElGamal is likely much more secure
That's insane... what they should do is use public key crypto secured transmission of private keys.
And encrypt the data payload in a CBC mode, with random shared quantum inputs used to manipulate the block chaining (e.g. by XORing each block against a random hash value generated using shared quantum channel after XORing with the previous ciphertext block).
They should knowledge of the symmetric private key alone is not sufficient to eavesdrop on the communication channel and
that compromise of the quantum channel alone is not sufficient to compromise the symmetric encrypted channel.
we have 90 days until we get to the "A sufficient number of bots bots to replace all interesting objects in the known (and unknown) parts of the universe with Kilobot swarms" stage?
Unless they are extremely versatile in their reproduction and operation, they run out of essential easily-obtainable resources on earth to harvest for rapid reproduction long before 90 days.
And have to start either mining resources themselves or utilizing enslaved species to do work to extract resources for Kilobot reproduction:)
1024 Terabots = 1 Petabot (A sufficient number of bots to enslave humanity)
1024 Petabots = 1 Exabot (A sufficient number of bots to enslave the the planets in our solar system)
1024 Exabots = 1 Zettabot (A sufficient number of bots to enslave our galaxy)
1024 Zettabots = 1 Yottabot (A sufficient number of bots to enslave 25% of the known universe)
1024 Yottabots = A sufficient number of bots bots to replace all interesting objects in the known (and unknown) parts of the universe with Kilobot swarms.
Domain names aren't trademarks, they're ways to address a node on a network.
Companies are all internet-enabled now, and they want anyone looking for their trademark via search engine or URL to find them.
Basically, "Domains aren't trademarks"; stopped working when beancounters everywhere decided they wanted them to be. And now they're on the verge of making the ultimadum "It's too unfriendly to have to have that.COM.NET or.ORG in there; take it off; just make us http://apple/ or what have you "
They are cows. We are raising them to eat them. We are not raising them as pets. Some people are slightly more rough on the food, but it is just food. What's next, Africa picking up on this and outlawing lions from playing with the gazelles? No, we are a dominate species and are going to eat these.
Until the animal is sacrificed to cut it up, the animal is not yet food.
Unfortunately (or fortunately, depending on your POV), the US has laws that restrict
what things we are allowed to use as food, and restrict how or when we can turn animals and plants into food or other supplements; and some animal cruelty laws have been lobbed in there.
Try nailing a Deer out of season or using an unauthorized bait or hunting weapon, for food, because your family is starving,
and see how much "mercy" your story about how you supposedly need "food" to survive or its inferior prey gets with the game warden.
As for lions playing with gazelles; they don't really mistreat their prey, they hunt it and kill it within fairly short order, once they are hungry, and they get a little exercise in chasing it for a few minutes.
More importantly, they don't have to obey human laws about how/when/where we can get food, and what we are allowed to use as food.
I'm not sure if the story's a step in the right direction or not.
This country sure needs to get rid of a lot of heavyhanded, silly laws, that unnecessarily restrict
freedom, based on some person's opinion or disgust at another person's supposedly cruel practices.
I mean.... what could be more cruel to a living thing than killing it(?)
Hex editors are hacking tools, because hackers can use them to edit machine language binaries to manually construct malicious code.
Compilers such as GCC and assemblers such as NASM are hacking tools, because they are used by hackers to facilitate construction of machine code.
Computer keyboards are hacking tools, because they facilitate the trivial entry of commands to computer systems.
Computer RS232 ports are hacking tools, because they facilitate arbitrary serial data connections.
Computer monitors are hacking tools, because they allow an attacker to see their debugger output/terminal window
showing them when the hack is successful.
Computer hard drives, CD-R drives, media, and thumb drives are hacking tools, because they allow an attacker to keep a persistent
copy of their malware for easy transportation to the victim's location.
Ethernet cards are hacking tools, because they are useful for hackers to facilitate the long range transmission of malware payloads.
SDRAM chips are hacking tools, because they temporarily hold malware payloads as they are being deployed.
CPUs are hacking tools, because they perform computations useful by hackers, and many hackers require CPUs to do their owrk.
Pens and paper are hacking tools, because hackers use them to draw diagrams and sketch out possible designs of attack which then translate into an effective hack.
Of course, my preference would be for the thief to keep using the phone, and hopefully Find My iPhone would enable me to actually recover the phone.
I have mixed thoughts about that. If more people reported their phone stolen immediately, to have the IMEI blocked by all the cell networks, it could be somewhat a deterrant against theft too. If you want to add a pascode remotely,
better remove sensitive data too.
The Find My iPhone function may indeed be used by some people in those situations.
There is also a problem, that if you don't have it deactivated immediately, and the thief racks up a few thousand in usage charges, e.g. international calls (your phone used by the thief to fraudulently re-sell toll calls) or overseas data roaming, you could be on the hook for some serious $$ in some cases.
The lost iPhone may be $600 to replace, but at least you can be confident there is such a strict limit to your losses, if you do brick/deactivate the phone's service before the perp can abuse the phone's access to your account.
It should be noted the passcode protection is only good against unsophisticated thieves.
There are ways to bypass the passcode and then remove it/view it, or gain access to all
data on an iPhone, without requiring any silliness of attempts, or trying to guess the passcode.
That is there are some people who can gain access to 100% of fully working iPhones, with physical access
and sufficient motive, common passcode or not.
For this reason.... I don't think there's anything irrational about the decision to use a weak/easy passcode.
Until Apple actually encrypts all data on the phone with the authenticator, that is,
and use biometrics, such as face recognition, rather than manual entry of digits.
is that if someone steals or finds a lost iPhone, he has a 15% chance of unlocking the device and accessing the data within before it gets wiped just by trying out the passwords on the aforementioned top 10 list."
I think that might be off -- If someone steals or finds a lost, working iPhone; he probably has a 80 - 90% chance of finding the device not secured with a passcode to begin with.
If he happened to get so unlucky as to find one of the 20% of iPhones with a passcode; he has a 15% chance of unlocking that locked device.
That brings it closer to a 100% chance of gaining access to it; if the found phone works at all -- only an 85% chance of it using an uncommon passcode.
Just because it's uncommon doesn't mean unguessable -- it depends on how much the thief knows or can find out about the person. If the thief gets the wallet too, they might try the birthdate on drivers license or do other research about numbers significant to the person (increasing chances of an unlock beyond 15% for fixed common) -- if we include things like phone numbers, anniversary year, 15% might be a real low ball for the amount of passcodes based on such guessable concepts.
If you create a new address at a domain you own, you're in the same identity-linking problem. Creating new accounts that need to be maintained every few months (gmail/yahoo/etc) are also a pain.
Another option is to use some e-mail hosting service that lets you pick a domain and create a number of aliases,
that just forward to your primary e-mail account.
E-mail remains a critical service that if compromised, you are in for a hurting, though.
If you opt to use a domain you own for an account on an 'embarrasing' site, you probably want to list the WHOIS contact using a pseudonym, and a forwarding address such as a private PO Box, MailboxesEtc or other mail forwarding service address.
Probably better to use the free/webmail accounts for that purpose though; and use e-mail under your domain for the addresses you actually share with friends.
So the whole possibility of domain registrars' private records being compromised can't introduce a permanent weakness
We already have the "don't re-use passwords" security best practices, but it seems e-mail addresses themselves are just as dangerous,
as they can be linked to identities, which could have social implications way beyond simple security compromise.
Always register accounts on porn sites (or other embarrasing websites) using a different e-mail address,
an e-mail address not known to friends, employers, coworkers, churchgoers, neighborhood busybodies, etc;
one that cannot easily be linked to your identity, social network accounts.
Security will also be improved, if you use separate e-mail accounts for private business.
For example: use one e-mail address for Facebook, use a separate e-mail address for your
bank account.
The hacker may attempt to login with the same e-mail address and password at many sites;
but if the e-mail address is different, they won't even have an account ID to attempt to attack
(even if the password did happen to be similar)
This wouldn't be such an issue if every website didn't demand to know your e-mail address
and store it in their database; but the reality, is your e-mail address has become kind of like your internet
driver's license or SSN, that every website demands before they can establish an account for you.
Thankfully, unlike a driver's license or SSN, you can have as many of them as you want, due to
the event of..... free webmail-based email services such as Gmail, Hotmail, Yahoo Mail:)
I stopped watching and reading the news once it was legal for them to lie. Until they fix that... I can never believe anything they say.
It hasn't been a crime for news reporters to lie, distort, or exaggerate, since the inception of the 1st amendment.
Some exaggeration is standard fare. Why should that stop you from watching and reading them?
Whether they tell the truth or not is a matter of honor. If they intentionally lie/deceive, then the reporter(s) credibility would be shot, as soon as the lie inevitably comes to light.
The problem with having a 'Google kids' search engine; is currently there is minimal webmaster assistance.
Not very many major websites use PICS labelling as safe for kids; PICS labelling/RSAC is more complicated than
"kid friendly / not kid friendly" and requires self-labelling involving several questions "violence rating, nudity rating, sex rating, and language rating". Again: if more sites published self-ratings, matters would be a lot easier.
Also, a site may be perfectly safe, but what about all its links?
What about the contents of linked pages unexpectedly changing, domain expired, unsavory content being introduced through user-generated postings/comments/replies, or what have you?
Policing the content of sites and their links is no easy job, and Google could be creating a huge risk to its reputation on creating a "Google kids" system; Google already has 'Safe Search' and 'Lock Safe Search on' options, which filter search results, and possible errors in that filtering are risky enough as it is...
I think a community effort is required.
Since the Internet is worthy of having a.XXX TLD.
Perhaps there should be a.KIDS TLD?
Sites that are kid-safe or have a combination of kid-safe and not kid-safe content, could then list under the.KIDS TLD.
Sites that are intended for adults would have no presence under.KIDS.
Specifically, perhaps there should be a TLD for websites and domains geared towards children.
The agreement regarding conditions of registering a domain on the TLD could include
some prescriptive rules about what content may be published on.KIDS domains
(rather than asking Webmasters to create special metadata tags) for example in the.KIDS TLD:
No 'parking pages' or domains registered solely to display third party ad banners or advertising with no original content, results of specific searches, or to attempt to sell domain(s)
No advertisement of any movie, video game, or other item that does not meet the.KIDS TLD content standards.
No inclusion of embedded content from domains in other TLDs that do not meet the.KIDS content standards.
No pornography/sexually explicit content
No advertising of any sex, gambling, smoking, alcohol, or drug related product
No gross violence.
No pages promoting, glorifying, or providing instructions/HOWTO information in regards to criminal behavior, drug use, defiance of teachers/parents, cheating on tests, dishonesty, or other unruly behavior
Required adherence to average community standards, for acceptable content, for children age 10.
No popup advertisements
The idea then, is safe sites geared towards kids would be on the.KIDS TLD,
and the parent could configure their browser to restrict access to sites not on a.KIDS domain.
Then search engines could easily offer a '.KIDS' TLD search option
I don't necessarily agree with read the fine print (personally).
My counter proposal: see a legal (or financial adviser), and have professionals read the fine print for you, if you are signing a contract, or taking conditional compensation of any sort, not just stock.
My reason for this counter proposal, is the average person on the street may not be sufficiently equipped to fully understand all implications of the fine print.
It's complicated enough that you may need a legal review of your contract by a lawyer to tell you what the fine print actually means.
And you need a review to help determine/have explained to you the possible/probable tax consequences of signing the deal also, so you can make an informed decision. For example, based on what kind of options you are receiving, based on the contract, do these count as qualified stock options, or are they going to be treated by the gov't as non-qualified -- do you have an immediate salary/employee tax liability when you receive the options, or do you have the employee tax and social security liabilities for the options when you exercise them?
Etc. All questions that have to be answered by your financial advisers working for you, and ultimately effect what income you have to report.
Yes, I am aware of those. Under a RFC eliminating TLDs longer than 3 characters, those would be allowed to continue to operate, for backwards compatibility, but DNS servers and DNS resolvers would not be required to resolve them, they'd fall under a: "A DNS resolver must not attempt to resolve a domain for a TLD containing more than 3 characters. However, a DNS resolver MAY attempt to resolve domains in the .INFO, .COOP, .ASIA, .AERO, .JOBS, .MOBI, .NAME, .MUSEUM, and .TRAVEL TLDs, as a temporary exception for backwards compatibility with prior versions of the Domain Name System implementation.
Yes, if you treat them like cogs, you can inflate the balance sheets for a couple of quarters. Then it all goes to hell.
Eh? I have heard it reported many times that Google treats their technical staff like cogs, and developers are considered interchangeable parts by the management. If everything's supposed to go to hell, then how can you explain Google's continued success?
Maybe not all managers that treat people as "cogs" do so in the same fashion?
Sounds like a lawsuit against the company for breach of contract....
"Firing" execs to avoid upholding the terms, in regards to required compensation for executives in event of a buyout?
This is not going to make things easier for that VC firm to do business going forward, after such a dirty show of dishonesty
Using what you describe, you have produced random unusable gibberish on the output.
Not really. If you generate some random data and transmit it over the quantum channel, both endpoints to the communication have the shared quantum secret, with an agreed upon hash, and agreed upon method of using the data and proper synchronization of the two data streams, they will both come up with the same thing, and the recipient will be able to inverse a simple XOR.
The whole point of quantum crypto is it can't be brute forced. But using standard crypto over non-quantum channel of course can be brute forced, when it is standard and quantum channel is used only for distributing the initial keys.
The quantum channel is basically wasted.... instead of using the quantum properties to secure the communication, it's just a fancy key rollover system.
Yep, but 24 out of 1000 is less than 2.5%, and 24^8 out of 1000^8 is less than 0.00000000001%, so you keep the box anyways :)
Maybe so... The string Kibi is really close to Kibo. Perhaps the folks on alt.religion.kibology could have some insight into what the strategy of Kibo's kibibots would be :-)
Then there is a second dirty secret: Quantum signaling is only for key distribution. The actual communication is done with conventional block ciphers like AES. This completely invalidates the concept, even if you assume Quantum signaling to be eavesdropper-proof, because RSA/ElGamal is likely much more secure
That's insane... what they should do is use public key crypto secured transmission of private keys.
And encrypt the data payload in a CBC mode, with random shared quantum inputs used to manipulate the block chaining (e.g. by XORing each block against a random hash value generated using shared quantum channel after XORing with the previous ciphertext block).
They should knowledge of the symmetric private key alone is not sufficient to eavesdrop on the communication channel and that compromise of the quantum channel alone is not sufficient to compromise the symmetric encrypted channel.
we have 90 days until we get to the "A sufficient number of bots bots to replace all interesting objects in the known (and unknown) parts of the universe with Kilobot swarms" stage?
Unless they are extremely versatile in their reproduction and operation, they run out of essential easily-obtainable resources on earth to harvest for rapid reproduction long before 90 days.
And have to start either mining resources themselves or utilizing enslaved species to do work to extract resources for Kilobot reproduction :)
1024 kilobots = 1 Megabot
1024 Megabots = 1 Gigabot (aka 1 Decepticon)
1024 Gigabots = 1 Terabot
1024 Terabots = 1 Petabot (A sufficient number of bots to enslave humanity)
1024 Petabots = 1 Exabot (A sufficient number of bots to enslave the the planets in our solar system)
1024 Exabots = 1 Zettabot (A sufficient number of bots to enslave our galaxy)
1024 Zettabots = 1 Yottabot (A sufficient number of bots to enslave 25% of the known universe)
1024 Yottabots = A sufficient number of bots bots to replace all interesting objects in the known (and unknown) parts of the universe with Kilobot swarms.
change the charter so the charges are very nominal, it would go a long way to prevent this sort of behavior
Excellent. How do we get ICANN's charter changed? :-/
I want to suggest a new RFC to the IETF and a revision to all standards: Top-level Domain names may not exceed 3 characters in length.
Get that on the standards track, get that into standard status. Stop this ICANN foolishnes.
Domain names aren't trademarks, they're ways to address a node on a network.
Companies are all internet-enabled now, and they want anyone looking for their trademark via search engine or URL to find them.
Basically, "Domains aren't trademarks"; stopped working when beancounters everywhere decided they wanted them to be. And now they're on the verge of making the ultimadum "It's too unfriendly to have to have that .COM .NET or .ORG in there; take it off; just make us http://apple/ or what have you "
That's like saying "Those who don't know how a locking mechanism works shouldn't use their car keys."
No. "Those who don't understand how a lock is operated shouldn't use a car that requires keys"
"How public key crypto works" is a basic cryptography topic; at the same level as knowing that you turn a key to open a lock.
They are cows. We are raising them to eat them. We are not raising them as pets. Some people are slightly more rough on the food, but it is just food. What's next, Africa picking up on this and outlawing lions from playing with the gazelles? No, we are a dominate species and are going to eat these.
Until the animal is sacrificed to cut it up, the animal is not yet food.
Unfortunately (or fortunately, depending on your POV), the US has laws that restrict what things we are allowed to use as food, and restrict how or when we can turn animals and plants into food or other supplements; and some animal cruelty laws have been lobbed in there.
Try nailing a Deer out of season or using an unauthorized bait or hunting weapon, for food, because your family is starving, and see how much "mercy" your story about how you supposedly need "food" to survive or its inferior prey gets with the game warden.
As for lions playing with gazelles; they don't really mistreat their prey, they hunt it and kill it within fairly short order, once they are hungry, and they get a little exercise in chasing it for a few minutes. More importantly, they don't have to obey human laws about how/when/where we can get food, and what we are allowed to use as food.
I'm not sure if the story's a step in the right direction or not. This country sure needs to get rid of a lot of heavyhanded, silly laws, that unnecessarily restrict freedom, based on some person's opinion or disgust at another person's supposedly cruel practices.
I mean.... what could be more cruel to a living thing than killing it(?)
Hex editors are hacking tools, because hackers can use them to edit machine language binaries to manually construct malicious code.
Compilers such as GCC and assemblers such as NASM are hacking tools, because they are used by hackers to facilitate construction of machine code.
Computer keyboards are hacking tools, because they facilitate the trivial entry of commands to computer systems.
Computer RS232 ports are hacking tools, because they facilitate arbitrary serial data connections.
Computer monitors are hacking tools, because they allow an attacker to see their debugger output/terminal window showing them when the hack is successful.
Computer hard drives, CD-R drives, media, and thumb drives are hacking tools, because they allow an attacker to keep a persistent copy of their malware for easy transportation to the victim's location.
Ethernet cards are hacking tools, because they are useful for hackers to facilitate the long range transmission of malware payloads.
SDRAM chips are hacking tools, because they temporarily hold malware payloads as they are being deployed.
CPUs are hacking tools, because they perform computations useful by hackers, and many hackers require CPUs to do their owrk.
Pens and paper are hacking tools, because hackers use them to draw diagrams and sketch out possible designs of attack which then translate into an effective hack.
Through collusion, they operate as an oligopoly, and they do have specific monopolies over specific
They cannot legally collude to fix prices, violation of the Antitrust act, and the feds would be all over them.
Of course, my preference would be for the thief to keep using the phone, and hopefully Find My iPhone would enable me to actually recover the phone.
I have mixed thoughts about that. If more people reported their phone stolen immediately, to have the IMEI blocked by all the cell networks, it could be somewhat a deterrant against theft too. If you want to add a pascode remotely, better remove sensitive data too.
The Find My iPhone function may indeed be used by some people in those situations.
There is also a problem, that if you don't have it deactivated immediately, and the thief racks up a few thousand in usage charges, e.g. international calls (your phone used by the thief to fraudulently re-sell toll calls) or overseas data roaming, you could be on the hook for some serious $$ in some cases.
The lost iPhone may be $600 to replace, but at least you can be confident there is such a strict limit to your losses, if you do brick/deactivate the phone's service before the perp can abuse the phone's access to your account.
It should be noted the passcode protection is only good against unsophisticated thieves. There are ways to bypass the passcode and then remove it/view it, or gain access to all data on an iPhone, without requiring any silliness of attempts, or trying to guess the passcode.
That is there are some people who can gain access to 100% of fully working iPhones, with physical access and sufficient motive, common passcode or not.
For this reason.... I don't think there's anything irrational about the decision to use a weak/easy passcode.
Until Apple actually encrypts all data on the phone with the authenticator, that is, and use biometrics, such as face recognition, rather than manual entry of digits.
is that if someone steals or finds a lost iPhone, he has a 15% chance of unlocking the device and accessing the data within before it gets wiped just by trying out the passwords on the aforementioned top 10 list."
I think that might be off -- If someone steals or finds a lost, working iPhone; he probably has a 80 - 90% chance of finding the device not secured with a passcode to begin with.
If he happened to get so unlucky as to find one of the 20% of iPhones with a passcode; he has a 15% chance of unlocking that locked device.
That brings it closer to a 100% chance of gaining access to it; if the found phone works at all -- only an 85% chance of it using an uncommon passcode. Just because it's uncommon doesn't mean unguessable -- it depends on how much the thief knows or can find out about the person. If the thief gets the wallet too, they might try the birthdate on drivers license or do other research about numbers significant to the person (increasing chances of an unlock beyond 15% for fixed common) -- if we include things like phone numbers, anniversary year, 15% might be a real low ball for the amount of passcodes based on such guessable concepts.
Un-friending someone is rather painful.
Though it does have the advantage, that you have an easy reference, in case you ever meet any of your friends IRL.
If you create a new address at a domain you own, you're in the same identity-linking problem. Creating new accounts that need to be maintained every few months (gmail/yahoo/etc) are also a pain.
Another option is to use some e-mail hosting service that lets you pick a domain and create a number of aliases, that just forward to your primary e-mail account. E-mail remains a critical service that if compromised, you are in for a hurting, though.
If you opt to use a domain you own for an account on an 'embarrasing' site, you probably want to list the WHOIS contact using a pseudonym, and a forwarding address such as a private PO Box, MailboxesEtc or other mail forwarding service address.
Probably better to use the free/webmail accounts for that purpose though; and use e-mail under your domain for the addresses you actually share with friends.
So the whole possibility of domain registrars' private records being compromised can't introduce a permanent weakness
Why not just cut to the chase? /^i.*/i
I'm surprised Apple has not sued over interstate numbering, e.g. I-57... clearly mark dilution. (J/K) :)
We already have the "don't re-use passwords" security best practices, but it seems e-mail addresses themselves are just as dangerous, as they can be linked to identities, which could have social implications way beyond simple security compromise.
Always register accounts on porn sites (or other embarrasing websites) using a different e-mail address, an e-mail address not known to friends, employers, coworkers, churchgoers, neighborhood busybodies, etc; one that cannot easily be linked to your identity, social network accounts.
Security will also be improved, if you use separate e-mail accounts for private business. For example: use one e-mail address for Facebook, use a separate e-mail address for your bank account.
The hacker may attempt to login with the same e-mail address and password at many sites; but if the e-mail address is different, they won't even have an account ID to attempt to attack (even if the password did happen to be similar)
This wouldn't be such an issue if every website didn't demand to know your e-mail address and store it in their database; but the reality, is your e-mail address has become kind of like your internet driver's license or SSN, that every website demands before they can establish an account for you.
Thankfully, unlike a driver's license or SSN, you can have as many of them as you want, due to the event of..... free webmail-based email services such as Gmail, Hotmail, Yahoo Mail :)
I stopped watching and reading the news once it was legal for them to lie. Until they fix that... I can never believe anything they say.
It hasn't been a crime for news reporters to lie, distort, or exaggerate, since the inception of the 1st amendment.
Some exaggeration is standard fare. Why should that stop you from watching and reading them?
Whether they tell the truth or not is a matter of honor. If they intentionally lie/deceive, then the reporter(s) credibility would be shot, as soon as the lie inevitably comes to light.
The problem with having a 'Google kids' search engine; is currently there is minimal webmaster assistance. Not very many major websites use PICS labelling as safe for kids; PICS labelling/RSAC is more complicated than "kid friendly / not kid friendly" and requires self-labelling involving several questions "violence rating, nudity rating, sex rating, and language rating". Again: if more sites published self-ratings, matters would be a lot easier.
Also, a site may be perfectly safe, but what about all its links? What about the contents of linked pages unexpectedly changing, domain expired, unsavory content being introduced through user-generated postings/comments/replies, or what have you?
Policing the content of sites and their links is no easy job, and Google could be creating a huge risk to its reputation on creating a "Google kids" system; Google already has 'Safe Search' and 'Lock Safe Search on' options, which filter search results, and possible errors in that filtering are risky enough as it is...
I think a community effort is required. Since the Internet is worthy of having a .XXX TLD.
Perhaps there should be a .KIDS TLD?
Sites that are kid-safe or have a combination of kid-safe and not kid-safe content, could then list under the .KIDS TLD.
.KIDS.
Sites that are intended for adults would have no presence under
Specifically, perhaps there should be a TLD for websites and domains geared towards children. The agreement regarding conditions of registering a domain on the TLD could include some prescriptive rules about what content may be published on .KIDS domains
(rather than asking Webmasters to create special metadata tags) for example in the .KIDS TLD:
The idea then, is safe sites geared towards kids would be on the .KIDS TLD,
and the parent could configure their browser to restrict access to sites not on a .KIDS domain.
Then search engines could easily offer a '.KIDS' TLD search option