English being my second language, I went to my dictionary with the hopes of learning something from your comment. Unfortunately, my dictionary only lists two entries for birth the verb:
1. intr. To have birth, be born. rare. 2. trans. To give birth to; to give rise to. Chiefly dial. and U.S. dial.
Do you mean give rise to?
Also, I don't find using words metaphorically to be "simple" English 101, or your 101 classes are rather advanced.
Charliemopp's claim that there is no live music and local bands are not permitted on the radio wasn't representative either--as evidenced by the existence of Seattle. The truth is somewhere in the middle: some places have great music scenes, some places have non-existent music scenes. I believe, as I stated in my last paragraph I think population has a lot to do with it.
And local bars don't have live music anymore because local bands aren't allowed on the radio.
I don't know where you live, but in Seattle there are three *pages* of live shows for *today* [1] and five *pages* of live shows for *this weekend* [2]. Granted that is both for bars and larger venues, but the vast majority are small local bars.
As to local bands not allowed on the radio?! There are plenty of radio stations that cater to music lovers and absolutely do play local bands. One of several Seattle (again, I live here; I don't think Seattle is unique) is KEXP. They even have an article on how to get airplay on KEXP [3]. While it's a local station, I know many of their listeners are from beyond the city limits so getting airplay on such a local station can have wider-ranging effects for an up-and-coming band.
I guess what "local" bars offer depends on locale but generally higher-population areas sustain more arts. That's always been the case, though. Artists and patrons congregate.
Already the industry is realizing what it needs to do.
Yep. In the wake of Snowden, people need to feel better. Performing encryption on a computer that you can't trust, is the best of both worlds and gives everyone what they need.
Users will be put at ease, manufacturers can check the "encryption" bullet point, and thanks to the computer working for someone other than the user, various other parties who "need" the data will be able to quietly get the keys without an unpleasant confrontation with the user. Everybody wins.
Trust is not a binary. If it were, I would say I don't trust anything that I don't fully control (like the compiler trust issue), become extremely paranoid and have no sane life. I choose to have some trust in some things and live a normal life.
If you read page nine of the iOS Security Guide, you'll learn that device storage is always encrypted with a unique key, regardless of the device lock settings.
So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you?
There are ways to store a key on the device and not need to read it automatically on boot. Page nine of the iOS Security Guide from September 2014 describes how Apple solves the problem.
And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.
I thought this was about ON THE HANDSET encryption?
Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...
Why not generate the key on the device and store it in a secure piece of hardware? That's been a pretty standard solution for a while now. I kind of imagined Android would also do the same.
and when user's complain their battery lasts much shorter as the CPU is busy encrypting and decrypting constantly, then they'll switch the default back... and when user's complain that they flip flop too much, they'll make it a giant setup screen option where new user's can complain about which option is on top.
iOS has encrypted most of its data most of the time already and iOS has not had significantly worse battery life than Android in the past. What's the crux here is not the addition of encryption, it's the location of the encryption key.
First, no one said anything about being angry. Second, no one said anything about "Hollywood" always getting history wrong in favor of the Americans. Third, gnasher719 and I are two different people.
What gnasher719 said about American movies rewriting history is true. My point was propagandists have used fiction to sway the masses and it appears to have worked: gnasher719 was responding to a common misconception that Americans broke German codes in WWII. A misconception perpetuated by Hollywood.
I have no gripe with Hollywood, but I do support people like gnasher719 who go out of their way to correct misconceptions others have because a Hollywood movie twisted history. You pointing out that it was not a documentary doesn't make the misconception any worse nor gnasher719's attempt to correct that misconception useless.
No one is saying fiction can't bend the truth, if that's what you thought.
Documentary or not, his point that American movies have re-written history was true. Would you feel the same way about a Russian fictional movie that portrayed the moon landing as being a Soviet accomplishment?
The ultimate monopoly is the Federal Government...
Only if it is the only government in the world. Plenty of people move to live under a different government due to being unhappy with their current one.
Yes, but it's between your MUA and your server. S/MIME, as far as I know, does not do server-to-sender public key exchange. If I send a signed message to you, then you have my public key and can encrypt messages to me, yes, but you can't get my public key from the server.
Frankly, S/MIME is really the best solution available today. It works with gmail (not web-mail but using a MUA). Most MUAs support it. It's easy to get a free personal S/MIME keypair from a CA. Google, Apple or whoever you use for mail never sees your private key and can't read your messages.
The subject of the photograph does not have zero thickness. The camera focal point could be along the plane of the front of the subject, which would make it *not* along the plane of the rear of the phone.
Imagine I am standing long the plane of the front of a building, am I also standing along the plan of the rear of a building? Am I looking at the building at a flat 90 (whatever that means)?
You generate a key pair, give Apple the public key. You manage your own private key.
Then, for each email:
Apple receives the email as plain text from another server (likely via SSL), encrypts it with your public key and stores it on their servers. When you connect to retrieve your mail they send you the encrypted blob that you decrypt via your private key.
Problems are this: first, Apple has a plain text copy of each email you receive and could be asked (nicely or forcefully) to record this somewhere before proceeding with encryption and storage. Second, replies are not encrypted.
Much better for users to manage their own keys and use S/MIME. That's what I do with my friends and Google (my email provider) never sees unencrypted messages from me to any of my friends and vice versa.
Tim Cook says they "don't" read your email and "can't" read your iMessages. So presumably, they CAN read emails but choose not to do so.
Which makes sense as most email clients out in the wild don't encrypt messages, so even if Apple were to encrypt messages stored on the server, they'd be doing it with *their* key, not the users (unless the user used S/MIME or PGP or GPG or what have you). If they want to interoperate with other email providers, they need access to the emails as that's how email works.
iMessage and FaceTime are technologies Apple designed and implemented, and they chose to do it in a different way than e-mail. E-mail uses a plain text protocol and is stored in plain text. While the transport can be encrypted, if one were to encrypt the data on the server it was stored on, one would use a symmetric key, and one would have access to that key. iMessage and FaceTime can be implemented using asymmetric keys and one would not need access to those keys. It makes sense if you as a company want to minimize how much data you hand over to a government: you let devices generate keys that your servers never see.
Slashdot Mirror
Even worse, he's talking about *four* devices (which I don't even think you can find four devices that sum up to under $650).
I looked around, and could not find two tablets and two phones that were $500 and "decent". Do you have some links?
English being my second language, I went to my dictionary with the hopes of learning something from your comment. Unfortunately, my dictionary only lists two entries for birth the verb:
1. intr. To have birth, be born. rare.
2. trans. To give birth to; to give rise to. Chiefly dial. and U.S. dial.
Do you mean give rise to?
Also, I don't find using words metaphorically to be "simple" English 101, or your 101 classes are rather advanced.
If "Android" sells 10M phones per day, that's 3.6 billion phone a year. Do you have some sort of actual data to back up that claim?
Way to confuse a birth with a purchase.
You're right, Seattle is not representative.
Charliemopp's claim that there is no live music and local bands are not permitted on the radio wasn't representative either--as evidenced by the existence of Seattle. The truth is somewhere in the middle: some places have great music scenes, some places have non-existent music scenes. I believe, as I stated in my last paragraph I think population has a lot to do with it.
RFID cards have proven to be easy to compromise.
I've not seen an RFID card. Do you have a link? Or did you mean EMV?
And local bars don't have live music anymore because local bands aren't allowed on the radio.
I don't know where you live, but in Seattle there are three *pages* of live shows for *today* [1] and five *pages* of live shows for *this weekend* [2]. Granted that is both for bars and larger venues, but the vast majority are small local bars.
As to local bands not allowed on the radio?! There are plenty of radio stations that cater to music lovers and absolutely do play local bands. One of several Seattle (again, I live here; I don't think Seattle is unique) is KEXP. They even have an article on how to get airplay on KEXP [3]. While it's a local station, I know many of their listeners are from beyond the city limits so getting airplay on such a local station can have wider-ranging effects for an up-and-coming band.
I guess what "local" bars offer depends on locale but generally higher-population areas sustain more arts. That's always been the case, though. Artists and patrons congregate.
[1] http://www.thestranger.com/gyr...
[2] http://www.thestranger.com/gyr...
[3] http://blog.kexp.org/2011/08/0...
Just because you sample something 192,000 times a second does not mean that you are reproducing a sound with a frequency of 1/192,000th of a second.
Yep. In the wake of Snowden, people need to feel better. Performing encryption on a computer that you can't trust, is the best of both worlds and gives everyone what they need.
Users will be put at ease, manufacturers can check the "encryption" bullet point, and thanks to the computer working for someone other than the user, various other parties who "need" the data will be able to quietly get the keys without an unpleasant confrontation with the user. Everybody wins.
Trust is not a binary. If it were, I would say I don't trust anything that I don't fully control (like the compiler trust issue), become extremely paranoid and have no sane life. I choose to have some trust in some things and live a normal life.
If you read page nine of the iOS Security Guide, you'll learn that device storage is always encrypted with a unique key, regardless of the device lock settings.
So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you?
There are ways to store a key on the device and not need to read it automatically on boot. Page nine of the iOS Security Guide from September 2014 describes how Apple solves the problem.
And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.
I thought this was about ON THE HANDSET encryption?
Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...
Why not generate the key on the device and store it in a secure piece of hardware? That's been a pretty standard solution for a while now. I kind of imagined Android would also do the same.
and when user's complain their battery lasts much shorter as the CPU is busy encrypting and decrypting constantly, then they'll switch the default back... and when user's complain that they flip flop too much, they'll make it a giant setup screen option where new user's can complain about which option is on top.
iOS has encrypted most of its data most of the time already and iOS has not had significantly worse battery life than Android in the past. What's the crux here is not the addition of encryption, it's the location of the encryption key.
Already the industry is realizing what it needs to do.
First, no one said anything about being angry. Second, no one said anything about "Hollywood" always getting history wrong in favor of the Americans. Third, gnasher719 and I are two different people.
What gnasher719 said about American movies rewriting history is true. My point was propagandists have used fiction to sway the masses and it appears to have worked: gnasher719 was responding to a common misconception that Americans broke German codes in WWII. A misconception perpetuated by Hollywood.
I have no gripe with Hollywood, but I do support people like gnasher719 who go out of their way to correct misconceptions others have because a Hollywood movie twisted history. You pointing out that it was not a documentary doesn't make the misconception any worse nor gnasher719's attempt to correct that misconception useless.
No one is saying fiction can't bend the truth, if that's what you thought.
Documentary or not, his point that American movies have re-written history was true. Would you feel the same way about a Russian fictional movie that portrayed the moon landing as being a Soviet accomplishment?
too late.
You're right! We should do nothing now! Why would we want to change something we don't like. Oh, that's right, it's too late.
What a defeatist attitude.
The ultimate monopoly is the Federal Government...
Only if it is the only government in the world. Plenty of people move to live under a different government due to being unhappy with their current one.
Yes, but it's between your MUA and your server. S/MIME, as far as I know, does not do server-to-sender public key exchange. If I send a signed message to you, then you have my public key and can encrypt messages to me, yes, but you can't get my public key from the server.
Frankly, S/MIME is really the best solution available today. It works with gmail (not web-mail but using a MUA). Most MUAs support it. It's easy to get a free personal S/MIME keypair from a CA. Google, Apple or whoever you use for mail never sees your private key and can't read your messages.
The subject of the photograph does not have zero thickness. The camera focal point could be along the plane of the front of the subject, which would make it *not* along the plane of the rear of the phone.
Imagine I am standing long the plane of the front of a building, am I also standing along the plan of the rear of a building? Am I looking at the building at a flat 90 (whatever that means)?
Even better would be a system such as:
You generate a key pair, give Apple the public key. You manage your own private key.
Then, for each email:
Apple receives the email as plain text from another server (likely via SSL), encrypts it with your public key and stores it on their servers. When you connect to retrieve your mail they send you the encrypted blob that you decrypt via your private key.
Problems are this: first, Apple has a plain text copy of each email you receive and could be asked (nicely or forcefully) to record this somewhere before proceeding with encryption and storage. Second, replies are not encrypted.
Much better for users to manage their own keys and use S/MIME. That's what I do with my friends and Google (my email provider) never sees unencrypted messages from me to any of my friends and vice versa.
Tim Cook says they "don't" read your email and "can't" read your iMessages. So presumably, they CAN read emails but choose not to do so.
Which makes sense as most email clients out in the wild don't encrypt messages, so even if Apple were to encrypt messages stored on the server, they'd be doing it with *their* key, not the users (unless the user used S/MIME or PGP or GPG or what have you). If they want to interoperate with other email providers, they need access to the emails as that's how email works.
iMessage and FaceTime are technologies Apple designed and implemented, and they chose to do it in a different way than e-mail. E-mail uses a plain text protocol and is stored in plain text. While the transport can be encrypted, if one were to encrypt the data on the server it was stored on, one would use a symmetric key, and one would have access to that key. iMessage and FaceTime can be implemented using asymmetric keys and one would not need access to those keys. It makes sense if you as a company want to minimize how much data you hand over to a government: you let devices generate keys that your servers never see.
fine fine, we will sell you a dumb pipe. 640Kb is enough for every one right? WHAT you want more.... ok fine but 4Mb is where we draw the line
It would all depend on the unit of time. If I got 4Mb per pico second I'd be one happy fish.