If the contents are encrypted then Google can't have the password (or else it is useless), so there is no way for them to provide you with your password. The best they can do is wipe your drive and give you a clean slate.
Reliable in that they reliably take the websites money, and in return give them the ability to advertise 'background checks'. Their responsibility is to the website, not you.
I recall a story a while ago on this same topic, except that a particular online dating site which did some form of background check was the primary backer -- they wanted all print and online personals sites to be required to display a warning if no background check was performed.
Services like this are fine for some purposes. Sending a link to a Google map from Outlook to mutt wraps to five lines and is a pain to copy / paste -- users invariably copy just the first part of it or don't properly remove the newlines and get a garbage result. However, this is just for temporary things such as the location of the LAN this weekend or what-have-you -- it shouldn't be used as the permanent reference to a site. Websites should use always full length link as they are built to handle that, although it would be better if the site inherently used reasonably long URLs to begin with.
If you need to unambiguously datestamp it, utilize a unbiased third party notary-like service such as http://www.itconsult.co.uk/stamper/stampinf.htm to sign the detached signature of the material and publish that signature. By signing it yourself, you are showing that you possessed the material. Employing the third party to sign your detached signature of the material provides a reliable timestamp of when you possessed the material. A challenge could be met by providing the material along with the relevant signatures. Logically it makes perfect sense, but legally it might be harder to explain it to a judge/jury, or bring the owner of the site to come and attest to his methods.
Employing a real world Notary to witness you signing a copy of the material would probably be easier to get admitted in a legal process (IANAL), but that is outside your 'digital world' stipulation.
(The reliability of that third party signature is reinforced since the date/time is evident not only in the signature, but also the time at which it was posted to usenet, which is archived by various parties.)
I know of at least one ISP that checks SPF records. SPF costs very little to implement in most cases and does not break email for someone who is not using it. Based on that there is really no reason *not* to implement it. It won't completely solve the problem, but it does enable someone who is SPF-aware to filter those emails.
The person who sold you the box was obligated to supply it, in this case as part of the box.
Would not the act of stripping out the source code / the offer to get the source code from the 'black box' be a modification of it, that itself would require you to accept the GPL and be obligated to supply it upon request?
Who created the copy they end user now possesses? That entity would seem to be on the hook for providing the source, even though they already provided the source with the device. It is not a one-time obligation.
All your argument has done is point out that the end user would have to get the software from the person who performed the copying -- you can't strip them of that just because you handled the device as a middleman.
I wonder then what happens if you refuse to disclose where the device came from.
The mere existence of a DomainKeys header does not mean the message is genuine -- you have to check the signature for validity. If you are getting spam that purports to be from a domain that it obviously isn't yet has a valid DomainKeys header, then that is a much bigger deal. I suspect in your case someone copied a header from a valid message. The header should process as invalid.
Jack & Jane could run Oracle 10g Express Edition for free on their windows or Linux server, assuming they could shoehorn themselves into 4GB of data and a limited number of concurrent connections, and live without some of the advanced features.
If they then went to a franchise model, J&J could upgrade to the non-free versions without having a lot of pain changing database backends.
The SSL protocol presents the server certificate before the client submits any dir or virtual host information, so SSL sites have to have a seperate IP per name.
There is most certainly versioning for Wikipedia articles. You can also create linkes to particular versions for citation purposes. There isn't a release date per se, but you can view the article at any point in time.
How many of these 'pure-play' applications make rash assumptions about Apache configurations, system configuration, and directory structures? One reason virtulization came about was because so many applications cannot be trusted to play well with others on the same host.
Its not so much one VM going bad, but that your application is totally self-contained on that VM, so you can move it (live, as with VMware ESX) to another hardware device with no worries about changing DNS, IPs, odd dependendencies in/usr/lib, etc.
Not to mention that this leaves the potentially lowest paid staff with the most access to the systems and probably no personal stake in those systems functionality.
Person B might modify the code during the check and add a backdoor. Person C may or may not build exactly the same code provided by Person B. Person D might deploy it in a way that leaves it open to subversion. Person E may keep a copy of the keys in their pocket.
Realistically, it looks like the only particularly untrusted person here is A, the rest have straightforward outs on how to subvert the control. Protecting any system against its own administative users is really difficult.
Do you trust your DBAs who run the control database, as they could change the settings at will? How about the SAs on the systems the DBAs use, who at a minimum could impersonate the DBAs? How about the network admins who run the network directing the traffic for the control, who could direct traffic to a machine of their choosing or interrupt traffic? The DNS admins who might be able to do the same? The Ceritificate Authority people who could issue a valid cert to anyone?
Its hard to justify paying a subscription for a game that pretty much requires keeping another game or book handy to fill in the gaps between interaction.
It does help. Most password crackers work by obtaining the password hash somehow and then attempting to figure out an input to the hash that results in the obtained output. Changing the password changes the stored hash and invalidates the work done by the cracker.
I think you are thinking of attempts to brute-force a password by trying to log in repeatedly. In that case it is true that changing the password only helps if the new password is before the current position of the password cracker. However, most authentication systems have protections against brute-forcing, such as locking accounts with excessive failed attempts or enforcing a timeout after every attempt.
Modems have the capability to retrain, which lets them renegotiate the line speed mid-connection in response to line conditions. It doesn't drop carrier, but it does cause a few second pause in traffic.
Slashdot Mirror
If the contents are encrypted then Google can't have the password (or else it is useless), so there is no way for them to provide you with your password. The best they can do is wipe your drive and give you a clean slate.
Reliable in that they reliably take the websites money, and in return give them the ability to advertise 'background checks'. Their responsibility is to the website, not you.
I recall a story a while ago on this same topic, except that a particular online dating site which did some form of background check was the primary backer -- they wanted all print and online personals sites to be required to display a warning if no background check was performed.
Services like this are fine for some purposes. Sending a link to a Google map from Outlook to mutt wraps to five lines and is a pain to copy / paste -- users invariably copy just the first part of it or don't properly remove the newlines and get a garbage result. However, this is just for temporary things such as the location of the LAN this weekend or what-have-you -- it shouldn't be used as the permanent reference to a site. Websites should use always full length link as they are built to handle that, although it would be better if the site inherently used reasonably long URLs to begin with.
If you need to unambiguously datestamp it, utilize a unbiased third party notary-like service such as http://www.itconsult.co.uk/stamper/stampinf.htm to sign the detached signature of the material and publish that signature. By signing it yourself, you are showing that you possessed the material. Employing the third party to sign your detached signature of the material provides a reliable timestamp of when you possessed the material. A challenge could be met by providing the material along with the relevant signatures. Logically it makes perfect sense, but legally it might be harder to explain it to a judge/jury, or bring the owner of the site to come and attest to his methods.
Employing a real world Notary to witness you signing a copy of the material would probably be easier to get admitted in a legal process (IANAL), but that is outside your 'digital world' stipulation.
(The reliability of that third party signature is reinforced since the date/time is evident not only in the signature, but also the time at which it was posted to usenet, which is archived by various parties.)
Government has no money of its own, it all comes from taxpayers in one form or another.
I know of at least one ISP that checks SPF records. SPF costs very little to implement in most cases and does not break email for someone who is not using it. Based on that there is really no reason *not* to implement it. It won't completely solve the problem, but it does enable someone who is SPF-aware to filter those emails.
The person who sold you the box was obligated to supply it, in this case as part of the box.
Would not the act of stripping out the source code / the offer to get the source code from the 'black box' be a modification of it, that itself would require you to accept the GPL and be obligated to supply it upon request?
Who created the copy they end user now possesses? That entity would seem to be on the hook for providing the source, even though they already provided the source with the device. It is not a one-time obligation.
All your argument has done is point out that the end user would have to get the software from the person who performed the copying -- you can't strip them of that just because you handled the device as a middleman.
I wonder then what happens if you refuse to disclose where the device came from.
The mere existence of a DomainKeys header does not mean the message is genuine -- you have to check the signature for validity. If you are getting spam that purports to be from a domain that it obviously isn't yet has a valid DomainKeys header, then that is a much bigger deal. I suspect in your case someone copied a header from a valid message. The header should process as invalid.
Jack & Jane could run Oracle 10g Express Edition for free on their windows or Linux server, assuming they could shoehorn themselves into 4GB of data and a limited number of concurrent connections, and live without some of the advanced features. If they then went to a franchise model, J&J could upgrade to the non-free versions without having a lot of pain changing database backends.
The SSL protocol presents the server certificate before the client submits any dir or virtual host information, so SSL sites have to have a seperate IP per name.
There is most certainly versioning for Wikipedia articles. You can also create linkes to particular versions for citation purposes. There isn't a release date per se, but you can view the article at any point in time.
How many of these 'pure-play' applications make rash assumptions about Apache configurations, system configuration, and directory structures? One reason virtulization came about was because so many applications cannot be trusted to play well with others on the same host.
Its not so much one VM going bad, but that your application is totally self-contained on that VM, so you can move it (live, as with VMware ESX) to another hardware device with no worries about changing DNS, IPs, odd dependendencies in /usr/lib, etc.
Probably so that he didn't get accused of directly teaching a classful of students how to vioate the campus AUP.
Not to mention that this leaves the potentially lowest paid staff with the most access to the systems and probably no personal stake in those systems functionality.
Person B might modify the code during the check and add a backdoor. Person C may or may not build exactly the same code provided by Person B. Person D might deploy it in a way that leaves it open to subversion. Person E may keep a copy of the keys in their pocket.
Realistically, it looks like the only particularly untrusted person here is A, the rest have straightforward outs on how to subvert the control. Protecting any system against its own administative users is really difficult.
Do you trust your DBAs who run the control database, as they could change the settings at will? How about the SAs on the systems the DBAs use, who at a minimum could impersonate the DBAs? How about the network admins who run the network directing the traffic for the control, who could direct traffic to a machine of their choosing or interrupt traffic? The DNS admins who might be able to do the same? The Ceritificate Authority people who could issue a valid cert to anyone?
--Cop, 5th Element, shortly before launching a rocket salvo.
Its hard to justify paying a subscription for a game that pretty much requires keeping another game or book handy to fill in the gaps between interaction.
Has anyone thought to ask if the USPS is storing or providing similiar To/From/Type information for items it handles?
It also supercharges the the electron gun in the monitor such that the image is projected onto the face of the user.
It does help. Most password crackers work by obtaining the password hash somehow and then attempting to figure out an input to the hash that results in the obtained output. Changing the password changes the stored hash and invalidates the work done by the cracker.
I think you are thinking of attempts to brute-force a password by trying to log in repeatedly. In that case it is true that changing the password only helps if the new password is before the current position of the password cracker. However, most authentication systems have protections against brute-forcing, such as locking accounts with excessive failed attempts or enforcing a timeout after every attempt.
Modems have the capability to retrain, which lets them renegotiate the line speed mid-connection in response to line conditions. It doesn't drop carrier, but it does cause a few second pause in traffic.