(usually its combined with your debit or cash withdrawl card, I've never seen a standalone cheque guarantee card)
Sir, your youth is showing
"Standalone" (ie single function) Cheque Guarantee Cards were common back in the 1980's.
--
They're from Mars. You do the English.
Our entire front end is ExtJS. This means MUCH EASIER porting a whole web app based (SIGH) on Grails to something less craptastic like Rails, Django, or anything else that is good at emitting JSON. It's not as easy to get started with... because you're starting with high-level widgets like controls, panels, and similar.
Yes. Because the Internet has reduced the friction of communication to the point where it is impossible to make a profit selling snake oil.
The people running dns servers are probably 0.000001% of internet users....
ummm... Okay... Only that's not what the story was talking about. The story was talking about a user using a different resolver from comcast, rather than their resolver. This has nothing to do with running a dns server. There are a number of reasons to want to use another resolver, including:
the rest are probably just infected machines... is it simply to try to get a handle on worms and malware... If the cost from malware
Sorry... what does using a different resolver have to do with malware? Yeah. I thought so.
The question is *why* do they care about filtering DNS traffic?
The reasons I've heard advanced most frequently to encourage the use of the ISP's caching nameserver are:
This detracts from their profitability only one one of their lines of business - the one where you are the product.
A well trained pilot would know when to trust the computers and when not to. They would also know how to maneuver and react in situations. It's like the pilot that landed his plane in the river after losing an engine to birds. I don't think a computer would have taken that option and not only would it have been likely that all the passengers would have been killed, but bystanders as the planes computer attempted to correct and eventually goes down in a populated street.
This comment looks sensible on the face of it, but I have to disagree with you. I have a pilot license and am familiar with the process of flying. I've never flown a fly-by-wire aircraft, but I've automated a radio broadcast desk - which might not look like it's relevant, but it taught me that "knowing when to trust the computer" is not an obvious state, not in a radio station and I seriously doubt in a cockpit.
For me the final "aha moment" came when the computer was attempting to tell me something useful, but because I was concentrating on a completely different aspect of interacting with it, I completely missed the information. In my case it caused a few seconds of dead air on a radio station, nothing life threatening, but not human obvious either.
The challenge is not "when to trust a computer and when not to" - the challenge is "how do you get the information that the computer is using to the human in such a way that they can manage that input stream in a timely fashion. Stick shakers are an example of making use of an extra input channel.
Accidents in planes are rarely just one thing going wrong, they generally are a whole string of things. A computer in the mix just exacerbates the issue.
In short, it's just some random operator on the 'net whose only real credential is they paid the fee needed to register a domain name (or SSL certificate).
I see. You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity (or identity other than "one who controls domain xxx.com." Perhaps that identity assertions other than those contained in cn or altSubjectName ought to have some meaning. Kinda what EV intends to do... for corp's.
The real problem here is that "trust" is just a very hard problem. It's labor-intensive to establish trust. What should want? Two forms of ID? Credit references? Notarized forms? Personal appearance? Background check investigations?
You are mixing / begging the question on a few concepts here, including:
- granularity of identification
- strength of identification verification
- reputation
Perhaps if these concepts were dealt with in an orderly, separate manner, the question of trust would be more easy to quantify and address.
Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.
Trust but verify. They publish a statement with respect to the policies and procedures that they follow. They are audited to ensure they follow those policies and procedures. It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes.
Please name such a CA which "happily hand over valid certs to anyone with a credit card" and does not "take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf" and which is trusted by the major browsers.
And then, perhaps, explain why you feel this is in _any_ way relevant to a discussion on DNSSEC.
Though, I suppose, this is Slashdot. Why post based on relevant facts rather than baseless, off-topic innuendo?
The basic idea is valid, but the implementation sucks
Umm... Perhaps, but probably not in quite the way you suggest. The current implementation doesn't allow the user to distinguish between certs issued by CAs with smart, rigorous CPS's (you do know what that is right), and certs issued by CAs that only check e-mail to admin@ postmaster@,...
(and can probably only be made to not suck in a closed environment). Some CAs being diligent isn't enough, they all (well, all the ones trusted by any major browser) have to be diligent for the system to work at all.
Yeah. Which is why the major browsers require that the CAs be audited (and if they delegate to resellers the resellers too) to verify that they actually comply with what they say they'll do (their CPS), and that their CPS meets a minimal set of standards.
It seems your argument really boils down to: there has been a race to the bottom on the documented signing policies in order to minimize costs because higher cost, more rigorous validation mechanisms can't be used to differentiate a cert in the marketplace. (Except EV, but that's a whole other story)
My choosing the best CA out there doesn't matter a bit, because they can't do anything to stop the worst from handing a phisher a cert for my domain.
And they can't do anything to stop the best from handing a phisher a cert. However, the browser producers require an audit (which serves as a detective and preventive control) to verify that appropriate and sufficient processes are in place to ensure that a) the CPS is followed and b) the CPS meets a (minimal) set of rules.
Now, all this means that when (as a user) you're presented with a cert [that is not EV], you can be strongly assured that at some point, that cert was issued to someone who could read and respond to mail at an administrative email account for that domain. Is this sufficient for the user? Maybe. If it's a forum site, or a blog site, then probably. If it's an eCommerce or online banking site, probably not.
The browser makers need to allow:
a) Certs with differing validation methods to be differentiated (on a finer granularity than EV / not EV)
b) Client-side policy to be implemented on the basis of that differentiation
In order to arrest this race for the bottom and competition solely on price by the CAs.
Incidentally, both of these can be achieved within the current CA infrastructure...
"Unless your going to pay the auditors to run a compliance check after every change you make"
Not relevant to the case at hand, but:
1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
... 6.3.1 Testing of all security patches, and system and software configuration changes before deployment, including but not limited to the following:
6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)
6.3.1.2 Validation of proper error handling
6.3.1.3 Validation of secure cryptographic storage
6.3.1.4 Validation of secure communications
6.3.1.5 Validation of proper rolebased access control (RBAC)...
6.4 Follow change control
procedures for all changes to system
components. The procedures must
include the following:
6.4.1 Documentation of impact
6.4.2 Management sign-off by appropriate parties
6.4.3 Testing of operational functionality
6.4.4 Back-out procedures...
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
- Installing a web-application firewall in front of public-facing web applications...
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the companyâ(TM)s internal staff.
11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a subnetwork added to the environment, or a web server added to the environment). These penetration tests must include the
following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests
"If the banks [sic] implementation followed PCI-DSS and the auditor did its job with a generally accepted level of precision"
It did not and they did not. Unencrypted storage of PANs, for which a previous audit had failed.
And they failed to do that.
They knew the processor had previously failed an audit because of storage of unencrypted PANs and non-compliant firewalls.
They provided an audit report that said "fully compliant" with CISP.
In the aftermath of the breach, it was discovered that the processor still had non-compliant firewalls and was still storing unencrypted PANs.
It appears that Savvis did not do their job. This will not be the big question at the trial, though.
Merrick was not in contractual privity with Savvis. Savvis was contracted by CardSystems, not Merrick. The issue at trial will likely be whether Savvis owed a duty of care to others that relied on their report (rather than just their client).
I would suggest that if an audit scheme is to have any benefit at all, it must accrue to those that rely on the audit findings. If 3rd parties cannot rely on the audit findings, then there is no reason to conduct the audit in the first place.
Your question of morality is interesting and I'll get to that in a moment, but I'd first like to share the experience in Australia where such a "First Home Buyers" scheme has been operating for some time. At one point it was AUD$21.000 if you were a first home buyer who built a home, I think at the moment it's "only" AUD$14.000. It started a few years ago at AUD$7.000.
From where I'm standing at the side-lines - I'm renting - it distorted the housing market in many unpredictable ways.
In essence it increased the price of all houses because the new builders would build a house with extras "for free", that incorporated the extra funding. Those first home buyers who didn't build got half the funding and that meant that existing home owners increased the value of their home by that amount so they could get the funding too.
Those same houses that were artificially increased in value caused a bubble in the price of housing, because the next owner saw the percentage increase in their area - as a result of the grant - and then they too wanted to see the same return on their investment, causing a self-feedback loop that made house prices increase like mad when really there was nothing to back that up. The result today is that the return on housing has in fact declined for the first time in decades - completely unheard of in most urban areas in the country.
The grant caused cases where the first home buyer was a child and many cases where people with extreme wealth found ways of getting the grant - for example, if the husband always bought their house as a company, then they could qualify for it as a private purchase etc.
By the examples I'm showing you might surmise that the grant brings out the worst in people. It goes directly to morality because it shows that when there is an opportunity to do wrong, a percentage of the population will in fact do so.
I don't think it's a good or sustainable means of stimulation, nor do I think it's appropriate to use aid that is not required. I think that shining the light on those who abuse the system will ultimately cause a return to common sense.
Those around me think it's appropriate to cheat on your taxes - for me, its the same thing. Ultimately you're cheating yourself and the society you are part of. Unemployment benefits, healthcare, education and infrastructure need to be paid for - even if I don't agree with all that is spent, that's the system I choose to be part of. Paying taxes is part of the responsibility that comes with being part of society - otherwise we'd be still living in caves, hunting and dying at age 22.
For me it's summarised in the following quote:
The ultimate result of shielding men from the effects of folly, is to fill the world with fools. --Herbert Spencer
"May your future be limited only by your dreams." -- Christa McAuliffe
