Deletion will always be possible. Even if you don't have a nuke at hand, there's always a sysadmin (or two, playing together) who can do it. If the value of "losing" audit logs is high enough, the solution will be found...
Most of the line printers have escape sequences to set many things. It's nice to use that to set the line feed distance to 0 points:-) [Can you buy a LP today that is dumb enough not to have such features?:-)]
Also, in most of the cases, you *can* change the logs (video tapes, etc.). Sure, it will be detected. So what? Applying crypto (hashes, HSM signed log entries, etc.) can show you that something was changed, but you'll never know what was the original data. For example: "What IP address did that hacker use, where did he come from? "Well, we don't know, but we do know that it's not what's in the log, as that is corrupt." Cool.
And yes, I'm being theoretical here. On the positive side, although you cannot say "once a log is written it can never be deleted or changed", you can mitigate the risk that this happens to you, down to a point where you (or SOX) find that acceptable.
What about someone nefarious at the company that you are paying? What measures are in place to prevent someone there from sniffing traffic? What's to prevent them releasing information about particular (or all) users either by negligence or malace?
You can always design a system that logs everything necessary to reconstruct events thus provides potential traceability. You can design one that has the only information (maybe even logged) absolutely needed for providing such a service. And you can have anything in between. What we don't know is where this service is in this aspect.
As you say, all this does is concentrate your incoming/outgoing connection through a Swedish ISP. Combined with the dubious anonominity of a credit card transaction this will only make this service a sizable target.
Call me bold, but I do think you can make it "secure" even if you have credit card payment (which is not worse (better?) in terms of traceability than any other method).
Suppose that when subscribing, you select a username/password on your own. To provide the service, they only have to know if a certain user has payed for the service - they don't have to (should not, in this case) store which transaction was that. When you connect, they check this, and associate your regular IP with another one. Since they have to keep bits moving, as long as you are connected, this association can be discovered. But if they don't log this and you disconnect, you're untraceable.
I'm sure life is not this easy, but my point is that it should be possible to set up a (centralized, for-profit) service that by design provides a level of anonimity. I hope this one is like that.
Until one asshole starts uploading/downloading child porn and then the game is up for everyone using that service including all all those credit card transaction histories.
Sadly, such jerks do and will exist. I'm afraid that only total surveillance could detect that (and - sadly again - not prevent it).
That means, you are introducing a single point of "failure": if things turn really bad (by some definition) the authorities only have to go to one place to collect all personal data. What we don't know currently is that how much personal data it is, i.e. could you or your IP (the real one) be traced back later. They'd certainly need to provide more information on this before people do start to sign up massively (I mean, those who care about this).
Highly interesting, though.
Don't you tell me that you don't know (or don't like) Túró Rudi???? Man, you don't know what you missed! That's THE product of the country:-)
[For the uninitiated, Túró Rudi is a rod of cottage cheese (well, kind of), covered with chocolate. _Every_ Hungarian kid - and pretty much everyone else - loves it.]
As far back as the 90s they were charging outrageous repeating fees -- and not really doing anything for the money, as the cases of CAs issued to fraudulent companies proved.
Well, they *are* doing something: they are getting around that annoying warning window:-)
To enlighten you a bit: think about session keys. They are produced temporarily to protect communication, and are disposed of at the end. If the gov't says "give me your key you used to communicate with X" you simply can't. That's the way it is supposed to work. As long as you don't keep the encrypted data, you're fine.
Of course this does not apply if some bad guys are stupid enough to keep the encrypted e-mails or whatever. If they use online comms (ie. secured communication instead of secured data) they're fine.
I wonder how long it will take for them to patent the idea of using a PHRASE as a password. Or, the idea of having longer than 10 character passwords. Sounds fun.
Btw this may be off topic, but one advantage Opera has against Firefox is that it can remember the opened tabs so I don't have to open them individually when restarting the browser. Is there a plugin or something for FF for this functionality?
That's right! Why do we need colleges and unis anyway? IT can be learned "on the job"!
But, wait a sec, why have high schools or primary schools either? You can learn the most important words (Google, slashdot, P2P, Dilbert, stc.) from the screen. as for writing, how many of us have used handwriting for real nowadays? That is also bullshit, since it is so much different form the TimesNewRoman! Unreadable!
Calculus is also unnecessary, Excel can do it way faster. Or BC, or expr.
Man, I wish I could spend all my study years in front of my PC... I'd be so much experienced and smart!
I have a Compaq Evo n1020v with 256MB RAM. It had the same problem (blue screen), and when the service company confirmed this, they instantly replaced the RAM. It is not listed as a defective model though, which could mean that I was unlucky or that other series are affected too.
Asuming there's no free energy we can state that: 1) either the energy is coming from the magnets, so the whole motor is actually usging them up and they have to be replaced regulary 2) or there's some unknown source of energy used (up). Long live Tesla!:-)
If there IS free energy, then... well, we have someone who has found it and still lives:-)
Is there something more to a CRL that i'm missing?
Not much; you are probably aware of OCSP, but the basic idea is the same there.
As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.
I wouldn't call this timestamping, then (as per "using some reliable third party to prove the time of something"). This way it provides no additional security at all.
Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.
Using the CA model you should. If the signature was created before the revocation (proven by a timestamp), then you could accept it. If there's no timestamp, then you shouldn't, but the decision is really up to you.
I would be willing to pay a good CA for actual verification, even as a client, if i could be sure that they were actually verifying the folks they issued certificates to. But it would need to be big enough to be able to certify a large number of sites to be worthwhile...
IMHO the problem is that there is no distinction between the "good" and "bad" CAs (e.g. in the EU: conforms to the EU directive or not). This will be really interesting when you want to use some legal background behind eelctronic signatures.
The non-hierarchical nature of the web of trust model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
It suffers from one serious drawback though: it has no revocation information. If your key pair is stolen, you are pretty much doomed. There is no infomation on whether your key is still yours, and if not, from what point of time?
Average end users don't care about HOW things are done, they just want a reliable infrastructure. Th problem is that there's no such thing if you don't care about the details...
From this point you can think of many other ideas that actually have a point. For example, you can make Braille printing on a regular laser printer: you just have to reprint the page 5 times on the same paper. Any visually impaired person could "read" this, if you printed Braille characters.
IBM sells a crypto module for quite a while now which can take all the crypto processing off the main CPU. Things like key generation, hashes, encryption/decryption etc. Think of an OpenSSL implementation, which simply forwards these requests to a hw module, and this way provides hw based SSL and such to applications...
You only have to code triggers once and they get executed every time when needed. If you do it "by hand", you have to insert this code in every place where the DB would execute the trigger. What if you forget one such place? What if the trigger logic changes? It's much easier to maintain the trigger, than all the code.
Slashdot Mirror
If you don't have anything to hide, you have nothing to fear...
Deletion will always be possible. Even if you don't have a nuke at hand, there's always a sysadmin (or two, playing together) who can do it. If the value of "losing" audit logs is high enough, the solution will be found...
:-) [Can you buy a LP today that is dumb enough not to have such features? :-)]
Most of the line printers have escape sequences to set many things. It's nice to use that to set the line feed distance to 0 points
Also, in most of the cases, you *can* change the logs (video tapes, etc.). Sure, it will be detected. So what? Applying crypto (hashes, HSM signed log entries, etc.) can show you that something was changed, but you'll never know what was the original data. For example: "What IP address did that hacker use, where did he come from? "Well, we don't know, but we do know that it's not what's in the log, as that is corrupt." Cool.
And yes, I'm being theoretical here. On the positive side, although you cannot say "once a log is written it can never be deleted or changed", you can mitigate the risk that this happens to you, down to a point where you (or SOX) find that acceptable.
Sure they are. You only have to ignore the fact that there is a whole lot of stuff outside the US. Which happens here sometimes.
You can always design a system that logs everything necessary to reconstruct events thus provides potential traceability. You can design one that has the only information (maybe even logged) absolutely needed for providing such a service. And you can have anything in between. What we don't know is where this service is in this aspect.
Call me bold, but I do think you can make it "secure" even if you have credit card payment (which is not worse (better?) in terms of traceability than any other method).
Suppose that when subscribing, you select a username/password on your own. To provide the service, they only have to know if a certain user has payed for the service - they don't have to (should not, in this case) store which transaction was that. When you connect, they check this, and associate your regular IP with another one. Since they have to keep bits moving, as long as you are connected, this association can be discovered. But if they don't log this and you disconnect, you're untraceable.
I'm sure life is not this easy, but my point is that it should be possible to set up a (centralized, for-profit) service that by design provides a level of anonimity. I hope this one is like that.
Sadly, such jerks do and will exist. I'm afraid that only total surveillance could detect that (and - sadly again - not prevent it).
That means, you are introducing a single point of "failure": if things turn really bad (by some definition) the authorities only have to go to one place to collect all personal data. What we don't know currently is that how much personal data it is, i.e. could you or your IP (the real one) be traced back later. They'd certainly need to provide more information on this before people do start to sign up massively (I mean, those who care about this). Highly interesting, though.
Don't you tell me that you don't know (or don't like) Túró Rudi???? Man, you don't know what you missed! That's THE product of the country :-)
[For the uninitiated, Túró Rudi is a rod of cottage cheese (well, kind of), covered with chocolate. _Every_ Hungarian kid - and pretty much everyone else - loves it.]
Well, about 400 years ago, Turkey was too close to Hungary... in fact, they overlapped :-O
Well, they *are* doing something: they are getting around that annoying warning window :-)
I don't exatly see why another company has to get around a bug in Sun's code, instead of them correcting it...
I hope it runs faster and faster if you embed more and more layers of virtual machines! I'll never have to buy a newer processor again!
To enlighten you a bit: think about session keys. They are produced temporarily to protect communication, and are disposed of at the end. If the gov't says "give me your key you used to communicate with X" you simply can't. That's the way it is supposed to work. As long as you don't keep the encrypted data, you're fine.
Of course this does not apply if some bad guys are stupid enough to keep the encrypted e-mails or whatever. If they use online comms (ie. secured communication instead of secured data) they're fine.
In Netherlands, you can get a pre-paid with no ID at all.
That's so typical... I'd like to inform you that there's a world outside the US. Where the majority of the people live.
I wonder how long it will take for them to patent the idea of using a PHRASE as a password. Or, the idea of having longer than 10 character passwords. Sounds fun.
Btw this may be off topic, but one advantage Opera has against Firefox is that it can remember the opened tabs so I don't have to open them individually when restarting the browser. Is there a plugin or something for FF for this functionality?
That's right! Why do we need colleges and unis anyway? IT can be learned "on the job"!
But, wait a sec, why have high schools or primary schools either? You can learn the most important words (Google, slashdot, P2P, Dilbert, stc.) from the screen. as for writing, how many of us have used handwriting for real nowadays? That is also bullshit, since it is so much different form the TimesNewRoman! Unreadable!
Calculus is also unnecessary, Excel can do it way faster. Or BC, or expr.
Man, I wish I could spend all my study years in front of my PC... I'd be so much experienced and smart!
I have a Compaq Evo n1020v with 256MB RAM. It had the same problem (blue screen), and when the service company confirmed this, they instantly replaced the RAM. It is not listed as a defective model though, which could mean that I was unlucky or that other series are affected too.
I wonder how a legitim user is going to install the new patches from the update, when his Internet connection is shut down by the ISP. Think about it.
Or maybe, the ISP will know which users have pirated copies and who is legitim? That sounds interesting...
Asuming there's no free energy we can state that: :-)
:-)
1) either the energy is coming from the magnets, so the whole motor is actually usging them up and they have to be replaced regulary
2) or there's some unknown source of energy used (up). Long live Tesla!
If there IS free energy, then... well, we have someone who has found it and still lives
Well, hopefully there's also a Makefile target that excludes backdoor.cpp from the build list...
Not much; you are probably aware of OCSP, but the basic idea is the same there.
As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.
I wouldn't call this timestamping, then (as per "using some reliable third party to prove the time of something"). This way it provides no additional security at all.
Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.
Using the CA model you should. If the signature was created before the revocation (proven by a timestamp), then you could accept it. If there's no timestamp, then you shouldn't, but the decision is really up to you.
Forgive me if I'm offtopic.
IMHO the problem is that there is no distinction between the "good" and "bad" CAs (e.g. in the EU: conforms to the EU directive or not). This will be really interesting when you want to use some legal background behind eelctronic signatures.
The non-hierarchical nature of the web of trust model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
It suffers from one serious drawback though: it has no revocation information. If your key pair is stolen, you are pretty much doomed. There is no infomation on whether your key is still yours, and if not, from what point of time?
Average end users don't care about HOW things are done, they just want a reliable infrastructure. Th problem is that there's no such thing if you don't care about the details...
From this point you can think of many other ideas that actually have a point. For example, you can make Braille printing on a regular laser printer: you just have to reprint the page 5 times on the same paper. Any visually impaired person could "read" this, if you printed Braille characters.
Methinks this is actually a good idea.
IBM sells a crypto module for quite a while now which can take all the crypto processing off the main CPU. Things like key generation, hashes, encryption/decryption etc. Think of an OpenSSL implementation, which simply forwards these requests to a hw module, and this way provides hw based SSL and such to applications...
You only have to code triggers once and they get executed every time when needed. If you do it "by hand", you have to insert this code in every place where the DB would execute the trigger. What if you forget one such place? What if the trigger logic changes? It's much easier to maintain the trigger, than all the code.