I am still not comfortable with the idea even from an efficiency point of view, that would slow down my web accesses, effectively doubling the latency for any web accesses not in Microsofts white list
The phishing check occurs in parallel with the site download. Odds are, you're going to wait longer for the page to download than the phishing check.
Do you see where the processing load of phish processing for all ie7 users in the world could bog things down globally if Microsoft didn't provide enough processing power at the lookup point. I have yet to be convinced that Microsoft can handle it, especially if they are using their own software to handle the lookup
The windows update site should be sufficient to demonstrate that Microsoft does have the resources to handle a large load of traffic. Only sites NOT in the whitelist are sent -- most traffic won't hit their servers, reducing the effective load. Finally, I personally have noticed any performance related problems since I started using it.
I don't think my idea about the URL hashing was that far off, at the very least they could resolve the url to an IP number which could be kept on the black list. What is wrong with that?
It would result in every page on geocities being flagged as a phishing site. (not that I especially like geocities or think that their content is worth vieweing, but you should be able to grasp the general problem posed by your suggestion)
That might have the effect of causing trouble for an ISP who was hosting a phishing site, but that would motivate them to shut down the phishing site and appply for clemency from Microsoft.
No, it would motivate them to sue the crap out of Microsoft. You're looking at this as if it were a rather static problem. It isn't; as I said before, the typical lifetime of a phishing site is very short -- typically 1 or 2 days. ISPs already actively shut down phishing sites and don't need additional "encouragement" to do so.
I think giving Microsoft the ability to unilaterally block ie7 access for all internet users to a site is a lot of power, don't you think
Wait a minute; you don't trust Microsoft with your URL path, but you trust them enough to censor the internet for you?
To summarize: * IE has a list of whitelisted sites which is stored locally * If the site you are visiting is in the whitelist, nothing is transmitted to Microsoft * If the site you are visiting is not in the whitelist, the URL path is transmitted to Microsoft to check against a blacklist (the URL path does not include parameters)
Given the short lifetime and large quantity of phishing websites, maintaining a local blacklist isn't practicle -- it wouldn't be updated as fast as a centralized list and it would be too large to transmit to modem users. Additionally, a hash based "URL" check is useless for a phishing filter given the infinite number of ways an URL can be constructed.
A healthy dose of paranoia is good and all, but quite frankly if Microsoft was trying to obtain your browsing history for some devious purpose there are a number of other, easier ways for them to do so.
If it took 2 weeks for you to get XP up and running, you weren't trying very hard. If your PS2 hardware wasn't "recognized", there is something VERY wrong with your setup, not windows.
My last system was a MCE PC built from the following parts:
- AMD 3800+ X2 processor - 2 x 1gb DDR2-800 ram (Corsair, 5-5-5-8) - 2 x 500gb SATA drives (Western Digital RE2 WD5000YS) - ASUS M2NPV-VM GF6150 AM2 mobo - NVidia 7600GS based video card w/256MB ram (fanless board made by xfx) - NVidia dual tv capture card
Install of XP took roughly 30 minutes. Windows update took about an hour (that includes time taken installing WHQL drivers for everything on the mobo + video). Took 2 minutes to stick in the driver disk for the VFD display and install it. Took 10 minutes to download the latest drivers for the tuner card and install it. Took another 5 minutes to install the nvidia dvd decoder package. It took me 10 minutes to find the underscan settings in the nvidia display driver and tweak those.
Done.
Total time: less than 2 hours.
If you wanted to be adventurous, you could spend another 5 minutes and install the AMD cool 'n quiet driver (reduce power consumption when idle).
If it weren't a MCE install, it would have taken me less than 1.5 hours (MCE involves some disk swapping and updates not required for a normal xp install).
It took me far longer to troubleshoot a stability problem than installing XP (my ram wouldn't run at spec in dual channel mode; each stick worked fine single channel).
There are tons of products with a cost directly linked to the price of oil. The fact that they exclude the cost of gas at the pump doesn't mean that oil has no impact on the "core" inflation metrics.
Google "kernel patch protection" if you're interesting in looking up technical details. Somewhere out there you'll discover details regarding how this is actually implemented in x64 XP/2k3.
There is actual logic in the 64bit windows kernel which is designed to detect modifications to internal kernel structures. If a change is detected, it crashes the box (calls bugcheckex).
The kind of structure we're talking about are rather static, and no API currently exists to manipulate those structures -- the changes are done as part of other (legitimate) operations.
Actually, the cost of gasoline is a core component in measuring inflation.
One of the things that constantly amuses me are the print articles comparing the cost of gasole in the late 70's to now, using inflation adjusted figures. Of course it isn't going to look like the cost of gas has risen much -- you essentially just performed a calculation designed to factor out the changes in gas price over time...
Email clients are not what SenderID is for: it's for mail servers, to reject the spam before it even gets into the user's cue.
SenderID can be implemented on both mail servers and clients.
Unfortunately SenderID is not only patented, the Microsoft license prevents other people from modifying it for other uses. This means it should not and cannot be used in Sendmail, Postfix, or other open source MTA's due to license restrictions.
SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange rules about encryption being a material of war.
SenderID has no cryptography. You're thinking DomainKeys.
SenderID is also fundamentally broken: SPF rejects spam messages in a way that is very lightweight and free to implement (publish a TXT record in your domain's DNS), and rejects the message before its contents are even sent, based on the "FROM" line used for email bounces.
Incorrect. Both SenderID and SPF are based off of DNS TXT records. The primary difference between the two is that SenderID validates that the FROM field has not been forged, while SPF validates that the return path has not been forged.
SenderID requires purchased keys from Microsoft, and requires the MTA to accept the email message to process the SenderID key, which seriously burdens the server.
SenderID basically has nothing to do with SPF or anti-spam: it has to do with selling keys for bulk emailers, legitimate or not, to send bulk email while avoiding anti-spam messages. Its presence in a message is actually a very powerful sign that the message is spam, just as those "Haiku" messages in email headers used to be.
SenderID has no cryptography. You purchase nothing from Microsoft. You're thinking DomainKeys.
Unfortunately, the creators of SPF accepted Microsoft sponsorship and involvement with SenderID to get Microsoft support, integrating SPF-like features into Hotmail and other Microsoft tools in order to get a larger user base, but unfortunately accepting a corrupt influence that has actively hindered the acceptance of SPF.
Blah blah blah, insert Microsoft is teh big evil rant here. You should learn what you're talking about before complaining about something it doesn't do.
Regulating the envelope sender is rather useless. Yes, spammers typically forge the sender as well as the from fields. However, a "valid" sender can still forge the from address.
Not much. It basically involves a DNS lookup, parsing of some string information, and some rule-based comparisons derrived from the parsing. Probably a couple days worth of dev work to read up on the RFC (http://www.ietf.org/rfc/rfc4406.txt?number=4406), implement it, and test the core logic. Can't really say how long it would take to integrate into your mail client of choice.
I would be. No company wants to make product annoucements on joe schmuck's blog and no sane PR department wants to spend in spin control mode after said leak. Not to mention that leaks give a company's competitors a leg up on future events (the less your competition knows about products in development the better).
Really? Is there some sort of autism-related focus on cable TV I somehow missed during the last 20 years? Just about everything I've seen on the subject has been broadcast on network TV or PBS...
Certainly. However, the potential that other factors may exist does not eliminate the potential of the factor highlighted in this study.
How about the increased understanding of and accurate diagnosis of autism and autism-related disorders around that time?
Certainly a reasonable hypothesis, however no data exists to back it up. Care to demonstrate that the state of accurate diagnosis of autism and autism related disorders advanced with and mirrored only the rollout of cable-tv?
How about the repetitive nature of television programming, especially kids shows, appealing to autistics as a source of consistency and comfort?
This may be true. However, autistic children didn't create the demand for cable in those areas...
How about the fact that the places getting cable were also the places getting elevated concentrations of geeks, who seem to have genetic quirks that have this tendancy to result in autism-like disorders? Could that POSSIBLY have ANYTHING to do with a rise in autism in Washington, _Oregon_, and *CALIFORNIA*?
Wow, now there is an unsubstantiated leep if I've ever seen one. Geeks have genetic quirks? Smart people are automatically genetically defective? It would be about as fair and accurate to replace "geek" with "Democrat".
Except 100% of the children who do not have Autism also consume water regularly. It would be fair to say that there is no correlation between water consumption and Autism.
Those APIs are still only accessable to a driver running in kernel space. The only thing prevented (as opposed to before) was hooking kernel syscalls and manipulating other undocumented kernel data structures.
Microsoft's (and other 3rd party AV) solutions use the same tools available to McAfee and Symantec. Symantec and McAfee just didn't want to spend any effort changing their code so that it used a documented api.
Hello World maybe. Your supposition depends on the human brain to always evaluate complex logical conditions correctly, 100% of the time. That doesn't happen in the real world.
Slashdot Mirror
I am still not comfortable with the idea even from an efficiency point of view, that would slow down my web accesses, effectively doubling the latency for any web accesses not in Microsofts white list
The phishing check occurs in parallel with the site download. Odds are, you're going to wait longer for the page to download than the phishing check.
Do you see where the processing load of phish processing for all ie7 users in the world could bog things down globally if Microsoft didn't provide enough processing power at the lookup point. I have yet to be convinced that Microsoft can handle it, especially if they are using their own software to handle the lookup
The windows update site should be sufficient to demonstrate that Microsoft does have the resources to handle a large load of traffic. Only sites NOT in the whitelist are sent -- most traffic won't hit their servers, reducing the effective load. Finally, I personally have noticed any performance related problems since I started using it.
I don't think my idea about the URL hashing was that far off, at the very least they could resolve the url to an IP number which could be kept on the black list. What is wrong with that?
It would result in every page on geocities being flagged as a phishing site. (not that I especially like geocities or think that their content is worth vieweing, but you should be able to grasp the general problem posed by your suggestion)
That might have the effect of causing trouble for an ISP who was hosting a phishing site, but that would motivate them to shut down the phishing site and appply for clemency from Microsoft.
No, it would motivate them to sue the crap out of Microsoft. You're looking at this as if it were a rather static problem. It isn't; as I said before, the typical lifetime of a phishing site is very short -- typically 1 or 2 days. ISPs already actively shut down phishing sites and don't need additional "encouragement" to do so.
I think giving Microsoft the ability to unilaterally block ie7 access for all internet users to a site is a lot of power, don't you think
Wait a minute; you don't trust Microsoft with your URL path, but you trust them enough to censor the internet for you?
You should read about how the phishing filter works before freaking out:4 .aspx
* http://blogs.msdn.com/ie/archive/2005/09/09/46320
To summarize:
* IE has a list of whitelisted sites which is stored locally
* If the site you are visiting is in the whitelist, nothing is transmitted to Microsoft
* If the site you are visiting is not in the whitelist, the URL path is transmitted to Microsoft to check against a blacklist (the URL path does not include parameters)
Given the short lifetime and large quantity of phishing websites, maintaining a local blacklist isn't practicle -- it wouldn't be updated as fast as a centralized list and it would be too large to transmit to modem users. Additionally, a hash based "URL" check is useless for a phishing filter given the infinite number of ways an URL can be constructed.
A healthy dose of paranoia is good and all, but quite frankly if Microsoft was trying to obtain your browsing history for some devious purpose there are a number of other, easier ways for them to do so.
It isn't even that bad. Gold accounts get a time limited exclusive -- Silver users still get access to the content a week later...
I'd be willing to bet that the PS2 continues to outsell the PS3 in Japan for another 2 years.
If it took 2 weeks for you to get XP up and running, you weren't trying very hard. If your PS2 hardware wasn't "recognized", there is something VERY wrong with your setup, not windows.
My last system was a MCE PC built from the following parts:
- AMD 3800+ X2 processor
- 2 x 1gb DDR2-800 ram (Corsair, 5-5-5-8)
- 2 x 500gb SATA drives (Western Digital RE2 WD5000YS)
- ASUS M2NPV-VM GF6150 AM2 mobo
- NVidia 7600GS based video card w/256MB ram (fanless board made by xfx)
- NVidia dual tv capture card
Install of XP took roughly 30 minutes. Windows update took about an hour (that includes time taken installing WHQL drivers for everything on the mobo + video). Took 2 minutes to stick in the driver disk for the VFD display and install it. Took 10 minutes to download the latest drivers for the tuner card and install it. Took another 5 minutes to install the nvidia dvd decoder package. It took me 10 minutes to find the underscan settings in the nvidia display driver and tweak those.
Done.
Total time: less than 2 hours.
If you wanted to be adventurous, you could spend another 5 minutes and install the AMD cool 'n quiet driver (reduce power consumption when idle).
If it weren't a MCE install, it would have taken me less than 1.5 hours (MCE involves some disk swapping and updates not required for a normal xp install).
It took me far longer to troubleshoot a stability problem than installing XP (my ram wouldn't run at spec in dual channel mode; each stick worked fine single channel).
There are tons of products with a cost directly linked to the price of oil. The fact that they exclude the cost of gas at the pump doesn't mean that oil has no impact on the "core" inflation metrics.
Google "kernel patch protection" if you're interesting in looking up technical details. Somewhere out there you'll discover details regarding how this is actually implemented in x64 XP/2k3.
There is actual logic in the 64bit windows kernel which is designed to detect modifications to internal kernel structures. If a change is detected, it crashes the box (calls bugcheckex).
The kind of structure we're talking about are rather static, and no API currently exists to manipulate those structures -- the changes are done as part of other (legitimate) operations.
Since when is implementing logic which prevents mucking with internal kernel structures "security by obscurity?"
Actually, the cost of gasoline is a core component in measuring inflation.
One of the things that constantly amuses me are the print articles comparing the cost of gasole in the late 70's to now, using inflation adjusted figures. Of course it isn't going to look like the cost of gas has risen much -- you essentially just performed a calculation designed to factor out the changes in gas price over time...
Email clients are not what SenderID is for: it's for mail servers, to reject the spam before it even gets into the user's cue.
SenderID can be implemented on both mail servers and clients.
Unfortunately SenderID is not only patented, the Microsoft license prevents other people from modifying it for other uses. This means it should not and cannot be used in Sendmail, Postfix, or other open source MTA's due to license restrictions.
Wrong: http://www.microsoft.com/interop/osp/default.mspx
SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange rules about encryption being a material of war.
SenderID has no cryptography. You're thinking DomainKeys.
SenderID is also fundamentally broken: SPF rejects spam messages in a way that is very lightweight and free to implement (publish a TXT record in your domain's DNS), and rejects the message before its contents are even sent, based on the "FROM" line used for email bounces.
Incorrect. Both SenderID and SPF are based off of DNS TXT records. The primary difference between the two is that SenderID validates that the FROM field has not been forged, while SPF validates that the return path has not been forged.
SenderID requires purchased keys from Microsoft, and requires the MTA to accept the email message to process the SenderID key, which seriously burdens the server.
SenderID basically has nothing to do with SPF or anti-spam: it has to do with selling keys for bulk emailers, legitimate or not, to send bulk email while avoiding anti-spam messages. Its presence in a message is actually a very powerful sign that the message is spam, just as those "Haiku" messages in email headers used to be.
SenderID has no cryptography. You purchase nothing from Microsoft. You're thinking DomainKeys.
Unfortunately, the creators of SPF accepted Microsoft sponsorship and involvement with SenderID to get Microsoft support, integrating SPF-like features into Hotmail and other Microsoft tools in order to get a larger user base, but unfortunately accepting a corrupt influence that has actively hindered the acceptance of SPF.
Blah blah blah, insert Microsoft is teh big evil rant here. You should learn what you're talking about before complaining about something it doesn't do.
Regulating the envelope sender is rather useless. Yes, spammers typically forge the sender as well as the from fields. However, a "valid" sender can still forge the from address.
Not much. It basically involves a DNS lookup, parsing of some string information, and some rule-based comparisons derrived from the parsing. Probably a couple days worth of dev work to read up on the RFC (http://www.ietf.org/rfc/rfc4406.txt?number=4406), implement it, and test the core logic. Can't really say how long it would take to integrate into your mail client of choice.
The game is fun. The story could be written on a single sheet of toilet paper.
I would be. No company wants to make product annoucements on joe schmuck's blog and no sane PR department wants to spend in spin control mode after said leak. Not to mention that leaks give a company's competitors a leg up on future events (the less your competition knows about products in development the better).
They weren't exactly able to keep it secret though, were they?
Seriously, when was the last time Microsoft made a product announcement that wasn't leaked weeks ahead of time?
Nobody is crying bloody murder about PFS because they're too concerned about not being able to use music they've purchased from iTunes...
...you'd be looking at something made by iRiver.
Hmmm ... bug in slashdot? The "someone replied to your post" message linked to your post...
Really? Is there some sort of autism-related focus on cable TV I somehow missed during the last 20 years? Just about everything I've seen on the subject has been broadcast on network TV or PBS...
Last time I checked, I said absolutely nothing about correlation. Moron.
Could there POSSIBLY be other factors at work?
Certainly. However, the potential that other factors may exist does not eliminate the potential of the factor highlighted in this study.
How about the increased understanding of and accurate diagnosis of autism and autism-related disorders around that time?
Certainly a reasonable hypothesis, however no data exists to back it up. Care to demonstrate that the state of accurate diagnosis of autism and autism related disorders advanced with and mirrored only the rollout of cable-tv?
How about the repetitive nature of television programming, especially kids shows, appealing to autistics as a source of consistency and comfort?
This may be true. However, autistic children didn't create the demand for cable in those areas...
How about the fact that the places getting cable were also the places getting elevated concentrations of geeks, who seem to have genetic quirks that have this tendancy to result in autism-like disorders? Could that POSSIBLY have ANYTHING to do with a rise in autism in Washington, _Oregon_, and *CALIFORNIA*?
Wow, now there is an unsubstantiated leep if I've ever seen one. Geeks have genetic quirks? Smart people are automatically genetically defective? It would be about as fair and accurate to replace "geek" with "Democrat".
Except 100% of the children who do not have Autism also consume water regularly. It would be fair to say that there is no correlation between water consumption and Autism.
Those APIs are still only accessable to a driver running in kernel space. The only thing prevented (as opposed to before) was hooking kernel syscalls and manipulating other undocumented kernel data structures.
Microsoft's (and other 3rd party AV) solutions use the same tools available to McAfee and Symantec. Symantec and McAfee just didn't want to spend any effort changing their code so that it used a documented api.
Hello World maybe. Your supposition depends on the human brain to always evaluate complex logical conditions correctly, 100% of the time. That doesn't happen in the real world.