May all of OS X's "massive holes" be so insignificant to me.
The most concerning is the TIFF vulnerability; fortunately that's a 10.5 issue, not a 10.6 issue. The second most concerning is the SSL vulnerability, but I've not trusted SSL alone for a while now. Still tossing up throwing out Firefox's trust anchor code and replacing it with an SSH style known-hosts setup... but the FF code is a total dog to work with. And I don't care. Mostly, I guess, I don't care. Thank you, my bank, for two-factor authentication.
More memory is cheaper than more developer time. I'd be disappointed in my developers if they spent their time optimising a program's memory usage to get it to fit in 512kb instead of putting in a P.O. for another 1GB in the machine.
Just don't ask the Mythbusters to test the myth that the LHC will destroy the Earth. After they demonstrate that the popular, but stupid, misconception is busted, they will keep adding explosives until they manage to get the job done, just to satisfy our explosion lust.
(I hear Michael Bay is directing the next season!)
Remember, of course, that if you only work just hard enough to not get fired, you'll only be paid just enough to not want to quit.
The general idea that your main motivation for working well is loyalty to the company seems a bit off, to me. The first reason to work well is you feel better when you do. It's very satisfying to be proud of the work you've done, and that can have an impact on every aspect of your life. It's extremely helpful if your managers recognise your good work, too, but motivation is not a one-way street, and the more self-sufficient you are with respect to motivation, the better you'll do generally. You can't start your own business if you require external motivators, for instance!
The next reason to work well is that you have loyalty to your immediate manager. If they're doing their job well, they'll be supporting your professional development, representing you to higher management, shielding you from the shit spattering out of the fan, and providing you the autonomy, environment, and feedback to enable you to do the best you can. If you're not delivering to your manager, your manager won't be delivering to their manager, and it's going to adversely affect them.
(If your immediate manager doesn't give a shit, well, have fun riding the cushy job wave, but remember reason #1 - maybe you should manage upwards a little, or perhaps look for promotion opportunities or a new job).
Mark me down as hypocrite for posting this while at work, of course.:-)
Software cannot erase the contents of a modern hard drive.
If you're trying to erase a single file, you do not know where it has always been stored. You may be able to find where its data is now, but that doesn't mean it's always lived in those sectors; it may be in your swap space, it may still be in sectors that were used for a temporary file, it may have been defragmented and moved around.
Your OS caches writes; let's assume your software is smart enough to bypass those caches.
Your hard drive firmware caches writes; your software can do nothing about that.
Your hard drive firmware remaps sectors transparently; software can't even detect it happening.
Your hard drive write head only writes to the centre of the track, leaving ghosts of past data at the edges of the track.
Your hard drive read head uses a coarse binary measure, but sensitive instruments can get the percent of a percent of a percent of multiple writes past even from the centre of the track.
If you find some way to bypass all of these problems, you still need to worry about the bit encoding scheme used by the drive firmware. A recent drive (ie, something you got in the last five years) can probably be reasonably well erased with a random pattern, but to be sure, you should be writing out the data patterns that best erase data on RLL encoded drives.
But even after all that, sufficiently sensitive analysis equipment can still find ghosts in your machine.
Degaussing is also ineffective. If you apply enough power to wipe the magnetisation pattern on the drive, you also wipe the sector markers, sync fields, ID fields, and ECC information. And probably still don't apply enough power to completely bust the ghosts: degaussers are measured at the peak, and the peak may not align with your platter.
Oh, and fire doesn't work.
As far as I can tell, the only way to actually be sure is to use strong encryption for every write to the disk, and forget the key: if you never store the data in the first place, it can't be recovered.
What you do about GW depends on its cause. If you accept GW and all its dire consequences then a reasonable course of action is to look to ways to mitigate some of those consequences, but one should also be looking at ways to slow, stop or reverse GW too. And then it matters what the cause is.
(The cynic in me also says that debating the cause also stalls any action without needing to directly debate the truth of the effect).
Unfounded fear, doom and gloom, for the most part.
Homoglyphs are not a problem that somehow escaped the attention of the tens of thousands of people whose work contributes indirectly to ICANN. Top level domain registries are required to use a single script per domain, so you can't register a Greek and Latin 'A' in the same label. Mathematical symbols, including 1D694, are never allowed.
Multiple representations of the same character are already taken care of in the IDN ToASCII() operation; they are case-folded, order of accents is fixed, and composed and decomposed variants map to the same result.
There's been so much attention given to it, at this stage, that the riskiest form of domain name is the plain old ASCII domain name. We are on sIashdot.org. No, wait, s1ashdot.org. Or slashdot.org. (Your font may show these distinctly; mine shows upper-i quite distinctly but one and lower-l are nearly indistinguishable).
You're also always going to be susceptible to tricks like slashdot.org--comments.pl.sid.142242.op.Reply.threshold.0.example.org, depending on how switched on you are at the time. IDNs don't alter the potential for that at all. You're vulnerable to CSS fonts specifying a custom font file in which "example.org" renders as "citibank.com". And you're still vulnerable to a Kaminsky DNS attack, since DNSSEC is not enabled at the root, and many resolvers don't error on missing signatures in any case. Again, IDN won't alter that condition.
A list of names doesn't seem to have much potential to be interesting. The phone book is pretty dull to read, and that has addresses and phone numbers as well as names!
Did you read the article? This was done to increase Playboy's sagging sales.
Right, there's Playboy's motivation for it. Not sure that Fox/Groening would give a shit about Playboy's sales, though, and there'll be two signatures on the contract.
Yes. It doesn't help because few users and server admins understand the difference, and for those that do, it's too dilute a message. It further doesn't help because even if you configured your browser to reject any non-EV certs you've just hit a magic reset button, and you haven't solved the fundamental problem that CAs are not accountable for what they sign. (Imagine if you remove an operator's EV status, how long will it take to propagate that change to all browsers?)
I'd disagree with "SSL was stupid to start with." SSL is just fine. x509 is, likewise, just fine. Both are technologies that are well suited to their particular roles.
The use of x509 as a trust model for HTTPS, that was stupid to start with. x509 solves the problem of hierarchical trust. The web is not hierarchical. Fail.
This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise. If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you. To clarify, "Microsoft Necessary Claims" are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement the required portions (which also include the required elements of optional portions) of the Covered Specification that are described in detail and not those merely referenced in the Covered Specification.
You mean, something like RFC 4255, the SSH key RRTYPE? Such a beast has been proposed in the IETF dnsext WG, current status seems to be withdrawn pending further work, as of July this year, but I haven't seen it re-submitted. The agenda for IETF 76 in early November isn't set yet, but alas, both pkix and v6ops conflict with dnsext, so I am likely to miss that session.
(Might be worth trawling the mail archive for dnsext on this subject here).
Ahh, you've discovered why SSL on the web is fundamentally broken -- CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
The monopoly dollar is currently pegged to the US dollar, so unless Hasbro changes their virtual economy to peg a different currency, float, or use a basket that isn't dominated by the US dollar, that will never happen.
I hadn't heard anything on oil reserves; 2050 is interesting, seems like the time is right to be experimenting with alternate energy sources, kind of like we are:-) I kinda guessed cutting edge research would be generating sensationalist stories, but big media's only out to expose more viewers to attached advertising anyway.
In 2003, RIPE NCC noted that estimates fell around 2012. I will grant you that 2003 is not 12 years ago, only 6, but that was a result on the first page of google for "IPv4 run-out estimates over time."
I'm unfamiliar with oil reserves and cold fusion research, but I'd like to see your justifications for those claims, too:-)
Slashdot Mirror
May all of OS X's "massive holes" be so insignificant to me.
The most concerning is the TIFF vulnerability; fortunately that's a 10.5 issue, not a 10.6 issue. The second most concerning is the SSL vulnerability, but I've not trusted SSL alone for a while now. Still tossing up throwing out Firefox's trust anchor code and replacing it with an SSH style known-hosts setup... but the FF code is a total dog to work with. And I don't care. Mostly, I guess, I don't care. Thank you, my bank, for two-factor authentication.
More memory is cheaper than more developer time. I'd be disappointed in my developers if they spent their time optimising a program's memory usage to get it to fit in 512kb instead of putting in a P.O. for another 1GB in the machine.
Leaking memory is a different issue, of course.
I think you're looking for "money implies poverty."
(Thanks to Iain M. Banks).
Just don't ask the Mythbusters to test the myth that the LHC will destroy the Earth. After they demonstrate that the popular, but stupid, misconception is busted, they will keep adding explosives until they manage to get the job done, just to satisfy our explosion lust.
(I hear Michael Bay is directing the next season!)
3. Daylight Saving Time.
I.. it just...
No. Must not start ranting.
Remember, of course, that if you only work just hard enough to not get fired, you'll only be paid just enough to not want to quit.
The general idea that your main motivation for working well is loyalty to the company seems a bit off, to me. The first reason to work well is you feel better when you do. It's very satisfying to be proud of the work you've done, and that can have an impact on every aspect of your life. It's extremely helpful if your managers recognise your good work, too, but motivation is not a one-way street, and the more self-sufficient you are with respect to motivation, the better you'll do generally. You can't start your own business if you require external motivators, for instance!
The next reason to work well is that you have loyalty to your immediate manager. If they're doing their job well, they'll be supporting your professional development, representing you to higher management, shielding you from the shit spattering out of the fan, and providing you the autonomy, environment, and feedback to enable you to do the best you can. If you're not delivering to your manager, your manager won't be delivering to their manager, and it's going to adversely affect them.
(If your immediate manager doesn't give a shit, well, have fun riding the cushy job wave, but remember reason #1 - maybe you should manage upwards a little, or perhaps look for promotion opportunities or a new job).
Mark me down as hypocrite for posting this while at work, of course. :-)
Software cannot erase the contents of a modern hard drive.
If you're trying to erase a single file, you do not know where it has always been stored. You may be able to find where its data is now, but that doesn't mean it's always lived in those sectors; it may be in your swap space, it may still be in sectors that were used for a temporary file, it may have been defragmented and moved around.
Your OS caches writes; let's assume your software is smart enough to bypass those caches.
Your hard drive firmware caches writes; your software can do nothing about that.
Your hard drive firmware remaps sectors transparently; software can't even detect it happening.
Your hard drive write head only writes to the centre of the track, leaving ghosts of past data at the edges of the track.
Your hard drive read head uses a coarse binary measure, but sensitive instruments can get the percent of a percent of a percent of multiple writes past even from the centre of the track.
If you find some way to bypass all of these problems, you still need to worry about the bit encoding scheme used by the drive firmware. A recent drive (ie, something you got in the last five years) can probably be reasonably well erased with a random pattern, but to be sure, you should be writing out the data patterns that best erase data on RLL encoded drives.
But even after all that, sufficiently sensitive analysis equipment can still find ghosts in your machine.
Degaussing is also ineffective. If you apply enough power to wipe the magnetisation pattern on the drive, you also wipe the sector markers, sync fields, ID fields, and ECC information. And probably still don't apply enough power to completely bust the ghosts: degaussers are measured at the peak, and the peak may not align with your platter.
Oh, and fire doesn't work.
As far as I can tell, the only way to actually be sure is to use strong encryption for every write to the disk, and forget the key: if you never store the data in the first place, it can't be recovered.
Oh, won't somebody think of the tentacles!
Timescale matters, too :-)
What you do about GW depends on its cause. If you accept GW and all its dire consequences then a reasonable course of action is to look to ways to mitigate some of those consequences, but one should also be looking at ways to slow, stop or reverse GW too. And then it matters what the cause is.
(The cynic in me also says that debating the cause also stalls any action without needing to directly debate the truth of the effect).
Yes, but which IE version should you target, seeing as how they all have different bugs?
Fear, doom and gloom.
Unfounded fear, doom and gloom, for the most part.
Homoglyphs are not a problem that somehow escaped the attention of the tens of thousands of people whose work contributes indirectly to ICANN. Top level domain registries are required to use a single script per domain, so you can't register a Greek and Latin 'A' in the same label. Mathematical symbols, including 1D694, are never allowed.
Multiple representations of the same character are already taken care of in the IDN ToASCII() operation; they are case-folded, order of accents is fixed, and composed and decomposed variants map to the same result.
There's been so much attention given to it, at this stage, that the riskiest form of domain name is the plain old ASCII domain name. We are on sIashdot.org. No, wait, s1ashdot.org. Or slashdot.org. (Your font may show these distinctly; mine shows upper-i quite distinctly but one and lower-l are nearly indistinguishable).
You're also always going to be susceptible to tricks like slashdot.org--comments.pl.sid.142242.op.Reply.threshold.0.example.org, depending on how switched on you are at the time. IDNs don't alter the potential for that at all. You're vulnerable to CSS fonts specifying a custom font file in which "example.org" renders as "citibank.com". And you're still vulnerable to a Kaminsky DNS attack, since DNSSEC is not enabled at the root, and many resolvers don't error on missing signatures in any case. Again, IDN won't alter that condition.
A list of names doesn't seem to have much potential to be interesting. The phone book is pretty dull to read, and that has addresses and phone numbers as well as names!
N...o? I guess everyone who wanted to probably has. She's not bad, if you're into blueheads, but she's no Bugs Bunny in drag.
Right, there's Playboy's motivation for it. Not sure that Fox/Groening would give a shit about Playboy's sales, though, and there'll be two signatures on the contract.
Yes. It doesn't help because few users and server admins understand the difference, and for those that do, it's too dilute a message. It further doesn't help because even if you configured your browser to reject any non-EV certs you've just hit a magic reset button, and you haven't solved the fundamental problem that CAs are not accountable for what they sign. (Imagine if you remove an operator's EV status, how long will it take to propagate that change to all browsers?)
I'd disagree with "SSL was stupid to start with." SSL is just fine. x509 is, likewise, just fine. Both are technologies that are well suited to their particular roles.
The use of x509 as a trust model for HTTPS, that was stupid to start with. x509 solves the problem of hierarchical trust. The web is not hierarchical. Fail.
Does this help?
The relevant portion of the promise would be:
Emphasis mine.
No, it's easy.
... just get added to their payroll.
You mean, something like RFC 4255, the SSH key RRTYPE? Such a beast has been proposed in the IETF dnsext WG, current status seems to be withdrawn pending further work, as of July this year, but I haven't seen it re-submitted. The agenda for IETF 76 in early November isn't set yet, but alas, both pkix and v6ops conflict with dnsext, so I am likely to miss that session.
(Might be worth trawling the mail archive for dnsext on this subject here).
Ahh, you've discovered why SSL on the web is fundamentally broken -- CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
The monopoly dollar is currently pegged to the US dollar, so unless Hasbro changes their virtual economy to peg a different currency, float, or use a basket that isn't dominated by the US dollar, that will never happen.
... but I see your point! :-)
Do you know how hard it is to have 12 or 13 million people hold still while you do a quick head-count?
I hadn't heard anything on oil reserves; 2050 is interesting, seems like the time is right to be experimenting with alternate energy sources, kind of like we are :-) I kinda guessed cutting edge research would be generating sensationalist stories, but big media's only out to expose more viewers to attached advertising anyway.
[citation needed]
In 2003, RIPE NCC noted that estimates fell around 2012. I will grant you that 2003 is not 12 years ago, only 6, but that was a result on the first page of google for "IPv4 run-out estimates over time."
I'm unfamiliar with oil reserves and cold fusion research, but I'd like to see your justifications for those claims, too :-)