Comment Re:Bockpit video (Score 1) 447
Just because it doesn't help in every case doesn't mean there's no point.
Just because it doesn't help in every case doesn't mean there's no point.
Similar deal in NZ, but it may take a few hours, and it costs nothing. It's a pretty standard way of paying someone if you can't be bothered messing about with cash. Ours doesn't use email though, just bank account numbers (and increasingly phone numbers, but I haven't explored how that works.)
8 months? I've had a smartwatch talking to my phone for nearly 2 years now.
Ta. I was actually curious
[citation needed]
Maybe it's just that what you think "premium" means isn't what everyone else thinks it means? Though, I'm still rocking a Nexus 4 with a glass back, no expandable storage, and no removable battery. It's a pretty nice phone and I don't care about those things.
Why is your cell phone sending AM signals?
No, that's not true. Trite, but still false. Additionally, in your case, it's neither automatic, nor trustworthy.
Thing is, there is a mechanism to make doing it this way trustworthy. By opting out of that mechanism, you put the burden onto everyone else for no reason. The result is that you remove your key from the set able to be considered trustworthy without effort.
You can retain a copy of my public key on your compter. Then you can trust any signed message from me to be from the same source as the previous signed message from me.
No, I can't. That's the point. Not without jumping through manual hoops.
"get it to me somehow, and I would have no choice but to accept it"? You allow random strangers to update your hard disk? I don't.
It's not an uncommon configuration to have email clients automatically fetch the keys for signed messages in order to check them. This is generally a sensible configuration, too. However you not using the normal ways of validating trust means that the normal ways don't work in your single case. So trust of your emails can't be verified. Essentially, participating in the web of trust and uploading to keyservers resolves this issue. But because you don't, there is no possible trust path.
There is an argument for trust continuance (i.e. if I trust your key once, why not do it in the future), but your methods make that very annoying to implement, requiring manual checking.
It feels like you either have a misunderstanding of how the WoT is supposed to work that leads you to false conclusions on how best to use it, or you're attempting to subvert it for some reason, however only succeeding in making it too annoying for other people to be bothered working with it.
Wrong. You can retain a copy of my public key on your compter. Then you can trust any signed message from me to be from the same source as the previous signed message from me.
Someone could make a key with the same details, get it to me somehow, and I would have no choice but to accept it, or:
These are all things that don't normally have to be done. By eschewing the trust mechanisms, you're reducing the amount of trust I would have that messages to/from you couldn't be compromised.
I've only ever bothered for Slackware, for which I believe the ISO images are signed with the official Slackware key.
If you use Ubuntu or Debian, then you are using it every time you do an apt-get update to verify the resulting software lists (which includes the hashes of the software itself.)
It is not on any "KeyServer"
Not true:
$ gpg --search "73D9A8A4"
gpg: zoeken naar '73D9A8A4' van de hkps server hkps.pool.sks-keyservers.net
(1) Andy Canfield
2048 bit RSA key 73D9A8A4, aangemaakt: 2014-08-03
However, it's not associated with your email address, so no mail client can understand it to use it.
Later, you say:
and the public key you get from my web site should confirm the signature.
But I can't trust your site, because it's not HTTPS (which isn't perfect, but is better.) You can get free SSL certs. And I can't trust your key because it's not in the web of trust.
Basically, you have a PGP key, but it's useless for many cases because you haven't done some simple steps to make it useable. I could never trust any signed message to actually be for you, and I can't trust the information I have to encrypt something to you.
Also, yes keyservers can be subverted by the NSA etc. They can also be subverted by me. They're insecure by design, and so that makes them safer.
Once again slashdotters
... direct their ire at the wrong party.
Kinda like how you are doing to "slashdotters", when it was in fact just one person?
Heh, I used it for a project about 6 or 7 years ago. As far as I know, it's still around.
Flashblock in firefox has the option to block HTML5 video, too. And you've just reminded me to turn it on.
If all else fails, lower your standards.