I thought the reason why someone goes and brutally murders another human being is because he is either an evil bastard to start with, or brainwashed by other evil bastards to be an evil bastard himself, and because he thinks he can be an evil bastard without getting caught and getting punished for it.
Im not clear how that would work. NFC is NFC. Apple pay / Google wallet should interoperate.
Since they are both for _making_ payments, I'd expect them not to interoperate at all. However, both should interoperate with the same devices that are made for _accepting_ payments. At least one would hope so.
You regularly use NFC for payments? You must be some kind of wizard.
In the UK, an awful lot of debit and credit cards are NFC enabled, and an awful lot of stores have NFC enabled terminals. For payment, you just hold your card against the terminal. Or just hold your wallet against the terminal; the only problem with that is when you have more than one NFC card, you can't control which one will be used (but it's guaranteed that only one payment will be taken).
Actually, I can use NFC payment in my company's canteen to pay for my lunch or breakfast, that's how common it is.
The limitation is that this only goes up to £20, because anyone stealing your wallet can use your card that way until the card is cancelled.
The difference with Apple Pay is that they can't use a stolen phone, there will likely be no limit because the payment is authenticated with your finger print, and nobody ever sees your debit or credit card number which avoids fraud.
Some people have pointed you in the direction of Chromebooks, which to my knowledge doesn't have a POP3 client available because Google assumes you'll have web access. There may be other reasons why it won't work.
These people's setup seems to be so outdated. I wouldn't have the slightest clue how to connect an iPad to a dial up network, and I wouldn't be surprised if you can't do that with a Chromebook either.
The interesting thing is that for Apple Pay, NFC itself doesn't need to be secure. With Apple Pay, the phone sends data over NFC that cannot be forged, that cannot be modified in a useful way, and that cannot be decoded or reused if it is recorded. The worst that an attacker could do is to interfere with the transmission somehow and stop it from working. Or count how often a terminal was used to take payments.
I suspect that for many applications you would want your communications to be secure, and that is probably not available (yet).
It seems someone is speculating that Apple doesn't want other NFC based payment options on the iPhone and therefore closes down NFC.
That's nonsense. There is no f***ing way in hell that the banks would allow NFC based payments from iPhones through anyone other than Apple, because Apple is the only one with access to the bank-designed secure enclave in the iPhone. That means Apple is the only one who can guarantee to the banks that any payment request is genuinely coming from the user and not created by some hacked, jailbroken iPhone or some malicious or buggy app on the iPhone.
The only way to get alternative payment methods is for other phone manufacturers to build similar hardware into their phones, get an agreement with the banks, and create similar apps.
No; they are FAILED engineers; nothing they create works properly; that's why they are trying to force the world to their will through violence, not intellect.
I remember an actual medical doctor trying to explode stuff I think at Glasgow Airport. They said he was so incompetent, he would have caused more damage if he had kept working in his profession.
If you have a deadline, and you can't finish the project within the deadline, you have a problem. If you tell your manager that you can't finish the project within the deadline, your manager has a problem.
Since managers don't like problems, bad managers try their very hardest to make you not tell them that you are going to miss the deadline. For example, by overriding your estimates. Without realising that overriding someone's estimates doesn't finish the code any faster.
Not saying it would be simple. https means: Data is encrypted with a key K and decrypted with the key K', and somehow both sides agree about the key. First, Apple could store your email encrypted with a key A so it can be decrypted with key A'. If they combine A' and K, it could be possible to send the https message to you without ever producing the decrypted message at Apple. Now if Apple didn't store the key A', but some means to combine A' with a (yet unknown) key K, then they couldn't decrypt your message.
Yes, a National Security Letter may do so. We have no way of knowing, so have to assume the worst.
You are wrong. There is no way to legally force Tim Cook to lie. There are ways to legally force him to be quiet about a subject, and not to give us information, but there is nothing that can force him to lie.
Your suggestion is a protocol change, so that cannot be implemented without a change in the email client. But if we make such a change, then email senders could also implement the same change:
The sender could ask Apple for your public key. If Apple has your public key, it gives the public key to the sender, the sender encrypts the message with your public key, sends it to Apple who cannot read it, which sends it to you. Oh well, that's called S/Mime:-(
Hi everyone, maybe someone more clever than me can figure this out: Could it be possible for Apple (or any other company) to store emails in an encrypted form so they can be delivered to me, but cannot be read by the company?
Let's say my email address is gnasher@icloud.com and my password is "Password" You are sending me an unencrypted email (no S/MIME) and it is received by Apple's email server. No matter how encrypted Apple stores the data, when I request my email, Apple has to send me the unencrypted email.
Now let's say Apple creates a public/private key pair for my email address and hashes the private key with my password; that happens the very first time that I ever read any email from their server. From then on, every email intended for me gets encrypted with the public key. Now if someone tries to read my email (for example I myself), they need to send the email address and the password to Apple's email server. Apple uses the password to try to unhash the private key, decrypts the email, and sends it to me.
If Apple never stores my password, they can't read my emails. Of course whenever they decided at time X they want to read my mails, they could read any emails received after time X, or as soon as I tried to download emails again with my password.
Questions;
1. Would that work, technically?
2. Would that work, legally? If Apple got a subpoena, they wouldn't be able at that point to give anyone my emails. Could they be forced to deliver all emails they receive on my behalf after receiving the subpoena, or all emails that I download after receiving the subpoena, or all stored emails once I requested delivery of emails?
It is this. EMAIL IS NOT SECURE. No matter who starts it or finishes it.
Well, exactly. If you send me an unencrypted email, and it is stored on Apple's servers somehow, and my computer asks Apple's email server for the mail, then Apple has to send the unencrypted email to my computer. In other words, Apple _must_ be able to produce the unencrypted email.
(Hmmh. I wonder if this is right. I wonder if there would be a way with https to store an encrypted mail, which would be decrypted when my computer decrypts the https? But then the NSA could just request my email through https and they could read it? )
I still wouldn't trust any company not to hand over my information to the government. Lavabit was one hell of an exception, and one geeks the world over should be proud of.
But then Lavabit made the big mistake of being _capable_ of decrypting your data. Once they were _capable_ of decrypting it, that was it, and they started a fight with the government that they couldn't win.
With Apple's iMessage system, they _can't_ read your data. And since they _can't_ read your data, Tim Cook can refuse to give them your data (actually, he can't give them your data anyway because he just can't) without fear of having to go to jail for this refusal. So no heroics needed for Apple. Much better solution than Lavabit.
All Uber needs is one good lawsuit, say, a driver running over a boy scout with a little old lady in the crosswalk, to make all the profits disappear. The business model haven't been tested in court yet. So liability may not be limited to the drivers.
The boy scout can end up an awful lot more expensive. The major cost of a bad accident ends when the person dies. A boy scout who needs severe medical help every day for the next 70 years, that's expensive. Not an old lady who is gone in five years.
Wait, what? There's a ton wrong with Uber, but this does not seem to be on the list. In my experience, Uber X charges approximately 50% or less what a conventional cab would charge (and about 75% what a flat-rate cab would charge).
Well, you fell to their propaganda. Uber tries, apparently successfully in your case, to be at the same time a taxi company, while not being a taxi company but a company that matches partners for car sharing.
Uber drivers get less money than normal taxi drivers, that's why you pay less. Uber, on the other hand, charges more for its service: In London, about 20% of the fare, while normal services that the taxi drivers use charge about 10%. So yes, Uber charges more for the same service. The service isn't driving you around, the service is matching cars and passengers, and they charge more for it.
The documentary about Kosmo.com, e-Dreams [imdb.com], is both fascinating and painful to watch. These guys went through a breathtakingly huge pile of money in a very short time, trying to do exactly this sort of personalized delivery. It gives you a real feel for how truly insane VC funding was in the late '90s. Maybe Kalanick should check this film out before putting too much effort into this idea.
I think you've got that wrong. They didn't go through a huge pile of investors' money while trying unsuccessfully to create a personalised delivery service. They went highly successfully through a huge pile of money while pretending to create a delivery service.
This is totally wrong. Apple could not be more clear that Swift is built to supplant Objective-C.
Right now a problem with Objective-C is that it exists on top of C. For an experienced C or C++ programmer that's no problem. But for someone who is learning Objective-C as their first and only language, there are some very strange things going on. They are all quite logical if you know C or C++, but not at all if you don't.
That's one thing that Swift gets rid of. There is nothing that is weird for historical reasons. (There are things that look weird to the C programmer though). Another thing that's gone is automatic type conversions, which are trouble for inexperienced programmers (what happens if you compare signed int and unsigned int), and pointers. So I'd say it's very much aimed at the programmer who starts from scratch.
Not at the beginner; you'll have to learn and understand it to use it properly. But at someone who starts from scratch and learns it thoroughly, and there are no silly surprises. (Like why is 010 not a ten? )
No one is demanding anything, but some of us believe that distributing your software as free and open source software is better for everyone including the original developer. There's nothing wrong in suggesting it.
You can add some reasons why you think that open sourcing Swift would be good for Apple. When you do that, it would be good to look at it from Apple's point of view. Try to find arguments that would convince Tim Cook.
Type-casting -oh my lord type casting- is so astoundingly bad in Swift it really beggars belief that in the 21st century anyone could design something that bad!
If Apple doesn't want the help of the OSS community then forget 'em.
There is this part of the open source community that is quite willing to help - but requests that for their help, you are effectively losing control over your own work. That's why Apple dropped gcc. I think they can live without you.
Under the deal between Apple and the band where Bono is one of the members, U2 "gives away" the album on iTune and for that, Apple awards them with a cool Two Hundred Million United States Greenbacks
You have taken the cost of a whole advertising campaign, doubled it, and attributed it to one little part of that campaign.
Slashdot Mirror
I thought the reason why someone goes and brutally murders another human being is because he is either an evil bastard to start with, or brainwashed by other evil bastards to be an evil bastard himself, and because he thinks he can be an evil bastard without getting caught and getting punished for it.
Im not clear how that would work. NFC is NFC. Apple pay / Google wallet should interoperate.
Since they are both for _making_ payments, I'd expect them not to interoperate at all. However, both should interoperate with the same devices that are made for _accepting_ payments. At least one would hope so.
What asshole would trust Apple as a wallet?
It seems you're one that wouldn't.
You regularly use NFC for payments? You must be some kind of wizard.
In the UK, an awful lot of debit and credit cards are NFC enabled, and an awful lot of stores have NFC enabled terminals. For payment, you just hold your card against the terminal. Or just hold your wallet against the terminal; the only problem with that is when you have more than one NFC card, you can't control which one will be used (but it's guaranteed that only one payment will be taken).
Actually, I can use NFC payment in my company's canteen to pay for my lunch or breakfast, that's how common it is.
The limitation is that this only goes up to £20, because anyone stealing your wallet can use your card that way until the card is cancelled.
The difference with Apple Pay is that they can't use a stolen phone, there will likely be no limit because the payment is authenticated with your finger print, and nobody ever sees your debit or credit card number which avoids fraud.
Some people have pointed you in the direction of Chromebooks, which to my knowledge doesn't have a POP3 client available because Google assumes you'll have web access. There may be other reasons why it won't work.
These people's setup seems to be so outdated. I wouldn't have the slightest clue how to connect an iPad to a dial up network, and I wouldn't be surprised if you can't do that with a Chromebook either.
The interesting thing is that for Apple Pay, NFC itself doesn't need to be secure. With Apple Pay, the phone sends data over NFC that cannot be forged, that cannot be modified in a useful way, and that cannot be decoded or reused if it is recorded. The worst that an attacker could do is to interfere with the transmission somehow and stop it from working. Or count how often a terminal was used to take payments.
I suspect that for many applications you would want your communications to be secure, and that is probably not available (yet).
It seems someone is speculating that Apple doesn't want other NFC based payment options on the iPhone and therefore closes down NFC.
That's nonsense. There is no f***ing way in hell that the banks would allow NFC based payments from iPhones through anyone other than Apple, because Apple is the only one with access to the bank-designed secure enclave in the iPhone. That means Apple is the only one who can guarantee to the banks that any payment request is genuinely coming from the user and not created by some hacked, jailbroken iPhone or some malicious or buggy app on the iPhone.
The only way to get alternative payment methods is for other phone manufacturers to build similar hardware into their phones, get an agreement with the banks, and create similar apps.
No; they are FAILED engineers; nothing they create works properly; that's why they are trying to force the world to their will through violence, not intellect.
I remember an actual medical doctor trying to explode stuff I think at Glasgow Airport. They said he was so incompetent, he would have caused more damage if he had kept working in his profession.
So why are so many terrorists engineers?
Citation?
Isis is violating a good amount of Islamic teachings with this ban.
Considering that they are not Muslims but f***ing bastards, that doesn't come unexpected. I mean they are so bad that Al'Quaeda calls them barbaric.
If you have a deadline, and you can't finish the project within the deadline, you have a problem. If you tell your manager that you can't finish the project within the deadline, your manager has a problem.
Since managers don't like problems, bad managers try their very hardest to make you not tell them that you are going to miss the deadline. For example, by overriding your estimates. Without realising that overriding someone's estimates doesn't finish the code any faster.
Not saying it would be simple. https means: Data is encrypted with a key K and decrypted with the key K', and somehow both sides agree about the key. First, Apple could store your email encrypted with a key A so it can be decrypted with key A'. If they combine A' and K, it could be possible to send the https message to you without ever producing the decrypted message at Apple. Now if Apple didn't store the key A', but some means to combine A' with a (yet unknown) key K, then they couldn't decrypt your message.
Yes, a National Security Letter may do so. We have no way of knowing, so have to assume the worst.
You are wrong. There is no way to legally force Tim Cook to lie. There are ways to legally force him to be quiet about a subject, and not to give us information, but there is nothing that can force him to lie.
Your suggestion is a protocol change, so that cannot be implemented without a change in the email client. But if we make such a change, then email senders could also implement the same change:
:-(
The sender could ask Apple for your public key. If Apple has your public key, it gives the public key to the sender, the sender encrypts the message with your public key, sends it to Apple who cannot read it, which sends it to you. Oh well, that's called S/Mime
Hi everyone, maybe someone more clever than me can figure this out: Could it be possible for Apple (or any other company) to store emails in an encrypted form so they can be delivered to me, but cannot be read by the company?
Let's say my email address is gnasher@icloud.com and my password is "Password" You are sending me an unencrypted email (no S/MIME) and it is received by Apple's email server. No matter how encrypted Apple stores the data, when I request my email, Apple has to send me the unencrypted email.
Now let's say Apple creates a public/private key pair for my email address and hashes the private key with my password; that happens the very first time that I ever read any email from their server. From then on, every email intended for me gets encrypted with the public key. Now if someone tries to read my email (for example I myself), they need to send the email address and the password to Apple's email server. Apple uses the password to try to unhash the private key, decrypts the email, and sends it to me.
If Apple never stores my password, they can't read my emails. Of course whenever they decided at time X they want to read my mails, they could read any emails received after time X, or as soon as I tried to download emails again with my password.
Questions;
1. Would that work, technically?
2. Would that work, legally? If Apple got a subpoena, they wouldn't be able at that point to give anyone my emails. Could they be forced to deliver all emails they receive on my behalf after receiving the subpoena, or all emails that I download after receiving the subpoena, or all stored emails once I requested delivery of emails?
It is this. EMAIL IS NOT SECURE. No matter who starts it or finishes it.
Well, exactly. If you send me an unencrypted email, and it is stored on Apple's servers somehow, and my computer asks Apple's email server for the mail, then Apple has to send the unencrypted email to my computer. In other words, Apple _must_ be able to produce the unencrypted email.
(Hmmh. I wonder if this is right. I wonder if there would be a way with https to store an encrypted mail, which would be decrypted when my computer decrypts the https? But then the NSA could just request my email through https and they could read it? )
I still wouldn't trust any company not to hand over my information to the government. Lavabit was one hell of an exception, and one geeks the world over should be proud of.
But then Lavabit made the big mistake of being _capable_ of decrypting your data. Once they were _capable_ of decrypting it, that was it, and they started a fight with the government that they couldn't win.
With Apple's iMessage system, they _can't_ read your data. And since they _can't_ read your data, Tim Cook can refuse to give them your data (actually, he can't give them your data anyway because he just can't) without fear of having to go to jail for this refusal. So no heroics needed for Apple. Much better solution than Lavabit.
All Uber needs is one good lawsuit, say, a driver running over a boy scout with a little old lady in the crosswalk, to make all the profits disappear. The business model haven't been tested in court yet. So liability may not be limited to the drivers.
The boy scout can end up an awful lot more expensive. The major cost of a bad accident ends when the person dies. A boy scout who needs severe medical help every day for the next 70 years, that's expensive. Not an old lady who is gone in five years.
Wait, what? There's a ton wrong with Uber, but this does not seem to be on the list. In my experience, Uber X charges approximately 50% or less what a conventional cab would charge (and about 75% what a flat-rate cab would charge).
Well, you fell to their propaganda. Uber tries, apparently successfully in your case, to be at the same time a taxi company, while not being a taxi company but a company that matches partners for car sharing.
Uber drivers get less money than normal taxi drivers, that's why you pay less. Uber, on the other hand, charges more for its service: In London, about 20% of the fare, while normal services that the taxi drivers use charge about 10%. So yes, Uber charges more for the same service. The service isn't driving you around, the service is matching cars and passengers, and they charge more for it.
The documentary about Kosmo.com, e-Dreams [imdb.com], is both fascinating and painful to watch. These guys went through a breathtakingly huge pile of money in a very short time, trying to do exactly this sort of personalized delivery. It gives you a real feel for how truly insane VC funding was in the late '90s. Maybe Kalanick should check this film out before putting too much effort into this idea.
I think you've got that wrong. They didn't go through a huge pile of investors' money while trying unsuccessfully to create a personalised delivery service. They went highly successfully through a huge pile of money while pretending to create a delivery service.
This is totally wrong. Apple could not be more clear that Swift is built to supplant Objective-C.
Right now a problem with Objective-C is that it exists on top of C. For an experienced C or C++ programmer that's no problem. But for someone who is learning Objective-C as their first and only language, there are some very strange things going on. They are all quite logical if you know C or C++, but not at all if you don't.
That's one thing that Swift gets rid of. There is nothing that is weird for historical reasons. (There are things that look weird to the C programmer though). Another thing that's gone is automatic type conversions, which are trouble for inexperienced programmers (what happens if you compare signed int and unsigned int), and pointers. So I'd say it's very much aimed at the programmer who starts from scratch.
Not at the beginner; you'll have to learn and understand it to use it properly. But at someone who starts from scratch and learns it thoroughly, and there are no silly surprises. (Like why is 010 not a ten? )
No one is demanding anything, but some of us believe that distributing your software as free and open source software is better for everyone including the original developer. There's nothing wrong in suggesting it.
You can add some reasons why you think that open sourcing Swift would be good for Apple. When you do that, it would be good to look at it from Apple's point of view. Try to find arguments that would convince Tim Cook.
Type-casting -oh my lord type casting- is so astoundingly bad in Swift it really beggars belief that in the 21st century anyone could design something that bad!
Then I'd say you didn't understand it.
If Apple doesn't want the help of the OSS community then forget 'em.
There is this part of the open source community that is quite willing to help - but requests that for their help, you are effectively losing control over your own work. That's why Apple dropped gcc. I think they can live without you.
Under the deal between Apple and the band where Bono is one of the members, U2 "gives away" the album on iTune and for that, Apple awards them with a cool Two Hundred Million United States Greenbacks
You have taken the cost of a whole advertising campaign, doubled it, and attributed it to one little part of that campaign.